From: Pierre Habouzit <madcoder@madism.org>
To: Git ML <git@vger.kernel.org>
Subject: fixing workdirs
Date: Thu, 8 Jul 2010 13:08:42 +0200 [thread overview]
Message-ID: <20100708110842.GC12789@madism.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
At work we (ab-)use workdirs a lot, though, workdirs aren't for
everybody, and as our company grows, not everybody uses them sanely.
The two problems (that are well known to this list, and is the reason
why git new-workdir is in contrib afaict) with workdirs are:
- the HEAD reflogs aren't shared, which means that pruning a working
directory may trash accessible stuff from the reflog of another one.
- if two workdirs are on the same branch at the same time, really,
really, *REALLY* bad things may happen if one isn't aware of that
fact.
I'm intending to adress those issues, though I would like to know how it
would be received. My current plan is this one. Have a git workdir
command, with a few subcommands (create, move, rename, ...), that
addresses both of the previous issues.
for the first one, the fix is simple: workdirs have now a name, and
their HEAD reflog lives in the "master" git repository reflog namespace
under logs/workdir/$workdir_name/HEAD. The workdir HEAD reflog is then a
symlink to the masters.
In this way, all workdirs see all the reflogs of every single workdir,
and pruning is safe again.
For the second one, when a workdir is created, a [workdir "foo"] section
is added to the master directory, with a path configuration variable
pointing to the ... path of the working directory. My plan would be to
teach git checkout to lean about that, and when there are workdirs
set up, git checkout would check that no other workdir is currently "on
the same branch", and would refuse to checkout to a branch that is
already checkouted elsewhere.
The current state of my git-workdir.sh is attached, though before I
start diving into the checkout builtin, I wanted to be sure that's the
way to go, and if there isn't any other issue I could have missed, plus
if this work has any chance to enter git.git :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: git-workdir.sh --]
[-- Type: application/x-sh, Size: 3640 bytes --]
next reply other threads:[~2010-07-08 11:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-08 11:08 Pierre Habouzit [this message]
2010-07-08 18:37 ` fixing workdirs Tait
2010-07-08 18:56 ` Joshua Jensen
2010-07-09 7:49 ` Pierre Habouzit
2010-07-08 19:40 ` Junio C Hamano
2010-07-08 19:56 ` Avery Pennarun
2010-07-09 7:56 ` Pierre Habouzit
2010-07-09 22:25 ` Junio C Hamano
2010-07-19 9:02 ` Pierre Habouzit
2010-08-17 18:34 ` Jan Hudec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100708110842.GC12789@madism.org \
--to=madcoder@madism.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).