Git Is Fun

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Oct 25, 2009.

  1. Using a distributed version-control tool like Git can really make a
    difference to your productivity.

    In one ongoing project for a client, I was asked a couple of weeks ago to
    add a project import-export function. I started working on this, but found a
    few subtleties I had to figure out how to deal with, which meant it took a
    bit longer than I originally expected to get it working.

    In the meantime, a few other requests for smaller changes came through.
    Rather than put them aside, I decided to get them out of the way. So first I
    created a Git branch to save my work in progress:

    git branch import-export
    git add -u
    git commit -m"start work on import-export function"

    Then restore the state of the source tree to the last production version of
    the code:

    git checkout master

    Then implement the necessary changes, test them, put them into production
    and commit them to the master branch. Then back to working on the import-
    export function:

    git checkout import-export

    But what about the changes I'd already made on the master branch? I don't
    want to lose them when I finally put this version into production. Simple:
    merge them into this branch:

    git merge master

    And then I just continued working on the import-export function.

    The first time I did this, the merge went without a hiccup. The second time
    (after I'd added an option to the master branch to generate a new report),
    it reported a conflict over certain source lines. But it was easy enough to
    use the "git diff" command to see a 3-way diff of the two branches against
    their most recent common ancestor showing two columns of plus, minus or
    blank characters indicating the respective differences. I confirmed that
    there were nothing but single plus signs in these columns (both changes were
    independent additions with no deletions), included both sets of changes, and
    finished the merge.

    Linus Torvalds' advice with Git is to commit often, and not be afraid to
    create temporary branches like this. I'm beginning to see the value in this,
    versus my previous approach of saving copies of the work in progress in
    another directory, then trying to merge it back in myself using the diff and
    patch commands. This way I get a commit history which lets me try out
    different things without losing what I'd previously done. And when it
    finally goes into production, I can decide whether I want to keep that side
    branch for historical purposes, or get rid of it.
    Lawrence D'Oliveiro, Oct 25, 2009
    #1
    1. Advertising

  2. In message <hc0lko$agn$>, Lawrence D'Oliveiro wrote:

    > In one ongoing project for a client, I was asked a couple of weeks ago to
    > add a project import-export function.


    Oh by the way, if you're using XML as an interchange format, it can be
    really helpful to apply some compression to it. For example, with GZip
    compression, I'm seeing files over 4MB in size get knocked down to just over
    90K.

    Speeds up Web uploads and downloads, too.
    Lawrence D'Oliveiro, Oct 26, 2009
    #2
    1. Advertising

  3. In message <hc0lko$agn$>, Lawrence D'Oliveiro wrote:

    > Then restore the state of the source tree to the last production version
    > of the code:
    >
    > git checkout master
    >
    > Then implement the necessary changes, test them, put them into production
    > and commit them to the master branch. Then back to working on the import-
    > export function:
    >
    > git checkout import-export
    >
    > But what about the changes I'd already made on the master branch? I don't
    > want to lose them when I finally put this version into production. Simple:
    > merge them into this branch:
    >
    > git merge master
    >
    > And then I just continued working on the import-export function.


    And then, when I was finally ready to put the import-export function into
    production, I went

    git checkout master
    get merge import-export

    except that I'd already previously merged master into import-export. So Git
    reported nothing to do on that final merge--it was what's called a "fast-
    forward" merge. Except I wanted to save a commit comment saying I was
    putting the new function into production. But since there was no actual
    commit needed, there was no place to save that comment.

    Ah well. I could back out those last couple of merges and redo them the
    right way round--Git is flexible like that. But I don't think I'll bother
    after all...
    Lawrence D'Oliveiro, Oct 27, 2009
    #3
  4. Lawrence D'Oliveiro

    JohnO Guest

    On Oct 27, 11:17 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message <hc0lko$>, Lawrence D'Oliveiro wrote:
    >
    >
    >
    >
    >
    > > Then restore the state of the source tree to the last production version
    > > of the code:

    >
    > >     git checkout master

    >
    > > Then implement the necessary changes, test them, put them into production
    > > and commit them to the master branch. Then back to working on the import-
    > > export function:

    >
    > >     git checkout import-export

    >
    > > But what about the changes I'd already made on the master branch? I don't
    > > want to lose them when I finally put this version into production. Simple:
    > > merge them into this branch:

    >
    > >     git merge master

    >
    > > And then I just continued working on the import-export function.

    >
    > And then, when I was finally ready to put the import-export function into
    > production, I went
    >
    >     git checkout master
    >     get merge import-export
    >
    > except that I'd already previously merged master into import-export. So Git
    > reported nothing to do on that final merge--it was what's called a "fast-
    > forward" merge. Except I wanted to save a commit comment saying I was
    > putting the new function into production. But since there was no actual
    > commit needed, there was no place to save that comment.
    >
    > Ah well. I could back out those last couple of merges and redo them the
    > right way round--Git is flexible like that. But I don't think I'll bother
    > after all...


    .... and you think all the above is... fun?

    Sucks to be you, Larry.
    JohnO, Oct 28, 2009
    #4
  5. In message <a7f96edb-0319-4d07-b3bb-
    >, JohnO wrote:

    > ... and you think all the above is... fun?


    Well, this IS nz.comp.

    If you'd rather spend your time in nz.wank, nobody's stopping you.
    Lawrence D'Oliveiro, Oct 28, 2009
    #5
  6. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "JohnO" <> wrote in message
    news:...
    > On Oct 27, 11:17 pm, Lawrence D'Oliveiro <l...@geek-
    > central.gen.new_zealand> wrote:
    > > In message <hc0lko$>, Lawrence D'Oliveiro wrote:
    > >
    > > And then, when I was finally ready to put the import-export function
    > > into
    > > production, I went
    > >
    > > git checkout master
    > > get merge import-export
    > >
    > > except that I'd already previously merged master into import-export. So
    > > Git
    > > reported nothing to do on that final merge--it was what's called a
    > > "fast-
    > > forward" merge. Except I wanted to save a commit comment saying I was
    > > putting the new function into production. But since there was no actual
    > > commit needed, there was no place to save that comment.
    > >
    > > Ah well. I could back out those last couple of merges and redo them the
    > > right way round--Git is flexible like that. But I don't think I'll
    > > bother
    > > after all...

    >
    > ... and you think all the above is... fun?
    >
    > Sucks to be you, Larry.


    If you're a software developer and you need to use source control, and you
    do software development because you find programming fun, then yes, git is
    fun.

    Are you saying it sucks to enjoy what you do if you're a programmer?

    If that's what you're saying, I'm with Lawrence on this one (shock horror).
    Nik Coughlin, Oct 28, 2009
    #6
  7. In message <hc8jhm$8mi$-september.org>, Nik Coughlin wrote:

    > If you're a software developer and you need to use source control ...


    What I'm starting to conclude is that there aren't two ifs in the above
    phrase, there's only one: if you're a software developer, then you need to
    use source control. I'm starting to use Git even for simple standalone
    scripts, because it's so handy to have that development history--it makes me
    more willing to try different things.
    Lawrence D'Oliveiro, Oct 28, 2009
    #7
  8. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:hc8orf$234$...
    > In message <hc8jhm$8mi$-september.org>, Nik Coughlin wrote:
    >
    >> If you're a software developer and you need to use source control ...

    >
    > What I'm starting to conclude is that there aren't two ifs in the above
    > phrase, there's only one: if you're a software developer, then you need to
    > use source control.


    Well, there are some developers whose code is so bad that it would be
    criminal to replicate it in more than one place :)

    > I'm starting to use Git even for simple standalone
    > scripts, because it's so handy to have that development history--it makes
    > me
    > more willing to try different things.


    Makes sense. For simple things I generally just make a copy between major
    changes but I'm thinking that this approach is better
    Nik Coughlin, Oct 28, 2009
    #8
  9. In message <hcahjp$md0$-september.org>, Nik Coughlin wrote:

    > "Lawrence D'Oliveiro" <_zealand> wrote in message
    > news:hc8orf$234$...
    >
    >> I'm starting to use Git even for simple standalone
    >> scripts, because it's so handy to have that development history--it makes
    >> me more willing to try different things.

    >
    > Makes sense. For simple things I generally just make a copy between major
    > changes but I'm thinking that this approach is better


    Yup, that's how I used to do it. But it's so much quicker to simply commit
    another version--less chance of accidents, for one. You get into the habit
    of doing it for minor changes as well, not just major ones.

    I've even heard of sysadmins putting their entire /etc directories into
    version control. What better way to maintain an audit trail of changes to
    your system config?
    Lawrence D'Oliveiro, Oct 29, 2009
    #9
  10. On Thu, 29 Oct 2009 13:40:12 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <hcahjp$md0$-september.org>, Nik Coughlin wrote:
    >
    >> "Lawrence D'Oliveiro" <_zealand> wrote in message
    >> news:hc8orf$234$...
    >>
    >>> I'm starting to use Git even for simple standalone
    >>> scripts, because it's so handy to have that development history--it makes
    >>> me more willing to try different things.

    >>
    >> Makes sense. For simple things I generally just make a copy between major
    >> changes but I'm thinking that this approach is better

    >
    >Yup, that's how I used to do it. But it's so much quicker to simply commit
    >another version--less chance of accidents, for one. You get into the habit
    >of doing it for minor changes as well, not just major ones.
    >
    >I've even heard of sysadmins putting their entire /etc directories into
    >version control. What better way to maintain an audit trail of changes to
    >your system config?


    I use an editor (SlickEdit) that automatically keeps version history
    for all files each time you save the file. And it will diff between
    versions for you.
    Stephen Worthington, Oct 29, 2009
    #10
  11. In message <>, Stephen Worthington
    wrote:

    > I use an editor (SlickEdit) that automatically keeps version history
    > for all files each time you save the file. And it will diff between
    > versions for you.


    Does it handle branches and merges as well?
    Lawrence D'Oliveiro, Oct 29, 2009
    #11
  12. Lawrence D'Oliveiro

    John Little Guest

    On Oct 29, 2:27 pm, Stephen Worthington
    <34.nz56.remove_numbers> wrote:

    > I use an editor (SlickEdit) that automatically keeps version history
    > for all files each time you save the file.  And it will diff between
    > versions for you.


    Yeah, I do that with some vim script. But the git approach has been
    on my to do list for some time, thanks Lawrence for encouraging me.

    Regards, John
    John Little, Oct 29, 2009
    #12
  13. In message <1crfnxgc22mng$>, Adam Cameron wrote:

    > Out of interest, how does anything you describe here really differentiate
    > git from SVN?


    Learn to reply to the right posting, won't you?

    Git is distributed, SVN is centralized. Every Git user has their own
    complete repository. Instead of checking in and out to and from a central
    server, they "push" and "pull" changesets to/from each other.

    Last I heard, SVN was crap at handling merges. You could create a branch,
    but then you had all kinds of trouble trying to bring changes across from
    one branch to another. And trying to do it more than once from the same
    branch was just asking for trouble. By contrast, Git is designed to handle
    this kind of situation as an everyday occurrence.

    SVN checkins are slow. Git checkins are fast.

    Anything else you want to know?
    Lawrence D'Oliveiro, Oct 29, 2009
    #13
  14. On Thu, 29 Oct 2009 15:34:45 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <>, Stephen Worthington
    >wrote:
    >
    >> I use an editor (SlickEdit) that automatically keeps version history
    >> for all files each time you save the file. And it will diff between
    >> versions for you.

    >
    >Does it handle branches and merges as well?


    No, it is just on a single file basis, and stores deltas between the
    versions. It is not intended to replace proper version control, just
    to supplement it for when you forgot to do it. The backup directory
    path can be specified, but if you leave it empty it keeps them all
    under the user's home directory somewhere. It defaults to keeping up
    to 400 back versions of each file.
    Stephen Worthington, Oct 29, 2009
    #14
  15. In message <>, Stephen Worthington
    wrote:

    > On Thu, 29 Oct 2009 15:34:45 +1300, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >>In message <>, Stephen
    >>Worthington wrote:
    >>
    >>> I use an editor (SlickEdit) that automatically keeps version history
    >>> for all files each time you save the file. And it will diff between
    >>> versions for you.

    >>
    >>Does it handle branches and merges as well?

    >
    > No, it is just on a single file basis, and stores deltas between the
    > versions. It is not intended to replace proper version control ...


    Yet another proprietary solution to the wrong problem.

    Why don't they just support standard interfaces to proper VCSes? Even Emacs
    knows when I'm using Git.
    Lawrence D'Oliveiro, Oct 29, 2009
    #15
  16. On Thu, 29 Oct 2009 21:12:05 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <>, Stephen Worthington
    >wrote:
    >
    >> On Thu, 29 Oct 2009 15:34:45 +1300, Lawrence D'Oliveiro
    >> <_zealand> wrote:
    >>
    >>>In message <>, Stephen
    >>>Worthington wrote:
    >>>
    >>>> I use an editor (SlickEdit) that automatically keeps version history
    >>>> for all files each time you save the file. And it will diff between
    >>>> versions for you.
    >>>
    >>>Does it handle branches and merges as well?

    >>
    >> No, it is just on a single file basis, and stores deltas between the
    >> versions. It is not intended to replace proper version control ...

    >
    >Yet another proprietary solution to the wrong problem.
    >
    >Why don't they just support standard interfaces to proper VCSes? Even Emacs
    >knows when I'm using Git.


    SlickEdit also supports a number of VCS systems.
    Stephen Worthington, Oct 29, 2009
    #16
  17. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Adam Cameron" <> wrote in message
    news:gkrrnnrighv5$.2pczyqyfu1te$...
    >> If you're a software developer and you need to use source control, and
    >> you
    >> do software development because you find programming fun, then yes, git
    >> is
    >> fun.

    >
    > I think it's a bit of a stretch to say source control is *fun*. *Handy*,
    > and *life saving* sure. Fun? No, that's just weird.


    I don't mean fun in the sense of operating it, I mean fun in what it enables
    you to do, not to have to worry about changes, being able to access your
    assets from different locations, being able to compare versions etc. It
    enhances programming, which means that in its own little way it's fun, yes.
    Nik Coughlin, Oct 29, 2009
    #17
  18. In message <hccrrc$713$-september.org>, Nik Coughlin wrote:

    > It enhances programming, which means that in its own little way it's fun,
    > yes.


    I don't know about others, but for me programming is a professional
    activity. Because I do it for a living, I spend large amounts of time on it.
    It's an activity I chose to do because I found it interesting. And still do.
    Others may have jobs they consider dull and boring, but I don't.
    Lawrence D'Oliveiro, Oct 30, 2009
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    629
  2. Luke

    Fun fun fun

    Luke, Oct 7, 2003, in forum: Computer Support
    Replies:
    3
    Views:
    537
    Petit Alexi
    Oct 7, 2003
  3. Toolman Tim

    GNIP > Old Git!

    Toolman Tim, Dec 3, 2005, in forum: Computer Support
    Replies:
    6
    Views:
    393
    Toolman Tim
    Dec 3, 2005
  4. Lawrence D'Oliveiro

    Perl moves to Git

    Lawrence D'Oliveiro, Dec 24, 2008, in forum: NZ Computing
    Replies:
    1
    Views:
    329
    Enkidu
    Dec 25, 2008
  5. Lawrence D'Oliveiro

    Ah, the joys of git-bisect...

    Lawrence D'Oliveiro, Mar 18, 2010, in forum: NZ Computing
    Replies:
    0
    Views:
    337
    Lawrence D'Oliveiro
    Mar 18, 2010
Loading...

Share This Page