{"thread":{"id":"31377","subject":"git-rerere vs rebase --skip","startedAt":"2012-08-28T21:52:02Z","lastAt":"2012-08-28T22:55:26Z","messageCount":2,"participants":["Mike Hommey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198017","messageId":"20120828215202.GB7702@glandium.org","threadId":"31377","inReplyTo":null,"subject":"git-rerere vs rebase --skip","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2012-08-28T21:52:02Z","receivedAt":"2012-08-28T21:52:02Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nIn one of my workflows, I constantly rebase topic branches on top of new\nupstream imports. As there are several upstream import branches, I have\nsimilar topic branches on top of different imports.\nWhen rebasing the topic branches, I can hit conflict resolution that I\nalready had to do for other topic branches on another upstream import\nbranch. Here, git rerere is very helpful. But sometimes, the conflict\nresolution is just to skip the patch, because it was incorporated\nupstream in a way that git doesn't detect, or it was obsoleted, or\nwhatever. In such cases, git rerere is not being helpful because it\ndoesn't store any information about that, and I have to check again if\nthat's an actual conflict to solve or a patch to skip again.\n\nIt would be helpful if there was a rebase --skip mode that would tell\nrerere to record that the resolution *is* --skip.\n\nMike\n"},{"id":"198020","messageId":"7vzk5ey6ch.fsf@alter.siamese.dyndns.org","threadId":"31377","inReplyTo":"20120828215202.GB7702@glandium.org","subject":"Re: git-rerere vs rebase --skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-28T22:55:26Z","receivedAt":"2012-08-28T22:55:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n> When rebasing the topic branches, I can hit conflict resolution that I\n> already had to do for other topic branches on another upstream import\n> branch. Here, git rerere is very helpful. But sometimes, the conflict\n> resolution is just to skip the patch, because it was incorporated\n> upstream in a way that git doesn't detect, or it was obsoleted, or\n> whatever. In such cases, git rerere is not being helpful because it\n> doesn't store any information about that, and I have to check again if\n> that's an actual conflict to solve or a patch to skip again.\n>\n> It would be helpful if there was a rebase --skip mode that would tell\n> rerere to record that the resolution *is* --skip.\n\nThat is like saying \"my hammer is very helpful when I want to hit\nnails, but sometimes I wish it helped me with screws\".\n\nThe only thing \"rerere\" does is to remember the shape of the\nconflicted state and desired resolution _per_ _file_.  It does not\ntell \"rebase\" what to do next (you do, via \"git add -u\" followed by\n\"git rebase --continue\").\n\nPresumably, you _could_ run \"git checkout HEAD $path\" followed by\n\"git rerere\" to record that a particular shape of the conflicted\nstate should resolve to what you already have in the HEAD commit, so\nthat the same conflict that happens in future rebases automatically\nresolve to a no-op for these conflicted paths, and telling \"rebase\"\nto continue via the same \"add -u && rebase --continue\" might notice\nthat there is no change, and its \"skip empty\" logic might kick in.\n\nBut I wouldn't blindly recommend it.  If a change you are replaying\nhas two paths, one that somehow cleanly merges, and the other that\nconflicts because you do have an equivalent change (and more) in the\nupdated HEAD, letting \"rebase\" continue that way would record only\nthe changes to the first path while ignoring the other one, which\nmay or may not be what you want.\n"}]}