{"thread":{"id":"1446","subject":"use of temporary refs in resolve","startedAt":"2005-08-07T19:44:35Z","lastAt":"2005-08-09T12:51:48Z","messageCount":10,"participants":["Junio C Hamano","Linus Torvalds","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6908","messageId":"7v3bplwmzg.fsf@assigned-by-dhcp.cox.net","threadId":"1446","inReplyTo":null,"subject":"use of temporary refs in resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T19:44:35Z","receivedAt":"2005-08-07T19:44:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As promised I was looking into the fetching side today, but I\nended up trying to figure out the current operation of resolve\nfirst.\n\nHere is my understanding of various \"temporary heads\" left\ndirectly underneath $GIT_DIR:\n\n    HEAD      : updated only after successful auto merge.\n\n    ORIG_HEAD : records the head value before resolve started.\n                if automerge fails, this is the same as HEAD,\n                but after successful automerge, this can be used\n                to see what the previous head was.  This is the\n                first parent of the resulting commit.\n\n    MERGE_HEAD: present if auto merge is unsuccessful and\n\t\trecords the other head being merged.\n\n    LAST_MERGE: present if merge is unsuccessful or impossible and\n\t\trecords the other head being merged.\n\nWhenever resolve fails, LAST_MERGE would be there, while\nMERGE_HEAD exists only when we attempted and failed an\nautomerge.  I would propose to change this to leave LAST_MERGE\nonly when we did not even attempt to automerge.\n\nAlso ORIG_HEAD is probably redundant.  After a successful\nautomerge, the same information can be had by HEAD^1, and after\na failure, it is HEAD.  We do not use the existence of that file\nto detect if we are in a middle of the merge (MERGE_HEAD is used\nfor that purpose by git-commit).  We may want stop writing to it\nin git-resolve.\n\nWhat do you think?\n\nAnother thing I was thinking was to give git-resolve an ability\nto take more than two commits to do octopus ;-).  Instead of\nusing the third argument as a merge commit message, we would say\n(for backward compatibilities' sake) the last one is the\nmessage.  When we fail halfway, things would probably become messy,\nso this needs be postponed until some more thought.\n"},{"id":"6910","messageId":"Pine.LNX.4.58.0508071256140.3258@g5.osdl.org","threadId":"1446","inReplyTo":"7v3bplwmzg.fsf@assigned-by-dhcp.cox.net","subject":"Re: use of temporary refs in resolve","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-07T20:02:23Z","receivedAt":"2005-08-07T20:02:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 Aug 2005, Junio C Hamano wrote:\n> \n> Also ORIG_HEAD is probably redundant.  After a successful\n> automerge, the same information can be had by HEAD^1\n\nAbsolutely not.\n\nYou forgot about one of the most common merge cases: fast-forward.\n\nIn fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all \noperations take HEAD as default, but doing a\n\n\tgitk ORIG_HEAD..\n\nis extremely useful after a pull.\n\n\t\tLinus\n"},{"id":"6911","messageId":"7vd5opv74u.fsf@assigned-by-dhcp.cox.net","threadId":"1446","inReplyTo":"Pine.LNX.4.58.0508071256140.3258@g5.osdl.org","subject":"Re: use of temporary refs in resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T20:12:17Z","receivedAt":"2005-08-07T20:12:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> In fact, ORIG_HEAD is _the_ most common head I use explicitly.\n\nAhhhh.  You are right.\n\nHow about LAST_MERGE?\n"},{"id":"6912","messageId":"Pine.LNX.4.58.0508071317060.3258@g5.osdl.org","threadId":"1446","inReplyTo":"7vd5opv74u.fsf@assigned-by-dhcp.cox.net","subject":"Re: use of temporary refs in resolve","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-07T20:18:12Z","receivedAt":"2005-08-07T20:18:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 7 Aug 2005, Junio C Hamano wrote:\n> \n> How about LAST_MERGE?\n\nI don't think it matters. I kind of saw it as the \"other side\" of \nORIG_HEAD, but since we now clean it up and since I've never used it, I \nthink it falls under the status of \"well-intentioned but useless\".\n\n\t\tLinus\n"},{"id":"6925","messageId":"tnxk6iwx161.fsf@arm.com","threadId":"1446","inReplyTo":"7v3bplwmzg.fsf@assigned-by-dhcp.cox.net","subject":"Re: use of temporary refs in resolve","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-08T08:50:30Z","receivedAt":"2005-08-08T08:50:30Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Here is my understanding of various \"temporary heads\" left\n> directly underneath $GIT_DIR:\n>\n>     HEAD      : updated only after successful auto merge.\n>\n>     ORIG_HEAD : records the head value before resolve started.\n>                 if automerge fails, this is the same as HEAD,\n>                 but after successful automerge, this can be used\n>                 to see what the previous head was.  This is the\n>                 first parent of the resulting commit.\n>\n>     MERGE_HEAD: present if auto merge is unsuccessful and\n> \t\trecords the other head being merged.\n>\n>     LAST_MERGE: present if merge is unsuccessful or impossible and\n> \t\trecords the other head being merged.\n\nIs FETCH_HEAD going to be preserved by the git-fetch-script operation?\nIt should be, unless, git-pull-script removes it or it is changed to\ndo the fetch as well.\n\nIn a repository managed with StGIT (i.e. updated with 'stg pull'), the\nbase of the stack is always the same with FETCH_HEAD and StGIT uses\nthis file. I also find it quite useful for:\n\n  gitk ORIG_HEAD..FETCH_HEAD\n\nto only see the remote commits since the local StGIT patches are\nalways seen as commits on top of the FETCH_HEAD. It's also useful for\npeople using 'git rebase'.\n\n-- \nCatalin\n"},{"id":"6926","messageId":"7vfytkdcgm.fsf@assigned-by-dhcp.cox.net","threadId":"1446","inReplyTo":"tnxk6iwx161.fsf@arm.com","subject":"Re: use of temporary refs in resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-08T09:06:49Z","receivedAt":"2005-08-08T09:06:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n>   gitk ORIG_HEAD..FETCH_HEAD\n\nYeah, Linus immediately corrected me when I said ORIG_HEAD\nseemed useless.\n\n> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?\n> It should be, unless, git-pull-script removes it or it is changed to\n> do the fetch as well.\n\nI am not quite sure what is being asked (especially \"operation\";\nI take it you meant \"surgery\" or \"butchering\"), so my answer may\nbe missing the point.\n\nI would like to update fetch to deal with multiple references,\nand if the user tells it to fetch N references, the FETCH_HEAD\nfile would contain N lines, one line for each SHA1 object name.\nInitially I will not allow pull to take more than one reference\nbecause I will need to make resolve capable of resolving more\nthan two parents (i.e. octopus merge) before that happens.  But\nonce that is done, then pull will accept N references and call\nfetch with these N references, then fetch leaves N lines in\nFETCH_HEAD, and those N SHA1 object names along with the current\nhead would be given to resolve to create an (N+1)-head king\nghidorah.  I do not know how well this would go, but at least\nthat is the current plan.\n"},{"id":"6936","messageId":"tnxr7d4vi5v.fsf@arm.com","threadId":"1446","inReplyTo":"7vfytkdcgm.fsf@assigned-by-dhcp.cox.net","subject":"Re: use of temporary refs in resolve","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-08T10:26:20Z","receivedAt":"2005-08-08T10:26:20Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Catalin Marinas <catalin.marinas@gmail.com> writes:\n>> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?\n>> It should be, unless, git-pull-script removes it or it is changed to\n>> do the fetch as well.\n>\n> I am not quite sure what is being asked (especially \"operation\";\n> I take it you meant \"surgery\" or \"butchering\"), so my answer may\n> be missing the point.\n\nOK, I wasn't that clear. Currently git-fetch-script stores the fetched\nhead in the FETCH_HEAD file and git-pull-script uses this file to do\nthe merging (by passing its content to git-resolve-script). Anyway, I\ncan easily change StGIT to only use git-pull-script directly, without\nthe intermediate fetch.\n\n> I would like to update fetch to deal with multiple references,\n> and if the user tells it to fetch N references, the FETCH_HEAD\n> file would contain N lines, one line for each SHA1 object name.\n> Initially I will not allow pull to take more than one reference\n> because I will need to make resolve capable of resolving more\n> than two parents (i.e. octopus merge) before that happens.  But\n> once that is done, then pull will accept N references and call\n> fetch with these N references, then fetch leaves N lines in\n> FETCH_HEAD, and those N SHA1 object names along with the current\n> head would be given to resolve to create an (N+1)-head king\n> ghidorah.  I do not know how well this would go, but at least\n> that is the current plan.\n\nIt might be hard to deal with conflicts resulted from merging N > 2\nheads at the same time. I suspect it would call 'merge' (diff3) for\nevery new head but it might not be that obvious which head merging\nfailed (it depends on how you implement it). A way of continuing the\nmerge for the rest of the fetched heads after a failure needs to be\navailable.\n\n-- \nCatalin\n"},{"id":"6974","messageId":"7v1x53zuyv.fsf@assigned-by-dhcp.cox.net","threadId":"1446","inReplyTo":"tnxr7d4vi5v.fsf@arm.com","subject":"Re: use of temporary refs in resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T02:48:24Z","receivedAt":"2005-08-09T02:48:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n> OK, I wasn't that clear. Currently git-fetch-script stores the fetched\n> head in the FETCH_HEAD file and git-pull-script uses this file to do\n> the merging (by passing its content to git-resolve-script).\n\nCorrect.  I was not planning to change that arrangement.\n\n> Anyway, I\n> can easily change StGIT to only use git-pull-script directly, without\n> the intermediate fetch.\n\nIf you are happy then I should not complain ;-), and I am\ncertainly not complaining, but I still have this feeling that I\ndo not get what you are getting at.  You can change it to\ndirectly use pull without intermediate fetch, in order to cope\nwith what?  Could you explain how you currently do things, and\nwhat changes I will be making would break the way you currently\ndo things please?  I need to know which detail of the current\nimplementation behaviour people rely on to avoid breaking\nthings.\n"},{"id":"6981","messageId":"tnxmznr32cy.fsf@arm.com","threadId":"1446","inReplyTo":"7v1x53zuyv.fsf@assigned-by-dhcp.cox.net","subject":"Re: use of temporary refs in resolve","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-08-09T09:07:25Z","receivedAt":"2005-08-09T09:07:25Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> If you are happy then I should not complain ;-), and I am\n> certainly not complaining, but I still have this feeling that I\n> do not get what you are getting at.  You can change it to\n> directly use pull without intermediate fetch, in order to cope\n> with what?\n\nI shouldn't have said anything :-).\n\nStGIT implements a pull command which pops all the patches from the\nstack, pulls the latest remote changes and pushes the patches back. I\nwas lazy and I implemented the pulling stage by simply calling\ngit-fetch-script and advancing the base of the stack to the value in\nFETCH_HEAD. I didn't have any special reason for this and I could have\nused git-pull-script instead and not rely on the presence of\nFETCH_HEAD. I don't have any preference here.\n\n> Could you explain how you currently do things, and\n> what changes I will be making would break the way you currently\n> do things please?\n\nIf you plan to implement multiple values in FETCH_HEAD, StGIT won't be\nable to use this since it doesn't do any merging for the base of the\nstack. As I said above, this is not a problem and I was probably wrong\nwhen decided to use git-fetch-script directly and not git-pull-script.\n\nPlease let me know if you need more info.\n\n-- \nCatalin\n"},{"id":"6986","messageId":"7vy87bw9wb.fsf@assigned-by-dhcp.cox.net","threadId":"1446","inReplyTo":"tnxmznr32cy.fsf@arm.com","subject":"Re: use of temporary refs in resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T12:51:48Z","receivedAt":"2005-08-09T12:51:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n> If you plan to implement multiple values in FETCH_HEAD, StGIT won't be\n> able to use this since it doesn't do any merging for the base of the\n> stack. As I said above, this is not a problem and I was probably wrong\n> when decided to use git-fetch-script directly and not git-pull-script.\n>\n> Please let me know if you need more info.\n\nThanks.  Perfectly clear.\n"}]}