use of temporary refs in resolve

use of temporary refs in resolve

[Junio C Hamano]

As promised I was looking into the fetching side today, but I
ended up trying to figure out the current operation of resolve
first.

Here is my understanding of various "temporary heads" left
directly underneath $GIT_DIR:

    HEAD      : updated only after successful auto merge.

    ORIG_HEAD : records the head value before resolve started.
                if automerge fails, this is the same as HEAD,
                but after successful automerge, this can be used
                to see what the previous head was.  This is the
                first parent of the resulting commit.

    MERGE_HEAD: present if auto merge is unsuccessful and
		records the other head being merged.

    LAST_MERGE: present if merge is unsuccessful or impossible and
		records the other head being merged.

Whenever resolve fails, LAST_MERGE would be there, while
MERGE_HEAD exists only when we attempted and failed an
automerge.  I would propose to change this to leave LAST_MERGE
only when we did not even attempt to automerge.

Also ORIG_HEAD is probably redundant.  After a successful
automerge, the same information can be had by HEAD^1, and after
a failure, it is HEAD.  We do not use the existence of that file
to detect if we are in a middle of the merge (MERGE_HEAD is used
for that purpose by git-commit).  We may want stop writing to it
in git-resolve.

What do you think?

Another thing I was thinking was to give git-resolve an ability
to take more than two commits to do octopus ;-).  Instead of
using the third argument as a merge commit message, we would say
(for backward compatibilities' sake) the last one is the
message.  When we fail halfway, things would probably become messy,
so this needs be postponed until some more thought.

Re: use of temporary refs in resolve

[Linus Torvalds]

On Sun, 7 Aug 2005, Junio C Hamano wrote:
> 
> Also ORIG_HEAD is probably redundant.  After a successful
> automerge, the same information can be had by HEAD^1

Absolutely not.

You forgot about one of the most common merge cases: fast-forward.

In fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all 
operations take HEAD as default, but doing a

	gitk ORIG_HEAD..

is extremely useful after a pull.

		Linus

Re: use of temporary refs in resolve

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> In fact, ORIG_HEAD is _the_ most common head I use explicitly.

Ahhhh.  You are right.

How about LAST_MERGE?

Re: use of temporary refs in resolve

[Linus Torvalds]

On Sun, 7 Aug 2005, Junio C Hamano wrote:
> 
> How about LAST_MERGE?

I don't think it matters. I kind of saw it as the "other side" of 
ORIG_HEAD, but since we now clean it up and since I've never used it, I 
think it falls under the status of "well-intentioned but useless".

		Linus

Re: use of temporary refs in resolve

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
> Here is my understanding of various "temporary heads" left
> directly underneath $GIT_DIR:
>
>     HEAD      : updated only after successful auto merge.
>
>     ORIG_HEAD : records the head value before resolve started.
>                 if automerge fails, this is the same as HEAD,
>                 but after successful automerge, this can be used
>                 to see what the previous head was.  This is the
>                 first parent of the resulting commit.
>
>     MERGE_HEAD: present if auto merge is unsuccessful and
> 		records the other head being merged.
>
>     LAST_MERGE: present if merge is unsuccessful or impossible and
> 		records the other head being merged.

Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
It should be, unless, git-pull-script removes it or it is changed to
do the fetch as well.

In a repository managed with StGIT (i.e. updated with 'stg pull'), the
base of the stack is always the same with FETCH_HEAD and StGIT uses
this file. I also find it quite useful for:

  gitk ORIG_HEAD..FETCH_HEAD

to only see the remote commits since the local StGIT patches are
always seen as commits on top of the FETCH_HEAD. It's also useful for
people using 'git rebase'.

-- 
Catalin

Re: use of temporary refs in resolve

[Junio C Hamano]

Catalin Marinas <catalin.marinas@gmail.com> writes:

>   gitk ORIG_HEAD..FETCH_HEAD

Yeah, Linus immediately corrected me when I said ORIG_HEAD
seemed useless.

> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
> It should be, unless, git-pull-script removes it or it is changed to
> do the fetch as well.

I am not quite sure what is being asked (especially "operation";
I take it you meant "surgery" or "butchering"), so my answer may
be missing the point.

I would like to update fetch to deal with multiple references,
and if the user tells it to fetch N references, the FETCH_HEAD
file would contain N lines, one line for each SHA1 object name.
Initially I will not allow pull to take more than one reference
because I will need to make resolve capable of resolving more
than two parents (i.e. octopus merge) before that happens.  But
once that is done, then pull will accept N references and call
fetch with these N references, then fetch leaves N lines in
FETCH_HEAD, and those N SHA1 object names along with the current
head would be given to resolve to create an (N+1)-head king
ghidorah.  I do not know how well this would go, but at least
that is the current plan.

Re: use of temporary refs in resolve

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
>> It should be, unless, git-pull-script removes it or it is changed to
>> do the fetch as well.
>
> I am not quite sure what is being asked (especially "operation";
> I take it you meant "surgery" or "butchering"), so my answer may
> be missing the point.

OK, I wasn't that clear. Currently git-fetch-script stores the fetched
head in the FETCH_HEAD file and git-pull-script uses this file to do
the merging (by passing its content to git-resolve-script). Anyway, I
can easily change StGIT to only use git-pull-script directly, without
the intermediate fetch.

> I would like to update fetch to deal with multiple references,
> and if the user tells it to fetch N references, the FETCH_HEAD
> file would contain N lines, one line for each SHA1 object name.
> Initially I will not allow pull to take more than one reference
> because I will need to make resolve capable of resolving more
> than two parents (i.e. octopus merge) before that happens.  But
> once that is done, then pull will accept N references and call
> fetch with these N references, then fetch leaves N lines in
> FETCH_HEAD, and those N SHA1 object names along with the current
> head would be given to resolve to create an (N+1)-head king
> ghidorah.  I do not know how well this would go, but at least
> that is the current plan.

It might be hard to deal with conflicts resulted from merging N > 2
heads at the same time. I suspect it would call 'merge' (diff3) for
every new head but it might not be that obvious which head merging
failed (it depends on how you implement it). A way of continuing the
merge for the rest of the fetched heads after a failure needs to be
available.

-- 
Catalin

Re: use of temporary refs in resolve

[Junio C Hamano]

Catalin Marinas <catalin.marinas@gmail.com> writes:

> OK, I wasn't that clear. Currently git-fetch-script stores the fetched
> head in the FETCH_HEAD file and git-pull-script uses this file to do
> the merging (by passing its content to git-resolve-script).

Correct.  I was not planning to change that arrangement.

> Anyway, I
> can easily change StGIT to only use git-pull-script directly, without
> the intermediate fetch.

If you are happy then I should not complain ;-), and I am
certainly not complaining, but I still have this feeling that I
do not get what you are getting at.  You can change it to
directly use pull without intermediate fetch, in order to cope
with what?  Could you explain how you currently do things, and
what changes I will be making would break the way you currently
do things please?  I need to know which detail of the current
implementation behaviour people rely on to avoid breaking
things.

