Why is it important to learn git?

Why is it important to learn git?

[Tim Harper]

Hi all,

I'm preparing to teach a workshop on git, and would like to know how
other people benefit from the advanced features of git.  So, if you're
feeling kind enough to share a few minutes to respond (which I will
receive with gratitude):

How has mastering the advanced features of git helped you to be a
better programmer?

Re: Why is it important to learn git?

[Thomas Rast]

Tim Harper wrote:
> 
> How has mastering the advanced features of git helped you to be a
> better programmer?

I came from SVN, and I guess the most important change for me was:

  Learning to make nice, reviewable, working, one-change-per-revision
  commits.

This must be enforced by social pressure of course, but 'add --patch',
'commit --amend', 'rebase --interactive' and some others make it very
easy to actually do it even when working on a series of changes.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Why is it important to learn git?

[Sverre Rabbelier]

Heya,

On Wed, Jul 22, 2009 at 07:52, Thomas Rast<trast@student.ethz.ch> wrote:
>  Learning to make nice, reviewable, working, one-change-per-revision
>  commits.

I very much agree with those values, but also

  Commit early, commit often

It's very convenient to be able to go back to/diff with a previous
version later on, running 'git commit -am "got x half-working"' takes
only a few seconds, but can save hours later on when you got x
totally-not-working-at-all-anymore.

-- 
Cheers,

Sverre Rabbelier

Re: Why is it important to learn git?

[Jakub Narebski]

Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Wed, Jul 22, 2009 at 07:52, Thomas Rast<trast@student.ethz.ch> wrote:

> >  Learning to make nice, reviewable, working, one-change-per-revision
> >  commits.
> 
> I very much agree with those values, but also
> 
>   Commit early, commit often
 
I also find commit message convention: "short one-line description,
separated by empty line, then more detailed description" to be very
useful (git tools assume and expect this convention).  It helps
keeping changesets / commits small; if you can't write oneline summary
of commit, it is probably too large :-)

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Why is it important to learn git?

[Jeff King]

On Wed, Jul 22, 2009 at 09:52:26AM +0200, Thomas Rast wrote:

> > How has mastering the advanced features of git helped you to be a
> > better programmer?
> 
> I came from SVN, and I guess the most important change for me was:
> 
>   Learning to make nice, reviewable, working, one-change-per-revision
>   commits.

Same here. Git makes this easy to do. But it also makes me _want_ to do
it, because I benefit later from the advanced history investigation tools
like bisecting, pickaxe, blame, and even just decent visualization like
gitk that is lacking in other systems.

And of course if your workflow is based on reviewing patches (like for
git itself), then it is almost necessary.

-Peff

Re: Why is it important to learn git?

[Andreas Ericsson]

Thomas Rast wrote:
> Tim Harper wrote:
>> How has mastering the advanced features of git helped you to be a
>> better programmer?
> 
> I came from SVN, and I guess the most important change for me was:
> 
>   Learning to make nice, reviewable, working, one-change-per-revision
>   commits.
> 

Seconded. During the CVS days, noone bothered about history, but with
git a it's a veritable goldmine of important information, so it's
important to keep it clean with minimal changesets.

One of our developers was very sloppy about this until he ended up
with a bisection run landing him on a commit that fixed no less
than seven different issues. He spent four days debugging it and
finally had to resort to breaking the issues up and creating the
commits as they should have been on a temporary side-branch and
then bisecting that side-branch. Having done that, he spotted the
error in about 15 minutes. After some swearing, he finally saw the
light. He's actually a happier person now, since bugs that take a
long time to solve upset him quite enormously and now he never runs
into any :-)

Apart from that, the various ways of cooperating over large distances
(easy branching + merging, patch sending/applying utilities) are a
huge benefit for us.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Why is it important to learn git?

[Scott Chacon]

Hey,

On Tue, Jul 21, 2009 at 10:08 PM, Tim Harper<timcharper@gmail.com> wrote:
> Hi all,
>
> I'm preparing to teach a workshop on git, and would like to know how
> other people benefit from the advanced features of git.  So, if you're
> feeling kind enough to share a few minutes to respond (which I will
> receive with gratitude):
>
> How has mastering the advanced features of git helped you to be a
> better programmer?

I think the biggest gain Git gives many developers over other VCSs
(even other DVCSs) is the lightweight branching flexibility and easy
merging.  In Git, lightweight branches or topic branches are used in
much the same way that patch queuing tools like Hg's mq extension or
quilt, but I think most users find them much, much easier to use and
understand and often less error prone.  Using branches as silos
dedicated to a single work topic and being able to easily keep them
separated until you are ready to apply them to a main line of work
(such as merging with your master branch) is very powerful and is done
via a very simple and understandable existing paradigm of branches
rather than trying to learn a whole new command set of patching.  This
allows for fast and simple context switching and work unit isolation
that both very definitively changes most developers workflows in ways
that were completely impossible in SVN or Perforce or what-have-you.

Hope that helps.  If you need any material for your workshop, I have a
number of slides (Keynote and PDF) for presentations I have given at:

http://github.com/schacon/git-presentations

You can also get the PDF of the slides of the tutorial I gave at OSCON
yesterday on Git here:

http://en.oreilly.com/oscon2009/public/schedule/detail/7953

Let me know if there is anything else I can do to help.

Thanks,
Scott

Re: Why is it important to learn git?

[Dmitry Potapov]

On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:
> 
> How has mastering the advanced features of git helped you to be a
> better programmer?

I don't think that features itself make as big difference as the fact
Git provides you much more flexibility in choosing a more appropriate
workflow than you have with any centralized VCS. (Yes, you will still
find many Git features handy even if you work with it as you did with
CVS, but you will miss most benefits of Git).

