Re: Struggling with tangled

[Jakub Narebski <jnareb@gmail.com>]

Alan Chandler wrote:

> I am trying to sort out a tangled (in the sense that I several branches that 
> split a long time ago, but are reasonably close subsets of each other) 
> repository of mine using git rebase.  I want to isolate the commits that 
> cause the key differences so that I can then easily enhance the code but 
> carry forward the variants (using git-rebase again probably). 
> 
> I have some questions which are causing me some grief after merge conflicts. 
> Can someone help me. 
> 
> 1) I often edit a merge conflicted file to the state I expect it to be in at 
> the end.  This sometimes means that I edit it to a state where no change is 
> seen.  git-update-index notices this and doesn't do anything, but when I try 
> git-rebase --continue it won't because it says git-update-index has not been 
> run.  What am I supposed to do then? [Is the answer git-rebase --skip ?] 

If you resolve conflict to the state where no change is seen, it means that
the commit you currently are rebasing doesn't bring any changes; it was
applied. So you have to do "git rebase --skip".

Sidenote: with git version 1.4.3.4 you cannot "git rebase --skip" while
there are conflict in the index. It is most annoying - I'd like to skip
the resolving. I bring the files in conflict to the "base" version and run
"git update-index" before "git rebase --skip", but I'd like to skip that part.

> 2) Some files get completely munged with conflict resolution markers every 
> few lines.  Is there a simple way to say "don't use this file, but use the 
> [stage2/stage3] sources of the merge". (ie one of the original inputs to the 
> merge - and if so, which one is which) 

"git cat-file -p :<stage>: <filename> > <filename>", where stage = 1 means
version from the ancestor, stage = 2 means version from the HEAD (from the
base), and stage = 3 means version from the remote/other branch (from the
branch being rebased).  

> 3) I sometime hit a merge conflict in a file which I know will actually be 
> deleted at the tip of the topic I am rebasing.  Is there a way at this point 
> to just tell the conflict resolution to say make this file go away. 

"git rm <filename>" plus "git update-index <filename>" doesn't work?

> 4) I repeat the question I asked in a thread above.  What is the --merge 
> switch on git-rebase actually do.  The man page starts talking about merge 
> strategies, but there already is a -s switch for that. 

"git rebase" uses "git format-patch" + "git-am --3way" machinery by default.
The --merge option makes it use merge machinery instead (similar to the way 
"git checkout -m" uses merge strategy IIRC).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git