{"thread":{"id":"22429","subject":"Questions about branches in git","startedAt":"2010-01-28T18:44:26Z","lastAt":"2010-01-29T10:07:55Z","messageCount":21,"participants":["Mike Linck","Michael Witten","Jens Lehmann","Nicolas Pitre","David Aguilar","Eugene Sajine","Martin Langhoff","Heiko Voigt","Junio C Hamano","Nanako Shiraishi","Peter Krefting"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132902","messageId":"69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com","threadId":"22429","inReplyTo":null,"subject":"Questions about branches in git","fromName":"Mike Linck","fromEmail":"mgl@absolute-performance.com","sentAt":"2010-01-28T18:44:26Z","receivedAt":"2010-01-28T18:44:26Z","isPatch":false,"sender":{"key":"mgl@absolute-performance.com","avatar":null},"body":"Hi, my company switched to git a few months ago because the way it\nhandles submodules seems safer to us than our previous scm tool and\nbecause our ruby developers wanted to take advantage of the community\non github. However, I'm having some problems getting git's\nrepresentations of branches to show me what change sets they contain.\nIt seems that after a topic or bug branch is merged back into its\nparent, especially if it was fast forwarded, it becomes hard to\ndetermine what changes were made in it, to resolve the problem that it\nwas created to address. This is fairly important to me since I need\nto be able to backport fixes to older revisions on occasion, and to\nperform development on multiple releases for multiple platforms in\nparallel, so it seems really handy for a branch to show us just the\nchanges that were made in it, between the time it was spawned from its\nparent and the time the parent accepted its changes.\n\nI've looked through as much documentation as I can find about git show\nand git log, and I've played around with git rebase to try to apply\nchanges to multiple places, but I have not been able to find a way to\ndisplay the commits relevant to a particular bug/topic branch.\nRebasing from a branch that has already had the changeset merged back\nin, to another branch, seems to actually wipe out the contents of the\nbranch completely.\n\nI understand that there are mechanism kind of available to address\nthis problem. If we (all developers in my company) remember always to\nrebase -i before they merge their topic branches back in, then it\ncould be squashed making it easier to identify and cherry pick onto\nother branches, or *if* we always remember to rebase before we merge\nand then create a patch set and store that on the topic branch, we\ncould kind of organize our change sets that way. But it seems that it\nshould be easier than that, shouldn't it? If I look at the git log\nfor a branch, I really feel that I should see some distinction between\nthat changes that were originally made on a branch, and the ones that\nwere inherited from some other branch or merged in from some other\nbranch. Simply because mistakes get made and if you we don't realize\nthat a fix may need to be applied to some older revision when we first\ndevelop it, it seems that this could really cost a lot of time and\nmoney to try to identify the individual commits that were useful in\naddressing the problem.\n\nWhat am I missing here?\n\nAny help is appreciated.\n\nThank you,\n\nMichael Linck\n"},{"id":"132904","messageId":"b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com","threadId":"22429","inReplyTo":"69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-28T20:03:31Z","receivedAt":"2010-01-28T20:03:31Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck\n wrote:\n> ...\n> It seems that after a topic or bug branch is merged back into its\n> parent, especially if it was fast forwarded, it becomes hard to\n> determine what changes were made in it, to resolve the problem that it\n> was created to address.\n> ...\n> I understand that there are mechanism kind of available to address\n> this problem.  If we (all developers in my company) remember always to\n> rebase -i before they merge their topic branches back in, then it\n> could be squashed making it easier to identify and cherry pick onto\n> other branches...\n\nFor now, you should probably rely on graphical tools like gitk in\norder to visualize the various branches. There's also `git log\n--graph'. You could also just keep your branches around for reference\nand use `git merge-base' as necessary.\n\nHowever, I've been thinking for a while that it would be useful to\nhave übercommits (they don't exist) that are treated like single\ncommits but that actually encapsulate multiple continguous commits.\n\nFor your case, you could tell git to make merges by creating such\nübercommits, which would then be easily identified, referenced, and\nmanipulated for your backporting purposes; such übercommits would\nencapsulate the relevant commits.\n\nThese übercommits would also allow developers to make a string of\ncommits that by themselves break things but together formulate a\ncomplete solution; because the übercommits encapsulate the breakage,\nbisection would still be simple (no fear of dealing with broken\ncommits), but the small manageable commits would still be available\nfor references and manipulation.\n\nPerhaps trees could be reappropriated for the implementation of übercommits.\n\nSincerely,\nMichael Witten\n"},{"id":"132905","messageId":"4b61f1a8.02c3f10a.6608.ffff8a5f@mx.google.com","threadId":"22429","inReplyTo":"b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-28T20:20:56Z","receivedAt":"2010-01-28T20:20:56Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten wrote:\n> However, I've been thinking for a while that it would be useful to\n> have übercommits (they don't exist) that are treated like single\n> commits but that actually encapsulate multiple continguous commits.\n\nIn fact, the commit message body is already being used to create\nunofficial übercommits. Consider a common merge commit from a\nclone of Linus's Linux repo:\n\n commit e80b1359858df17b0034bdf7d1b6f3e0d5b97257\n Merge: 341031c b27d515\n Author: Linus Torvalds \n Date: Thu Jan 21 08:50:04 2010 -0800\n \n Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip\n \n * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:\n perf: x86: Add support for the ANY bit\n perf: Change the is_software_event() definition\n perf: Honour event state for aux stream data\n perf: Fix perf_event_do_pending() fallback callsite\n perf kmem: Print usage help for unknown commands\n perf kmem: Increase \"Hit\" column length\n hw-breakpoints, perf: Fix broken mmiotrace due to dr6 by reference change\n perf timechart: Use tid not pid for COMM change\n\nIt seems like this kind of useful information should be a more\nintegral part of the metadata.\n\nIndeed, it seems like commit messages are often used for metadata\nthat git perhaps *should* handle natively, like sign-offs and\nmultiple Authors, etc.\n\nOf course, I'm betting that git doesn't handle such things\nofficially because it would require more general data structures\n(especially for variable numbers of Authors) and thus slower\nalgorithms.\n\nSincerely,\nMichael Witten\n"},{"id":"132908","messageId":"4b61f52f.1d255e0a.4cc1.7f37@mx.google.com","threadId":"22429","inReplyTo":"b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-28T20:35:59Z","receivedAt":"2010-01-28T20:35:59Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten wrote:\n> These übercommits would also allow developers to make a string of\n> commits that by themselves break things but together formulate a\n> complete solution; because the übercommits encapsulate the breakage,\n> bisection would still be simple (no fear of dealing with broken\n> commits), but the small manageable commits would still be available\n\nAs a corollary to this, developers can maintain patch integrity.\n\nQuite often, I've sent a patch off to some project only to have\nthe maintainer `tweak' the result before making a commit. However,\nI frankly don't want my name attached to someone else's work,\nbecause I may disagree with what has been done.\n\nWere übercommits available, the maintainer could commit my original\nwork and then make a new `tweak' commit and then bundle the 2 together\nas an übercommit in order to encapsulate this series of events.\n"},{"id":"132910","messageId":"69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com","threadId":"22429","inReplyTo":"b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Mike Linck","fromEmail":"mgl@absolute-performance.com","sentAt":"2010-01-28T21:17:26Z","receivedAt":"2010-01-28T21:17:26Z","isPatch":false,"sender":{"key":"mgl@absolute-performance.com","avatar":null},"body":"On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten wrote:\n> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck\n> wrote:\n>> ...\n>> It seems that after a topic or bug branch is merged back into its\n>> parent, especially if it was fast forwarded, it becomes hard to\n>> determine what changes were made in it, to resolve the problem that it\n>> was created to address.\n>> ...\n>> I understand that there are mechanism kind of available to address\n>> this problem.  If we (all developers in my company) remember always to\n>> rebase -i before they merge their topic branches back in, then it\n>> could be squashed making it easier to identify and cherry pick onto\n>> other branches...\n>\n> For now, you should probably rely on graphical tools like gitk in\n> order to visualize the various branches. There's also `git log\n\nWell, even gitk can't show me the information I'm looking for if the\nparent branch ended up fast-forwarding to include the changes made in\nthe topic branch. As far as I can tell there is *no way* to tell what\nchanges were made in a particular branch after a fast-forward has\ntaken place, which seems to make it hard to organize fixes for\nspecific topics/bugs/tickets.\n\n> --graph'. You could also just keep your branches around for reference\n> and use `git merge-base' as necessary.\n>\n\nYeah, what concerns me is that there seems to be no point in keeping\nyour branches around \"for reference\" because even when you're looking\nat them you can't tell what changes were made in them after they were\nspawned, unless they haven't been merged into another branch yet. So\nit seems that a branch is only useful for merging once and unless the\nbranch was squashed in the process of mergin, good luck identifying\nyour change set for a particular topic.\n\nI don't know if an uebercommit is necessary. But it would help seem\nlike it would help if a branch knew about it's spawn point from its\nparent, and if you could use that to get git log to only show you the\ncommits made to a branch after it was spawned. And if there were\nforms of operations like merge, or rebase that could act intelligently\nbased on that information like \"merge this branch into that branch,\nand by this branch I don't mean anything from this branch's parent\nbranch\" so that a fix that was developed on edge or master could be\nsafely merged into an old branch without importing every other change\non edge or master, and also the other way around.\n\n\nI just looked at merge-base. It doesn't seem to address the problem.\nI grabbed an old topic branch from our repo which I knew was created\nfrom master and at some point merged back into master via\nfast-forward. I checked it out, I called \"git merge base topic-id\nmaster\", hoping that it would \"output a commit which is reachable from\nboth A and B through the parent relationship.\" Instead it seems to\nhave modified the topic branch by fast forwarding it to the include\nall the changes up to the tip of master. Clearly not what I'm looking\nfor.\n\n\nMichael Linck\n"},{"id":"132912","messageId":"4B6201BC.9030800@web.de","threadId":"22429","inReplyTo":"69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-01-28T21:29:32Z","receivedAt":"2010-01-28T21:29:32Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.01.2010 22:17, schrieb Mike Linck:\n> Well, even gitk can't show me the information I'm looking for if the\n> parent branch ended up fast-forwarding to include the changes made in\n> the topic branch. As far as I can tell there is *no way* to tell what\n> changes were made in a particular branch after a fast-forward has\n> taken place, which seems to make it hard to organize fixes for\n> specific topics/bugs/tickets.\n\nYou could disable fast forward merges using the --no-ff option. Then\ngit will always create a merge commit even if it could have done a\nfast forward. This can be enabled permanently for a branch with\n'git config branch.master.mergeoptions \"--no-ff\"'. We use that at my\ndayjob to preserve the branches after merging.\n"},{"id":"132914","messageId":"69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com","threadId":"22429","inReplyTo":"4B6201BC.9030800@web.de","subject":"Re: Questions about branches in git","fromName":"Mike Linck","fromEmail":"mgl@absolute-performance.com","sentAt":"2010-01-28T21:38:14Z","receivedAt":"2010-01-28T21:38:14Z","isPatch":false,"sender":{"key":"mgl@absolute-performance.com","avatar":null},"body":"On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann wrote:\n> Am 28.01.2010 22:17, schrieb Mike Linck:\n>> Well, even gitk can't show me the information I'm looking for if the\n>> parent branch ended up fast-forwarding to include the changes made in\n>> the topic branch.  As far as I can tell there is *no way* to tell what\n>> changes were made in a particular branch after a fast-forward has\n>> taken place, which seems to make it hard to organize fixes for\n>> specific topics/bugs/tickets.\n>\n> You could disable fast forward merges using the --no-ff option. Then\n> git will always create a merge commit even if it could have done a\n> fast forward. This can be enabled permanently for a branch with\n> 'git config branch.master.mergeoptions  \"--no-ff\"'. We use that at my\n> dayjob to preserve the branches after merging.\n>\n\nOK, so what I'm getting is that if a developer forgot to disable\nfast-forward when they created a topic branch, and if the parent\nbranch has been fast forwarded to include it, then you might as well\njust throw away the topic branch, is that correct?\n\nCould anyone point me to a good book that actually describes the style\nof code management that git was intended to support? Because I'm\nfinding this a bit baffling, to be honest. I thought it was intended\nto make the developers' side of code management easier to do, but it\nseems to me that they have to think a lot harder about what they're\ntrying to accomplish, at least in this sort of case. I'm not trying\nto be rude, but I just feel that if I want to keep working with this\ntool, I have to rethink how the code is organized in a pretty\nfundamental way and I'd like to get as comprehensive of a guide as\npossible from someone who has adopted their tactics to it.\n\nThanks\n\nMichael Linck\n"},{"id":"132916","messageId":"alpine.LFD.2.00.1001281656440.1681@xanadu.home","threadId":"22429","inReplyTo":"69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-01-28T22:04:36Z","receivedAt":"2010-01-28T22:04:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 28 Jan 2010, Mike Linck wrote:\n\n> Well, even gitk can't show me the information I'm looking for if the\n> parent branch ended up fast-forwarding to include the changes made in\n> the topic branch. As far as I can tell there is *no way* to tell what\n> changes were made in a particular branch after a fast-forward has\n> taken place, which seems to make it hard to organize fixes for\n> specific topics/bugs/tickets.\n\nYou should consider using tags in conjunction with your bugs/tickets \nsystem. The fork point for a bug fix may be tagged, as well as the last \ncommit representing the bugfix completion (not the merge point though). \nThis way you can always retrieve the exact set of commits forming up \nthat bugfix, regardless if it was merged back into the main branch with \na fast forward or not.\n\n\nNicolas\n"},{"id":"132919","messageId":"76c5b8581001281413v361e4bd8w5a74129c2ce1f05b@mail.gmail.com","threadId":"22429","inReplyTo":"alpine.LFD.2.00.1001281656440.1681@xanadu.home","subject":"Re: Questions about branches in git","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-01-28T22:13:24Z","receivedAt":"2010-01-28T22:13:24Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"I agree with Nicolas here - i was also thinking about using\nlightweight tags in this case. If you really, really need to port\nchanges to multiple branches, tags would show you exactly which\ncommits you should work with.\n\ngit log tag1(branched)..tag2(brnach_ready)\n\nIn addition to that i shold say that most of the time branches are\nsupposed to be created from the latest stable master, i.e. released\ncode. Each release should be tagged. So, in this case you don't need\nto have to have the first tag, as you branching from a tagged commit.\nAs soon as you have first point, second tag may be not necessary until\nyou can operate with the last commit. As soon as it is not possible -\nyou can create lightweight tag.\n\nOn Thu, Jan 28, 2010 at 5:04 PM, Nicolas Pitre wrote:\n>\n> On Thu, 28 Jan 2010, Mike Linck wrote:\n>\n> > Well, even gitk can't show me the information I'm looking for if the\n> > parent branch ended up fast-forwarding to include the changes made in\n> > the topic branch.  As far as I can tell there is *no way* to tell what\n> > changes were made in a particular branch after a fast-forward has\n> > taken place, which seems to make it hard to organize fixes for\n> > specific topics/bugs/tickets.\n>\n> You should consider using tags in conjunction with your bugs/tickets\n> system.  The fork point for a bug fix may be tagged, as well as the last\n> commit representing the bugfix completion (not the merge point though).\n> This way you can always retrieve the exact set of commits forming up\n> that bugfix, regardless if it was merged back into the main branch with\n> a fast forward or not.\n>\n>\n> Nicolas\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"132917","messageId":"20100128221439.GA6327@gmail.com","threadId":"22429","inReplyTo":"alpine.LFD.2.00.1001281656440.1681@xanadu.home","subject":"Re: Questions about branches in git","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2010-01-28T22:14:41Z","receivedAt":"2010-01-28T22:14:41Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Jan 28, 2010 at 05:04:36PM -0500, Nicolas Pitre wrote:\n> On Thu, 28 Jan 2010, Mike Linck wrote:\n> \n> > Well, even gitk can't show me the information I'm looking for if the\n> > parent branch ended up fast-forwarding to include the changes made in\n> > the topic branch. As far as I can tell there is *no way* to tell what\n> > changes were made in a particular branch after a fast-forward has\n> > taken place, which seems to make it hard to organize fixes for\n> > specific topics/bugs/tickets.\n> \n> You should consider using tags in conjunction with your bugs/tickets \n> system. The fork point for a bug fix may be tagged, as well as the last \n> commit representing the bugfix completion (not the merge point though). \n> This way you can always retrieve the exact set of commits forming up \n> that bugfix, regardless if it was merged back into the main branch with \n> a fast forward or not.\n> \n> \n> Nicolas\n\nTags, combined with --no-ff, should help you out a bit.\nIf you're worried about devs forgetting to configure the no-ff\nthen you might be able to help them out if you have any control\nover /etc/gitconfig on their systems. That gives you a\nstandard, global way to set defaults.\n\nThis table gives a great summary of 'git log' commands for\ninspecting branches.\n\nhttp://book.git-scm.com/3_reviewing_history_-_git_log.html\n\n\nAs far as \"what's the way to do branches right in git\" then\nthere is no \"one single way\" because git is a framework upon\nwhich you can build your ideal workflow. That said, there are\nsome very good examples to follow. For example, there is much\nthat can be learned by studying how git.git's branches are\nmanaged.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html\n\nThis webcast covers a few more workflows and is a very good\ncrash course:\n\nhttp://www.gitcasts.com/posts/railsconf-git-talk\n\n-- \n\t\tDavid\n"},{"id":"132918","messageId":"b4087cc51001281418m3f19d765rd9aab03a339f15a4@mail.gmail.com","threadId":"22429","inReplyTo":"69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-28T22:18:58Z","receivedAt":"2010-01-28T22:18:58Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck\n wrote:\n> On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten wrote:\n>> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck\n>> wrote:\n>>> ...\n>>> It seems that after a topic or bug branch is merged back into its\n>>> parent, especially if it was fast forwarded, it becomes hard to\n>>> determine what changes were made in it, to resolve the problem that it\n>>> was created to address.\n>>> ...\n>>> I understand that there are mechanism kind of available to address\n>>> this problem. If we (all developers in my company) remember always to\n>>> rebase -i before they merge their topic branches back in, then it\n>>> could be squashed making it easier to identify and cherry pick onto\n>>> other branches...\n>>\n>> For now, you should probably rely on graphical tools like gitk in\n>> order to visualize the various branches. There's also `git log\n>\n> Well, even gitk can't show me the information I'm looking for if the\n> parent branch ended up fast-forwarding to include the changes made in\n> the topic branch....\n\nAs Jens Lehmann pointed out, use something like:\n\n git checkout master\n git pull --no-ff . topic\n\n>> --graph'. You could also just keep your branches around for reference\n>> and use `git merge-base' as necessary.\n>>\n> ...\n> it seems that a branch is only useful for merging once and unless the\n> branch was squashed in the process of mergin, good luck identifying\n> your change set for a particular topic.\n> ...\n\nI would think that you'd only care about the contiguous commits\nbetween merges anyway.\n\n> I just looked at merge-base. It doesn't seem to address the problem.\n> I grabbed an old topic branch from our repo which I knew was created\n> from master and at some point merged back into master via\n> fast-forward. I checked it out, I called \"git merge base topic-id\n> master\", hoping that it would \"output a commit which is reachable from\n> both A and B through the parent relationship.\" Instead it seems to\n> have modified the topic branch by fast forwarding it to the include\n> all the changes up to the tip of master. Clearly not what I'm looking\n> for.\n\nYou incorrectly used `git merge' rather than `git merge-base'.\n\nThis is kind of off the top of my head. Try something like this:\n\n merged_commit_0=$(git merge-base master topic-id)\n merged_commit_1=$(git merge-base master ${merged_commit_0}^)\n\nI think that should give you the range of commits between the last 2\nmerges (for at least simple cases). Then:\n\n git log $merged_commit_1^..$merged_commit_0\n\nor\n\n gitk $merged_commit_1..$merged_commit_0\n\nto see them.\n\nYou could, I suppose, keep looping until you find the oldest\nmerge-base that is still in the topic-id branch. To do so, the\nfollowing information may be of use:\n\n http://marc.info/?l=git&m=126457707700573&w=2\n\nAnyway, it's probably best to use Nicolas Pitre's suggestion to use\ntags to mark commits yourself, but the above might be useful if you\nhaven't.\n"},{"id":"132920","messageId":"69b754db1001281456k7c275550r5ffde67b254b510e@mail.gmail.com","threadId":"22429","inReplyTo":"b4087cc51001281418m3f19d765rd9aab03a339f15a4@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Mike Linck","fromEmail":"mgl@absolute-performance.com","sentAt":"2010-01-28T22:56:30Z","receivedAt":"2010-01-28T22:56:30Z","isPatch":false,"sender":{"key":"mgl@absolute-performance.com","avatar":null},"body":"On Thu, Jan 28, 2010 at 3:18 PM, Michael Witten wrote:\n> On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck\n> wrote:\n>> On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten wrote:\n>>> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck\n>>> wrote:\n>>>> ...\n>>>> It seems that after a topic or bug branch is merged back into its\n>>>> parent, especially if it was fast forwarded, it becomes hard to\n>>>> determine what changes were made in it, to resolve the problem that it\n>>>> was created to address.\n>>>> ...\n>>>> I understand that there are mechanism kind of available to address\n>>>> this problem.  If we (all developers in my company) remember always to\n>>>> rebase -i before they merge their topic branches back in, then it\n>>>> could be squashed making it easier to identify and cherry pick onto\n>>>> other branches...\n>>>\n>>> For now, you should probably rely on graphical tools like gitk in\n>>> order to visualize the various branches. There's also `git log\n>>\n>> Well, even gitk can't show me the information I'm looking for if the\n>> parent branch ended up fast-forwarding to include the changes made in\n>> the topic branch....\n>\n> As Jens Lehmann pointed out, use something like:\n>\n>    git checkout master\n>    git pull --no-ff . topic\n>\n>>> --graph'. You could also just keep your branches around for reference\n>>> and use `git merge-base' as necessary.\n>>>\n>> ...\n>> it seems that a branch is only useful for merging once and unless the\n>> branch was squashed in the process of mergin, good luck identifying\n>> your change set for a particular topic.\n>> ...\n>\n> I would think that you'd only care about the contiguous commits\n> between merges anyway.\n>\n>> I just looked at merge-base.  It doesn't seem to address the problem.\n>> I grabbed an old topic branch from our repo which I knew was created\n>> from master and at some point merged back into master via\n>> fast-forward.  I checked it out, I called \"git merge base topic-id\n>> master\", hoping that it would \"output a commit which is reachable from\n>> both A and B through the parent relationship.\"  Instead it seems to\n>> have modified the topic branch by fast forwarding it to the include\n>> all the changes up to the tip of master.  Clearly not what I'm looking\n>> for.\n>\n> You incorrectly used `git merge' rather than `git merge-base'.\n>\n> This is kind of off the top of my head. Try something like this:\n>\n>    merged_commit_0=$(git merge-base master topic-id)\n>    merged_commit_1=$(git merge-base master ${merged_commit_0}^)\n>\n> I think that should give you the range of commits between the last 2\n> merges (for at least simple cases). Then:\n>\n>    git log $merged_commit_1^..$merged_commit_0\n>\n> or\n>\n>    gitk $merged_commit_1..$merged_commit_0\n>\n> to see them.\n>\n> You could, I suppose, keep looping until you find the oldest\n> merge-base that is still in the topic-id branch. To do so, the\n> following information may be of use:\n>\n>    http://marc.info/?l=git&m=126457707700573&w=2\n>\n> Anyway, it's probably best to use Nicolas Pitre's suggestion to use\n> tags to mark commits yourself, but the above might be useful if you\n> haven't.\n>\n\nWell, I'll be using tags more in the future and I'll look through some\nmore documentation about recommended workflows and see if I can work\nout something that will do what we need to do.\n\nYour example will work on non-FF branches if you make the second\nmerge-base use master~1 (else it just gives you the same commit sha\ntwice)\n\nThe tough thing to identify is the change sets that got fast-forwarded\nin though. I guess I'll just go ahead and erase those branches since\nthey won't do any of us any good anyway and I'll read up on the work\nflow, and try to avoid having the same mistakes recur.\n\nthanks again,\n\nmike\n"},{"id":"132921","messageId":"46a038f91001281500x5088206akb7390dec8839a169@mail.gmail.com","threadId":"22429","inReplyTo":"69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-01-28T23:00:55Z","receivedAt":"2010-01-28T23:00:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Jan 28, 2010 at 7:44 PM, Mike Linck\n wrote:\n> I've looked through as much documentation as I can find about git show\n> and git log, and I've played around with git rebase to try to apply\n> changes to multiple places, but I have not been able to find a way to\n> display the commits relevant to a particular bug/topic branch.\n\nI've done a similar job for quite a while, and kernel hackers need\nthat all the time too. If the branches merge a lot, what you need to\nknow is what patches are only on one side, and not on the other. Two\nthings to the rescue:\n\n - the \"3 dots\" \"...\" separator. try with gitk and git log:\n git log mybranch...hisbranch\n git log hisbranch...mybranch\n\n - git am (which is part of the rebase machinery) does the same as the\n\"...\" operator, but has additional tricks to try and spot commits that\nhave been cherry picked. So I would often export patches with git am\njust to review what' s on one side.\n\nhth,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"132922","messageId":"b4087cc51001281501y67a35f22k732c412ce2b46fb1@mail.gmail.com","threadId":"22429","inReplyTo":"69b754db1001281456k7c275550r5ffde67b254b510e@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-28T23:01:34Z","receivedAt":"2010-01-28T23:01:34Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Jan 28, 2010 at 4:56 PM, Mike Linck\n wrote:\n> Your example will work on non-FF branches if you make the second\n> merge-base use master~1 (else it just gives you the same commit sha\n> twice)\n\nThat's the point of the '^' character that I used in my example; it\nwasn't a mistake.\n"},{"id":"132923","messageId":"20100128230726.GC39683@book.hvoigt.net","threadId":"22429","inReplyTo":"69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com","subject":"Re: Re: Questions about branches in git","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2010-01-28T23:07:27Z","receivedAt":"2010-01-28T23:07:27Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Jan 28, 2010 at 02:38:14PM -0700, Mike Linck wrote:\n> On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann wrote:\n> > Am 28.01.2010 22:17, schrieb Mike Linck:\n> >> Well, even gitk can't show me the information I'm looking for if the\n> >> parent branch ended up fast-forwarding to include the changes made in\n> >> the topic branch.  As far as I can tell there is *no way* to tell what\n> >> changes were made in a particular branch after a fast-forward has\n> >> taken place, which seems to make it hard to organize fixes for\n> >> specific topics/bugs/tickets.\n> >\n> > You could disable fast forward merges using the --no-ff option. Then\n> > git will always create a merge commit even if it could have done a\n> > fast forward. This can be enabled permanently for a branch with\n> > 'git config branch.master.mergeoptions  \"--no-ff\"'. We use that at my\n> > dayjob to preserve the branches after merging.\n> >\n> \n> OK, so what I'm getting is that if a developer forgot to disable\n> fast-forward when they created a topic branch, and if the parent\n> branch has been fast forwarded to include it, then you might as well\n> just throw away the topic branch, is that correct?\n\nIf you want to enforce this you can use an update hook on the receivers\nside and check that a branch update can only be made to real merge\ncommits.\n\nThe practise we use at $dayjob is that we prepackage git installations\ncontaining default values in /etc/gitconfig so its not easily forgotten.\n\n> Could anyone point me to a good book that actually describes the style\n> of code management that git was intended to support? Because I'm\n> finding this a bit baffling, to be honest. I thought it was intended\n> to make the developers' side of code management easier to do, but it\n> seems to me that they have to think a lot harder about what they're\n> trying to accomplish, at least in this sort of case. I'm not trying\n> to be rude, but I just feel that if I want to keep working with this\n> tool, I have to rethink how the code is organized in a pretty\n> fundamental way and I'd like to get as comprehensive of a guide as\n> possible from someone who has adopted their tactics to it.\n\nAs stated in a later message there is no such thing as the design goal\nfor git. Its designed by practise which has made it so flexible that you\ncan design you own.\n\ncheers Heiko\n"},{"id":"132924","messageId":"7v636lls8d.fsf@alter.siamese.dyndns.org","threadId":"22429","inReplyTo":"69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-28T23:33:38Z","receivedAt":"2010-01-28T23:33:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Linck writes:\n\n> I understand that there are mechanism kind of available to address\n> this problem. If we (all developers in my company) remember always to\n> rebase -i before they merge their topic branches back in, then it\n> could be squashed making it easier to identify and cherry pick onto\n> other branches, or *if* we always remember to rebase before we merge\n> and then create a patch set and store that on the topic branch, we\n> could kind of organize our change sets that way.\n\nOn the quite contrary, probably an easier way is to pick a the oldest\ncommit that a fix or enhancement would apply, build a topic that deals\nwith only the fix or enhancement in question without doing anything else\non top of it, and merge the resulting topic. The choice of the fork point\nneeds to be made wisely in such a way that the resulting topic would not\ncause too much undue conflicts when merged to a modern mainline but old\nenough that you _could_ merge the result to any older maintenance branch\nif you choose to.\n\nOne implication is that you do _not_ rebase the series to newer codebase\nbecause doing so would make the result unmergeable to older releases even\nif you later realize that the fix/enhancement would be suitable to them.\n\nAnd if you fork from older commit than tip, you will automatically get a\nnon-ff merge when you merge it back to the mainline, which would delineate\nthe history of the side branch from the integration branches rather\nnicely.\n"},{"id":"132926","messageId":"20100129090345.6117@nanako3.lavabit.com","threadId":"22429","inReplyTo":"69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2010-01-29T00:03:45Z","receivedAt":"2010-01-29T00:03:45Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Mike Linck \n\n> Could anyone point me to a good book that actually describes the style\n> of code management that git was intended to support?\n\nYou may want to add the result of googling \n\n \"Fun with\" site:gitster.livejournal.com\n\nto the list of Git documents you read. \"Fork from the oldest branch\" is one of the techniques Junio teaches often and many of his other techiniques are built upon.\n\nHe not just teaches useful techniques but explains a lot about the reasoning behind them in his Git book. His blog articles have similar explanations on many topics I saw in his book but not in other places. It is a useful substitute until his book gets translated to English for people who don't read Japanese.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"132927","messageId":"69b754db1001281716i605c5c0fl50031ec008e2d216@mail.gmail.com","threadId":"22429","inReplyTo":"7v636lls8d.fsf@alter.siamese.dyndns.org","subject":"Re: Questions about branches in git","fromName":"Mike Linck","fromEmail":"mgl@absolute-performance.com","sentAt":"2010-01-29T01:16:29Z","receivedAt":"2010-01-29T01:16:29Z","isPatch":false,"sender":{"key":"mgl@absolute-performance.com","avatar":null},"body":"On Thu, Jan 28, 2010 at 4:33 PM, Junio C Hamano wrote:\n> Mike Linck writes:\n>\n>> I understand that there are mechanism kind of available to address\n>> this problem.  If we (all developers in my company) remember always to\n>> rebase -i before they merge their topic branches back in, then it\n>> could be squashed making it easier to identify and cherry pick onto\n>> other branches, or *if* we always remember to rebase before we merge\n>> and then create a patch set and store that on the topic branch, we\n>> could kind of organize our change sets that way.\n>\n> On the quite contrary, probably an easier way is to pick a the oldest\n> commit that a fix or enhancement would apply, build a topic that deals\n> with only the fix or enhancement in question without doing anything else\n> on top of it, and merge the resulting topic.  The choice of the fork point\n> needs to be made wisely in such a way that the resulting topic would not\n> cause too much undue conflicts when merged to a modern mainline but old\n> enough that you _could_ merge the result to any older maintenance branch\n> if you choose to.\n>\n> One implication is that you do _not_ rebase the series to newer codebase\n> because doing so would make the result unmergeable to older releases even\n> if you later realize that the fix/enhancement would be suitable to them.\n>\n> And if you fork from older commit than tip, you will automatically get a\n> non-ff merge when you merge it back to the mainline, which would delineate\n> the history of the side branch from the integration branches rather\n> nicely.\n>\n\nnice!\n"},{"id":"132936","messageId":"7vtyu5k3xz.fsf@alter.siamese.dyndns.org","threadId":"22429","inReplyTo":"20100129090345.6117@nanako3.lavabit.com","subject":"Re: Questions about branches in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-29T03:03:36Z","receivedAt":"2010-01-29T03:03:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Mike Linck \n>\n>> Could anyone point me to a good book that actually describes the style\n>> of code management that git was intended to support?\n>\n> You may want to add the result of googling \n>\n> \"Fun with\" site:gitster.livejournal.com\n>\n> to the list of Git documents you read. \"Fork from the oldest branch\" is\n> one of the techniques Junio teaches often and many of his other\n> techiniques are built upon.\n> ... It is a useful substitute until his book gets translated to English\n> for people who don't read Japanese.\n\nQuite honestly, I don't think my blog articles are all that good;\ncertainly not as good as the book, as I don't draw pictures.\n\nFor this particular topic, I would instead recommend:\n\n http://nvie.com/archives/323 (A successful Git branching model)\n\nWhat it teaches isn't anything earth-shattering (it's the same old \"how to\nuse topic branch effectively\" and I don't necessarily agree with the\nchoice of fork points of topic branches depicted in the article), but\npeople seem to like its graphics very much and it is scoring quite high in\ndelicio.us.\n"},{"id":"132943","messageId":"alpine.DEB.2.00.1001291103300.25954@ds9.cixit.se","threadId":"22429","inReplyTo":"69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-01-29T10:06:07Z","receivedAt":"2010-01-29T10:06:07Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Mike Linck:\n\n> It seems that after a topic or bug branch is merged back into its parent, \n> especially if it was fast forwarded, it becomes hard to determine what \n> changes were made in it, to resolve the problem that it was created to \n> address.\n\nIf you keep the branch name somewhere (either pushed to the master \nrepository, or to a side-repository used to store old \"dead\" branches), then \nyou at least have the pointer to the last commit on that particular branch.\n\nYou can then backtrack through the commits to the previous merge-point, or \nbranch head, in the history to find the point where it, most likely, was \nbranched off from.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"132944","messageId":"alpine.DEB.2.00.1001291106140.25954@ds9.cixit.se","threadId":"22429","inReplyTo":"b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com","subject":"Re: Questions about branches in git","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-01-29T10:07:55Z","receivedAt":"2010-01-29T10:07:55Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Michael Witten:\n\n> However, I've been thinking for a while that it would be useful to have \n> übercommits (they don't exist) that are treated like single commits but \n> that actually encapsulate multiple continguous commits.\n\nYour \"übercommits\" can easily be faked by wrapping the project up in a git \nsubmodule. The supermodule (which would just contain one entry -- the \nproject you are \"übercommit-tracking\") would then contain one single commit \nfor each set of commits you wish to publish.\n\nI'm not sure such a work-flow makes much sense, though. Annotated tags are \nprobably a better idea.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"}]}