Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   NZ Computing (http://www.velocityreviews.com/forums/f47-nz-computing.html)
-   -   Git Is Fun (http://www.velocityreviews.com/forums/t702848-git-is-fun.html)

Lawrence D'Oliveiro 10-25-2009 04:53 AM

Git Is Fun
 
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 10-26-2009 01:57 AM

Re: Git Is Fun
 
In message <hc0lko$agn$1@lust.ihug.co.nz>, 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 10-27-2009 10:17 AM

Re: Git Is Fun
 
In message <hc0lko$agn$1@lust.ihug.co.nz>, 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...

JohnO 10-28-2009 01:46 AM

Re: Git Is Fun
 
On Oct 27, 11:17*pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message <hc0lko$ag...@lust.ihug.co.nz>, 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.

Lawrence D'Oliveiro 10-28-2009 03:50 AM

Re: Git Is Fun
 
In message <a7f96edb-0319-4d07-b3bb-
de4e8bc1c228@v15g2000prn.googlegroups.com>, 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.

Nik Coughlin 10-28-2009 05:07 AM

Re: Git Is Fun
 
"JohnO" <johno1234@gmail.com> wrote in message
news:a7f96edb-0319-4d07-b3bb-de4e8bc1c228@v15g2000prn.googlegroups.com...
> On Oct 27, 11:17 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
> > In message <hc0lko$ag...@lust.ihug.co.nz>, 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).


Lawrence D'Oliveiro 10-28-2009 06:37 AM

Re: Git Is Fun
 
In message <hc8jhm$8mi$1@news.eternal-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.

Nik Coughlin 10-28-2009 10:46 PM

Re: Git Is Fun
 
"Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message
news:hc8orf$234$1@lust.ihug.co.nz...
> In message <hc8jhm$8mi$1@news.eternal-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


Lawrence D'Oliveiro 10-29-2009 12:40 AM

Re: Git Is Fun
 
In message <hcahjp$md0$1@news.eternal-september.org>, Nik Coughlin wrote:

> "Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message
> news:hc8orf$234$1@lust.ihug.co.nz...
>
>> 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?

Stephen Worthington 10-29-2009 01:27 AM

Re: Git Is Fun
 
On Thu, 29 Oct 2009 13:40:12 +1300, Lawrence D'Oliveiro
<ldo@geek-central.gen.new_zealand> wrote:

>In message <hcahjp$md0$1@news.eternal-september.org>, Nik Coughlin wrote:
>
>> "Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message
>> news:hc8orf$234$1@lust.ihug.co.nz...
>>
>>> 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.


All times are GMT. The time now is 01:12 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.