Re: Weird shallow-tree conversion state, and branches of shallow trees

> On 4/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > The tree that goes out to users is NOT git or CVS. What you point to
>> > here is impossible unless we forced all of the users to migrate to git
>> > (a truly herculean task if there was ever one).
>> > It's a tarball or an rsync of an automatically managed CVS checkout.
>> > (Tarballs go onto the release media, and are also widely used by those
>> > that sneaker-net their trees to machines for security reasons).
>> > Alternatively, the users browse the viewcvs, and pull something from

>> > Attic. Regardless of where they get the file from, the problem is that
>> > the file doesn't contain any markers to help the developers merge it
>> > back again.
>>
>> Git won't do this for you.  We specifically don't mangle source[*1*].
>>
>> What you could do is create a program that mangles the files before
>> delivery.  You would probably want to do something like:
>>
>>   $Id: 7fbf239:path/to/file$
>>
>> where 7fbf239 is the earliest commit that introduced that particular
>> version of path/to/file, even if that is months old.  That would
>> be most like what CVS would do.  8 char abbreviated commits should
>> be reasonably stable, and not too long to read or copy and paste.
>> A format like the above would also be easy to grab and copy into
>> a Git command line.
>>
>> If we had a Git library that could access the repository, this would
>> a pretty easy program to write.  You are basically blaming each path
>> in the current HEAD commit on the parent, until you cannot blame
>> anyone else for that path.  You do this blame on the entire tree,
>> and then output the munged structure (or only the files you want
>> munged).
>>
>> Its good we have a GSoC project working on libification!  ;-)
>>
>> [*1*] Yes, I'm ignoring the nutso crlf support that's now in...  Even
>>       though I work on Windows, the only true line ending is LF.  ;-)
> 
> Can we add an attribute like Subversion's svn:keywords? If the
> attribute is set, we expand keywords when checkout and remove
> expansion in memory before doing any git operations. It's some kind of
> I/O filter for working directory access.