threads / discuss / 43104

Re: Struggling with tangled

Subject: Re: Struggling with tangled

## tl;dr

7 messages between Nov 22, 2006 and Nov 22, 2006.

replies: 6people: 4as markdown or json

Alan Chandler· Nov 22, 2006, 10:37 UTC · lore

Struggling with tangled

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 ?] 
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) 
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. 
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. 
 --
Alan Chandler
alan@chandlerfamily.org.uk
Jakub Narebski· Nov 22, 2006, 11:01 UTC · re: Alan Chandler · lore
Alan Chandler wrote:
Show 14 quoted lines
> 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
Alan Chandler· Nov 22, 2006, 19:15 UTC · re: Jakub Narebski · lore
On Wednesday 22 November 2006 11:01, Jakub Narebski wrote:
> Alan Chandler wrote:
...
Show 9 quoted lines
> > 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).

Just a comment for the list. There have been lots of documentation ideas floating around recently. One thing that could be done is to cross reference the key sections in the man pages somewhat. I read the man page for git-cat-file, and that just says the non flag parameter is <object> and its an SHA1.

Once I saw this, I was puzzled and eventually found a reference to in in git-rev-parse.

Show 6 quoted lines
>
> > 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?
Well I _thought_ I tried git-update-index --remove and that hadn't worked.
Show 8 quoted lines
>
> > 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).
Yes but ...
... what does that mean in usage terms?
Why would I want to use one rather than the other?
-- 
Alan Chandler
Jakub Narebski· Nov 22, 2006, 19:40 UTC · re: Alan Chandler · lore
Alan Chandler wrote:
> On Wednesday 22 November 2006 11:01, Jakub Narebski wrote:
>> Alan Chandler wrote:
Show 7 quoted lines
>>> 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?
> 
> Well I _thought_ I tried git-update-index --remove and that hadn't worked.
I think "git update-index --force-remove" might be needed here.
Show 13 quoted lines
>>> 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).
> 
> Yes but ...
> 
> ... what does that mean in usage terms?
> 
> Why would I want to use one rather than the other?

Merge machinery can detect renames. I don't know if merge machinery supports skipping over commits. The format-patch/am --3way machinery was first (and is default).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Johannes Schindelin· Nov 22, 2006, 11:35 UTC · re: Alan Chandler · lore
Hi,
On Wed, 22 Nov 2006, Alan Chandler wrote:
> 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)
I find myself using
	git diff --ours <file>
and
	git diff --theirs <file>
in such a case sometimes. If I _know_ my version is good, I do
	git diff --ours <file> | git apply -R
This also updates the index.

Hth, Dscho

Junio C Hamano· Nov 22, 2006, 11:57 UTC · re: Johannes Schindelin · lore
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 22 quoted lines
> Hi,
>
> On Wed, 22 Nov 2006, Alan Chandler wrote:
>
>> 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)
>
> I find myself using
>
> 	git diff --ours <file>
>
> and
>
> 	git diff --theirs <file>
>
> in such a case sometimes. If I _know_ my version is good, I do
>
> 	git diff --ours <file> | git apply -R
>
> This also updates the index.

Good suggestion, but apply does not update the index without being told to do so with --index, so I think the commandline should be:

	git diff --ours <path> | git apply -R --index
Johannes Schindelin· Nov 22, 2006, 13:30 UTC · re: Junio C Hamano · lore
Hi,
On Wed, 22 Nov 2006, Junio C Hamano wrote:
Show 11 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	git diff --ours <file> | git apply -R
> >
> > This also updates the index.
> 
> Good suggestion, but apply does not update the index without
> being told to do so with --index, so I think the commandline
> should be:
> 
> 	git diff --ours <path> | git apply -R --index

Oops. Thanks! Dscho

← back to recent threads