git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org, Patrick Doyle <wpdster@gmail.com>
Subject: Re: yet another workflow question...
Date: Thu, 11 Oct 2007 19:28:18 +0200	[thread overview]
Message-ID: <470E5D32.7060306@op5.se> (raw)
In-Reply-To: <200710111610.55364.andyparkins@gmail.com>

Andy Parkins wrote:
> On Thursday 2007 October 11, Patrick Doyle wrote:
> 
>> burning question, "What can git do for me?"  (So far, I have come to
>> the conclusion that, for my simple, single developer, branchless,
>> linear projects, there's not much that git can do for me that any
>> other SCM could do for me.  It appears to have been designed to solve
> 
> Here's a few things that are relevant to a simple, single, branchless, linear 
> developer:
> 
>  - Fast.  Git wipes the floor with everything else, so much so that the SCM
>    becomes a tool in itself, not just a recorder of history.  I keep my own
>    simple projects in git just as much as my complicated, branchy, team-based
>    projects just to get the following tools fast:
>     git-diff
>     git-status
>     git-commit
>     git-log
> 
>  - Small.  In every project I've converted from SVN to git, the diskspace
>    usage has gone down.  SVN peppers the working tree with .svn directories,
>    each of which contains a pristine copy of the last checked in version of
>    all the working files.  On top of that is the repository disk space itself.
> 
>    Git on the other hand keeps one .git directory at the top of the tree and
>    that stores the _entire_ repository.  It is, in my experience, smaller than
>    the working tree.  That means that git uses less diskspace than svn does
>    for a single checkout to store everything it needs.
> 
>  - Useful.  The following are so good, that even if you weren't doing any 
>    revision tracking you'd still want to use them:
>     git-grep
>     git-diff
> 
>  - Backup.  Backing up subversion repositories requires that you write
>    yourself a script that uses svnadmin dump.  With git I just write a couple
>    of lines in my .git/config and then git-push produces a highly compact
>    backup whenever I want.  Even better, if a disaster happens it's easy to
>    pull stuff out of that backup without any additional operations.
> 
>  - Mobility.  This one is a bit distributed, but I hope you'll let me have it. 
>    I often do work on my desktop at home, my desktop at work and my laptop. 
>    By setting my remotes up correctly in git it's really easy to walk to
>    another system and pick up exactly where I left off from the other
>    computer.  More importantly though, when you accidentally make changes in
>    two places, there is no danger of data loss.
> 
> Even if you aren't doing complicated stuff, git is the way to go.  I can't 
> count the number of ways it's made me more productive and enhanced the code I 
> write and the documentation of its development.  If I never worked on another 
> group project again I would still use git all day every day.
> 

I'm amazed nobody has mentioned git-bisect yet. Recently, I had an enormous amount
of benefit from it, so I'll just add it here as a success-story in case any OSS
support company comes along and wants to peddle git.


As it happens, I have a daemon that does some fairly clever scheduling. Somewhere
in a recent change, I had introduced a very subtle bug that made the latency times
for when the actions were actually happening diverge from 0s. I know I get a
latency spike just when I fire the daemon up, but it's supposed to normalize after
10 or so minutes and converge on zero-latency. Instead it was slowly increasing,
but the effects weren't really visible until after about 2 hours.

git bisect to the rescue. Since I didn't feel terribly inclined to walk over to
my computer every two hours to recompile, wipe logs and start the daemon all over
again, I hacked up a script to do it for me. The script also checked the latency
figures and re-ran git-bisect as necessary.

22 hours (or 7 bisects) later, git had, with a little help from my script, shown
me exactly the commit that introduced the latency issue. During the time, I was
enjoying a walk in the sun, dinner with my girlfriend and a good nights sleep.

Life is good when you have the proper tools.

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

  reply	other threads:[~2007-10-11 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11 14:11 yet another workflow question Patrick Doyle
2007-10-11 14:18 ` David Kastrup
2007-10-11 14:44   ` Steffen Prohaska
2007-10-11 14:37 ` Johannes Sixt
2007-10-11 14:39 ` Wincent Colaiuta
2007-10-11 15:10 ` Andy Parkins
2007-10-11 17:28   ` Andreas Ericsson [this message]
2007-10-11 20:40   ` Jing Xue
2007-10-12  7:25     ` Andy Parkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470E5D32.7060306@op5.se \
    --to=ae@op5.se \
    --cc=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=wpdster@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).