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

[Jay Soffian <jaysoffian@gmail.com>]

On Wed, Oct 5, 2011 at 9:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> Now they do what? Either commit --force or create a new branch?
>> Wouldn't it have been better to create the new branch before they
>> started editing?
>
> If they are going to commit, and if they knew that they are going to
> commit, yes.

Committing is obviously the common case for a checked-out branch.

> But why do you want to forbid people from just checking things out if they
> are not interested in committing? That is where I think you are going
> backwards.

Because if they do decide to commit, it's now harder for them to do so.

It would be great if git could intervene after the checkout, but
before they edit any files, so that they don't have uncommitted work.
Obviously that's not possible, so git should prevent them from getting
to that point.

Let's consider the various situations:

1. master is checked out w/edits in workdir1, user wants to work on
topic in workdir2.

There's nothing to warn about in workdir2 neither at checkout nor commit time.

2. master is checked out w/edits in workdir1, user wants examine
unedited master in workdir2

At checkout time in workdir2:

My preference: checkout advices user to use --detach or --force.
Your preference: checkout is silent.

Now user decides they want to commit to master in workdir2 (which is
insane, they've got uncommitted changes to it in workdir1). What
happens?

In my scenario, the commit happens on a detached HEAD. When they
eventually switch back to a branch, git tells them how to move their
commit to a branch.

In your scenario, commit complains. User now has to --force, stash, or
create a new branch.

It's just seems insane to me putting in obstacles to the user
committing their work. That's where I think you are going backwards.

You have a use case where using a detached HEAD doesn't work because
you've scripted around the same branch multiply checked out. I think
that's probably an exceedingly rare use case, and justifies "checkout
--force".

>> I guess it depends what you mostly use your workdirs for. For me, it's
>> to have different branches checked out, not to have the same branch
>> checked out in multiple locations.
>
> Then you wouldn't have any problem if commit refused to make commit on the
> branch that is checked out elsewhere, no?

Yes, I would, because by that point, I've already made the mistake of
checking out the same branch twice. I want git to prevent me from
doing that by accident. Because I don't want to ever be in the
situation which comes next, which is that I've got uncommitted work
for the same branch in two places!

> I am not saying we should never have an option to _warn_ checking out the
> same branch in multiple places. I am saying it is wrong to forbid doing so
> by default.

I am not saying we should never have an option to allow checking out
the same branch in multiple places. I am saying it is wrong to allow
doing so by default.

j.