On Thu, 30 Jan 2014 07:56:08 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
> > And it's kind of
> > superficial anyway, because why would you check out a branch
> > containing only tagged commits? In git you can check out a commit
> > directly.
> How would you integrate any changes to that commit without making an
> unholy mess of the repo or releasing it as a patch?
Exactly the same as in the original gitflow model - by using hotfixes
branch. See the picture at .
Let's say you find a problem in tag 0.1. You create hotfixes/0.1
branch starting from commit 0.1. You fix the problem in one or more
commits. Then you tag the last commit as 0.1.1 or 0.2, as you wish.
Finally, you can delete hotfixes/0.1 branch, it's no longer necessary.
Then you discover problem in tag 0.1.1. You create hotfixes/0.1.1
branch starting from commit 0.1.1, fix the problem, tag the latest
commit as 0.1.2, delete the branch.
Of course all those hotfixes get merged into your development branch
as well. Everything is the same as in the picture. I was just trying
to point out that the rightmost thick line connecting tags 0.1, 0.2,
1.0 and so on (a branch called master on the picture) is not
necessary at all. The only "advantage" it has is that it allows you
to do "git pull" to get the latest stable release instead of checking
out a tag directly ('git tag' and 'git checkout <tag>').
However, since you don't agree with master referring to development
code and you rather want master to refer to the latest stable code
(something I haven't expected before), then yes, the original picture
in the article makes sense in this case. If you intention is to offer
people the latest stable code by default (when they open up our
github/bitbucket page, they are shown master as the default branch),
it all makes sense and the branch is needed. (That's not what Fedora
Infra does, however, they display 'develop' branch as default for
many of their repos; that defeats the purpose of the rename in the
I think that a lot of this stems from my misunderstanding of your
proposal. I thought you were proposing to merge the 'master' and
'develop' branches into a single branch, which is not what you actually
Honestly, I don't care much whether we change the default branch for
the repos or switch the way we're naming branches. I'm more interested
in maintaining the separation between stable and development branches,
do hotfixes etc.
The biggest impediment I see to changing the branch names is that we'd
have to go back and change blockerbugs (using gitflow with default
names) but I suppose that's not a huge issue.
> I'm not as worried, to be honest. We need to document our
> better but in a similar vein to what I said about github and making
> drive-by patches easier, if someone is not capable of looking at the
> readme or any other docs before writing a patch ... are we really
> that confident that any contributions would be useful and wanted? If
> reading the readme and typing 'git checkout develop' is too much
> work for testing, how likely is it that the same person would take
> the time to file a decent bug or send mail to the list?
I agree with you, people will need to read documentation anyway. The
only thing I dislike is that we want to divert from the traditions
that everyone knows. 'master' is traditionally used to mean the main
development branch, or at least _a_ *development* branch. If we want
to have a branch with just stable, released code, why wouldn't we
call it 'stable' (or anything similar) instead of changing the
meaning or 'master' and then using a different branch for the
purposes of master?
But I don't think we should spend too much time on this. If you
believe that we should go against the tide and have 'master' to mean
something else, I'm fine with that. I simply did not expect that this
is really your intention.
Agreed on not spending more time on this. We've got more important
things to deal with than branch names.
> It'd be nice to hear some more opinions on this - especially
> from folks who will be regular contributors (don't make me call you
> out by name because I will resort to that if needed).
I think they are a bit discouraged by the long discussion and they
don't want to wrap their brains around all those graphs and models.
I'm not surprised, I did not expect to go into so much detail anyway,
for me this was a trivial rename fix proposal. But apparently I
wasn't able to describe properly how simple all of this is, and it
evolved into such a complex monster issue :-) I'm fine with anything,
Yeah, I'm fine with either changing the default branch or renaming
stuff - as long as we do it for all projects and do it very soon.
After talking on IRC, I think we're both OK with changing the default
branch in bitbucket. It takes the least amount of work to change and I
suspect it'll mean less documentation and confusion since we'd be able
to use the defaults during gitflow setup (assuming folks are using
the gitflow tool). People landing on the bitbucket page will see the
devel code which makes sense to me and if I'm understanding you
correctly, was your main objection to gitflow.
Any objections to going forward with this - setting 'develop' as the
default branch for projects which are not dependent on fedora version
and keeping with the gitflow defaults?