[RFC] Change handling of RelNotes

[RFC] Change handling of RelNotes

[Stephen Cuppett]

I went to clone git onto a memory stick today.  The default fs on the
sticks doesn't support symlinks.  After looking a little bit, the only
symlink I can see in the source tree is RelNotes.  It appears when
going to a new release the file gets created in /Documentation and the
symlink updated.

I propose we eliminate this symlink.  There are multiple other things
we can do to eliminate it and make the repository more flexible across
filesystems:

 * Always have current release in /Documentation/RelNotes and keep the
prior versions named the way they are maintained now.  When starting a
new release, rename the file and create it again.
 * Keep the current in RelNotes and leave the archived ones in
/Documentation.  Doing same content move and clear operation when
starting a new release.
 * Keep two copies RelNotes and /Documentation/RelNotes-X.X.X that
essentially have same content and RelNotes has a lot of churn
 * others...?

With this one abnormality the git repo on a normal flash drive doesn't
work... at least in my case.

Re: [RFC] Change handling of RelNotes

[Petr Baudis]

On Fri, Aug 31, 2007 at 03:35:36AM CEST, Stephen Cuppett wrote:
> With this one abnormality the git repo on a normal flash drive doesn't
> work... at least in my case.

Wouldn't it be better to minimalize the restriction imposed to you by
git in case you are working on a filesystem that doesn't support
symlinks? Let's say that in that case Git will keep the symlink only in
the index... (And perhaps warn.)

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber

Re: [RFC] Change handling of RelNotes

[Junio C Hamano]

"Stephen Cuppett" <cuppett@gmail.com> writes:

> I went to clone git onto a memory stick today.  The default fs on the
> sticks doesn't support symlinks.  After looking a little bit, the only
> symlink I can see in the source tree is RelNotes.  It appears when
> going to a new release the file gets created in /Documentation and the
> symlink updated.

Well, I hope you do not compile nor checkout git onto a memory
stick but use it as just a sneakernet medium.

If that is the case why should it matter if the contents tracked
has symlinks?

Re: [RFC] Change handling of RelNotes

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> On Fri, Aug 31, 2007 at 03:35:36AM CEST, Stephen Cuppett wrote:
>> With this one abnormality the git repo on a normal flash drive doesn't
>> work... at least in my case.
>
> Wouldn't it be better to minimalize the restriction imposed to you by
> git in case you are working on a filesystem that doesn't support
> symlinks? Let's say that in that case Git will keep the symlink only in
> the index... (And perhaps warn.)

Didn't we already add support for Cygwin/MinGW in the form of
core.symlinks configuration item?

I just did this:

	$ git clone -l -s -n git.git victim-005
        $ cd victim-005
        $ git config core.symlinks false
        $ git checkout

Re: [RFC] Change handling of RelNotes

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

Junio C Hamano said the following on 31.08.2007 04:21:
> "Stephen Cuppett" <cuppett@gmail.com> writes:
>> I went to clone git onto a memory stick today.  The default fs on
>> the sticks doesn't support symlinks.  After looking a little bit,
>> the only symlink I can see in the source tree is RelNotes.  It
>> appears when going to a new release the file gets created in
>> /Documentation and the symlink updated.
> 
> Well, I hope you do not compile nor checkout git onto a memory 
> stick but use it as just a sneakernet medium.
> 
> If that is the case why should it matter if the contents tracked 
> has symlinks?

Well, you have the same thing on Windows, of course. Where the first 
time you try to clone git.git, it reports the RelNotes symlink.
So, at first you think, "Hmm, that just seems broken"; till you 
discover core.symlinks=false, and set that globally, and every thing 
works.

So, as a Windows user you always have that option set to false; but 
you have to discover it first. I can see it being a problem on Linux, 
mounting a memorystick, and then trying to clone git.git to it. Your 
inclination to discover core.symlinks=false is not as high, I guess. 
And since it's certainly nothing you'd want in your global config, it 
might take some time before you realize that the correct way of 
cloning it for a memorystick is in fact:
     git clone -n git://repo.or.cz/git.git

(and if you'd want it checked out too)
     cd git
     git config core.symlinks false
     git checkout


Maybe we should consider having Git detect the underlying FS's 
capabilities when cloning, and set core.symlinks to the correct value? 
(You'll have to manually adjust it if you just 'cp' it to another FS, 
that's as expected.)

^shrug^

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [RFC] Change handling of RelNotes

[Nanako Shiraishi]

Quoting "Stephen Cuppett" <cuppett@gmail.com>:

> I propose we eliminate this symlink.

Maybe it is just me, but you do not sound like you are proposing to do
anything yourself.  You are simply demanding Junio to change the way he
works.  Instead of being able to edit RelNotes at the toplevel, relying
on the symbolic link to let him edit the right file, you are forcing him
to edit the appropriate file in Documentation/ directory.

Shouldn't you have at least said "I request" instead?

I sometimes have a checkout on a filesystem that does not support
symbolic links, but I set core.symlink configuration variable to false
in such a case.  Would it make sense to update "git init" to autodetect
lack of symbolic link support in the filesystem?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5

Re: [RFC] Change handling of RelNotes

[Junio C Hamano]

Nanako Shiraishi <nanako3@bluebottle.com> writes:

> I sometimes have a checkout on a filesystem that does not support
> symbolic links, but I set core.symlink configuration variable to false
> in such a case.  Would it make sense to update "git init" to autodetect
> lack of symbolic link support in the filesystem?

Hmph.  Something along this line, perhaps?

 builtin-init-db.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index af15cb2..c411008 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -264,6 +264,22 @@ static int create_default_files(const char *git_dir, const char *template_path)
 		if (work_tree != git_work_tree_cfg)
 			git_config_set("core.worktree", work_tree);
 	}
+
+	/* Check if symlink is supported in the work tree */
+	if (!reinit) {
+		path[len] = 0;
+		strcpy(path + len, "tXXXXXX");
+		
+		if (!close(xmkstemp(path)) &&
+		    !unlink(path) &&
+		    !symlink("testing", path) &&
+		    !lstat(path, &st1) &&
+		    S_ISLNK(st1.st_mode))
+			; /* good */
+		else
+			git_config_set("core.symlinks", "false");
+	}
+
 	return reinit;
 }
 