Re: use of temporary refs in resolve

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
> If you are happy then I should not complain ;-), and I am
> certainly not complaining, but I still have this feeling that I
> do not get what you are getting at.  You can change it to
> directly use pull without intermediate fetch, in order to cope
> with what?

I shouldn't have said anything :-).

StGIT implements a pull command which pops all the patches from the
stack, pulls the latest remote changes and pushes the patches back. I
was lazy and I implemented the pulling stage by simply calling
git-fetch-script and advancing the base of the stack to the value in
FETCH_HEAD. I didn't have any special reason for this and I could have
used git-pull-script instead and not rely on the presence of
FETCH_HEAD. I don't have any preference here.

> Could you explain how you currently do things, and
> what changes I will be making would break the way you currently
> do things please?

If you plan to implement multiple values in FETCH_HEAD, StGIT won't be
able to use this since it doesn't do any merging for the base of the
stack. As I said above, this is not a problem and I was probably wrong
when decided to use git-fetch-script directly and not git-pull-script.

Please let me know if you need more info.

-- 
Catalin

Re: use of temporary refs in resolve

[Junio C Hamano]

Catalin Marinas <catalin.marinas@gmail.com> writes:

> If you plan to implement multiple values in FETCH_HEAD, StGIT won't be
> able to use this since it doesn't do any merging for the base of the
> stack. As I said above, this is not a problem and I was probably wrong
> when decided to use git-fetch-script directly and not git-pull-script.
>
> Please let me know if you need more info.

Thanks.  Perfectly clear.