Re: use of temporary refs in resolve
Catalin Marinas <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Junio C Hamano <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Catalin Marinas <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Junio C Hamano <[EMAIL PROTECTED]> wrote: > Catalin Marinas <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Catalin Marinas <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Junio C Hamano <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Linus Torvalds <[EMAIL PROTECTED]> writes: > In fact, ORIG_HEAD is _the_ most common head I use explicitly. A. You are right. How about LAST_MERGE? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
