Hi,
I think the first priority is to make the switch to Python, then it
will be easier to make changes.
regards,
Vlad
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
> 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
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
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