{"thread":{"id":"10479","subject":"merge vs rebase: Is visualization in gitk the only problem?","startedAt":"2007-10-27T07:17:05Z","lastAt":"2007-10-27T20:59:21Z","messageCount":5,"participants":["Steffen Prohaska","David Symonds","Johannes Schindelin","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"57329","messageId":"8E86BDBA-A49A-49BB-8E00-8BF6DD7237E9@zib.de","threadId":"10479","inReplyTo":null,"subject":"merge vs rebase: Is visualization in gitk the only problem?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-27T07:17:05Z","receivedAt":"2007-10-27T07:17:05Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"There are some discussions going on about merge vs. rebase. The\nsuggestions by Dscho is to prefer rebase over merge in a\nCVS-style workflow.\n\nRebase has definitely benefits but not all of its details\nare obvious at a first glance. Tell a newbie to read the\ngit rebase man page and explain what git reabase does and\nyou know what I mean. Rebase definitely can help to create a\ncleaner history. But it rewrites history and therefore destroys\ninformation, for example information about the original code\nbase a patch was developed against, or merge conflicts that\nwere resolved. You also need to decide when to use rebase and\nwhen to use merge. So you need to make a choice.\n\nWhy not always use git merge?\n\nIs the only problem of git merge that it might create loops\nin the history with potentially long running parallel lines\nthat are insufficiently visualized in gitk?\n\nIf so, why not improve the visualization?\n\nOr is there any other deficiency of always using merge and\nnever using rebase that I don't see?\n\nObviously you can use git merge only if you want to have _all_\nchanges from the other branch. But this is often what you\nwant. In a CVS-style workflow you want to merge all changes\nfrom the shared branch before pushing. Why going through the\nhassel of git rebase?\n\nI'm aware that you can do other things with git rebase that\ncannot be achieved by using git merge. For example moving a\ntopic branch to a different stable branch without merging all\nof the topic branch's history (\"--onto\" option). It is easy\nto explain that rebase has it's own value.\n\n\tSteffen\n"},{"id":"57332","messageId":"ee77f5c20710270116g45a644bp2b6783310e16ff20@mail.gmail.com","threadId":"10479","inReplyTo":"8E86BDBA-A49A-49BB-8E00-8BF6DD7237E9@zib.de","subject":"Re: merge vs rebase: Is visualization in gitk the only problem?","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-10-27T08:16:08Z","receivedAt":"2007-10-27T08:16:08Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On 10/27/07, Steffen Prohaska <prohaska@zib.de> wrote:\n>\n> Rebase has definitely benefits but not all of its details\n> are obvious at a first glance. Tell a newbie to read the\n> git rebase man page and explain what git reabase does and\n> you know what I mean. Rebase definitely can help to create a\n> cleaner history. But it rewrites history and therefore destroys\n> information, for example information about the original code\n> base a patch was developed against, or merge conflicts that\n> were resolved. You also need to decide when to use rebase and\n> when to use merge. So you need to make a choice.\n>\n> Why not always use git merge?\n\nI'd use git-rebase for when I'm sending stuff upstream that I don't\nwant to force the maintainer to merge, because I can probably do it\nbetter and quicker by rebasing. Once that's done, the upstream\nmaintainer can just do a git-am (or similar), and it'll apply neatly\non top of the current head. In other words, git-rebase allows the\n\"merge effort\" to be shifted to the brancher and away from the\nmainline maintainer/developer.\n\n\nDave.\n"},{"id":"57342","messageId":"CEA39C15-F9AE-46F5-BBE9-3F7AB0711494@zib.de","threadId":"10479","inReplyTo":"ee77f5c20710270116g45a644bp2b6783310e16ff20@mail.gmail.com","subject":"Re: merge vs rebase: Is visualization in gitk the only problem?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-27T08:58:14Z","receivedAt":"2007-10-27T08:58:14Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 27, 2007, at 10:16 AM, David Symonds wrote:\n\n> On 10/27/07, Steffen Prohaska <prohaska@zib.de> wrote:\n>>\n>> Rebase has definitely benefits but not all of its details\n>> are obvious at a first glance. Tell a newbie to read the\n>> git rebase man page and explain what git reabase does and\n>> you know what I mean. Rebase definitely can help to create a\n>> cleaner history. But it rewrites history and therefore destroys\n>> information, for example information about the original code\n>> base a patch was developed against, or merge conflicts that\n>> were resolved. You also need to decide when to use rebase and\n>> when to use merge. So you need to make a choice.\n>>\n>> Why not always use git merge?\n>\n> I'd use git-rebase for when I'm sending stuff upstream that I don't\n> want to force the maintainer to merge, because I can probably do it\n> better and quicker by rebasing. Once that's done, the upstream\n> maintainer can just do a git-am (or similar), and it'll apply neatly\n> on top of the current head. In other words, git-rebase allows the\n> \"merge effort\" to be shifted to the brancher and away from the\n> mainline maintainer/developer.\n\nThat definitely makes sense.\n\nBut you may need to do more merging because you need to merge every\nsingle commit. It may be easier to merge only the final state of\na topic branch.\n\nCould we somehow send rerere information together with a\npatch? This would give the upstream maintainer (and everyone\nelse who wants to test the patch) the help needed to do a merge.\n\n\tSteffen\n"},{"id":"57350","messageId":"Pine.LNX.4.64.0710271332030.4362@racer.site","threadId":"10479","inReplyTo":"CEA39C15-F9AE-46F5-BBE9-3F7AB0711494@zib.de","subject":"Re: merge vs rebase: Is visualization in gitk the only problem?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-27T12:33:59Z","receivedAt":"2007-10-27T12:33:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 27 Oct 2007, Steffen Prohaska wrote:\n\n> Could we somehow send rerere information together with a patch? This \n> would give the upstream maintainer (and everyone else who wants to test \n> the patch) the help needed to do a merge.\n\nIMHO this is not sensible to send over email.  But think I that something \nlike this could be done for pullers: they fetch from somewhere, and then \nrecreate the rerere information from the merge commits they just got (this \nwould have to be a new option to git-rerere, methinks).\n\nCiao,\nDscho\n"},{"id":"57375","messageId":"Pine.LNX.4.64.0710271609180.7345@iabervon.org","threadId":"10479","inReplyTo":"8E86BDBA-A49A-49BB-8E00-8BF6DD7237E9@zib.de","subject":"Re: merge vs rebase: Is visualization in gitk the only problem?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-27T20:59:21Z","receivedAt":"2007-10-27T20:59:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 27 Oct 2007, Steffen Prohaska wrote:\n\n> There are some discussions going on about merge vs. rebase. The\n> suggestions by Dscho is to prefer rebase over merge in a\n> CVS-style workflow.\n> \n> Rebase has definitely benefits but not all of its details\n> are obvious at a first glance. Tell a newbie to read the\n> git rebase man page and explain what git reabase does and\n> you know what I mean. Rebase definitely can help to create a\n> cleaner history. But it rewrites history and therefore destroys\n> information, for example information about the original code\n> base a patch was developed against, or merge conflicts that\n> were resolved. You also need to decide when to use rebase and\n> when to use merge. So you need to make a choice.\n> \n> Why not always use git merge?\n> \n> Is the only problem of git merge that it might create loops\n> in the history with potentially long running parallel lines\n> that are insufficiently visualized in gitk?\n>\n> If so, why not improve the visualization?\n> \n> Or is there any other deficiency of always using merge and\n> never using rebase that I don't see?\n\nNot all possible upstream systems support non-linear history. If upstream \nis actually svn or cvs, you need to rebase in order for the other system \nto be able to represent the result.\n\nI think it's easier for someone from the future trying to figure out the \nhistorical reason for some code to be a certain way if that code isn't \ntouched by a merge conflict resolution. If there is a conflict, the \nresulting content is most directly due to a commit that has no explanation \naside from a note that there was a conflict there; it's somewhat easier to \nunderstand if the code is entirely attributable to the commit that \nlogically introduces the change. (Although maybe we could make the display \ntake care of this; linearize the history using the rerere info in the \nmerge commit, and show that as the history, annotated suitably to indicate \nthat the blame for some of it falls partially on the merge commit.)\n\nIt's also more familiar for many users to be asked to place their changes \nafter all other committed changes, rather than leaving the ancestry pegged \nat the last time they updated before starting to work.\n\n> Obviously you can use git merge only if you want to have _all_\n> changes from the other branch. But this is often what you\n> want. In a CVS-style workflow you want to merge all changes\n> from the shared branch before pushing. Why going through the\n> hassel of git rebase?\n\nUnless you've got a series of changes to a section that the upstream also \nchanged, it's the same amount of resolution, but rebase lets you resolve \nlogical collections of conflicts (i.e., those due to a single one of your \ncommits) individually. IIRC, merging my builtin-fetch topic after 1.5.3 \nhad 3 scattered conflicts, and rebasing had 4 conflicts, with no more than \none per commit (so that I could test the resolutions independantly), and \nthe rebase was easier.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}