Re: On pathnames

Daniel Barkalow [off-list ref] writes:

$ git checkout branch
Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out
$ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c
$ edit xt_CONNMARK_caps.c
$ git add xt_CONNMARK_caps.c

Heh, I like that very much.

Hi,

On Thu, 24 Jan 2008, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

$ git checkout branch
Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out
$ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c
$ edit xt_CONNMARK_caps.c
$ git add xt_CONNMARK_caps.c

Heh, I like that very much.

It would make it easier to test on Linux, too, yes.

But then, it would break the build process all the same.

And the implementation would _need_ the index extension Linus seems to 
resent so.

Ciao,
Dscho

On Fri, 25 Jan 2008, Johannes Schindelin wrote:

Hi,

On Thu, 24 Jan 2008, Junio C Hamano wrote:

quoted

Daniel Barkalow [off-list ref] writes:

quoted

$ git checkout branch
Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out
$ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c
$ edit xt_CONNMARK_caps.c
$ git add xt_CONNMARK_caps.c

Heh, I like that very much.

It would make it easier to test on Linux, too, yes.

But then, it would break the build process all the same.

Sure, but it would permit a user of a filesystem that can't handle the 
project to make modifications that generate a commit the filesystem can 
handle, which is currently pretty difficult.

$ git checkout xt_CONNMARK.c --as xt_CONNMARK_tmp.c
$ mv xt_CONNMARK_tmp.c xt_connmark_flag.c
$ edit Makefile
$ git add xt_connmark_flag.c
$ git commit -a

(The key thing here being that git will determine that you removed 
xt_CONNMARK.c despite open(xt_CONNMARK.c) returning something unrelated)

Remember that this level of support is to allow users who can't have the 
project checked out in their filesystems to manipulate the project's data, 
not to actually make the project work as presented in the filesystem by 
git.

And the implementation would _need_ the index extension Linus seems to 
resent so.

Linus was objecting to having redundant information stored, because it 
could get skewed. If the information being stored is not redundant (i.e., 
the normal case is that entries have a flag saying they exist in the 
filesystem under their own names, and the new cases are that the entry 
isn't present in the filesystem at all or that the entry is present in the 
filesystem under some other name), that isn't an issue.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Fri, 25 Jan 2008, Daniel Barkalow wrote:

On Fri, 25 Jan 2008, Johannes Schindelin wrote:

quoted

On Thu, 24 Jan 2008, Junio C Hamano wrote:

quoted

Daniel Barkalow [off-list ref] writes:

quoted

$ git checkout branch
Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out
$ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c
$ edit xt_CONNMARK_caps.c
$ git add xt_CONNMARK_caps.c

Heh, I like that very much.

It would make it easier to test on Linux, too, yes.

But then, it would break the build process all the same.

Sure, but it would permit a user of a filesystem that can't handle the 
project to make modifications that generate a commit the filesystem can 
handle, which is currently pretty difficult.

$ git checkout xt_CONNMARK.c --as xt_CONNMARK_tmp.c
$ mv xt_CONNMARK_tmp.c xt_connmark_flag.c
$ edit Makefile
$ git add xt_connmark_flag.c
$ git commit -a

AFAICT it is possible right now:

$ git checkout xt_CONNMARK.c
$ git mv xt_CONNMARK.c xt_connmark_flag.c
$ git checkout xt_connmark.c
$ edit Makefile
$ git add Makefile
$ git commit

Ciao,
Dscho