[En-Nut-Discussion] Switching to GIT

[Harald Kipp]

Uwe,

On 25.09.2013 13:54, bon at elektron.ikp.physik.tu-darmstadt.de wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

> Killer argiment for GIT are:
> - The archive is local, so you can work without net connection

Most of the time I'm working local without net connection, using SVN.
When syncing my Git repo with the master, I still need a network
connection (more on this below). In this simplified way, this is _not_ a
killer argument.


> - Checkin are local first, so you have a grace period for error correction
> until you really decide to upload. How often did you do the SVN checkin and
> in the next moment you regretted the commit message or detected an error.

...which violates "release early, release often". Again, no killer argument.


> - Branching is easy, so you can first can develop in a local branch

Branching isn't difficult in SVN: "svn copy trunk branch".


> - Git can keep the SVN history.

What kind of killer argument pro Git contra SVN is that?! :-)


> - Git can easily tag (*)

Same as branching, very easy with SVN too. Still waiting for the killer
argument.


> - Git is wide spread.

Come on! SVN is widespread too, possibly more wide spread than Git.
Believe me, there is a world beside your Linux desktops, a large world.

What does all this really mean in practice for the "normal" developer?
Nothing, except spending hours, possibly days, to become familiar with a
new tool, which is badly known for its steep learning curve.

I have at least the following killer arguments:

1. Before releasing a new version, we are testing as much as possible.
If something fails, we need to query the history often, either to follow
the changes or to blame a developer. With SVN this is very time
consuming. Git keeps the history local, which makes this much, much faster.

2. _Switching_ between branches and revisions with SVN is, well,
suboptimal. With Git this takes almost no time.

3. Git provides more freedom for sharing. With SVN, sharing is limited
to a central repository, or you need to create patches, another patch,
one more and so on. With Git, developers can directly share and maintain
their local modifications without asking for access to a central repository.


> Before switching, what about first testing local? Either do a git svn
> checkout (**) or I can send you my 84 MByte repo, as file or as access to my
> dropbox.

I'm already using Git in a limited way. Anyway, thanks for your offer.
(You may regret that, when I select you as my Git Guru and bother you
with all kind of stupid problems later.)


> But if you use git locally, there is also no urgent need to switch the
> public repository anymore...

And how do you intent to get my local changes?

In general, I think we first need to come up with an intended workflow.
I found a good overview here:

https://www.atlassian.com/git/workflows

My personal favorite is the so called "Forking Workflow", which I think
is also used in the U-Boot project. Its big advantage is, that small
groups can freely work on specific topics without disturbing the master
repo. Even if their changes never make it into the master, it is still
available for further development.


> (*) One problem with tags is, that I can't find the date when the tag was
> done. Let me explain with the linux kernel. I can see with "git log" when a
> driver was introduced. But "git tag" doesn't give me a timeline so see which
> kernel release number first distributed this driver first. So if we change to
> git, we should make it a habbit to comment tags with the date.

How about

git log --tags --format=%aD

Regards,

Harald