# use of temporary refs in resolve 10 messages from 2005-08-07 to 2005-08-09. Participants: Junio C Hamano, Linus Torvalds, Catalin Marinas. Thread: https://gitlist.dev/t/1446 ## Junio C Hamano, 2005-08-07 19:44 Subject: use of temporary refs in resolve Message-ID: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bplwmzg.fsf%40assigned-by-dhcp.cox.net ``` 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. ``` ## Linus Torvalds, 2005-08-07 20:02 Subject: Re: use of temporary refs in resolve Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508071256140.3258%40g5.osdl.org In-Reply-To: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Junio C Hamano, 2005-08-07 20:12 Subject: Re: use of temporary refs in resolve Message-ID: <7vd5opv74u.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd5opv74u.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > In fact, ORIG_HEAD is _the_ most common head I use explicitly. Ahhhh. You are right. How about LAST_MERGE? ``` ## Linus Torvalds, 2005-08-07 20:18 Subject: Re: use of temporary refs in resolve Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508071317060.3258%40g5.osdl.org In-Reply-To: <7vd5opv74u.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Catalin Marinas, 2005-08-08 08:50 Subject: Re: use of temporary refs in resolve Message-ID: URL: https://gitlist.dev/e/tnxk6iwx161.fsf%40arm.com In-Reply-To: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano 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 ``` ## Junio C Hamano, 2005-08-08 09:06 Subject: Re: use of temporary refs in resolve Message-ID: <7vfytkdcgm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfytkdcgm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Catalin Marinas 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. ``` ## Catalin Marinas, 2005-08-08 10:26 Subject: Re: use of temporary refs in resolve Message-ID: URL: https://gitlist.dev/e/tnxr7d4vi5v.fsf%40arm.com In-Reply-To: <7vfytkdcgm.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Catalin Marinas 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 ``` ## Junio C Hamano, 2005-08-09 02:48 Subject: Re: use of temporary refs in resolve Message-ID: <7v1x53zuyv.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1x53zuyv.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Catalin Marinas 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. ``` ## Catalin Marinas, 2005-08-09 09:07 Subject: Re: use of temporary refs in resolve Message-ID: URL: https://gitlist.dev/e/tnxmznr32cy.fsf%40arm.com In-Reply-To: <7v1x53zuyv.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano 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 ``` ## Junio C Hamano, 2005-08-09 12:51 Subject: Re: use of temporary refs in resolve Message-ID: <7vy87bw9wb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy87bw9wb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Catalin Marinas 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. ```