[Novalug] Developer question(s)-- things have changed! (rcs $Id$ in git?)

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Wed Jun 1 14:56:19 EDT 2011


  You don't have to be...you'd be the One Eyed Man in the Kingdom of the 
Blind.

Besides...I'm thinking that some of the features that Linus is 
Championing are actually Bad...such as the ability to Rewrite the 
History. Clearly, the Ministry of Truth uses git ;-)

OK, back to the original discussion. While it would seem that Keywords 
do indeed have less meaning when there is more than one repo, files DO 
exist outside of the repos, and it's often quite useful to examine the
date. Of course there are Tags that are unique, but so are the 
Change-IDs. And indeed, an abbreviated
list of the most recent changes could be stamped on a file. I wouldn't 
mind seeing something like:

$Git: 3141-5926-5358-9793-2384-6abc-dead-beef-face-0000$

That string should be (assuming identical formatting) unique, no?

JIM

On 5/31/2011 6:45 PM, Jason Kohles wrote:
> I'd be happy to give one, though I'm far from a git expert.  :)
>
>
>
> Jason Kohles
> Palantir Technologies | UNIX Systems Engineer
> jkohles@palantirtech.com | 703.957.5784
>
> ----- Original Message -----
> From: greg pryzby [mailto:greg@pryzby.org]
> Sent: Tuesday, May 31, 2011 03:43 PM
> To: Jason Kohles
> Cc: plarsen@famlarsen.homelinux.com<plarsen@famlarsen.homelinux.com>; novalug@calypso.tux.org<novalug@calypso.tux.org>
> Subject: Re: [Novalug] Developer question(s)-- things have changed! (rcs $Id$ in git?)
>
> And I would LOVE a git talk at a future meeting.
>
>
> On Tue, May 31, 2011 at 6:22 PM, Jason Kohles<jkohles@palantir.com>  wrote:
>> in that case there isn't any need for arguing.  :). Git has tagging, and IMHO it's better thought out than subversions "it's a tag because it's in a directory named 'tags'" implementation.  In git a tag is basically a checkpoint that says "at the time this tag was made, the repository contained these changesets".
>>
>>
>>
>> Jason Kohles
>> Palantir Technologies | UNIX Systems Engineer
>> jkohles@palantirtech.com | 703.957.5784
>>
>> ----- Original Message -----
>> From: Peter Larsen [mailto:plarsen@famlarsen.homelinux.com]
>> Sent: Tuesday, May 31, 2011 02:47 PM
>> To: Jason Kohles
>> Cc: novalug@calypso.tux.org<novalug@calypso.tux.org>
>> Subject: Re: [Novalug] Developer question(s)-- things have changed! (rcs $Id$ in git?)
>>
>> (see comments below)
>>
>> On Tue, 2011-05-31 at 12:58 -0700, Jason Kohles wrote:
>>> The big difference is that when you used $Version$ with CVS, every file
>>> had it's own distinct version number, and it made sense to be able to put
>>> that information into the file.
>>>
>>> With subversion people get all confused by the fact that each file doesn't
>>> have it's own specific version,  instead you have just one revision number
>>> for each commit (which may cover multiple files), so you end up with
>>> people doing odd things to try and make the subversion revision number
>>> *look* like a version number (I'm sure if you look hard enough you can
>>> find some of my old perl code that does things like '$VERSION = sprintf(
>>> '1.%03d', qw$Version$').
>>>
>>> With git this is even more meaningless, because instead of trying to
>>> manipulate a revision number into a version, you have a 40-character
>>> cryptographic hash.  There is no way for git to put this information into
>>> the file in a meaningful way, because even if it just stuck the hash into
>>> the file where you told it to, you still need the rest of the repository
>>> in order to determine whether one particular hash is more recent than
>>> another.  The hashes by themselves don't tell you anything about the age
>>> of the file, so if you want a version number in the file header, you still
>>> need an external script to determine what that version number should be,
>>> so it makes sense to have that script do the substitution, rather than put
>>> that functionality into git.
>> Ahhh - ok, I see the miscommunication here. I'm not talking about
>> specifically about a file/module. We all know software is comprised of a
>> lot of different modules. I'm not a GIT person (yet) - I know SVN
>> better. What I'm talking about is "tags" which do stay consistent.
>> You'll tag a collection of files at given revisions to belong to the
>> same "release" which is what makes sense when you do your RPM builds and
>> your final code release.
>>
>> You'll get no argument from me, that during distributed development,
>> version numbers make little sense. I love the SVN concept of revision
>> numbers that just count up. That makes more sense than the artificial
>> 1.2.3.4 numbers/letters on individual files. That construct is
>> artificial anyway, and hence the TAG.
>>
>> In other words - I do see the need to be able to query the metadata on
>> build. Of course you can just change a constant yourself and check it
>> in. It would have the same programmable effect - but you wouldn't have a
>> sync/link to the version control.
>>
>> --
>> Best Regards
>>   Peter Larsen
>>
>> Wise words of the day:
>> "A power so great, it can only be used for Good or Evil!"
>>                 -- Firesign Theatre, "The Giant Rat of Summatra"
>> _______________________________________________
>> Novalug mailing list
>> Novalug@calypso.tux.org
>> http://calypso.tux.org/mailman/listinfo/novalug
>>
>
>




More information about the Novalug mailing list