{"thread":{"id":"17276","subject":"how to keeping track of cherry-pick?","startedAt":"2009-01-20T23:53:08Z","lastAt":"2009-01-21T12:04:32Z","messageCount":6,"participants":["Knut Olav Bøhmer","Junio C Hamano","Michael J Gruber","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101324","messageId":"497663E4.4000302@telenor.com","threadId":"17276","inReplyTo":null,"subject":"how to keeping track of cherry-pick?","fromName":"Knut Olav Bøhmer","fromEmail":"knut-olav.bohmer@telenor.com","sentAt":"2009-01-20T23:53:08Z","receivedAt":"2009-01-20T23:53:08Z","isPatch":false,"sender":{"key":"knut-olav.bohmer@telenor.com","avatar":null},"body":"Hi,\n\nWe are changing from subversion to git. We used to merge revisions from\ndevelopment branch to stable with svnmerge.py.\n\nsvnmerge.py can give us a list of revisions available for merging. The\nresult is similar to \"git log --chery-pick master..dev\" The difference\nis that svnmerge.py operates on revision-numbers, and --chery-pick looks\nat the diffs. The result of that is that when we get a conflict when a\npatch is cherry-picked, it will still show up as \"available\" when I run\n\"git log --cherry-pick master..dev\"\n\nsvnmerge.py can also mark revisions as blocked, and will not show up in\nthe list of available revisions.\n\nHow can I keep track of cherry-picked patches, and mark patches as\n\"blocked\", in the same (or similar) way as I did in subversion with\nsvnmerge.py?\n\n-- \nKnut Olav Bøhmer\n"},{"id":"101332","messageId":"7vfxjdjvk8.fsf@gitster.siamese.dyndns.org","threadId":"17276","inReplyTo":"497663E4.4000302@telenor.com","subject":"Re: how to keeping track of cherry-pick?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-21T01:29:27Z","receivedAt":"2009-01-21T01:29:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Knut Olav Bøhmer writes:\n\n> svnmerge.py can give us a list of revisions available for merging. The\n> result is similar to \"git log --chery-pick master..dev\" The difference\n> is that svnmerge.py operates on revision-numbers, and --chery-pick looks\n> at the diffs. The result of that is that when we get a conflict when a\n> patch is cherry-picked, it will still show up as \"available\" when I run\n> \"git log --cherry-pick master..dev\"\n\nI think you are looking at it a wrong way.\n\nBecause subversion (at least the older one) does not keep track of merges,\nyou had to track cherry-picks. But cherry-pick is not how you usually do\nthings in git. You keep many topic branches with different doneness, and\nyou merge well-cooked ones to the more stable integration branch while\nleaving others still cooking. So what you want to know is not cherry-pick\nstatus, but merge status.\n\nBecause git tracks merges, output from \"git log master..$topic\" gives all\nyou need to know about $topic. The command lists changes that are still\nnot merged to master on the $topic branch. If it is empty, $topic is\nalready merged fully to master. Otherwise you still have things to\nmerge.\n\nTo get a list of topics that have been merged (or not merged) to a\nparticular integration branch, you should be able to use \"git branch\" with\nits --merged and --no-merged options. This does not list what commits\neach yet-to-be-merged topics have, though.\n"},{"id":"101356","messageId":"4976E059.6000404@telenor.com","threadId":"17276","inReplyTo":"7vfxjdjvk8.fsf@gitster.siamese.dyndns.org","subject":"Re: how to keeping track of cherry-pick?","fromName":"Knut Olav Bøhmer","fromEmail":"knut-olav.bohmer@telenor.com","sentAt":"2009-01-21T08:44:09Z","receivedAt":"2009-01-21T08:44:09Z","isPatch":false,"sender":{"key":"knut-olav.bohmer@telenor.com","avatar":null},"body":"Junio C Hamano wrote:\n> Knut Olav Bøhmer writes:\n> \n>> svnmerge.py can give us a list of revisions available for merging. The\n>> result is similar to \"git log --chery-pick master..dev\" The difference\n>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks\n>> at the diffs. The result of that is that when we get a conflict when a\n>> patch is cherry-picked, it will still show up as \"available\" when I run\n>> \"git log --cherry-pick master..dev\"\n> \n> I think you are looking at it a wrong way.\n> \n> Because subversion (at least the older one) does not keep track of merges,\n> you had to track cherry-picks. But cherry-pick is not how you usually do\n> things in git. You keep many topic branches with different doneness, and\n> you merge well-cooked ones to the more stable integration branch while\n> leaving others still cooking. So what you want to know is not cherry-pick\n> status, but merge status.\n\n\nI was afraid I would get this answer. I know that you change your\nworkflow when you migrate to git, but I was looking for a way to resolve\nthe situation we are in, due to our old vcs.\n\n-- \nKnut Olav Bøhmer\n"},{"id":"101359","messageId":"4976E728.5030302@drmicha.warpmail.net","threadId":"17276","inReplyTo":"4976E059.6000404@telenor.com","subject":"Re: how to keeping track of cherry-pick?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-21T09:13:12Z","receivedAt":"2009-01-21T09:13:12Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Knut Olav Bøhmer venit, vidit, dixit 21.01.2009 09:44:\n> Junio C Hamano wrote:\n>> Knut Olav Bøhmer writes:\n>>\n>>> svnmerge.py can give us a list of revisions available for merging. The\n>>> result is similar to \"git log --chery-pick master..dev\" The difference\n>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks\n>>> at the diffs. The result of that is that when we get a conflict when a\n>>> patch is cherry-picked, it will still show up as \"available\" when I run\n>>> \"git log --cherry-pick master..dev\"\n>> I think you are looking at it a wrong way.\n>>\n>> Because subversion (at least the older one) does not keep track of merges,\n>> you had to track cherry-picks. But cherry-pick is not how you usually do\n>> things in git. You keep many topic branches with different doneness, and\n>> you merge well-cooked ones to the more stable integration branch while\n>> leaving others still cooking. So what you want to know is not cherry-pick\n>> status, but merge status.\n> \n> \n> I was afraid I would get this answer. I know that you change your\n> workflow when you migrate to git, but I was looking for a way to resolve\n> the situation we are in, due to our old vcs.\n\nIn the transition phase, while you still have to work off your\nun-gittish svn feature branches, you can mimick svnmerge.py's blocking\nat least somewhat: If you merge that branch (or a commit on that branch,\ni.e. that branch up to that commit) using \"git merge -s ours\" then git\nrecords a merge but does not change your base branch. This effectively\nblocks all commits up that one from being merged in subsequent merges:\nThey're recorded as merged, but they are not \"applied\".\n\nThe disadvantage is that you have to go through your svn feature branch\nsequentially, merge what you want to keep, merge -s ours what you want\nto block. You can't easily \"unblock\" later because that would mean\nreverting a merge.\n\nFor sure, the better option is to rip your svn feature branch apart into\ngit feature branches as Junio suggests, maybe using one of the patch\nqueue like \"extensions\" to git.\n\nMichael\n"},{"id":"101362","messageId":"7v63k9gfdk.fsf@gitster.siamese.dyndns.org","threadId":"17276","inReplyTo":"4976E059.6000404@telenor.com","subject":"Re: how to keeping track of cherry-pick?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-21T09:47:19Z","receivedAt":"2009-01-21T09:47:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Knut Olav Bøhmer writes:\n\n> Junio C Hamano wrote:\n>> Knut Olav Bøhmer writes:\n>> \n>>> svnmerge.py can give us a list of revisions available for merging. The\n>>> result is similar to \"git log --chery-pick master..dev\" The difference\n>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks\n>>> at the diffs. The result of that is that when we get a conflict when a\n>>> patch is cherry-picked, it will still show up as \"available\" when I run\n>>> \"git log --cherry-pick master..dev\"\n>> \n>> I think you are looking at it a wrong way.\n>> \n>> Because subversion (at least the older one) does not keep track of merges,\n>> you had to track cherry-picks. But cherry-pick is not how you usually do\n>> things in git. You keep many topic branches with different doneness, and\n>> you merge well-cooked ones to the more stable integration branch while\n>> leaving others still cooking. So what you want to know is not cherry-pick\n>> status, but merge status.\n>\n>\n> I was afraid I would get this answer. I know that you change your\n> workflow when you migrate to git, but I was looking for a way to resolve\n> the situation we are in, due to our old vcs.\n\nMaybe I should rephrase the answer, then.\n\nI had an impression that you made it sound as if svnmerge.py is a tool\nonly meant for a workflow of always cherry-picking, but it actually is\nnot. It also enhances your SVN experience by giving something closer to\nproper merge tracking. Even though you only mentioned cherry-picks and\nmerge blocking, if you like things offered by svnmerge.py other than these\ntwo, you might find that git already has them natively.\n\nWhen your workflow is based on a single large, unfocused, everything\nmixed-in, playpen branch, plus one stable integration branch, you have to\ncherry pick to keep the stable integration branch sane, and you need a\ngood tool to help you keep track of what is cherry picked and what isn't\n(yet). Maybe your SCM has such a tool natively, or maybe it doesn't and\nneeds a third party tool support (similar to users of older SVN needed to\nuse svnmerge.py for merge tracking) bolted on.\n\n ---A1--B1--C1--A2--A3--C2--D1--... playpen kitchen-sink\n\n ---o---o---o---A1'--A2'--A3'... stable integration\n\nThe workflow when using git is typically merge based, and git lets you\nmanage topic branches well and helps you merge easily by keeping track of\nmerges.\n\nI am reading from http://www.orcaware.com/svn/wiki/Svnmerge.py while I am\ntyping this, but here is a summary:\n\n (1) Because merge tracking is built-in to git, you do not need \"something\n like svnmerge.py\" bolted on. If you have been using topic branches\n in your established SVN-based workflow, you can keep the same\n workflow and git will do the right thing when you merge your\n branches naturally.\n\n (2) We didn't have need for \"cherry-pick tracking\" part of what\n svnmerge.py offers, because we do not do cherry-picks as often.\n\n You can call this shortcoming if you want, but it should be easy for\n you to contribute a patch to add such a tool if you miss this part of\n svnmerge.py; essentially, you need to keep a database of commit\n object names on the \"playpen branch\" depicted above, and\n corresponding commit objects cherry-picked from them into the\n integration branch.\n\n (3) We have \"listing changes that are available for merging\" natively, as\n I've already explained in the previous message.\n\n (4) Bidirectional merges, merging from multiple branches, reverting\n merges, and merge commit message generation are all native features\n of \"git merge\". If you have git, you already have them. If you do\n not like the merge result, you can always amend it; commit-free-ness\n is listed as if it is a feature but it does not matter here.\n\n (5) We do not have \"merge blocking\". This falls into the same category\n as (2) above.\n"},{"id":"101375","messageId":"alpine.DEB.1.00.0901211258080.3586@pacific.mpi-cbg.de","threadId":"17276","inReplyTo":"4976E059.6000404@telenor.com","subject":"Re: how to keeping track of cherry-pick?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-21T12:04:32Z","receivedAt":"2009-01-21T12:04:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Jan 2009, Knut Olav Bøhmer wrote:\n\n> Junio C Hamano wrote:\n> > Knut Olav Bøhmer writes:\n> > \n> >> svnmerge.py can give us a list of revisions available for merging. The\n> >> result is similar to \"git log --chery-pick master..dev\" The difference\n> >> is that svnmerge.py operates on revision-numbers, and --chery-pick looks\n> >> at the diffs. The result of that is that when we get a conflict when a\n> >> patch is cherry-picked, it will still show up as \"available\" when I run\n> >> \"git log --cherry-pick master..dev\"\n> > \n> > I think you are looking at it a wrong way.\n> > \n> > Because subversion (at least the older one) does not keep track of merges,\n> > you had to track cherry-picks. But cherry-pick is not how you usually do\n> > things in git. You keep many topic branches with different doneness, and\n> > you merge well-cooked ones to the more stable integration branch while\n> > leaving others still cooking. So what you want to know is not cherry-pick\n> > status, but merge status.\n> \n> \n> I was afraid I would get this answer. I know that you change your\n> workflow when you migrate to git, but I was looking for a way to resolve\n> the situation we are in, due to our old vcs.\n\nYou could accomodate your workflow by having the newly introduced commit \nnotes provide a mapping of which commits reflect which patch, in a way \nintroducing equality classes of patches (thereby having the original SHA-1 \nof the commit as kind of a \"patch id\").\n\nBut believe me, you would regret it.\n\nIf you are working on different topics, and want to apply only some of \nthem, you really want to have different topic branches (it is even \nrelatively easy to create them using \"git checkout -b \n && git rebase -i master\" and then deleting the \ncommits not referring to a certain subject).\n\nThe problem with having a single branch is that patches which are \nindependent, can touch the same parts of the code, and are hard to manage \nindependently. If you had them in topic branches, merging them \nindividually, you could at least use the rerere mechanism to resolve merge \nconflicts for such overlapping topics.\n\nI speak of experience: my current workflow is exactly what you described, \nand I feel the pain. That's why I said you would regret it, because I \nsure do.\n\nCiao,\nDscho\n"}]}