Re: Re[surrecting]: Version Control and Public Repository

[Phil Holmes]

----- Original Message ----- 
From: "Alec Bartsch" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: "Alexander Kobel" <address@hidden>; "Urs Liska" <address@hidden>; 
<address@hidden>
Sent: Friday, September 27, 2013 5:20 PM
Subject: Re: Re[surrecting]: Version Control and Public Repository



On Sep 27, 2013, at 3:50 AM, Phil Holmes <address@hidden> wrote:

> > If you have scoreA.ly and this includes my-tweak.ily and you create a 
> > commit in the git repo for this music, no matter how often you then 
> > alter my-tweak, you could always return to the commit for this music, 
> > and my-tweak will always be at the appropriate version.  That how 
> > version control works.

> So in git, would that commit be best expressed as a tag rather than a 
> branch? I'm still learning my way around git terminology. (We use perforce 
> at work.)

> Thanks,

> Alec

Well, others here will tell you I'm no expert.  However, the normal way of 
doing this would be that each time you make a specific change, then you 
commit this with a git commit:

git commit -am 'my change information'

This will return you a commitish, which is the key of that change.  You can 
then always revert to that state with:

git checkout that_commitish.

Tools like gitk or the web representation of the git state can help you find 
the commitish if you don't know it.  Alternatively, if it's soemthing you 
really think you will need to return to, a tag will serve the same purpose.

--
Phil Holmes