To really understand what benefits Git offers, you have to realize first
what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to
explain just in a few words. Some implementation deficiency of CVS is
obvious (and it was addressed in some CVS clones like Subversion), but
more fundamental problems are far less obvious even for people who used
CVS for many years.

To be fair to CVS, it is far from the worst VCS. There are some insane
lock-based VCS, which were so painful to use (mostly due to these
exclusive locks but often due to some other insanity too) that anyone
who worked with may think about CVS as a really nice system...

In some way, CVS was really revolutionary for its time, because it used
the copy-modify-merge paradigm instead of excluding locking, which was
dominant before the CVS era. Those exclusive locks not only could not
work over the Internet, they were so excruciatingly annoying even if
everyone was sitting in the same room... Despite some initial skepticism
about essentially the lock-free VCS, I think it is safe to say now that
the copy-modify-merge paradigm won. Period.

However, if you look at the support of this paradigm in CVS and other
centralized VCSes, it is very limited in every aspect:
- copy: you can have a copy only one revision. (it may not be a big
  issue unless you like to work offline and to look at history).
- modify: there is no problem with modification itself, but you cannot
  save your changes without committing that to the official repo, which
  is not such a good thing if they are not ready yet or were not reviewed
  properly.
- merge: well.. I don't think there is any sane person who enjoyed
  merging branches in CVS... The only merge that was _relatively_ easy
  to do was merging your worktree with the upstream. Even that is not
  perfect in CVS, because you cannot save your changes before merge. So,
  if you made a mistake during 'cvs update', you risk to losing your
  work... Also, there is no possibility to review the merge later or to
  delegate to someone else when its resolution happens to be tricky...

The above limitations have further consequences with negatively affect
co-operation among developers. For instance, it is very difficult to
organize the review process with any centralized VCS. Typically, a
review process may require saving and share your work with reviewer
without committing it to the central repo. Also, this work should be
split into logical steps to make review easier. The only way to do that
with a centralized VCS is to use some patch management system on top of
it.... and at that point you may ask whether you want to learn two
systems with overlapping functionality and not so well integrated with
each other?

Another important reason why feature branches are so useful is that they
allow to postpone the decision about integration of some feature to the
master branch to the time when you convince that it is ready and useful.
In a "centralized" workflow, people often commit as they progress to
their goal, but some ideas may not so good as they initially appeared.
At the time when you realize that, your changes already intervened with
other people changes. There is no easy way to remove them cleanly. And,
some work even if it is useful may be not ready to the time when you
planned to realize a new version. This results in unnecessary delays in
release.

There are more problems with the "centralized" workflow used by CVS and
alike. They may be not very noticeable on small projects, but it tends
to get worse as any project growths over time.


So, the main advantage of Git is not in the number of features (and Git
has plenty of them despite of efforts to limit them to only truly useful
for many users), but its conceptual wholeness and flexibility, which
allows you to choose the appropriate workflow for your needs.


Dmitry

Re: Why is it important to learn git?

[Jakub Narebski]

Dmitry Potapov <dpotapov@gmail.com> writes:

> On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:
> > 
> > How has mastering the advanced features of git helped you to be a
> > better programmer?
> 
> I don't think that features itself make as big difference as the fact
> Git provides you much more flexibility in choosing a more appropriate
> workflow than you have with any centralized VCS. (Yes, you will still
> find many Git features handy even if you work with it as you did with
> CVS, but you will miss most benefits of Git).
> 
> To really understand what benefits Git offers, you have to realize first
> what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to
> explain just in a few words. Some implementation deficiency of CVS is
> obvious (and it was addressed in some CVS clones like Subversion), but
> more fundamental problems are far less obvious even for people who used
> CVS for many years.

See also my answer for "Difference between GIT and CVS" question
at StackOverflow:

  http://stackoverflow.com/questions/802573/difference-between-git-and-cvs/824241#824241
 
> To be fair to CVS, it is far from the worst VCS. There are some insane
> lock-based VCS, which were so painful to use (mostly due to these
> exclusive locks but often due to some other insanity too) that anyone
> who worked with may think about CVS as a really nice system...

By the way, even if CVS didn't implement support for file renames and
copying, at least it provides support for file deletion (as opposed to
*khem* SourceSafe).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Why is it important to learn git?

[Allan Kelly]

Has anyone done a presentation on this (very interesting) subject with examples?

What's good about this practice/pattern?
What's bad about that practice/pattern?

I ask because if not, I'd like to - with your help!

Cheers, al.

2009/7/22 Jakub Narebski <jnareb@gmail.com>:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:
>> >
>> > How has mastering the advanced features of git helped you to be a
>> > better programmer?
>>
>> I don't think that features itself make as big difference as the fact
>> Git provides you much more flexibility in choosing a more appropriate
>> workflow than you have with any centralized VCS. (Yes, you will still
>> find many Git features handy even if you work with it as you did with
>> CVS, but you will miss most benefits of Git).
>>
>> To really understand what benefits Git offers, you have to realize first
>> what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to
>> explain just in a few words. Some implementation deficiency of CVS is
>> obvious (and it was addressed in some CVS clones like Subversion), but
>> more fundamental problems are far less obvious even for people who used
>> CVS for many years.
>
> See also my answer for "Difference between GIT and CVS" question
> at StackOverflow:
>
>  http://stackoverflow.com/questions/802573/difference-between-git-and-cvs/824241#824241
>
>> To be fair to CVS, it is far from the worst VCS. There are some insane
>> lock-based VCS, which were so painful to use (mostly due to these
>> exclusive locks but often due to some other insanity too) that anyone
>> who worked with may think about CVS as a really nice system...
>
> By the way, even if CVS didn't implement support for file renames and
> copying, at least it provides support for file deletion (as opposed to
> *khem* SourceSafe).
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>