{"thread":{"id":"11410","subject":"Anomalous conflicts during git rebase","startedAt":"2007-12-27T22:42:57Z","lastAt":"2007-12-28T18:54:49Z","messageCount":8,"participants":["adr3nald0s@gmail.com","Johannes Sixt","Daniel Barkalow","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64129","messageId":"m3ir2ju5ce.fsf@euroclydon.lan","threadId":"11410","inReplyTo":null,"subject":"Anomalous conflicts during git rebase","fromName":"","fromEmail":"adr3nald0s@gmail.com","sentAt":"2007-12-27T22:42:57Z","receivedAt":"2007-12-27T22:42:57Z","isPatch":false,"sender":{"key":"adr3nald0s@gmail.com","avatar":null},"body":"\nOn a clone of linux-2.6:\n\n git checkout -b topic/test v2.6.15\n touch drivers/a-file.c\n git add drivers/a-file.c\n git commit -m 'Add a file'\n git checkout -b temp0 v2.6.16\n git rebase topic/test\n\nI get the following:\n\n Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename\n \n error: patch failed: drivers/acpi/glue.c:99\n error: drivers/acpi/glue.c: patch does not apply\n error: patch failed: drivers/char/hpet.c:897\n error: drivers/char/hpet.c: patch does not apply\n Using index info to reconstruct a base tree...\n Falling back to patching base and 3-way merge...\n Auto-merged drivers/acpi/glue.c\n Auto-merged drivers/acpi/pci_link.c\n Auto-merged drivers/char/hpet.c\n CONFLICT (content): Merge conflict in drivers/char/hpet.c\n Failed to merge in the changes.\n Patch failed at 0007.\n \n When you have resolved this problem run \"git rebase --continue\".\n If you would prefer to skip this patch, instead run \"git rebase --skip\".\n To restore the original branch and stop rebasing run \"git rebase --abort\".\n\nIs this a bug, or is there a reason I am seeing conflicts in files\nI've never touched?\n"},{"id":"64131","messageId":"20071227225703.B33A25A709@dx.sixt.local","threadId":"11410","inReplyTo":"m3ir2ju5ce.fsf@euroclydon.lan","subject":"Re: Anomalous conflicts during git rebase","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-12-27T22:57:03Z","receivedAt":"2007-12-27T22:57:03Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"adr3nald0s@gmail.com wrote:\n> On a clone of linux-2.6:\n> \n> git checkout -b topic/test v2.6.15\n> touch drivers/a-file.c\n> git add drivers/a-file.c\n> git commit -m 'Add a file'\n> git checkout -b temp0 v2.6.16\n> git rebase topic/test\n> \n> I get the following:\n> \n> Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename\n..\n> CONFLICT (content): Merge conflict in drivers/char/hpet.c\n..\n> Is this a bug, or is there a reason I am seeing conflicts in files\n> I've never touched?\n\nYou are using the rebase the wrong way round.\n\nThe (first) argument to git rebase tells *where the current branch* will be\nmoved to, and not *which branch to move*.\n\nSo, instead of last two commands (git checkout...; git rebase...) you say\n\n git rebase v2.6.16\n\nand you don't need the branch temp0.\n\n-- Hannes\n"},{"id":"64133","messageId":"alpine.LNX.1.00.0712271840030.13593@iabervon.org","threadId":"11410","inReplyTo":"m3ir2ju5ce.fsf@euroclydon.lan","subject":"Re: Anomalous conflicts during git rebase","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-12-27T23:45:29Z","receivedAt":"2007-12-27T23:45:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 27 Dec 2007, adr3nald0s@gmail.com wrote:\n\n> \n> On a clone of linux-2.6:\n> \n> git checkout -b topic/test v2.6.15\n> touch drivers/a-file.c\n> git add drivers/a-file.c\n> git commit -m 'Add a file'\n> git checkout -b temp0 v2.6.16\n> git rebase topic/test\n\nThis will rebase temp0 (= v2.6.16) onto topic/test. This process \nlinearizes the history being rebased, and conflicts in that history (that \nwere resolved in the merges) show up when the second change to those lines \ngets introduced.\n\nWhat you probably want is\n\n...\n git commit -m 'Add a file'\n git checkout -b temp0\n git rebase v2.6.16\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"64148","messageId":"m3odca7ry1.fsf@euroclydon.lan","threadId":"11410","inReplyTo":"20071227225703.B33A25A709@dx.sixt.local","subject":"Re: Anomalous conflicts during git rebase","fromName":"","fromEmail":"adr3nald0s@gmail.com","sentAt":"2007-12-28T15:35:34Z","receivedAt":"2007-12-28T15:35:34Z","isPatch":false,"sender":{"key":"adr3nald0s@gmail.com","avatar":null},"body":"Johannes Sixt writes:\n\n> adr3nald0s@gmail.com wrote:\n>> On a clone of linux-2.6:\n>> \n>> git checkout -b topic/test v2.6.15\n>> touch drivers/a-file.c\n>> git add drivers/a-file.c\n>> git commit -m 'Add a file'\n>> git checkout -b temp0 v2.6.16\n>> git rebase topic/test\n>> \n>> I get the following:\n>> \n>> Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename\n> ..\n>> CONFLICT (content): Merge conflict in drivers/char/hpet.c\n> ..\n>> Is this a bug, or is there a reason I am seeing conflicts in files\n>> I've never touched?\n>\n\nI am not picking on you, Johannes, but I was expecting a response like\nthis:\n\n> You are using the rebase the wrong way round.\n\nI am very well aware of how rebase is intended to be used. The\ncomponents of git are not always used for their semantic purpose. As\nrecommended frequently on this list, it is common to bend them to your\npurpose and use them in non-intuitive ways.\n\nThe purpose of the commands above is to have a git repository from\n2.6.15 forward that has our code, XEN and some cherry-pick'd\nback-ported fixes integrated throughout. We will be doing a lot of\ngit-bisect'ing to find where various things changed that break our\ncode and certain edge-case usages of XEN.\n\nSo my question stands and it is not, \"Adr3nalD0S, why _would_ you do\nthis?\" It is, \"Why does git report conflicts that do not exist?\"\n\nP.S. This isn't the first project I have run into this on. It's just\nthe first one where I decided to try and do something about it.\n"},{"id":"64150","messageId":"m3k5my7r1u.fsf@euroclydon.lan","threadId":"11410","inReplyTo":"alpine.LNX.1.00.0712271840030.13593@iabervon.org","subject":"Re: Anomalous conflicts during git rebase","fromName":"","fromEmail":"adr3nald0s@gmail.com","sentAt":"2007-12-28T15:54:53Z","receivedAt":"2007-12-28T15:54:53Z","isPatch":false,"sender":{"key":"adr3nald0s@gmail.com","avatar":null},"body":"Daniel Barkalow writes:\n\n> This will rebase temp0 (= v2.6.16) onto topic/test. This process \n> linearizes the history being rebased, and conflicts in that history (that \n> were resolved in the merges) show up when the second change to those lines \n> gets introduced.\n\nThank you for the explaination of why this is happening. This is\nsomething I had not considered WRT git-rebase.\n\nWhen you say it linearizes history how is this done. Mentally I still\nhave a model of where the \"mainline\" is at all times and I assumed\nthat git-rebase was following this mainline. However, upon\nreflection, I realize this is naïve.\n\nWhen there is a branch and a subsequent merge, does rebase follow both\nbranches? If so, why does it not use the original merged result for\nthe newly rebased file if there are no conflicts between the original\nmerge result and the file that is being rebased onto as compared to\ntheir mutual ancestor?\n\nThanks again.\n\n-- \nAdr3nalD0S\n"},{"id":"64152","messageId":"alpine.LNX.1.00.0712281246330.13593@iabervon.org","threadId":"11410","inReplyTo":"m3k5my7r1u.fsf@euroclydon.lan","subject":"Re: Anomalous conflicts during git rebase","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-12-28T17:58:40Z","receivedAt":"2007-12-28T17:58:40Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:\n\n> Daniel Barkalow writes:\n> \n> > This will rebase temp0 (= v2.6.16) onto topic/test. This process \n> > linearizes the history being rebased, and conflicts in that history (that \n> > were resolved in the merges) show up when the second change to those lines \n> > gets introduced.\n> \n> Thank you for the explaination of why this is happening. This is\n> something I had not considered WRT git-rebase.\n> \n> When you say it linearizes history how is this done. Mentally I still\n> have a model of where the \"mainline\" is at all times and I assumed\n> that git-rebase was following this mainline. However, upon\n> reflection, I realize this is naïve.\n> \n> When there is a branch and a subsequent merge, does rebase follow both\n> branches? If so, why does it not use the original merged result for\n> the newly rebased file if there are no conflicts between the original\n> merge result and the file that is being rebased onto as compared to\n> their mutual ancestor?\n\nRebase takes a list of commits that are in the current branch and \naren't in the origin branch as what it's going to work on; these are \nordered in some arbitrary way such that children always follow parents. It \nthen resets to the origin branch's commit, and, in sequence, cherry-picks \neach of the commits in the working list. This has two implications:\n\n - the result is always linear, even if there are forks and merges in the \n old history, because the new history is formed out of a single sequence \n of cherry-picks, ignoring the shape of the original.\n\n - merge results from the old history aren't available, because they're in \n a commit later in the list than the commit where the cherry-picking \n finds a conflict.\n\nIn theory, of course, it could try to resolve conflicts by looking through \nthe rest of the list for merges which would have those conflicts and using \nwhat that merge did. But that's not at all easy, due to the structure of \nthe process, and it's rare that people actually want to rebase history \nwith forks in it, anyway, so it hasn't been done.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"64153","messageId":"m3fxxm7jp6.fsf@euroclydon.lan","threadId":"11410","inReplyTo":"alpine.LNX.1.00.0712281246330.13593@iabervon.org","subject":"Re: Anomalous conflicts during git rebase","fromName":"","fromEmail":"adr3nald0s@gmail.com","sentAt":"2007-12-28T18:33:41Z","receivedAt":"2007-12-28T18:33:41Z","isPatch":false,"sender":{"key":"adr3nald0s@gmail.com","avatar":null},"body":"Daniel Barkalow writes:\n\n> On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:\n>\n>> When you say it linearizes history how is this done.\n>\n> Rebase takes a list of commits that are in the current branch and \n> aren't in the origin branch as what it's going to work on; these are \n> ordered in some arbitrary way such that children always follow parents. It \n> then resets to the origin branch's commit, and, in sequence, cherry-picks \n> each of the commits in the working list.\n\nThanks again for the clear explanation.\n\n> In theory, of course, it could try to resolve conflicts by looking through \n> the rest of the list for merges which would have those conflicts and using \n> what that merge did. \n\nGiven the implementation, this would be just plain ugly. I would not\nwant to attempt to implement something like this, nor would I expect\nanyone else to do so.\n"},{"id":"64154","messageId":"20071228185449.GA30574@atjola.homenet","threadId":"11410","inReplyTo":"m3fxxm7jp6.fsf@euroclydon.lan","subject":"Re: Anomalous conflicts during git rebase","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-12-28T18:54:49Z","receivedAt":"2007-12-28T18:54:49Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.12.28 12:33:41 -0600, adr3nald0s@gmail.com wrote:\n> Daniel Barkalow writes:\n> \n> > On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:\n> >\n> >> When you say it linearizes history how is this done.\n> >\n> > Rebase takes a list of commits that are in the current branch and \n> > aren't in the origin branch as what it's going to work on; these are \n> > ordered in some arbitrary way such that children always follow parents. It \n> > then resets to the origin branch's commit, and, in sequence, cherry-picks \n> > each of the commits in the working list.\n> \n> Thanks again for the clear explanation.\n> \n> > In theory, of course, it could try to resolve conflicts by looking through \n> > the rest of the list for merges which would have those conflicts and using \n> > what that merge did. \n> \n> Given the implementation, this would be just plain ugly. I would not\n> want to attempt to implement something like this, nor would I expect\n> anyone else to do so.\n\nI wouldn't make sense either. The conflict resolution that was done in\nthe merge commit might need stuff from commits that haven't been rebased\nyet. For example a new function that was introduced later, it was\navailable for the merge, but is still missing from the rebased linear\nhistory.\n\nThat said, what _might_ make sense is to teach interactive rebase with\n-p to use \"cherry-pick -m1\" or whatever instead of \"merge\" to recreate\nthe merge commits (or maybe it does that already now? didn't check...).\nThat way, it wouldn't have to rely on rerere being enabled to avoid the\nrepeated resolving of the merge conflicts. I'm not sure how that would\nneed to interact with new changes introduces into one of the rewritten\nbranches.\n\nBjörn\n"}]}