[PATCH] autodetect core.symlinks in git-init

[Junio C Hamano]

We already autodetect if filemode is reliable on the filesystem
to deal with VFAT and friends.  Do the same for symbolic link
support.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * The earlier one left the test symlink behind after testing is
   complete.  Embarrassing...

 builtin-init-db.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index af15cb2..763fa55 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -264,6 +264,21 @@ static int create_default_files(const char *git_dir, const char *template_path)
 		if (work_tree != git_work_tree_cfg)
 			git_config_set("core.worktree", work_tree);
 	}
+
+	/* Check if symlink is supported in the work tree */
+	if (!reinit) {
+		path[len] = 0;
+		strcpy(path + len, "tXXXXXX");
+		if (!close(xmkstemp(path)) &&
+		    !unlink(path) &&
+		    !symlink("testing", path) &&
+		    !lstat(path, &st1) &&
+		    S_ISLNK(st1.st_mode))
+			unlink(path); /* good */
+		else
+			git_config_set("core.symlinks", "false");
+	}
+
 	return reinit;
 }
 

Re: [PATCH] autodetect core.symlinks in git-init

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>:

> We already autodetect if filemode is reliable on the filesystem
> to deal with VFAT and friends.  Do the same for symbolic link
> support.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  * The earlier one left the test symlink behind after testing is
>    complete.  Embarrassing...
>
>  builtin-init-db.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)

Thank you for a quick patch.  I was about to report that leftover test
file as a bug.  Do you ever sleep?  I am always amazed how quickly any
potential issue raised on the mailing list is resolved.

With this patch my "git init" in a pendrive correctly says "[core]
symlinks = false".

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

Re: [PATCH] autodetect core.symlinks in git-init

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Junio C Hamano said the following on 31.08.2007 09:22:
> We already autodetect if filemode is reliable on the filesystem
> to deal with VFAT and friends.  Do the same for symbolic link
> support.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> +		if (!close(xmkstemp(path)) &&

Just tried this with 4msysgit (so, MinGW on Windows), and with a patch 
for adding xmkstemp() to git-compat-util.h, this patch works perfectly 
on Windows. It's obviously the right thing to do.

Acked-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [RFC] Change handling of RelNotes

[Stephen Cuppett]

Sorry, I didn't mean to imply a demand on anybody, or mandate anybody
change their workflow if really awkward or inconvenient.  Just new to
git and was trying some things and noticed this oddity.  In software
test, so I typically file reports for usability nits as well as big
things, and never expect to fix them myself.  Used to my
"recommendations" getting rejected too.  ;)

Just trying to lower a barrier to entry in a weird case....

I tested out the patch on Linux with a regular filesystem and with a
memory stick.  It picked it up and did the right thing with RelNotes
in both cases, leaving the symlink alone on ext3 and changing it to a
regular file on the memory stick.

I tried compiling it on Windows (cygwin), but ended up with:

/home/stcupp/git/builtin-init-db.c:305: undefined reference to `_xmkstemp'

I tried including git-compat-util.h and some other things to resolve
it, but was unable with my limited knowledge of their toolchain.

Re: [RFC] Change handling of RelNotes

[Junio C Hamano]

"Stephen Cuppett" <cuppett@gmail.com> writes:

> Sorry, I didn't mean to imply a demand on anybody, or mandate anybody
> change their workflow...

I have to admit that your "I propose" phrase did raise my
eyebrow, but it's not a big deal.  I've grown thicker skins ;-)

As a general principle, I agree it is a good idea to keep
git.git easily accessible by people on different platforms and
environments.  After all, you would need to get git.git in order
to obtain newer repository features, so there is a chicken and
egg problem involved that is more severe than other projects.

That is exactly the reason why I do not use subprojects to bind
gitk and git-gui into git.git.  It needs to wait until everybody
has 1.5.2 or newer --- otherwise peole cannot clone or fetch
from git.git to get the feature that allows such a fetch to
begin with.

It would have been a different issue if the build procedure
depended on having a tracked symlink foo.h pointing at cache.h
and some source file included foo.h.  You cannot build such a
thing on a filesystem without symbolic links.  But the RelNotes
symlink is there for people to easily find the notes for the
latest to be released, and that symlink appears as a text file
that records the name of the Documentation file in a checkout
with "core.symlinks = false"; I do not think it is such a big
show stopper, even for people on a filesystem without symbolic
links.