{"thread":{"id":"3004","subject":"RE: git pull on Linux/ACPI release tree","startedAt":"2006-01-08T07:47:30Z","lastAt":"2006-01-09T03:50:32Z","messageCount":7,"participants":["Brown, Len","David S. Miller","Junio C Hamano","Linus Torvalds","Al Viro","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14295","messageId":"F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com","threadId":"3004","inReplyTo":null,"subject":"RE: git pull on Linux/ACPI release tree","fromName":"Brown, Len","fromEmail":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","sentAt":"2006-01-08T07:47:30Z","receivedAt":"2006-01-08T07:47:30Z","isPatch":false,"sender":{"key":"len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org","avatar":null},"body":"Hi Linus,\n\nadding git-u79uwXL29TaiAVqoAR/hOK1cXZ9k6wlg@public.gmane.org\n\n>> please pull this batch of trivial patches from: \n>> \n>> \n>git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release\n>\n>Len,\n>\n>I _really_ wish you wouldn't have those automatic merges.\n>\n>Why do you do them? They add nothing but ugly and unnecessary \n>history, and in this pull, I think almost exactly half of the\n>commits were just these empty merges.\n\nIs it possible for it git, like bk, to simply ignore merge commits in its summary output?\n\nNote that \"Auto-update from upstream\" is just the place-holder comment\nembedded in the wrapper script in git/Documentation/howto/using-topic-branches.txt\nAll instances of it here are from me manually updating --\nthe only \"auto\" happening here is the automatic insertion of that comment:-)\n\nI think that Tony's howto above captures two key requirements\nfrom all kernel maintainers -- which the exception of you --\nwho hang out  in the middle of the process rather than\nat the top of the tree.\n\n1. It is important that we be able (and encouraged, not discouraged)\nto track the top of tree as closely as we have time to handle.\nDivergence and conflicts are best handled as soon as they are noticed\nand can be a huge pain if left to fester and discovered\nonly when it is time to push patches upstream.\nPlus, tracking the top of tree means we force more folks to\ntrack the top of tree, and so it gets more testing.  This is goodness.\n\nEarlier in your release cycle when changes are appearing faster,\nmy need/desire to sync is greater than later in the cycle when changes\nare smaller and infrequent.  On average, I think that one sync/day\nfrom upstream is an entirely reasonable frequency.\n\n2. It is also important that we be able to cherry pick individual patches\nin our trees so that they don't block each other from going upstream.\nTony's using-topic-branches.txt above is the best way I know of doing that.\nI think it is a big improvement over the bk model since I can have a simple\nbranch for each patch or group of patches rather than an entire repository\ndedicatd to each.  But for this to work, I need to be able to update\nany and all of the topic branches from upstream, and to merge them with\neach other -- just like I could with BK.  Otherwise they become \"dated\"\nin the time they were first integrated, and it is not convenient to do\nsimple apples/apples comparisons that are needed to debug and test.\n\nI'm probably a naïve git user -- but I expect I have a lot of company.\nIf there is a better way of using the tool to get the job done,\nI'm certainly a willing customer with open ears.\n\nthanks,\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":"14296","messageId":"20060108.001651.02992220.davem@davemloft.net","threadId":"3004","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"David S. Miller","fromEmail":"davem@davemloft.net","sentAt":"2006-01-08T08:16:51Z","receivedAt":"2006-01-08T08:16:51Z","isPatch":false,"sender":{"key":"davem@davemloft.net","avatar":null},"body":"From: \"Brown, Len\" <len.brown@intel.com>\nDate: Sun, 8 Jan 2006 02:47:30 -0500\n\n> I'm probably a naïve git user -- but I expect I have a lot of company.\n> If there is a better way of using the tool to get the job done,\n> I'm certainly a willing customer with open ears.\n\nWhat I do is simply build a new fresh tree if I feel the urge\nto sync with the top of Linus's tree.  I use the script below\nwhich I call \"git suck\".  It just sucks the patches out of\none tree and sticks them into another tree.  You go:\n\nbash$ cd new-2.6\nbash$ git suck ../foo-2.6\n\nIt preserves everything except the dates, and it's so incredibly\ncheap and fast with GIT.\n\nI know a lot of people react to this kind of usage with \"what's the\npoint of the source control system if you're just messing with patches\nin and out of the tree all the time\" But as a subsystem maintainer,\nyou deal with a lot of changes and it's important to get a pristine\nclean history when you push things to Linus.\n\nIn fact, I do this so much that Linus's tree HEAD often equals my\norigin when he pulls.\n\nMerges really suck and I also hate it when the tree gets cluttered\nup with them, and Linus is right, ACPI is the worst offender here.\n\nYes, we can grep the merges out of the shortlog or whatever, but that\nmerging crap is still physically in the tree.\n\nJust don't do it.  Merge into a private branch for testing if you\ndon't want to rebuild trees like I do, but push the clean tree to\nLinus.\n\n#!/bin/sh\n#\n# Usage: git suck path-to-tree\n#\n# Pull all patches relative to 'origin' from the tree specified\n# and apply them to the current directory tree, keeping all changelog\n# and authorship information identical.  It will update the dates\n# of the changes of course.\n(cd $1; git format-patch --mbox origin) || exit 1\nfor i in $1/*.txt\ndo\n   sed 's/\\[PATCH\\] //' <$i >tmp.patch\n   git-applymbox -k tmp.patch || exit 1\ndone\n"},{"id":"14410","messageId":"tnx64os3xri.fsf@arm.com","threadId":"3004","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-01-08T08:16:51Z","receivedAt":"2006-01-08T08:16:51Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"\"Brown, Len\" wrote:\n>>I _really_ wish you wouldn't have those automatic merges.\n>>\n>>Why do you do them? They add nothing but ugly and unnecessary \n>>history, and in this pull, I think almost exactly half of the\n>>commits were just these empty merges.\n>\n> Is it possible for it git, like bk, to simply ignore merge commits\n> in its summary output?\n\nAs Junio suggested, you can have a look at StGIT\n(http://www.procode.org/stgit/) for a different workflow. There is a\ntutorial both on the web and in the doc/ directory but, anyway, it is\npretty similar to Quilt only that the patches are GIT commits.\n\nIn principle, you keep all the patches in a stack whose base is the\nHEAD of Linus' kernel. You can indefinitely modify/push/pop the\npatches and, once you are happy with the state of the stack, ask Linus\nto pull using standard GIT commands (or mail them with 'stg\nmail'). You can afterwards pull the latest changes from Linus using\n'stg pull'. This operation pops the patches you have, advances the\nbase of the stack (so no \"merge\" message) and pushes your patches\nback. Since pushing is done with a three-way merge, it detects whether\nthere are any upstream modifications to your patches (if not, all the\npatches should become empty and safely removed from the stack).\n\nYou can also have a branch for upstream merges only and you can easily\ncherry-pick patches or commits from other branches. This is quite\nuseful if you want to continue the work on your development branch\nuntil Linus merges your patches.\n\n-- \nCatalin\n"},{"id":"14297","messageId":"7virsv3y8k.fsf@assigned-by-dhcp.cox.net","threadId":"3004","inReplyTo":"20060108.001651.02992220.davem@davemloft.net","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-08T08:44:27Z","receivedAt":"2006-01-08T08:44:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David S. Miller\" <davem@davemloft.net> writes:\n\n> I know a lot of people react to this kind of usage with \"what's the\n> point of the source control system if you're just messing with patches\n> in and out of the tree all the time\" But as a subsystem maintainer,\n> you deal with a lot of changes and it's important to get a pristine\n> clean history when you push things to Linus.\n\nI suppose another possibility of rebasing the topic branches\nevery now and then amounts to almost the same thing; I think\nyour way is safer just in case something goes wrong.  Maybe\nCatalin can give us a short tutorial on StGIT here?\n\n> #!/bin/sh\n> (cd $1; git format-patch --mbox origin) || exit 1\n> for i in $1/*.txt\n> do\n>    sed 's/\\[PATCH\\] //' <$i >tmp.patch\n>    git-applymbox -k tmp.patch || exit 1\n> done\n\nWith \"git format-patch --mbox -k origin\", you would not need the\nsed command.\n\nOr doing it inside a single repository:\n\n   #!/bin/sh \n   git branch -f anchor ;# mark the current head\n   git reset --hard linus ;# rewind to linus head\n   # extract them, and apply them -- I suspect origin and linus\n   # are the same\n   git format-patch --stdout -k origin anchor | git am -k -3\n\nTo check the results, since the patch you fed to \"am\" as a whole\nshould be fairly close to the difference between the linus head\nand your resulting HEAD, parhaps:\n\n   git diff $(git merge-base origin anchor) anchor |\n       git apply --stat --summary >status.1\n   git diff linus HEAD | git apply --stat --summary >status.2\n   diff -u status.1 status.2\n\nIf you do not like the result, you can \"git reset --hard anchor\"\nto come back to where you started.\n\n* format-patch --stdout implies --mbox.\n\n* -3 to \"am\" is optional and as a matter of taste.  If you want\n  to resolve conflicts by hand to be sure, running \"am\" without\n  it may be preferable.  Otherwise when a patch does not cleanly\n  apply it would construct an appropriate merge base tree on the\n  fly and runs a 3-way merge.\n"},{"id":"14313","messageId":"Pine.LNX.4.64.0601081100220.3169@g5.osdl.org","threadId":"3004","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B3005A13489-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org","subject":"RE: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds-3nddppzayc0@public.gmane.org","sentAt":"2006-01-08T19:10:20Z","receivedAt":"2006-01-08T19:10:20Z","isPatch":false,"sender":{"key":"torvalds-3nddppzayc0@public.gmane.org","avatar":null},"body":"\n\nOn Sun, 8 Jan 2006, Brown, Len wrote:\n> \n> Is it possible for it git, like bk, to simply ignore merge commits in its summary output?\n\nThat's not the point. It does: \"git log --no-merges\" does exactly that.\n\nBut fire up \"gitk\" to watch the history, and see the difference.\n\n> Note that \"Auto-update from upstream\" is just the place-holder comment\n> embedded in the wrapper script in git/Documentation/howto/using-topic-branches.txt\n\nThat has absolutely nothing to do with anything. It's not the comment \n(which admittedly gives absolutely no information - but why should it, \nsince the _commit_ itself has no information in it?)\n\nIt's like you have empty commits that don't do anything at all, except \nthat they are worse, because they have two parents.\n\n> I think that Tony's howto above captures two key requirements\n> from all kernel maintainers -- which the exception of you --\n\nNo. Your commits make it harder for _everybody_ to track the history. \n\nA merge by definition \"couples\" the history of two branches. That's what a \nmerge very fundamentally is. It ties two things together. But two things \nthat don't have any connection to each other _shouldn't_ be tied together.\n\nJust as an example: because of the extra merges, you've made all your \ncommits dependent on what happened in my tree, with no real reason. So \nlet's say that somebody reports that something broke in ACPI. Now you \ncan't just go to the top of the ACPI history and work backwards - you'll \nhave tied up the two histories so that they are intertwined.\n\nAnd yes, you can always work around it, but there's just no point. And \nnone of the other developers seem to need to do it. They do their \ndevelopment, and then they say \"please pull\". At that point the two \nhistories are tied together, but now they are tied together for a \n_reason_. It was an intentional synchronization point.\n\nAn \"automated pull\" by definition has no reason. If it works automated, \nthen the merge has zero semantic meaning. \n\n\t\t\tLinus\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":"14328","messageId":"20060109004844.GG27946@ftp.linux.org.uk","threadId":"3004","inReplyTo":"Pine.LNX.4.64.0601081100220.3169@g5.osdl.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Al Viro","fromEmail":"viro@ftp.linux.org.uk","sentAt":"2006-01-09T00:48:44Z","receivedAt":"2006-01-09T00:48:44Z","isPatch":false,"sender":{"key":"viro@ftp.linux.org.uk","avatar":null},"body":"On Sun, Jan 08, 2006 at 11:10:20AM -0800, Linus Torvalds wrote:\n> That has absolutely nothing to do with anything. It's not the comment \n> (which admittedly gives absolutely no information - but why should it, \n> since the _commit_ itself has no information in it?)\n\nHow do you deal with conflict resolution?  That's a genuine question -\nI'm not talking about deliberate misuse to hide an attack, just a normal\nsituation when you have to resolve something like\n\nA:\n\tif (foo)\n\t\tbar\n\nB:\n\tif (foo & baz)\n\t\tbar\n\nA':\n#ifdef X\n\tif (foo)\n\t\tbar\n\t...\n#endif\n\nmerge of A' and B: trivial conflict\n\nand have git pull fail.  The obvious way (edit file in question, update-index,\ncommit) will not only leave zero information about said conflict and actions\nneeded to deal with it, but will lead to situation when git whatchanged will\nnot show anything useful.   I.e. if conflict turns out to be non-trivial and\nends up being resolved wrong, everyone will have very nasty time trying to\nfigure out where the breakage had come from when looking at history 6 months\ndown the road.\n\nIs there any SOP I'm missing here?\n\nWorse (for my use), format-patch on such tree will not give a useful patchset.\nYou get a series of patches that won't apply to _any_ tree.  Even if all\nconflicts had been resolved correctly, they still remain there for everyone\ntrying to apply the patch series, unless you manually rebase it before\nformat-patch.\n\nAnd that's a fundamental problem behind all that rebase activity, AFAICS.\nIt definitely is in my case, and yes, it's fscking inconvenient in a lot\nof respects.  E.g. I'm using git for resync between build trees on several\nboxen.  There's a repository holding patchset, plus one clone per build\nbox.  Fixes for build breakage, etc., get done in those clones; after they\nare committed there, I pull into master and then pull from other clones\nto spread them to other build trees.  Works fine, but...  Any rebase in\nmaster => instant hell for all clones.  I've ended up with the following\nlayout that kinda-sorta avoids mess:\nmaster:origin: matches upstream\nmaster:topic branch: _not_ rebased until there is a conflict, never get\n\ta pull from anywhere\nmaster:master: gets pulls from topic branches and origin _and_ _nothing_ _else_\nmaster:work: where interaction with build boxen and any edits done in master\n\trepository go.  Edits, commits, pulls from master:master, pulls from\n\tbuild boxen.\nbuildN:origin == master:work\nbuildN:work: where work on buildN goes.\nWhen I want to get new stuff (== difference between master:master and\nmaster:work) into the patchset, I cherry-pick from work to topic branches\nand re-pull them into master:master until it matches master:work.  Then\nI pull master:master into master:work to create a point in work history\nthat marks beginning of new portion of pending stuff.  New stuff upstream\nis pulled to master:origin -> master:master -> master:work -> build trees.\n\nThat works, and gives me merge-free topic branches I can safely format-patch\nwhile keeping master in sync with mainline _and_ also safe for format-patch.\nThe price is in rather convoluted SOP.  And the following piece of fun:\nwhen cherry-pick work->topic, pull topic->master or pull origin->master\ngives a conflict, it's time to rebase.  Which I do by renaming topic branches\n(direct mv in .git/refs/heads), then starting new ones at current origin\nand applying old ones to them (cherry + cherry-pick if possible, format-patch\n+ applymbox if things get hairy).  Then master is recreated as branch from\norigin that gets pulls from topic branches, work is branched from it and\nbuild trees get killed and cloned from scratch.  It's tolerable since I'm\nusing ccache on build boxen, so it's _not_ that much of rebuild.\n\nHowever, that clearly is a killer if any poor sucker (me included) ever\nclones from master for any other purpose.  And that, BTW, is the main\nreason that stops me from moving master to kernel.org right now.\n\n> And yes, you can always work around it, but there's just no point. And \n> none of the other developers seem to need to do it. They do their \n> development, and then they say \"please pull\". At that point the two \n> histories are tied together, but now they are tied together for a \n> _reason_. It was an intentional synchronization point.\n> \n> An \"automated pull\" by definition has no reason. If it works automated, \n> then the merge has zero semantic meaning. \n\nI'm afraid you are missing a part of picture.  There is a bunch of git\nuses that handle a heap of foam rather than a long-term branching.  I.e.\nthe tree is tied to mainline closely and most of the stuff in it is\nsupposed to get flushed into mainline soon after it appears.  I.e. the\nsituation when we have a mergepoint for fixes that _has_ to follow\nmainline closely.\n\nI wonder what life would be without merge nodes and with equality nodes\ninstead.  I.e. to merge\nO -> A1 -> ..... -> An (=A)\n  -> B1 -> ..... -> Bm (=B)\nwould be to create a new branch (C) at Bm, have entire A1...An replayed there,\nhave B1...Bm replayed in A and then create a node certifying that new head\nof A and head of C refer to the same tree.  Plus have a way to see which\ncommits are claimed to be replays of each other.  At least that way rebase\nwould be simply saying that old history is superceded by new one, with\nequality node proving that it's OK to do.  We would have\nO -> M1 -> ....  ->Mn for mainline\nO -> B1 -> ....  -> B for branch post-pull\nMn -> P1 -> ... -> P for merge branch\nand B == P as equality node.   Old branch would have a bunch of changesets\nof its own plus ones from mainline that got there by pulls (including the\nlast one).  And new branch would contain the ports of not-yet-merged ones\nto new mainline head, with the same tree as the result and all further\ndevelopment going on there rather than in the old branch.  Oh, well...\n"},{"id":"14336","messageId":"Pine.LNX.4.64.0601081927520.3169@g5.osdl.org","threadId":"3004","inReplyTo":"20060109004844.GG27946-rfM+Q5joDG/XmaaqVzeoHQ@public.gmane.org","subject":"Re: git pull on Linux/ACPI release tree","fromName":"Linus Torvalds","fromEmail":"torvalds-3nddppzayc0@public.gmane.org","sentAt":"2006-01-09T03:50:32Z","receivedAt":"2006-01-09T03:50:32Z","isPatch":false,"sender":{"key":"torvalds-3nddppzayc0@public.gmane.org","avatar":null},"body":"\n\nOn Mon, 9 Jan 2006, Al Viro wrote:\n> \n> How do you deal with conflict resolution?  That's a genuine question -\n> I'm not talking about deliberate misuse to hide an attack, just a normal\n> situation when you have to resolve something like\n> \n> A:\n> \tif (foo)\n> \t\tbar\n> \n> B:\n> \tif (foo & baz)\n> \t\tbar\n> \n> A':\n> #ifdef X\n> \tif (foo)\n> \t\tbar\n> \t...\n> #endif\n> \n> merge of A' and B: trivial conflict\n\nActually, these days git is pretty good at it. Much better than CVS, \ncertainly. You can see the \"conflict against my old tree\", or \"conflict \nagainst the remote tree\" by using the \"--ours\" or \"--theirs\" flag to \"git \ndiff\" respectively.\n\n(Or \"diff conflict against common base\": \"git diff --base\").\n\nSo for your particular example with a trivial base file:\n\n\tline    1\n\t        2\n\t        3\n\t        if (foo)\n\t                bar\n\t        6\n\t        7\n\t        8\n\nand then the changes you had as an example in the A' and B branches, if I \nfrom A' do a \"git pull . B\", I get:\n\n\tTrying really trivial in-index merge...\n\tfatal: Merge requires file-level merging\n\tNope.\n\tMerging HEAD with ad56343c578785b8d932224a8676615e7a3e191f\n\tMerging: \n\t9d619225e3adecee6432a36d67d140e29b0acf62 A' case \n\tad56343c578785b8d932224a8676615e7a3e191f B: case \n\tfound 1 common ancestor(s): \n\t93765ba3f64e9c73438e52683fffa68e5a493df7 Base commit \n\tAuto-merging A \n\tCONFLICT (content): Merge conflict in A \n\n\tAutomatic merge failed; fix up by hand\n\nand then the file contains the contents\n\n\tline    1\n\t        2\n\t        3\n\t<<<<<<< HEAD/A\n\t#ifdef X\n\t        if (foo)\n\t=======\n\t        if (foo && baz)\n\t>>>>>>> ad56343c578785b8d932224a8676615e7a3e191f/A\n\t                bar\n\t        6\n\t#endif\n\t        7\n\t        8\n\nie it will have does a CVS-like merge for me, and I need to fix this up. \nHowever, to _help_ me fix it up, I can now see what the diff is aganst my \noriginal version (A'), with \"git diff --ours\" (the \"--ours\" is default, so \nit's unnecessary, but just to make it explicit):\n\n\t* Unmerged path A\n\tdiff --git a/A b/A\n\tindex 06dd3bc..7334364 100644\n\t--- a/A\n\t+++ b/A\n\t@@ -1,8 +1,12 @@\n\t line   1\n\t        2\n\t        3\n\t+<<<<<<< HEAD/A\n\t #ifdef X\n\t        if (foo)\n\t+=======\n\t+       if (foo && baz)\n\t+>>>>>>> ad56343c578785b8d932224a8676615e7a3e191f/A\n\t                bar\n\t        6\n\t #endif\n\nwhich is very helpful especially once I have resolved it. IOW, I just edit \nthe file and do the trivial resolve, and now I can do a \"git diff\" again \nto make sure that it looks ok:\n\n\t* Unmerged path A\n\tdiff --git a/A b/A\n\tindex 06dd3bc..924fc97 100644\n\t--- a/A\n\t+++ b/A\n\t@@ -2,7 +2,7 @@ line    1\n\t        2\n\t        3\n\t #ifdef X\n\t-       if (foo)\n\t+       if (foo && baz)\n\t                bar\n\t        6\n\t #endif\n\nahh, looks good, so I just do \"git commit A\" and that creates the \nresolved merge.\n\n>  The obvious way (edit file in question, update-index, commit) will not \n> only leave zero information about said conflict and actions needed to \n> deal with it, but will lead to situation when git whatchanged will not \n> show anything useful.\n\nNow, this is a real issue. \n\nThe resolve part is pretty easy, but the fact that it's hard to see in \n\"git-whatchanged\" is a limitation of git-whatchanged. \n\nYou need to use \"gitk\", which _does_ know how to show merges as a diff \n(and yes, I just checked).\n\n> Is there any SOP I'm missing here?\n\nYou're just missing the fact that git-whatchanged (or rather, \n\"git-diff-tree\") isn't smart enough to show merges nicely. It really \n_should_. It doesn't. You can choose to show merges with the \"-m\" flag, \nbut that will show diffs against each parent, which really isn't what you \nwant. \n\nI should do the same thing gitk does in git-diff-tree.\n\n> Worse (for my use), format-patch on such tree will not give a useful patchset.\n> You get a series of patches that won't apply to _any_ tree. \n\nNow, git-diff-tree _does_ do that. Use the \"-m\" flag, and choose the tree \nyou want.\n\nAnd btw, that works with \"git-whatchanged\" too. You _can_ pass the \"-m\" \nflag to git-whatchanged, and it will show you each side of the merge \ncorrectly. So it _works_. It's just such a horrible format that by default \nit prefers to shut up about merges entirely. \n\n(I don't know of a good three-way diff format. \"gitk\" can do it, because \ngitk can show colors. That's a big deal when you do three-way - or \nmore-way - diffs).\n\n> And that's a fundamental problem behind all that rebase activity, AFAICS.\n\nYou do _not_ want to rebase a merge. It not only won't work, it's against \nthe whole point of rebasing.\n\nRebasing is really only a valid operation when you have a few patches OF \nYOUR OWN that you want to move up to a new version of somebody elses tree \nthat you are tracking. You fundamentally _cannot_ rebase if you've done \nanything but a linear set of patches. And that has nothing to do with the \npatch difficulty - it simply isn't an operation that makes sense.\n\n(Btw, not making sense doesn't mean it might not work. It sometimes might \nactually work and do what you _hoped_ it would do, but it's basically by \npure luck, and not because it is a sensible operation. Even stupid \npeople hit on the right solution every once in a while - not because \nthey thought about things right, but just because they happened to try \nsomething that worked. The same is true of \"git rebase\" with merges ;^).\n\nThe fundamental reason a rebase doesn't make sense is that if you've done \na merge, it obviously means that some other branch has done development, \nand already has the commits that you're trying to rebase. And you CANNOT \nrebase for them.\n\nSo instead of rebasing across a merge, what you can do is to not do the \nmerge at all, but instead rebase one of the two branches against the \nother. Then you can rebase the result against the thing that you wanted to \nrebase them both against. Now you've never rebased a merge - you've just\nlinearised branches that were linear in themselves against each other.\n\nBasically, a merge ties two branches together. Once you've merged, you \ncan't make a linear history any more. The merge fundamentally is not \nlinear.\n\n\t\tLinus\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"}]}