Hi,
Matthew,
Hi,
...
Even without the foulup, I think you would see that the merges from
maintenance branches into subsequent branches and into master make it
very hard to figure out what has actually been done on any given branch.
I strongly disagree. The only reason you get cleaner history graphs
with cherry picking is because it doesn't graph the cherry picks! If
you want to know what has been merged, you have to inspect the commit
message in one branch and match it up with the commit message in
another branch. How does that make it easier to figure out what has
been done on any given branch?
I think Eric's point is that it kind of feels (and looks) wrong to
merge maintenance into master, rather than backporting fixes from
master with cherry-picks. Maybe 'feels wrong' might be translatable
as 'harder to think about' and therefore 'more error prone'?
Maybe "feels wrong" translates to "unfamiliar", and has nothing to do
with difficulty or potential for error.
Ah no - I mean that the way I think most of think of bugfix workflow
is that we fix in trunk and backport the fix to the maintenance
branch. Here though you are fixing in the maintenance branch and
_merging_ to trunk. The counter-argument is 'well think of it the
other way round and it will be fine'. It's a little difficult to know
if that's true I suppose.
It's a funny kind of thing too, because it puts an extra constraint on
the bugfix. For example, imagine a bugfix in maintenance, in some
code that has crazy-changed in trunk. Now you have to decide if you
try and merge it anyway, and basically do a rewrite as you fix the
merge conflict. Or you could merge-ours on that commit and write a
completely different fix on trunk. But that's getting a bit dark and
magic. And so it imposes some slight what-will-happen brain overhead
on the person writing the fix.
Git is a powerful tool. If we
used a cherry-picking workflow (which I would not advocate), there
would still be chances for error by inappropriately specifying hash
ranges, for example. I think there is much more potential for error
using cherry-picking. There are other advantages as well, see
Git Cherry-pick vs Merge Workflow - Stack Overflow
(note the warnings about rebasing, which are not relevant to this
discussion)
I can
see the argument for doing it though. It is a common workflow?
Yes, I believe it is a very common workflow.
Ah - OK, I guess I had not seen it before.
Before we made the git transition, I read about various workflows.
What we are doing now is somewhat similar to what used to be done with
svnmerge. I just googled "git workflow", and found
gitworkflows(7) .
See the section on "Merging Upwards":
Yes, I think I see why it would be attractive.
With cherry picking, imagine we get ready to cut a v1.0.2 release, and
we want to know if all of the bug fixes that should be applied to the
maintenance branch have been applied. How do we verify? Much easier is
to apply them like the docs at kernel.org suggest, to the oldest
supported branch that require them and then merge upwards. Then the
history graph can tell you that the bug fixes in older versions have
been applied to newer branches.
I believe that the git log --cherry etc machinery is designed to deal
with this case, but I haven't used it myself. I have to emphasize,
the projects I've been involved with have fewer developers and smaller
code-bases,
Cheers,
Matthew
···
On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale <dsdale24@...149...> wrote:
On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett <matthew.brett@...149...> wrote:
On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale <dsdale24@...149...> wrote:
On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <efiring@...229...> wrote:
