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

> > 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 the
> > 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.  ;-)