[PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Adeodato Simó]

If logs/refs or rr-cache are dangling symlinks in the workdir, and reflogs
and/or rerere are enabled, commit will die with "fatal: Could not create
directory". (In the case of rr-cache, it will die after having created the
commit.)

This commit just creates logs/refs and rr-cache in the origin repository if
they don't exist already.

Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
 contrib/workdir/git-new-workdir |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index 993cacf..a4e89d0 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -66,6 +66,12 @@ mkdir -p "$new_workdir/.git" || die "unable to create \"$new_workdir\"!"
 for x in config refs logs/refs objects info hooks packed-refs remotes rr-cache svn
 do
 	case $x in
+	logs/refs|rr-cache)
+		if [ ! -e "$git_dir/$x" ]; then
+			mkdir -p "$git_dir/$x"
+		fi
+	esac
+	case $x in
 	*/*)
 		mkdir -p "$(dirname "$new_workdir/.git/$x")"
 		;;
-- 
1.6.1.263.g35eb3c

Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Junio C Hamano]

Adeodato Simó <dato@net.com.org.es> writes:

> If logs/refs or rr-cache are dangling symlinks in the workdir, and reflogs
> and/or rerere are enabled, commit will die with "fatal: Could not create
> directory". (In the case of rr-cache, it will die after having created the
> commit.)
>
> This commit just creates logs/refs and rr-cache in the origin repository if
> they don't exist already.

Hmm, is that better than not creating the symlink of the borrowed
repository does not have them?

Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Adeodato Simó]

* Junio C Hamano [Sat, 17 Jan 2009 17:31:57 -0800]:

> Adeodato Simó <dato@net.com.org.es> writes:

> > If logs/refs or rr-cache are dangling symlinks in the workdir, and reflogs
> > and/or rerere are enabled, commit will die with "fatal: Could not create
> > directory". (In the case of rr-cache, it will die after having created the
> > commit.)

> > This commit just creates logs/refs and rr-cache in the origin repository if
> > they don't exist already.

> Hmm, is that better than not creating the symlink of the borrowed
> repository does not have them?

I would say so. I'll agree this covers a less common case, because one
normally starts a regular repo, work on it, and at some point realize
you'd like another checkout, and create a workdir. By that point, logs/refs
surely should exist in the original repo.

However, I've as of late directly created bare repositories knowing that
I wanted to work just with workdirs against it. In this case, the logs
for each checkout'ed branch will be stored in the workdirs and not the
repo, so deleting the workdir will make you lose those logs. Which is
bad, since workdirs should always be safe to delete.

As I said, I realized this is a bit of a cornercase, but I think it
would be nice solving in the proposed way. (If you want, I can put a
shorter version of the above rationale in the commit message.)

Thanks,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
La música es de los que la quieren escuchar y de nadie más.
                -- Andrés Calamaro

Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Junio C Hamano]

Adeodato Simó <dato@net.com.org.es> writes:

> However, I've as of late directly created bare repositories knowing that
> I wanted to work just with workdirs against it. In this case, the logs
> for each checkout'ed branch will be stored in the workdirs and not the
> repo, so deleting the workdir will make you lose those logs. Which is
> bad, since workdirs should always be safe to delete.

I had to think about the above for a while, but after realizing that you
have a strict distinction between a "workdir" and a normal "repository
with a work tree" in mind, I can see where you are coming from.  A workdir
is transient in nature and you should be able to dismiss it safely as long
as the repository it borrows from is intact.

But "safely" is somewhat relative.

What state would you be discarding when you remove a workdir?  I can think
of:

 - local uncommitted changes, in the work tree contents and in the index
   (obviously);

 - reflog for the HEAD (aka branch switching);

 - what branch you had checked out when you discarded the workdir;

and everything else (commits created, the tips and histories of refs,
configuration changes) are kept in the .git repository of the original.

But what if the original does _not_ want to keep track of changes of
certain nature?  It is nonsensical for the original not to want to keep
the commits nor the tips of the refs, but it is not unreasonable for a
bare repository used as a distribution point not want to keep reflogs, for
example.  A workdir could be defined as "a transient work tree created on
an existing repository, the side effects of working in which are saved to
the original repository (except for the ones listed above).  The kind of
side effects saved are however limited to the ones that are saved while
working in the original repository."

With such a definition, you can "safely" create a workdir out of a bare
repository, without fear of contaminating it with unwanted reflogs.

I tend to think the definition your patch seems to use would be more
useful in practice, though.

    A workdir is a new work area that is not a normal "work tree with a
    full repository", but borrows from an existing repository.  Any side
    effect from the work you do in a workdir will be saved in the original
    repository, and removing one would lose only the three kind of
    information listed above.  Creating a new workdir has the side effect
    of enabling reflogs and rerere in the original repository.

But the last sentence somehow feels dirty.

Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Adeodato Simó]

* Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:

> Adeodato Simó <dato@net.com.org.es> writes:

> > However, I've as of late directly created bare repositories knowing that
> > I wanted to work just with workdirs against it. In this case, the logs
> > for each checkout'ed branch will be stored in the workdirs and not the
> > repo, so deleting the workdir will make you lose those logs. Which is
> > bad, since workdirs should always be safe to delete.

> I had to think about the above for a while, but after realizing that you
> have a strict distinction between a "workdir" and a normal "repository
> with a work tree" in mind, I can see where you are coming from.  A workdir
> is transient in nature and you should be able to dismiss it safely as long
> as the repository it borrows from is intact.

The thing, for me, is that a workdir should result in effects as close
as possible as doing the work in the repository with the workdir itself.
I normally use workdirs when it's not feasible to do the work in the
repo itself (eg., there's work in progress I'd rather have around,
rather than committing it to a temporary branch, to leave the repo
"clean" for further work).

>     A workdir is a new work area that is not a normal "work tree with a
>     full repository", but borrows from an existing repository.  Any side
>     effect from the work you do in a workdir will be saved in the original
>     repository, and removing one would lose only the three kind of
>     information listed above.  Creating a new workdir has the side effect
>     of enabling reflogs and rerere in the original repository.

> But the last sentence somehow feels dirty.

I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
*enable* reflogs and rerere at all? Or, rather, it just gives an empty
space for the workdirs "connecting" to it to save their reflogs and
rerere stuff iff they are configured to do so?

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
                -- Oscar Hammerstein II

Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository

[Junio C Hamano]

Adeodato Simó <dato@net.com.org.es> writes:

> * Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:
> ...
>>     A workdir is a new work area that is not a normal "work tree with a
>>     full repository", but borrows from an existing repository.  Any side
>>     effect from the work you do in a workdir will be saved in the original
>>     repository, and removing one would lose only the three kind of
>>     information listed above.  Creating a new workdir has the side effect
>>     of enabling reflogs and rerere in the original repository.
>
>> But the last sentence somehow feels dirty.
>
> I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
> *enable* reflogs and rerere at all? Or, rather, it just gives an empty
> space for the workdirs "connecting" to it to save their reflogs and
> rerere stuff iff they are configured to do so?

I thought rerere does not kick in if rr-cache is absent, and it kicks in
if rr-cache is present when you do not explicitly disable it.  So creation
of directory is a way to enable it.  Besides, the net effect for a person
who does not want to have the bare repository contaminated with these
directories is the same.  The original repository aquires them.

As I said already, I suspect that it would be more useful in practice to
create these directories as your patch did, than making the new workdir
inherit the lack of rerere and reflog support if the original repository
lacked them.  I just wanted to see some documentation that makes it clear
that the original repository _is_ modified by a creation of a new workdir.