{"thread":{"id":"3013","subject":"RE: git pull on Linux/ACPI release tree","startedAt":"2006-01-09T05:53:12Z","lastAt":"2006-01-09T06:46:06Z","messageCount":4,"participants":["Brown, Len","Martin Langhoff","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14338","messageId":"F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com","threadId":"3013","inReplyTo":null,"subject":"RE: git pull on Linux/ACPI release tree","fromName":"Brown, Len","fromEmail":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","sentAt":"2006-01-09T05:53:12Z","receivedAt":"2006-01-09T05:53:12Z","isPatch":false,"sender":{"key":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","avatar":null},"body":"\n>On 1/9/06, Brown, Len wrote:\n>> Perhaps the tools should try to support what \"a lot of people\"\n>> expect, rather than making \"a lot of people\" do extra work\n>> because of the tools?\n>\n>I think it does. All the tricky stuff that David and Junio have been\n>discussing is actually done very transparently by\n>\n> git-rebase \n>\n>Now, git-rebase uses git-format-patch | git-am so\n>it sometimes has problems merging. In that case, you can choose to\n>either resolve the problem (see the doco for how to signal to git-am\n>that you've resolved a conflict) or to cancel the rebase. If you\n>choose to cancel the rebase, do\n>\n> cp .git/refs/heads/{,}\n> cat .git/HEAD_ORIG > .git/refs/heads/\n> git-reset --hard\n> rm -fr .dotest\n>\n>and you'll be back to where you started. Perhaps this could be rolled\n>into something like git-rebase --cancel to make it easier, but that's\n>about it. The toolchain definitely supports it.\n\nThis is completely insane.\nDo you have any idea what \"sometimes has problems merging\" means\nin practice? It means the tools are really nifty in the trivial\ncase but worse than worthless when you need them the most.\n\n-Len\n-\nTo unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\nthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"14340","messageId":"46a038f90601082208i95cd19fmda542da0da8cc9ef@mail.gmail.com","threadId":"3013","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-01-09T06:08:44Z","receivedAt":"2006-01-09T06:08:44Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 1/9/06, Brown, Len wrote:\n> This is completely insane.\n> Do you have any idea what \"sometimes has problems merging\" means\n> in practice? It means the tools are really nifty in the trivial\n> case but worse than worthless when you need them the most.\n\nLen,\n\nall I meant was that you will sometimes see conflicts. And in that\ncase, you are far better off cancelling the rebase and doing a merge,\nwhere you will have to resolve the conflicts by hand.\n\ngit-rebase is for when the potential merge is clearly trivial. In any\nother case, you do want a proper merge. But in any case, it is easy to\ndo\n\n git-fetch && git-rebase \n\nand if it does anything but a very trivial merge, backtrack and do a merge.\n\nIn any case, if I have any suspicion that the merge may not be trivial, I do\n\n git-fetch && gitk --since=\" 1 month ago\" upstream master\n\nbefore deciding on a course of action. Of course, you can merge all\nthe time. It's whether people care about a readable/useful history\nafterwards.\n\ncheers,\n\n\nmartin\n"},{"id":"14342","messageId":"Pine.LNX.4.64.0601082212420.3169@g5.osdl.org","threadId":"3013","inReplyTo":"46a038f90601082208i95cd19fmda542da0da8cc9ef@mail.gmail.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-09T06:13:49Z","receivedAt":"2006-01-09T06:13:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 9 Jan 2006, Martin Langhoff wrote:\n> \n> and if it does anything but a very trivial merge, backtrack and do a merge.\n\nTo be fair, backtracking a \"git-rebase\" isn't obvious. One of the \ndownsides of rebasing.\n\n\t\tLinus\n"},{"id":"14346","messageId":"7vlkxpucep.fsf@assigned-by-dhcp.cox.net","threadId":"3013","inReplyTo":"Pine.LNX.4.64.0601082212420.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-09T06:46:06Z","receivedAt":"2006-01-09T06:46:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> To be fair, backtracking a \"git-rebase\" isn't obvious. One of the \n> downsides of rebasing.\n\nI thought \"git reset --hard ORIG_HEAD\" as usual would do.\n"}]}