rebase

Has the man page states about git rebase --preserve : Merge conflict resolutions or manual amendments to merge commits are not preserved. Is there any good reason for that? It would be the same reason for the existence of the command git rerere ( Re use re corded re solution of conflicted merges) See " rerere your boat " and " Fix conflicts only once with git rerere ". Git does not record merge conflict resolution for any merge (including the one done again during a rebase -p ) Basically, a conflict merge resolution is a manual step (meaning a human decision has to be made), which git is not

Say I introduced <feature.c> a while ago and now notice it shouldn't have been part of my main branch but rather a branch feature . Is it possible to use e.g. git-filter-branch to automatically move all of <feature.c>'s history out of my main branch into the feature branch? It sounds like you're doing something fairly insane! :) That said, I see a few options, none of which are particularly automated. If you've got a ton of commits with that file present, just admit the mistake, make a new branch off of your HEAD, and put further commits with that feature into that branch until they're stable.

I simply want to speed up my .NET-base client side app and am considering NGEN-ing the code. Jeffery Richter wrote this warning about ngening code: •Inferior Load-Time Performance (Rebasing). When Windows loads an NGend file, it checks to see if the file loads at its preferred base address. If the file cant load at its preferred base address, then Windows relocates the file, fixing-up all of the memory address references. This is extremely time consuming because Windows must load the entire file into memory and modify various bytes within the file. For more information about rebasing please

The following is a scenario I commonly face: You have a set of commits on master or design , that I want to put on top of production branch. I tend to create a new branch with the base as production cherry-pick these commits on it and merge it to production Then when I merge master to production, I face merge conflicts because even tho the changes are same, but are registered as a different commit because of cherry-pick. I have found some workarounds to deal with this, all of which are laborious and can be termed "hacks". Altho' I haven't done too much rebasing, I believe that too creates a

I am trying on working on my featureA branch while keeping it up-to-date with the master branch. Here is the scenario git clone ssh://xxx/repo git checkout -b featureA $ git add file.txt $ git commit -m 'adding file' $ git push origin featureA meanwhile a couple new commits where pushed to origin master git checkout master git pull origin master git checkout featureA git rebase master git push origin feature A To ssh://xxx/repo ! [rejected] featureA -> featureA (non-fast-forward) error: failed to push some refs to 'ssh://xxx/repo' To prevent you from losing history, non-fast-forward updates