Struggling with tangled

Struggling with tangled

[Alan Chandler]

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

Re: Struggling with tangled

[Jakub Narebski]

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

Re: Struggling with tangled

[Alan Chandler]

On Wednesday 22 November 2006 11:01, Jakub Narebski wrote:
> 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)
>
> "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.


>
> > 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.

>
> > 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

Re: Struggling with tangled

[Jakub Narebski]

Alan Chandler wrote:

> On Wednesday 22 November 2006 11:01, Jakub Narebski wrote:
>> Alan Chandler wrote:

>>> 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.

>>> 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

Re: Struggling with tangled

[Johannes Schindelin]

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

Re: Struggling with tangled

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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

Re: Struggling with tangled

[Johannes Schindelin]

Hi,

On Wed, 22 Nov 2006, Junio C Hamano wrote:

> 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