Hi, On Wed, 21 Jan 2009, Knut Olav Bøhmer wrote: > Junio C Hamano wrote: > > Knut Olav Bøhmer <knut-olav.bohmer@xxxxxxxxxxx> writes: > > > >> svnmerge.py can give us a list of revisions available for merging. The > >> result is similar to "git log --chery-pick master..dev" The difference > >> is that svnmerge.py operates on revision-numbers, and --chery-pick looks > >> at the diffs. The result of that is that when we get a conflict when a > >> patch is cherry-picked, it will still show up as "available" when I run > >> "git log --cherry-pick master..dev" > > > > I think you are looking at it a wrong way. > > > > Because subversion (at least the older one) does not keep track of merges, > > you had to track cherry-picks. But cherry-pick is not how you usually do > > things in git. You keep many topic branches with different doneness, and > > you merge well-cooked ones to the more stable integration branch while > > leaving others still cooking. So what you want to know is not cherry-pick > > status, but merge status. > > > I was afraid I would get this answer. I know that you change your > workflow when you migrate to git, but I was looking for a way to resolve > the situation we are in, due to our old vcs. You could accomodate your workflow by having the newly introduced commit notes provide a mapping of which commits reflect which patch, in a way introducing equality classes of patches (thereby having the original SHA-1 of the commit as kind of a "patch id"). But believe me, you would regret it. If you are working on different topics, and want to apply only some of them, you really want to have different topic branches (it is even relatively easy to create them using "git checkout -b <new-topic> <miscellaneous-branch> && git rebase -i master" and then deleting the commits not referring to a certain subject). The problem with having a single branch is that patches which are independent, can touch the same parts of the code, and are hard to manage independently. If you had them in topic branches, merging them individually, you could at least use the rerere mechanism to resolve merge conflicts for such overlapping topics. I speak of experience: my current workflow is exactly what you described, and I feel the pain. That's why I said you would regret it, because I sure do. Ciao, Dscho
