On Fri, 4 Dec 2009, Sverre Rabbelier wrote: > After specifying 'feature relative-marks' the paths specified with > 'feature import-marks' and 'feature export-marks' are relative to an > internal directory in the current repository. > > In git-fast-import this means that the paths are relative to the > '.git/info/fast-import' directory. However, other importers may use a > different location. > > Add 'feature non-relative-marks' to disable this behavior, this way > it is possible to, for example, specify the import-marks location as > relative, and the export-marks location as non-relative. > > Also add tests to verify this behavior. > > Cc: Daniel Barkalow <barkalow@xxxxxxxxxxxx> > Signed-off-by: Sverre Rabbelier <srabbelier@xxxxxxxxx> > --- > > As requested by Daniel, it is now possible to have the marks be > relative to a constant directory. We might want to consider making > this the default at some point. > > This patch opens the way for remote-helpers to use the marks feature > without poluting the work tree, which I think is very important. I think it would be better to make relative paths be the only available method, in part because we don't want to polute the work tree, but more because otherwise scripts aren't transferrable. That is, if you have an absolute path, you can't send the same script to two different importers (because they'd have to write their marks to the same location). And there's no way for the program constructing a script to determine a good absolute location if the script may be run on a different host than it's generated on (think of getting a Linux user getting a script attached to a bug report from a native Windows user; there are no absolute paths that are valid on both of these). (However, it probably does make sense to permit absolute paths in the command line, since whoever's writing the command line is presumably aware of any local conventions) -Daniel *This .sig left intentionally blank* -- 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