cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [DISCUSS] git commit proces
Date Wed, 30 Jul 2014 08:21:09 GMT
On Jul 30, 2014, at 1:14 AM, Sheng Yang <> wrote:
> The issue with current development process?
> 1. Cherry-pick is needed for RM to choose stable fix commit after code
> freeze to enforce quality.
> 2. Bug fix to current release branch need to be checked in both release
> branch and MASTER.
> 3. I believe there would be more. Please comment.

4. where commits need to go is dependent on what phase of the release process you’re in,
which requires sync. For example, if you’re working on a bug fix against 4.4 but then that
is frozen you have to rebase against 4.4-forward. If you are doing this work on a public feature
branch you have to re-cut your branch since you don’t want to rebase those.
5. requires using synchronous process (freezes) to keep track of what is going on. This is
not very healthy for a distributed project with contributors across many continents and companies.
In contrast if you branch early and often you don’t freeze, you just avoid merging things
that could destabilize things.
6. does not allow looking into history to see what happened. I.e. if you were to cut a 4.5
branch from master, its code history is not at all the same or comparable (using git tools)
to the code history of 4.4.
7. reliant on error-prone human checking of merge status (looking if all cherries have been
picked properly) rather than tool support (git confirming for you all changes from branch
A made it to branch B)
8. default/naive checkouts of cloudstack tree result in a very unstable and sometimes unbuildable

The list goes on! But I don’t see why we should repeat all these things here when the internet
is full of these kinds of discussions already, as are this mailing list’s archives…

> 3. Code freeze: No such concept in the flow. Need to know how to guide the
> check in.

Mostly by discipline. Committers normally commit to develop and/or feature branches, and switch
only to the release branch to commit very specific bugfixes. You can agree a policy (for example
like Alena described) for how to make the decision what should and should not go on onto the
release branch.

> 5. The original post didn't mention minor release. I suppose it may work
> like this:
>   1. Branch out MASTER to 4.4 release
>   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
>   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's needed
>   is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we fix
>   it in develop branch(which meant for test)? I can't see how you can avoid
>   cherry-pick or extra commit if you want to have a maintenance release.

There will be extra commits, but they will be merge commits. I.e.

master                 ------4.3-----4.4--------------x4.5
                                     |  \              /
release/4.4.1                        |   \——----x--   /
                                     |    \    /     /
bugfix/CLOUDSTACK-1234               |     \—x/     /
                                     |      \ \    /
release/4.5                          |       \—x—-/
                                     |          \ \
develop                --------------y-----------x---------

the commit x will always be there exactly once, it will get exactly one sha1 checksum and
one spot in the git index, and git will forever remember all the different branches that include

On some of those branches there may be merge commits (if you explicitly chose to have them,
or if git decided they were needed) following x, to record the merges that were done.

You can basically always do this as long as you *start your fix on the oldest branch* that
you want to fix. So if you want to fix a bug in 4.4.1, 4.5.0, and all future releases, you
develop the fix against the 4.4.1 branch, and then merge from there to the 4.5 branch, and
then merge from there to the develop branch.

This works very well with git because it remembers the complete history of everything (if
you don’t cherry-pick). I.e. if commit y is the last commit that is in common between master
and develop, when it becomes time
to merge x to develop, git will traverse the whole history of x until it finds y, then consider
the situation from there. As long as you don’t cherry-pick, git can do this logic provably
correctly looking mostly at sha1 commit ids.

> Before realizing the maintenance release issue, I was quite like this
> approach, which means no more duplicate work need to be done. But sadly the
> most usage for cherry-pick is due to we need to fix multiple versions.
> Current I can't see how utilize gitflow or git merge would solve the issue.
> Is there a better way to handle this?

I hope the above helps. If it doesn’t, what I recommend to you (and anyone else having these
kinds of questions is) to just _try it_. These kinds of conversations are very hard, and the
diagrams can be confusing, but, when you’re actually doing the work and typing in the commands,
it is really much much easier to follow than the discussion itself. If you’ve never worked
on a many-branches git project before you’re in for a treat: the first time you do what
you think is a complex merge, and git just does it for you, it feels like magic :-)

> And, I think gitflow model doesn't have "code freeze" period which we can
> have a gatekeeper to keep the quality. So, if we want to compare to gitflow
> model, we would simply skip "code freeze" stage in our current process. I
> don't think it make much sense.

You know, you could keep the concept of a freeze, git-flow doesn’t mind. The way it would
look is that after a release branch freeze, all further bugfixes to that release would be
required to be on their own bug fix branches, and the gatekeeper(s) would be the only ones
merging those into the release branch.

But, generally, teams find that increased discipline in what&how to commit combined with
a solid branch workflow means they don’t need such heavy-handed methods. It’s one of the
true joys of distributed version control to let go of things like this!

For example, the linux kernel has at least two active minor releases at any given time, and
many more minor releases and forks going on at that same time, with hundreds (thousands?)
of active developers, and even _they_ don’t need freezes. Instead the power is in their
choices of what they do and do not

> 3. How about the workload for merge between release and develop branch? It
> would be quite frequently.

Yes it would be frequent. Exactly because it is frequent, it should be relatively effortless,
no more work than 'git pull'. (after all, git pull is nothing more than 'git fetch' followed
by 'git merge' do lots of merging already...)

> Btw, that no-cherry-picking(
> article
> has a mistake in it. The result it's showing in fact shows that git cherry
> -v DID recongize the cherry-pickup result by showing "-" in front of the
> commit. I guess git is smart enough to know that.
>       The equivalence test is based on the diff, after removing whitespace
> and line numbers. git-cherry therefore detects when commits have been
> "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).

Yeah, it’s pretty powerful :-)

Unfortunately comparing the diff is not nearly as powerful as comparing the sha1 ID. Those
commit ids don’t just point at a diff, they point at a _commit_, which is that diff *as
applied to all the history that came before*. With that extra detail, you can do much more
powerful things, and git can do much more powerful things for you.



View raw message