Search Results

Search found 120 results on 5 pages for 'rebase'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 2/5 | < Previous Page | 1 2 3 4 5  | Next Page >

  • How to rebase one Git repository onto another one?

    - by kroimon
    Hi there! I had one Git repository (A) which contains the development of a project until a certain point. Then I lost the USB stick this repo A was on. Luckily I had a backup of the latest commit, so I could create a new repository (B) later where I imported the latest project's state and continue development. Now I recovered that lost USB stick, so I have two Git repositories. I think I just have to rebase repo B onto repo A somehow, but I have no idea how to do that, maybe using fetch/pull and rebase? Thanks in advance for your help!

    Read the article

  • is there a way to recursively merge then rebase all branches?

    - by yao jiang
    Let's say I have git repo like this: master webapp-1252 webapp-1285 webapp-1384 webapp-1433 webapp-1524 webapp-824 x_____jira_ x_webapp-11 x_webapp-11 x_webapp-11 z_____jira_ I've updated all of them and ready to push them all to svn or something. Then someone makes a quick change that would require me to basically go through all of them to merge etc. Is there a shortcut to go through all the branches I have here, merge them with whatever work that was fetched, then rebase them?

    Read the article

  • Do I need to perform a commit after a rebase?

    - by Benjol
    I've just rebased a feature branch onto another feature branch (in preparation for rebasing everything to the head of my master), and it involved quite a few tricky merge resolutions. Is the rebase automatically saved as a commit somewhere? Just where do those modifications live? I can't see anything in gitk, or git log --oneline. (Same question for when I merge back my branch after rebasing.)

    Read the article

  • What does it mean when git pull causes a conflict but git pull --rebase doesn't?

    - by Jason Baker
    I'm pulling from a repository that only I have access to. As far as I know, I've only pushed to it from one repository. A couple of times, I've pulled from it and gotten this: To [email protected]:tsched_dev.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to '[email protected]:tsched_dev.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Generally, that just means that I have to do a git pull (although all the changes should be fast-forwardable). When I do a git pull, I get conflicts. If I do a git pull --rebase, it works fine. What am I doing wrong?

    Read the article

  • git merge, git rebase none seems to work, should I delete my github fork and refork from the upstream master?

    - by Joan Yin
    I have to confess my github sins. 4 month ago, I forked a upstream repo, without knowing much of git and pull request, i did some work on master branch locally, later on I realized the mistake, created a new branch, and squashed the changes to one and successfully send a PR later from that branch. the PR is accepted, and I moved on. Now I need to submit another PR. But my master branch is so messed up, when I do merge, or rebase, there are so many mistakes. I probably committed a few more sins this morning. I have been battling this for the whole morning now. so it comes to the point that I want a clean start. Can I delete the github fork and refork from the upstream master? What are the correct steps?

    Read the article

  • git rebse onto remote updates

    - by Blake Chambers
    I work with a small team that uses git for source cod management. Recently, we have been doing topic branches to keep track of features then merging them into master locally then pushing them to a central git repository on a remote server. This works great when no changes have been made in master: I create my topic branch, commit it, merge it into master, then push. Hooray. However, if someone has pushed to origin before i do, my commits are not fast-forward. Thus a merge commit ensues. This also happens when a topic branch needs to merge with master locally to ensure my changes work with the code as of now. So, we end up with merge commits everywhere and a git log rivaling a friendship bracelet. So, rebasing is the obvious choice. What I would like is to: create topic branches holding several commits checkout master and pull (fast-forward because i haven't committed to master) rebase topic branches onto the new head of master rebase topics against master(so the topics start at masters head), bringing master up to my topic head My way of doing this currently is listed below: git checkout master git rebase master topic_1 git rebase topic_1 topic_2 git checkout master git rebase topic_2 git branch -d topic_1 topic_2 Is there a faster way to do this?

    Read the article

  • Mercurial/Intellij9 hg4idea Error: cannot update with applied MQ patches, please use rebase

    - by johnrock
    I am getting the following error when trying to update my project from Intellij 9 using hg4idea: Error: cannot update with applied MQ patches, please use rebase What does this mean? I have not created or applied any patches as far as I know. I can pull changes from my remote repository but cannot update the project from within Intellij. I can call hg update from the command line and that works fine. Thanks

    Read the article

  • git rebase conflict was caused by which commit

    - by dorelal
    when I do git rebase master I get conflict sometimes. And sometimes it becomes very difficult to track down an issue even with error messages. It would be a real help if I could find out which commit git is trying to reapply and is causing conflict. How can I find out which commit is causing the conflict?

    Read the article

  • Git svn - no changes, no branches (except master), rebase/info is not working

    - by ex3v
    I know that similar questions were asked before, but I think my is a little bit different, so please don't point me to existing threads. I'm migrating our old svn repo to git. I did git svn clone path --authors-file abc.txt and everything seemend legit to me. Then I did git remote add origin xyz and git push --all origin and it also worked. I created this repo as test one, with only me having access to both local repo and origin. No changes were made in project held on this repo, nothing to commit, no pushing and so on. There is also only one branch, because someone initialized svn years ago without creating proper folder structure (branches, trunk, tags). Meanwhile someone pushed their work to svn, so I tried to git svn fetch (which worked), and git svn rebase which didn't, giving me error: Unable to determine upstream SVN information from working tree history Is there any reason why git svn decided to stop working?

    Read the article

  • SVN tool to rebase a branch in git style

    - by timmow
    Are there any tools available that will let me rebase in git style an SVN branch onto a new parent? So, in the following situation, I create a feature branch, and there are commits to the trunk E---F---G Feature / A---B---C---D--H--I trunk I'm looking for a tool which copies the trunk, and applies the commits one by one, letting me resolve any conflicts if any exist - but each commit retains the same commit message, and is still a separate commit. E'---F'---G' Feature / A---B---C---D--H--I trunk So commit E' will be a commit with the same changes as E, except in the case of E causing a conflict, in which case E' will differ from E in that E' has the conflicts resolved, and the same commit message as E. I'm looking for this as it helps in keeping branches up to date with trunk - the svnmerge.py / mergeinfo way does not help, as you still need to resolve your changes when you merge back to trunk.

    Read the article

  • When will `git pull --rebase` get me in to trouble?

    - by Gabe Hollombe
    I understand that when I use git pull --rebase, git will re-write history and move my local commits to occur after all of the commits in the branch I just pulled from. What I don't understand is how this would ever be a bad thing. People talk about getting in to trouble with git pull --rebase where you can end up with a branch that other people can't pull from. But I don't get how that's possible since all you're doing is replaying your local, not-yet-public, commits on top of the branch you pulled from. So, what's the problem there?

    Read the article

  • Git repository is out of sync after rebase

    - by Keyo
    I have squashed 2 commits (A and B) into one new commit (C). The previous two commits (A and B) where removed. I pushed these commits from my development repo to a central(bare) repository. The git-log on both repos confirms that commits A and B have been removed. The problem is when I do a pull on a third repository which already had (A and B) it now has all three commits (A, B and C). I would have thought the pull would synchronise these changes. Do I need to checkout A~1 and then merge in the new changes? This seems like a hassle, especially in a production environment.

    Read the article

  • Can I rename LOCAL, REMOTE and BASE as used in git mergetool?

    - by carleeto
    Lets say I'm doing a rebase B of a branch onto master and there's a conflict. git opens up the default merge tool with 3 files as input : file.LOCAL, file.BASE, file.REMOTE (they're named a little differently, but LOCAL, BASE and REMOTE are in the file names and is how they are distinguished). Now, according to the mergetool man page: $LOCAL is set to the name of a temporary file containing the contents of the file on the current branch; $REMOTE set to the name of a temporary file containing the contents of the file to be merged, and $BASE set to the name of a temporary file containing the common base for the merge. That really does not make sense to me. LOCAL is the current state of the branch. Where I get lost is BASE and REMOTE. So my question is : Is it possible to make git use the branch name instead of LOCAL and similarly more meaningful names other than BASE and REMOTE? For example, if the branch name is FeatureX and the BASE = the file as it exists in master, is there a way to get git to substitute FeatureX for LOCAL and master for BASE, so that it is more apparent where the source is coming from? This is especially a problem when doing a rebase.

    Read the article

  • Is version history really sacred or is it better to rebase?

    - by dukeofgaming
    I've always agreed with Mercurial's mantra, however, now that Mercurial comes bundled with the rebase extension and it is a popular practice in git, I'm wondering if it could really be regarded as a "bad practice", or at least bad enough to avoid using. In any case, I'm aware of rebasing being dangerous after pushing. OTOH, I see the point of trying to package 5 commits in a single one to make it look niftier (specially at in a production branch), however, personally I think would be better to be able to see partial commits to a feature where some experimentation is done, even if it is not as nifty, but seeing something like "Tried to do it way X but it is not as optimal as Y after all, doing it Z taking Y as base" would IMHO have good value to those studying the codebase and follow the developers train of thought. My very opinionated (as in dumb, visceral, biased) point of view is that programmers like rebase to hide mistakes... and I don't think this is good for the project at all. So my question is: have you really found valuable to have such "organic commits" (i.e. untampered history) in practice?, or conversely, do you prefer to run into nifty well-packed commits and disregard the programmers' experimentation process?; whichever one you chose, why does that work for you? (having other team members to keep history, or alternatively, rebasing it).

    Read the article

  • Can I make fast forwarding be off by default in git?

    - by Jason Baker
    I can't really ever think of a time when I would use git merge rather than git rebase and not want to have a commit show up. Is there any way to configure git to have fast forwarding off by default? The fact that there's an --ff option would seem to imply that there's a way, but I can't seem to find it in the documentation.

    Read the article

  • What are the advantages of a rebase over a merge in git?

    - by eSKay
    In this article, the author explains rebasing with this diagram: Rebase: If you have not yet published your branch, or have clearly communicated that others should not base their work on it, you have an alternative. You can rebase your branch, where instead of merging, your commit is replaced by another commit with a different parent, and your branch is moved there. while a normal merge would have looked like this: So, if you rebase, you are just losing a history state (which would be garbage collected sometime in the future). So, why would someone want to do a rebase at all? What am I missing here?

    Read the article

  • git: how to squash the first two commits?

    - by kch
    With git rebase --interactive <commit> you can squash any number of commits together into a single one. It's an OCD heaven. And that's all great unless you want to squash commits into the initial commit. That seems impossible to do. Any way to achieve it? Moderately related: In a related question, I managed to come up with a different approach to the need of squashing against the first commit, which is, well, to make it the second one. If you're interested: git: how to insert a commit as the first, shifting all the others?

    Read the article

  • Merge changes when a file on a branch has split into two files on the master

    - by carleeto
    This is basically the result of a massive class C on the master having been refactored down the line into two smaller classes, C1 and C2. C was then made a subclass of C2 and cut down to a skeletal version for backward compatibility. So from that point on, master contained C, C1 and C2. On that master commit git said C was renamed to C1. The branch was last updated before this happened. (All C++ code, if it helps to visualize the files involved) Obviously, when I tried a rebase of the branch onto master, there were conflicts that needed to be resolved. As usual, I used mergetool. So now the mergetool comes up with the following: On Local, I have the skeletal version of C. Base and Remote have a bunch of changes to C. Because the skeletal version of C exists on Local, I conclude that the changes from Base and Remote should actually go into C1, leaving C alone. My question is, how do I do this?

    Read the article

  • Rails and GIT workflow advice.

    - by dannymcc
    Hi Everyone, I need some advice with my desired setup with git and rails. Basically for my first Rails application I used a base application template from GitHub, I then made a ton of changes and now have a full application which is fairly customised. I have now extracted all of the changes I made to the files within the base application template and have committed the changes to my fork of the github repo. Ideally, I would like to have the base application template as a branch in my application and rebase it with my master. Is this actually possible? The reason I want to do this: I want to keep the base application up to date and functional, so for my next project I can just clone the base application template from my github fork and get working. Likewise, if anyone fixes any bugs in the base application template, I could merge those fixes with any application I have the base application template as a branch? Is this possible? Is there a better/more common way to do this? Thanks in advanced! Thanks, Danny

    Read the article

  • Is git svn rebase required before git svn dcommit?

    - by allyourcode
    I'm reading about using git as an svn client here: http://learn.github.com/p/git-svn.html That page suggests that you do git svn rebase before git svn dcommit, which makes perfect sense; it's like doing svn update before doing svn commit. Then, I started looking at the documentation for git svn dcommit (I was wondering what the 'd' is about): http://www.kernel.org/pub/software/scm/git/docs/git-svn.html You have to scroll down a bit to see the documentation on dcommit, which says this: Commit each diff from a specified head directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This confuses me, because if you do as the first page says, there will be no changes to pull down from svn once the first part of dcommit finishes. I'm also confused by the part that talks about reset; isn't git reset for removing changes from the staging area? Why would rebase or reset follow (the first part of) a dcommit?

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 1 2 3 4 5  | Next Page >