Tagging releases & git-flow flexibility
Vlad Dumitrescu
First, cool description of the workflow and cool tool to support it!
I've seen some comments to the original post questions about whether
one shouldn't tag the release on the release branch instead, so that
'git describe' on develop picks it up. An alternative to that would be
to
- merge to master
- tag release
- merge from master to develop (instead to from release branch)
It's probably just a matter of taste, but it brings up an issue about
the git-flow tool. There are many possible variations to the workflow
out there and I believe it will be difficult for a generic tool to
support them all without becoming as cumbersome as using the basic git
commands.
What I was envisioning was a configuration file that defines the
current workflow and allows the commands to be very simple and with
much less opportunities for human error.
For example, everybody always uses 'git flow release finish
<release>', but the current configuration says if the tag is set on
the release or master branch, if the merge to develop is done from
release or master, and so on.
Does that make sense here, or is it material for a parallel project?
best regards,
Vlad
Vincent Driessen
> I've seen some comments to the original post questions about whether
> one shouldn't tag the release on the release branch instead, so that
> 'git describe' on develop picks it up. An alternative to that would be
> to
> - merge to master
> - tag release
> - merge from master to develop (instead to from release branch)
is that "git describe" reports the previous-by-one version as the base
version, which is extremely confusing.
I've thought about its consequences for the model diagram and the git-
flow tool. In all cases, I think git-flow should never stand in the
way of the general git commands (in this case, git-describe).
Therefore, I think I will change this in the model and update git-flow
to use that convention instead.
The model diagram will become a little less attractive, but that's
just a matter of taste. Technically, this is a better way of merging,
since you record that, after finishing a release, the develop branch
is a descendent of the tagged release (which it really is
semantically).
I've filed a ticket for this one, at http://github.com/nvie/gitflow/issues/issue/49.
> It's probably just a matter of taste, but it brings up an issue about
> the git-flow tool. There are many possible variations to the workflow
> out there and I believe it will be difficult for a generic tool to
> support them all without becoming as cumbersome as using the basic git
> commands.
describe which branch types may branch off from where, and where they
may merge back in to. However, I've not yet concretised it enough to
be sure whether such would be possible, keeping all current commands.
> Does that make sense here, or is it material for a parallel project?
project.
Please keep in touch about any the ideas you have.
Cheers,
Vincent
Vlad Dumitrescu
>> It's probably just a matter of taste, but it brings up an issue about
>> the git-flow tool. There are many possible variations to the workflow
>> out there and I believe it will be difficult for a generic tool to
>> support them all without becoming as cumbersome as using the basic git
>> commands.
>
> Also, I like your idea of a "rules" file (with sane defaults), that
> describe which branch types may branch off from where, and where they
> may merge back in to. However, I've not yet concretised it enough to
> be sure whether such would be possible, keeping all current commands.
Hi,
I think the first priority is to make the switch to Python, then it
will be easier to make changes.
regards,
Vlad
Vlad Dumitrescu
>> Also, I like your idea of a "rules" file (with sane defaults), that
>> describe which branch types may branch off from where, and where they
>> may merge back in to. However, I've not yet concretised it enough to
>> be sure whether such would be possible, keeping all current commands.
Just a few ideas in this area:
* The configuration file could sit at the top level in the repository
and be picked up automatically (name suggestion '.gitflow'). This way
people can use the same commands in different projects, but these can
result in different operations (as defined by the project's policies).
One no longer needs to remember the exact details for the current
project.
* The config file would even contain the naming conventions for the
project, something like
master: prj_master
develop: integration
release: rel_$vsn
feature: features/$name
where $ introduces variables and the first field is the "standard"
name to be used in the rules, for example a reference to 'release'
when $vsn=0.5 will use a value of 'rel_0.5'.
* The most general way to make the operations configurable would be to
basically let the users write their own sequence of git operations and
be able to call those with a common name. The difference between this
and 'git-alias' would be that here we can add useful common operations
(like checking prerequisites for the commands), give meaningful
messages, handle arguments liberally and even be able to undo an
operation if it failed.
* For example a spec for "release finish $ver" could be
check exists release
checkout master
merge release (see above, it's actually 'rel_$ver')
error: ignore (this is default)
tag -a -m '$ver' v_$ver
checkout develop
merge v_$ver
error: break "error message here" (don't push if there were merge errors)
push origin master
push origin develop
echo "done!"
So it's a scripted execution of git commands, hopefully no 'if's are
needed, which would make it maybe too complicated.
best regards,
Vlad
Vincent Driessen
Thanks again for your input.
On Aug 27, 2:00 pm, Vlad Dumitrescu <vladd...@gmail.com> wrote:
> * The configuration file could sit at the top level in the repository
> and be picked up automatically (name suggestion '.gitflow'). This way
> people can use the same commands in different projects, but these can
> result in different operations (as defined by the project's policies).
> One no longer needs to remember the exact details for the current
> project.
config file, but there's one catch to it: it's brought inside version
control rules (which is good) that it defines itself (which is not
good). In practice, this can lead to extremely confusing scenario's,
like when you make a change to the file on develop, it differs from
master. Now let's say you finish a release branch that leads to a
merge conflict, which pauses the finishing process. When you resolve
the conflict and pick the finish up, the .gitflow file has been
changed during the finish process.
Or worse: a merge conflict inside the .gitflow file?
Of course, these scenario's are rather rare, but when they happen,
users may get very confused and desperate.
> * The config file would even contain the naming conventions for the
> project, something like
> master: prj_master
> develop: integration
> release: rel_$vsn
> feature: features/$name
> where $ introduces variables and the first field is the "standard"
> name to be used in the rules, for example a reference to 'release'
> when $vsn=0.5 will use a value of 'rel_0.5'.
this won't let you share your branch strategy details with other
users, as would a file under version control, but you'll never have
the confusing behaviour. Maybe it would be an option to store the
settings inside a versioned file, and load the settings into git-
config variables from there. This would be the best of both worlds.
> * The most general way to make the operations configurable would be to
> basically let the users write their own sequence of git operations and
> be able to call those with a common name. The difference between this
> and 'git-alias' would be that here we can add useful common operations
> (like checking prerequisites for the commands), give meaningful
> messages, handle arguments liberally and even be able to undo an
> operation if it failed.
kind of branching rules. I think relaxing the current static rule set
is a good idea, but this implementation is kind of a slippery slope.
I can see where this is heading. You already mentioned the if-
statement, but if you go down this road, if-statement support would be
inevitable. Next would be a while loop, then would be some kind of
control command that lets you start a CI job, mail some people, but
not if it's Friday in odd months (unless the user is "johndoe"). If
you know what I mean :-)
One of the reasons why git-flow and the article is so popular is that
it provides a *specific* workflow, which is structured, clear, well-
illustrated (easily communicated) and therefore, well, more or less
standardised. Varying branch and tag names isn't too exciting, but if
everybody started using git-flow with completely different branching
rules, that would eventually inflate its value as a standard. In other
words, what you'd loose is that if you tell somebody that your project
uses git-flow, he/she would know what your branching strategy is like.
I believe this is a value that we've already gained and it's one of
the key successes of the tool so far.
Cheers,
Vincent
Vlad Dumitrescu
> I believe this is a value that we've already gained and it's one of
> the key successes of the tool so far.
These were just some ideas. I agree with you about keeping things
under control, and yet I don't :-)
You probably noticed that there are already requests for new things to
add :-) My guess that there will be more of those, because I don't
think people like to adapt to a tool but want a tool that works as
they want it to.
You can mainly ignore them and let the tool implement a single
process, with very few knobs to turn and tweak. I believe that this
will lead to forks of the tools, each implementing their own process,
if that process isn't supported.
You can accept most of the requests, by adding options and parameters.
I believe this will make the difference to using git commands directly
smaller and smaller. Still, not everyone will be satisfied anyway.
You can make the tool a swiss-army knife and let everyone define their
own process (up to a point, of course). There are of course more
opportunities to shoot oneself in the foot, but once a process is in
place for a project, there is no reason for random members to change
it. Like everything else, one should know what one is doing when
tinkering with stuff.
No one can say that one or the other of the alternatives is the only
right one. All have pros and cons.
best regards,
Vlad
Vincent Driessen
On 27 aug 2010, at 22:03, Vlad Dumitrescu wrote:
> These were just some ideas. I agree with you about keeping things
> under control, and yet I don't :-)
I completely understand what you mean :)
> You probably noticed that there are already requests for new things to
> add :-) My guess that there will be more of those, because I don't
> think people like to adapt to a tool but want a tool that works as
> they want it to.
I believe that, too. But I think the value of git-flow still is that it simplifies high-level repository operations and that it communicates well at the same time. Best would be to allow some degree of custom rules, but I'm only saying we should be careful of adding too much. Allowing too much flexibility, git-flow looses whatever value it added over using vanilla git directly.
> No one can say that one or the other of the alternatives is the only
> right one. All have pros and cons.
True, very true. And let this be clear: I was very excited to read your comments, and the last thing I wanted to do is give you the feeling that it was unappreciated or useless—on the contrary! Please keep this discussion going. I think the main point now is to get the Python rewrite started and we can discuss things further as the details reveal themselves.
I'll try to put some more energy into it, but my main problem really is the amount of free time minus other projects that currently have my priority.
Cheers,
Vincent
Vlad Dumitrescu
On Sun, Aug 29, 2010 at 21:06, Vincent Driessen <vin...@datafox.nl> wrote:
>> You probably noticed that there are already requests for new things to
>> add :-) My guess that there will be more of those, because I don't
>> think people like to adapt to a tool but want a tool that works as
>> they want it to.
>
> I believe that, too. But I think the value of git-flow still is that it simplifies high-level repository operations and that it communicates well at the same time. Best would be to allow some degree of custom rules, but I'm only saying we should be careful of adding too much. Allowing too much flexibility, git-flow looses whatever value it added over using vanilla git directly.
Exactly. The trick is to go far enough, but not too far. Anyway,
regular users should only care about the git-flow commands, not the
details behind them.
I think that it is enough to allow git-related commands, to print
messages on the console, to check for different conditions and raise
errors if they don't match. It should also be nice if it was possible
to revert the last operation (either after the fact or when there is
an error).
For most operations, reverting is the sane error handling, but when
the "error" consists of merge conflicts, then there are two options:
the user should be allowed to resolve them and continue the operation,
like when rebasing; or the tool forces conflict resolution before
running any operation (it doesn't have to save/restore the state, it's
much easier to write).
Unfortunately, my Python skills are very limited and I'm not sure if I
have the time to learn it properly just for this project... but the
parser and interpreter for the command configuration are a very
interesting problem, so I might find that time somehow :-)
Regarding putting all configuration in a file stored in git, you were
worried that users may modify it carelessly. I don't think that's a
problem, there are many files that not everybody should fiddle with
and they don't. If configuration is done manually, there's still room
for error (for example in the initial configuration of git-flow I
could misspell branch names).
best regards,
Vlad