[RFC] Make grafts versionable

[RFC] Make grafts versionable

[Johannes Schindelin]

... by moving the location from .git/info/grafts to .gitgrafts. This 
allows checking it in like .gitignore, and sure enough also pulling it (as 
well as knowing who the heck added that particular graft anyway).

Totally untested.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

	This would make half the discussion about rewriting history
	obsolete, methinks.

	Of course, to take advantage of it, you have to move the file 
	.git/info/grafts (if it exists) into the correct place yourself:

		mv -i .git/info/grafts .gitgrafts

 environment.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

applies-to: 20259f7c4418392e0e0c2f3a867811f657498afe
a1756142e3be780ed7992cd6a3f5e64b53c42253
diff --git a/environment.c b/environment.c
index b5026f1..b0c2f79 100644
--- a/environment.c
+++ b/environment.c
@@ -35,7 +35,7 @@ static void setup_git_env(void)
 	}
 	git_graft_file = getenv(GRAFT_ENVIRONMENT);
 	if (!git_graft_file)
-		git_graft_file = strdup(git_path("info/grafts"));
+		git_graft_file = strdup(git_path("../.gitgrafts"));
 }
 
 char *get_git_dir(void)
---
0.99.9.GIT

Re: [RFC] Make grafts versionable

[H. Peter Anvin]

Johannes Schindelin wrote:
> ... by moving the location from .git/info/grafts to .gitgrafts. This 
> allows checking it in like .gitignore, and sure enough also pulling it (as 
> well as knowing who the heck added that particular graft anyway).

This is problematic, because it means something that isn't in GIT_DIR 
affects its interpretation.  I would say that that is a showstopper.

One could even argue that it's incorrect, since it would mean different 
points on the history have different grafts.

Now, CVS has a reserved namespace (CVSROOT/) for things under version 
control which are still significant to CVS.  The logical equivalent to 
git would be to have .git/ be such a namespace, if it makes sense.

	-hpa

Re: [RFC] Make grafts versionable

[Linus Torvalds]

On Mon, 21 Nov 2005, H. Peter Anvin wrote:
> 
> Now, CVS has a reserved namespace (CVSROOT/) for things under version control
> which are still significant to CVS.  The logical equivalent to git would be to
> have .git/ be such a namespace, if it makes sense.

Well, there's two reasons for disallowing git from tracking it's own .git 
directory:

 - it protects against people doing somethin glike

	git-update-cache --add -- $(find . -type f | cut -c3..)

   and finding the pre-existing files in ".git"

   This used to literally be how I imported trees into git. These days, 
   you can just do it with "git-ls-files --others", and in fact that is 
   exactly what "git add" does, so now you can just do

	git add .

   and be done with it - without getting that ".git" directory by mistake.

   So that _old_ reason may not be as valid any more.

However, there's one fundamental reason:

 - if you have a file in ".git", that implies that even a "raw git repo" 
   would have versions matter, since technically such a file would be 
   inside the "raw" part. And that I find to be confusing. One of the 
   whole points of a raw git repo is that because it doesn't have anything 
   that is version-controlled and checked out, none of the branches or 
   tags are special, and nothing needs to be updated when you push to such 
   a repo.

   Now, if you have files in .git, suddenly that fundamental nature of a 
   raw repository is no longer clear.

In general, making any internal git data versionable is very confusing. So 
you make the grafts file versionable - that suddenly means that different 
branches may have different parents for the same commit. And that 
depending on which branch you have checked out, git-fsck-cache may result 
in an error, or it may not. That's _nasty_, in my opinion.

So I much prefer to say: everything under ".git" is not versionable, for 
the fundamental reason that the files under .git are "global" to that git 
repository. 

And I think .git/grafts in particular makes no sense to version.

If you want to track a git "grafts" file, you can do it as another git 
repository and a symlink.

		Linus

Re: [RFC] Make grafts versionable

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> However, there's one fundamental reason:
> 
>  - if you have a file in ".git", that implies that even a "raw git repo" 
>    would have versions matter, since technically such a file would be 
>    inside the "raw" part. And that I find to be confusing. One of the 
>    whole points of a raw git repo is that because it doesn't have anything 
>    that is version-controlled and checked out, none of the branches or 
>    tags are special, and nothing needs to be updated when you push to such 
>    a repo.
> 
>    Now, if you have files in .git, suddenly that fundamental nature of a 
>    raw repository is no longer clear.
> 

Note that I didn't actually mean that they should necessarily represent 
files in .git/.  The point was more that if we wanted to have 
version-controlled metadata, using .git/ as a namespace would be suitable.

In particular, I believe that if we ever do that, git should obtain this 
metadata from the repository/object database.

> In general, making any internal git data versionable is very confusing. So 
> you make the grafts file versionable - that suddenly means that different 
> branches may have different parents for the same commit. And that 
> depending on which branch you have checked out, git-fsck-cache may result 
> in an error, or it may not. That's _nasty_, in my opinion.
> 
> So I much prefer to say: everything under ".git" is not versionable, for 
> the fundamental reason that the files under .git are "global" to that git 
> repository. 
> 
> And I think .git/grafts in particular makes no sense to version.
> 
> If you want to track a git "grafts" file, you can do it as another git 
> repository and a symlink.

I fully concur with this (as I pointed out in my post, although perhaps 
fuzzily.)

	-hpa

Re: [RFC] Make grafts versionable

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Linus Torvalds wrote:

> In general, making any internal git data versionable is very confusing. So 
> you make the grafts file versionable - that suddenly means that different 
> branches may have different parents for the same commit. And that 
> depending on which branch you have checked out, git-fsck-cache may result 
> in an error, or it may not. That's _nasty_, in my opinion.

Yes, that is nasty. It does not reflect my normal usage pattern, but that 
does not make it better. So let's forget about that idea of mine.

Ciao,
Dscho