patchcontrib/workdir: create logs/refs and rr-cache in the origin repository

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

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

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

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

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@net.com.org.es> writes:

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.

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

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

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@net.com.org.es> writes:

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.