Nguyen Thai Ngoc Duy wrote: > On 4/15/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> 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 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. ;-) > > 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. There was some talk about keyword expansion, and it is doable IIRC. Check out threads containing: Message-ID: <20070301175200.GA21433@xxxxxxxxxxxxxxxxxxxxxxxxxx> http://permalink.gmane.org/gmane.comp.version-control.git/41108 (with some inane totally irrelevant subject) -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html