[En-Nut-Discussion] Switching to GIT
harald.kipp at egnite.de
Thu Sep 26 14:19:50 CEST 2013
On 26.09.2013 13:52, bon at elektron.ikp.physik.tu-darmstadt.de wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
> Harald> Uwe, On 26.09.2013 11:03,
> Harald> bon at elektron.ikp.physik.tu-darmstadt.de wrote:
> >>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
> >> Well, there is "git svn branch <branchname> " and "git svn dcommit
> >> <branchname>" that imply it can be done. I didn't test however yet.
> Harald> Until now I'm almost the only one who merges bug fixes from the
> Harald> trunk into maintenance branches. Considering my limited time,
> Harald> I'm a bit concerned about any additional complexity.
> Come on! Where is the added complexity?
I didn't want to state, there is added complexity, but wanted to express
my concerns that there may be, if nobody tested it.
> With regard of releases, you always were the master. But during my time
> contributing, I didn't see such a workflow or such a master for our SVN
> HEAD. So to implement the workflow above, we would need a person to take the
> role of such a master. If somebody intends to step in, a switch to git is
> justified and needed.
I intend to keep the master role and continue to pack the releases. Who
else, as I'm obviously the only one doing that for Linux, Windows and,
sometimes, Mac OS.
> But you restarted the discussion with the argument that SF is slow for "svn
> log" . And this can be solved if you checkout SVN locally as git and use
> "git log". And this doesn't justify a switch.
I think here is the core of misunderstanding. If I switch from SVN to
Git and if all other currently active developers agree, I will fully
switch. I never intended to use Git as a fix for SVN deficiency only,
but make use of Git's opportunities.
If there is an advantage of keeping SVN, and if that wouldn't introduce
additional complexity, we may keep SVN as a master. Right now I can not
really see this.
> But again, if you intend to use more advanced features and workflows for the
> central repo and require others to obey new rules, a switch may be needed
> and the workflow change has to be used by other contributors.
And I'd like to discuss this work flow. That's why I earlier posted a
and referring to the U-Boot project as an example.
Email conversation sometimes turns out to be difficult. I'm sorry for
any confusion I may have introduced by not clearly stating my thoughts.
More information about the En-Nut-Discussion