Re: [BUG] - git rebase -i performs rebase when it shouldn't?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Montag, 12. April 2010, Michal Vitecek wrote:
>  Is there any chance for merge to behave the same? I really like that I
>  don't have to do a checkout prior rebasing.

If you mean "prior to merging", i.e., you want a "git merge --into master", 
you can do it this way:

# we are on branch 'topic' here
git checkout HEAD^0	# detach
git merge master
git reset --soft master	# keep index(!!!) and worktree
git checkout master	# re-attach
git merge topic

The point is that the second merge will succeed even with a dirty index 
because for each file the result of the merge is identical to the index!

If you have conflicts during the merge, resolve them in the first merge and 
commit to prime the rerere database; the second merge will fail for each 
conflicting file; just 'git checkout HEAD -- the/conflicting/file' and retry. 
rerere will resolve the conflicts for you.

You can of course get away with only one merge, but then you will have to do 
extra work to switch the parents around and to fix the commit message.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]