[RFC] Change handling of RelNotes

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.

On Fri, Aug 31, 2007 at 03:35:36AM CEST, Stephen Cuppett wrote:

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 Baudis <pasky@suse.cz> writes:

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

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

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?

Junio C Hamano said the following on 31.08.2007 04:21:

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^

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

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 <nanako3@bluebottle.com> writes:

Hmph.  Something along this line, perhaps?

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

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(-)

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

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".

Junio C Hamano said the following on 31.08.2007 09:22:

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>

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.

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

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.