Re: [RFC/PATCH] Add multiple workdir support to branch/checkout

From: Jay Soffian <jaysoffian@gmail.com>
Date: Oct 6, 2011, 00:57 UTC
Message-ID: <CAG+J_DxXcvF3tBPkf7ZEtiXvEK80zYJvP1rNx-PagM8TV-1KSA@mail.gmail.com>
In-Reply-To: <7vsjn73q6j.fsf@alter.siamese.dyndns.org>

On Wed, Oct 5, 2011 at 8:43 PM, Junio C Hamano <gitster@pobox.com> wrote:

> Not at all. My build infrastructure determines where to install the built
> binary based on what branch is checked out. Having a head detached at a
> commit that is at the tip of one branch is not necessarily the same as
> having the branch actually checked out.

That's fair, but I'm willing to wager that's a minority use-case. Not that it shouldn't be possible, but perhaps it should require telling git that's really what you want to do with checkout --force.

Show 8 quoted lines

>> Also, if we wait till commit time to tell the user "sorry, topic's
>> been updated elsewhere", now the user is in a perilous state.
>
> Wouldn't the "elsewhere" user would be warned before being able to update
> the branch? I thought the whole point of your adding "this branch is
> checked out over there" is exactly so that the "elsewhere" user can come
> talk to you before that happens. These two people might be yourself, of
> course.

So you're envisioning this?

  $ git commit foo.c
  Warning, master is also checked out in workdir2

How does that help the user? Now they have to go to workdir2 and reset --hard. Is that really something we want to encourage?

And what if they do this:

  $ cd workdir1
  $ edit foo.c
  ... time passes...
  $ cd workdir2
  $ edit foo.c
  $ git commit foo.c
  Warning, master is also checked out in workdir1

j.