You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2013/11/24 16:27:17 UTC
[cli] Moving to Git?
What about experimenting the migration to Git with cli?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Torsten Curdt <tc...@vafer.org>.
Trying hard not to get sucked into the git debate again but I am almost
offended to be offered this ridiculously simplified argument:
> For reminder, the argument was that it is quite easy to provide a
> contribution with Subversion:
> $ svn co "<URL>"
> $ cd trunk
> $ mvn test
> $ svn diff > "issue<xxxx>.patch"
>
When has it ever been that easy - unless it's maybe contributing a typo fix
that gets applied right after submission?
If you guys need to start the debate all over again at least come up with a
real world scenario:
$ somevcs checkout "<URL">
you do some modifications
meanwhile someone else commits changes
now you want to integrate these changes and see if you modifications still
apply
# somecvs magic
$ somebuildtool test
$ somecvs diff > "issue<xxxx>.patch"
submit the patch
wait 2 weeks up to 6 months for you patch to be looked at
be asked to update your patch so it applies cleanly with further changes in
trunk
update your patch and re-submit
2 weeks later: yay! it's in trunk now
If anyone here has ever maintained a larger patch for bit longer - I am
sorry if I have brought back some painful memories from when you were using
svn.
I do not care about [cli] much anymore - said by others before there are
much better libs out there.
I so do not care about what tool to use - but I want to use the right tool
for the right job.
And as tools change, so does what is "right".
Maybe an angle worth exploring for some when thinking about the whole VCS
debate.
Torsten out - fire away
Re: [cli] Moving to Git?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 26, 2013 at 8:56 AM, Gilles <gi...@harfang.homelinux.org>wrote:
> On Tue, 26 Nov 2013 14:47:09 +0100, Emmanuel Bourg wrote:
>
>> Le 26/11/2013 14:42, Benedikt Ritter a écrit :
>>
>> What's the point of using git then?
>>>
>>
>> To provide a better collaboration tool for the external contributors,
>> and thus increasing the external contributions?
>>
>
> Unless I missed some of the recent discussions, this point has been
> argued against and no counter-argument was presented.
>
> For reminder, the argument was that it is quite easy to provide a
> contribution with Subversion:
> $ svn co "<URL>"
> $ cd trunk
> $ mvn test
> $ svn diff > "issue<xxxx>.patch"
>
> Using a different source management system must bring added value to
> the project (IOW: the regular developers).
>
For me, this is not about one VCS vs. another, it's about having more than
one, which we currently support.
>From a process standpoint, today I see a lot (1/2?) of patches come in
through Git (either as a pull request or a patch).
When it's a Git patch file, I have to manually fiddle with the patch file
to make it an SVN patch file, which is a pain. If it's a pull request, it's
more fiddling.
Personally, I do not see the point of mirroring our SVN stuff to Git, it
makes the process more complicated for me. But, Git is popular and the way
of the future, there is no unringing that bell. Fine, let's move forward.
Git seems more like another way to make our code more public. To that end,
it would seem simpler to switch to Git (hosted at Apache) so that the
process of sharing code and patches is less painful. This means getting rid
of SVN.
So my point is not that have we need to show that using Git is better, it's
that now, having BOTH SVN and Git is a pain.
Gary
>
> Best regards,
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [cli] Moving to Git?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 27 Nov 2013 11:04:15 +0100, Luc Maisonobe wrote:
> Le 26/11/2013 14:56, Gilles a écrit :
>> On Tue, 26 Nov 2013 14:47:09 +0100, Emmanuel Bourg wrote:
>>> Le 26/11/2013 14:42, Benedikt Ritter a écrit :
>>>
>>>> What's the point of using git then?
>>>
>>> To provide a better collaboration tool for the external
>>> contributors,
>>> and thus increasing the external contributions?
>>
>> Unless I missed some of the recent discussions, this point has been
>> argued against and no counter-argument was presented.
>
> Here are some counter arguments. I think they were already given, but
> I
> may be mistaken.
>
> - Git allows unconnected operation, as everyone has a local
> repository,
> this is *really* interesting for some developers (like me), who
> may
> work in remote environment
> - Git separates the notion of "commit" and the notion of "push" to
> the
> reference repository. This is important as some work may take time
> for the developer and need some iterations with small steps. With
> svn, you can save your work only by also pushing to an
> experimental
> branch, which is discussed in next point.
> - Svn branches are a real problem, and Git branches a real solution.
> We already tried to use branches when preparing a major release
> for
> [math] while continuing maintenance for the previous release (I
> don't
> remember if it was 1.2/2.0 or 2.2/3.0). It ended up in a big mess
> and
> we lost a tremendous amount of time (I was responsible for this
> bad
> choice)
> - Git allows to exchange changesets between people that do not have
> write access: they can create their own repository, make full use
> of
> the tools (diffs, updating their tree from the official repo,
> branches, creating patches either for intermediate changes or
> globally) and they can also either give access back to the regular
> developers so they import and commit these changes in the tree,
> do you remember this message
> <http://markmail.org/message/36x2zajx3stoqvc6> or this one
> <http://markmail.org/message/q6gbalkiifvmame2>? Git solves exactly
> this
> kind of problems, and
> instead of having to ask for a single diff, the regular developer
> just imports the "full history" of the changes, and can go to
> whatever level of details he wants: either looking at each
> individual
> change and accept/reject them one at a time, or combine them and
> look at the global diff and commit in one chunk, or do any
> intermediate decision
> - Git branching/merging features are far superior to SVN. Some
> branches
> are better handled using a rebase policy, some using a merge
> policy,
> both are possible. When you are stuck with conflicts, it is
> generally
> much easier to sort out what happens and get back to a clean way
> without losing lots of work, by combining creation of temporary
> local branches (the kind of branches you create just for a few
> minutes while you run a few commands) and by using stash features.
> - Git provides a stash feature that is really great to switch from
> one line of work to another without losing temporary work
>
>>
>> For reminder, the argument was that it is quite easy to provide a
>> contribution with Subversion:
>> $ svn co "<URL>"
>> $ cd trunk
>> $ mvn test
>> $ svn diff > "issue<xxxx>.patch"
>>
>> Using a different source management system must bring added value to
>> the project (IOW: the regular developers).
>
> I really think it does. It brings a lot of value. Git is not easy to
> get
> used to, but people can start using it almost just like they use SVN,
> and learn progressively. Once used to Git features, it is really
> difficult to go back to SVN.
I have _zero_ problem accepting that Git is better than anything that
existed before: I'm a GNU/Linux user since 1995.
The list above was not necessary to convince me.
I just do not buy the argument that we'll get more contributors by
using Git. This is pure wishful thinking (for Commons Math at least).
The initial post of this thread was intended to indeed make Git useful,
for the project(s), by taking advantage of its specific features
(IIUC);
but this has been answered somewhat negatively, hence the quite valid
question on top of this page, followed by the unproven (IMHO) answer...
I'll post a follow-up in a new [Math] mail.
Gilles
> Luc
>
>>
>> Best regards,
>> Gilles
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Jens Kapitza <j....@schwarze-allianz.de>.
Am 27.11.2013 11:13, schrieb Stefan Bodewig:
> Hi
>
> I don't intend to argue for git or svn at all, but rather for "let the
> people decide who do the work".
+1
> IIUC we can migrate CLI to git without forcing all other Commons
> components to make the move as well. I for one do not intend to work on
> [cli] and if I had to patch a small thing (like I did a few hours ago) I
> can do so with either system - and this will be true for most of us
> here.
+1
>
> So can we please allow the folks who actively work on [cli] today make
> the decsision which vcs they want to use?
+1
>
> Stefan
>
--
Jens Kapitza
Wir bewältigen unseren Alltag fast ohne das geringste Verständnis der
Welt.
-- Carl Sagan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <em...@gmail.com>.
Le 27/11/2013 11:46, Gilles a écrit :
> Do "we" really have to allow them? Or do they have the right to do as
> they please?
Well, I thought after the last vote/discussion about Git that we had a
consensus to experiment with Git at a component level.
Do we want to vote formally for cli?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-11-27, Gilles wrote:
>> So can we please allow the folks who actively work on [cli] today
>> make the decsision which vcs they want to use?
> Do "we" really have to allow them? Or do they have the right to do as
> they please?
"allow" was meant to be "let" rather than "permit" - my internal German
to English translator picked the wrong meaning of "machen lassen" when
it created the sentence :-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
On Wed, 27 Nov 2013 11:13:25 +0100, Stefan Bodewig wrote:
> Hi
>
> I don't intend to argue for git or svn at all, but rather for "let
> the
> people decide who do the work".
Exactly. Unless I'm mistaken those who do the work are not the
unidentified people out there who might some beautiful day (in
the near or distant future) contribute, but the fairly well
identified regular developers who contribute today.
>
> IIUC we can migrate CLI to git without forcing all other Commons
> components to make the move as well. I for one do not intend to work
> on
> [cli] and if I had to patch a small thing (like I did a few hours
> ago) I
> can do so with either system - and this will be true for most of us
> here.
>
> So can we please allow the folks who actively work on [cli] today
> make
> the decsision which vcs they want to use?
Do "we" really have to allow them? Or do they have the right to do as
they please?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Stefan Bodewig <bo...@apache.org>.
Hi
I don't intend to argue for git or svn at all, but rather for "let the
people decide who do the work".
IIUC we can migrate CLI to git without forcing all other Commons
components to make the move as well. I for one do not intend to work on
[cli] and if I had to patch a small thing (like I did a few hours ago) I
can do so with either system - and this will be true for most of us
here.
So can we please allow the folks who actively work on [cli] today make
the decsision which vcs they want to use?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 26/11/2013 14:56, Gilles a écrit :
> On Tue, 26 Nov 2013 14:47:09 +0100, Emmanuel Bourg wrote:
>> Le 26/11/2013 14:42, Benedikt Ritter a écrit :
>>
>>> What's the point of using git then?
>>
>> To provide a better collaboration tool for the external contributors,
>> and thus increasing the external contributions?
>
> Unless I missed some of the recent discussions, this point has been
> argued against and no counter-argument was presented.
Here are some counter arguments. I think they were already given, but I
may be mistaken.
- Git allows unconnected operation, as everyone has a local repository,
this is *really* interesting for some developers (like me), who may
work in remote environment
- Git separates the notion of "commit" and the notion of "push" to the
reference repository. This is important as some work may take time
for the developer and need some iterations with small steps. With
svn, you can save your work only by also pushing to an experimental
branch, which is discussed in next point.
- Svn branches are a real problem, and Git branches a real solution.
We already tried to use branches when preparing a major release for
[math] while continuing maintenance for the previous release (I don't
remember if it was 1.2/2.0 or 2.2/3.0). It ended up in a big mess and
we lost a tremendous amount of time (I was responsible for this bad
choice)
- Git allows to exchange changesets between people that do not have
write access: they can create their own repository, make full use of
the tools (diffs, updating their tree from the official repo,
branches, creating patches either for intermediate changes or
globally) and they can also either give access back to the regular
developers so they import and commit these changes in the tree,
do you remember this message
<http://markmail.org/message/36x2zajx3stoqvc6> or this one
<http://markmail.org/message/q6gbalkiifvmame2>? Git solves exactly this
kind of problems, and
instead of having to ask for a single diff, the regular developer
just imports the "full history" of the changes, and can go to
whatever level of details he wants: either looking at each individual
change and accept/reject them one at a time, or combine them and
look at the global diff and commit in one chunk, or do any
intermediate decision
- Git branching/merging features are far superior to SVN. Some branches
are better handled using a rebase policy, some using a merge policy,
both are possible. When you are stuck with conflicts, it is generally
much easier to sort out what happens and get back to a clean way
without losing lots of work, by combining creation of temporary
local branches (the kind of branches you create just for a few
minutes while you run a few commands) and by using stash features.
- Git provides a stash feature that is really great to switch from
one line of work to another without losing temporary work
>
> For reminder, the argument was that it is quite easy to provide a
> contribution with Subversion:
> $ svn co "<URL>"
> $ cd trunk
> $ mvn test
> $ svn diff > "issue<xxxx>.patch"
>
> Using a different source management system must bring added value to
> the project (IOW: the regular developers).
I really think it does. It brings a lot of value. Git is not easy to get
used to, but people can start using it almost just like they use SVN,
and learn progressively. Once used to Git features, it is really
difficult to go back to SVN.
Luc
>
> Best regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 26 Nov 2013 14:47:09 +0100, Emmanuel Bourg wrote:
> Le 26/11/2013 14:42, Benedikt Ritter a écrit :
>
>> What's the point of using git then?
>
> To provide a better collaboration tool for the external contributors,
> and thus increasing the external contributions?
Unless I missed some of the recent discussions, this point has been
argued against and no counter-argument was presented.
For reminder, the argument was that it is quite easy to provide a
contribution with Subversion:
$ svn co "<URL>"
$ cd trunk
$ mvn test
$ svn diff > "issue<xxxx>.patch"
Using a different source management system must bring added value to
the project (IOW: the regular developers).
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 26/11/2013 14:42, Benedikt Ritter a écrit :
> What's the point of using git then?
To provide a better collaboration tool for the external contributors,
and thus increasing the external contributions?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Benedikt Ritter <br...@apache.org>.
2013/11/26 Gary Gregory <ga...@gmail.com>
> On Tue, Nov 26, 2013 at 3:52 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> > Le 26/11/2013 08:43, Benedikt Ritter a écrit :
> > > I propose [1] as branching model. It looks very complicated at first,
> but
> > > I've found it very useful to always have a release ready version of the
> > > code in master.
> > >
> > > [1] http://nvie.com/posts/a-successful-git-branching-model/
> >
> > It looks complicated indeed. I prefer having the current developments on
> > the master branch and create topic branches to experiment with more
> > involved changes. I don't think we have enough active developers per
> > component to require a more sophisticated model.
> >
>
> I agree with Emmanuel. Let's keep it simple by not mixing a change in VCS
> and process at the same time. Let's do Git and see how that goes.
>
What's the point of using git then?
>
> Gary
>
>
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [cli] Moving to Git?
Posted by Christian Grobmeier <gr...@gmail.com>.
On 29 Nov 2013, at 14:39, Torsten Curdt wrote:
>>
>> This in fact means:
>>>>
>>>> create a master branch which is stable.
>>>> create a develop branch which is not so stable.
>>>> create feature branches from develop where you work out your
>>>> changes.
>>>>
>>>
>>> We are just swapping the branch names here, in the end your model
>>> isn't
>>> very different from mine. Let's say the develop branch is named
>>> 'master', the stable branch is named '1.x' or 'stable' and we are
>>> basically dealing with the same workflow.
>>>
>>
>> It's not my model, its the model described here:
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> This is a model many people follow. Having a development branch which
>> is
>> called master
>> will confuse a lot of people.
>
>
> I highly doubt that. In fact master being unstable is kind of the
> default
> if you look around on github.
>
>
>
>> We should respect the naming conventions of git as good as possible.
>>
>
> There are *many* project that use git that have the master being
> unstable.
> Rails is just one example.
Aha ok, good to know. Well you are more into that. I have learned it a
different
way but well, I stand corrected.
> Please lets not mix one bike shedding topic with the other - that's
> madness
> ;)
"I am not mad!"
- Nyarlathotep, the mad faceless god from Lovecrafts Cthulhu mythos
;-)
Cheers
Christian
>
> cheers,
> Torsten
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Torsten Curdt <tc...@vafer.org>.
>
> This in fact means:
>>>
>>> create a master branch which is stable.
>>> create a develop branch which is not so stable.
>>> create feature branches from develop where you work out your changes.
>>>
>>
>> We are just swapping the branch names here, in the end your model isn't
>> very different from mine. Let's say the develop branch is named
>> 'master', the stable branch is named '1.x' or 'stable' and we are
>> basically dealing with the same workflow.
>>
>
> It's not my model, its the model described here:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> This is a model many people follow. Having a development branch which is
> called master
> will confuse a lot of people.
I highly doubt that. In fact master being unstable is kind of the default
if you look around on github.
> We should respect the naming conventions of git as good as possible.
>
There are *many* project that use git that have the master being unstable.
Rails is just one example.
Please lets not mix one bike shedding topic with the other - that's madness
;)
cheers,
Torsten
Re: [cli] Moving to Git?
Posted by Benedikt Ritter <br...@apache.org>.
Hi again,
2013/12/6 Emmanuel Bourg <eb...@apache.org>
> Le 06/12/2013 14:19, Benedikt Ritter a écrit :
>
> > what about this? I've not seen any strong objections against migrating
> cli
> > to git in general. How about setting up the repo and learn about the
> > migration process and then start to stink about a development process?
> > You can use git in a very SVN like way. Maybe we should start with this
> so
> > that folks get used to it.
>
> I'm not sure to know where to start. Looking at the current Git mirror
> it seems some branches are missing.
>
> https://github.com/apache/commons-cli
>
> On GitHub I can see trunk, cli-1.x and avalon-implementation. The
> abandonned 2.0 branch is missing.
>
> I guess we have to move back the branches under
> https://svn.apache.org/repos/asf/commons/proper/cli/dead into
> ../branches and ask the infra team to regenerate the Git repository.
>
I'm not sure we need infra for this. If you're planning to continue the
once dead branch 2.0, you should copy it to /branches anyway. Maybe the
sync will create the corresponding branch in git by itself.
Benedikt
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 06/12/2013 14:19, Benedikt Ritter a écrit :
> what about this? I've not seen any strong objections against migrating cli
> to git in general. How about setting up the repo and learn about the
> migration process and then start to stink about a development process?
> You can use git in a very SVN like way. Maybe we should start with this so
> that folks get used to it.
I'm not sure to know where to start. Looking at the current Git mirror
it seems some branches are missing.
https://github.com/apache/commons-cli
On GitHub I can see trunk, cli-1.x and avalon-implementation. The
abandonned 2.0 branch is missing.
I guess we have to move back the branches under
https://svn.apache.org/repos/asf/commons/proper/cli/dead into
../branches and ask the infra team to regenerate the Git repository.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Benedikt Ritter <br...@apache.org>.
He Emmanuel,
what about this? I've not seen any strong objections against migrating cli
to git in general. How about setting up the repo and learn about the
migration process and then start to stink about a development process?
You can use git in a very SVN like way. Maybe we should start with this so
that folks get used to it.
Benedikt
2013/11/29 Emmanuel Bourg <eb...@apache.org>
> Le 29/11/2013 15:17, Christian Grobmeier a écrit :
>
> > Lets say i have had good experiences with that model. I shared this
> > information with you.
>
> Thank you. And I discovered a tool to deal easily with topic branches.
> The "git flow feature start/finish" syntax looks interesting.
>
>
> > Do as you please. I am not working on CLI anyway.
>
> But you will probably work on the next components migrating to Git. I
> think it's important to have consistent rules between the components, so
> it's a good thing to discuss the workflow now.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/11/2013 15:17, Christian Grobmeier a écrit :
> Lets say i have had good experiences with that model. I shared this
> information with you.
Thank you. And I discovered a tool to deal easily with topic branches.
The "git flow feature start/finish" syntax looks interesting.
> Do as you please. I am not working on CLI anyway.
But you will probably work on the next components migrating to Git. I
think it's important to have consistent rules between the components, so
it's a good thing to discuss the workflow now.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Christian Grobmeier <gr...@gmail.com>.
On 29 Nov 2013, at 14:44, Emmanuel Bourg wrote:
> Le 29/11/2013 14:28, Christian Grobmeier a écrit :
>
>> We should respect the naming conventions of git as good as possible.
>
> But git is a tool, not a development method, right? As such it doesn't
> mandate any specific workflow, even if a random blogger chose to name
> its own popular workflow "The Git Flow".
Lets say i have had good experiences with that model. I shared this
information with you.
> Developing on the master branch with Git is like working on the trunk
> for SVN. That's what people are used to do here, and that's the less
> disruptive option.
Do as you please. I am not working on CLI anyway.
Cheers
Christian
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/11/2013 14:28, Christian Grobmeier a écrit :
> We should respect the naming conventions of git as good as possible.
But git is a tool, not a development method, right? As such it doesn't
mandate any specific workflow, even if a random blogger chose to name
its own popular workflow "The Git Flow".
Developing on the master branch with Git is like working on the trunk
for SVN. That's what people are used to do here, and that's the less
disruptive option.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Christian Grobmeier <gr...@gmail.com>.
On 29 Nov 2013, at 14:09, Emmanuel Bourg wrote:
> Le 29/11/2013 12:20, Christian Grobmeier a écrit :
>
>> This in fact means:
>>
>> create a master branch which is stable.
>> create a develop branch which is not so stable.
>> create feature branches from develop where you work out your changes.
>
> We are just swapping the branch names here, in the end your model
> isn't
> very different from mine. Let's say the develop branch is named
> 'master', the stable branch is named '1.x' or 'stable' and we are
> basically dealing with the same workflow.
It's not my model, its the model described here:
http://nvie.com/posts/a-successful-git-branching-model/
This is a model many people follow. Having a development branch which is
called master
will confuse a lot of people. Its like using a svn branch as trunk.
We should respect the naming conventions of git as good as possible.
Cheers
Christian
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/11/2013 12:20, Christian Grobmeier a écrit :
> This in fact means:
>
> create a master branch which is stable.
> create a develop branch which is not so stable.
> create feature branches from develop where you work out your changes.
We are just swapping the branch names here, in the end your model isn't
very different from mine. Let's say the develop branch is named
'master', the stable branch is named '1.x' or 'stable' and we are
basically dealing with the same workflow.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Christian Grobmeier <gr...@gmail.com>.
On 26 Nov 2013, at 14:35, Gary Gregory wrote:
> On Tue, Nov 26, 2013 at 3:52 AM, Emmanuel Bourg <eb...@apache.org>
> wrote:
>
>> Le 26/11/2013 08:43, Benedikt Ritter a écrit :
>>> I propose [1] as branching model. It looks very complicated at
>>> first, but
>>> I've found it very useful to always have a release ready version of
>>> the
>>> code in master.
>>>
>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>
>> It looks complicated indeed. I prefer having the current developments
>> on
>> the master branch and create topic branches to experiment with more
>> involved changes. I don't think we have enough active developers per
>> component to require a more sophisticated model.
>>
>
> I agree with Emmanuel. Let's keep it simple by not mixing a change in
> VCS
> and process at the same time. Let's do Git and see how that goes.
I disagree. One of great benefits of Git is its branching power. You can
work
with Git as you did with SVN but this will ultimately lead to problems.
If attracting new committers is one of your goals you need to adapt the
common
way to work with the tool.
This in fact means:
create a master branch which is stable.
create a develop branch which is not so stable.
create feature branches from develop where you work out your changes.
merge back when done.
This all is supported by good clients. In example SourceTreeApp:
http://www.sourcetreeapp.com/
makes this all happen with just one click (its called git flow).
In my opinion:
if we don't adapt the common approach to use git, we should stick with
svn.
Only if use git as git should be used it makes sense to migrate.
If we are not open to learn (or don't have fun doing that or time) then
let's not do that.
Cheers
Christian
>
> Gary
>
>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second
> Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 26, 2013 at 3:52 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 26/11/2013 08:43, Benedikt Ritter a écrit :
> > I propose [1] as branching model. It looks very complicated at first, but
> > I've found it very useful to always have a release ready version of the
> > code in master.
> >
> > [1] http://nvie.com/posts/a-successful-git-branching-model/
>
> It looks complicated indeed. I prefer having the current developments on
> the master branch and create topic branches to experiment with more
> involved changes. I don't think we have enough active developers per
> component to require a more sophisticated model.
>
I agree with Emmanuel. Let's keep it simple by not mixing a change in VCS
and process at the same time. Let's do Git and see how that goes.
Gary
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [cli] Moving to Git?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 26/11/2013 08:43, Benedikt Ritter a écrit :
> I propose [1] as branching model. It looks very complicated at first, but
> I've found it very useful to always have a release ready version of the
> code in master.
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
It looks complicated indeed. I prefer having the current developments on
the master branch and create topic branches to experiment with more
involved changes. I don't think we have enough active developers per
component to require a more sophisticated model.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [cli] Moving to Git?
Posted by Benedikt Ritter <br...@apache.org>.
I propose [1] as branching model. It looks very complicated at first, but
I've found it very useful to always have a release ready version of the
code in master.
[1] http://nvie.com/posts/a-successful-git-branching-model/
2013/11/24 Benedikt Ritter <br...@apache.org>
> Let's give it a try. No objections from my side.
>
>
> 2013/11/24 Emmanuel Bourg <eb...@apache.org>
>
>> What about experimenting the migration to Git with cli?
>>
>> Emmanuel Bourg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [cli] Moving to Git?
Posted by Benedikt Ritter <br...@apache.org>.
Let's give it a try. No objections from my side.
2013/11/24 Emmanuel Bourg <eb...@apache.org>
> What about experimenting the migration to Git with cli?
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter