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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 5, 2011 at 12:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> In this case, each workdir needs its own key, so I'd have to record
>> the key somewhere, unless you meant using a key of "checkout:
>> </path/to/workdir>".
>
> That actually is how I read his message.
>
> I do not think "we cannot off the top of our heads think of the reason
> other than the branch is checked out that we might want to forbid its
> update" is a very good excuse to cast the word "checkout" in the UI; you
> would paint yourself in a difficult corner that you have to expend more
> energy to get out of by later adding backward compatibility support.

Git has survived w/o needing to lock branches till now. What are these
use cases we cannot already think of today?

> I think "switch_branches()" that updates HEAD to point at a local branch
> is one good place to lock the branch, but I do not know if it is a good
> idea to hook the check into the codepaths for deletion of the branch using
> "branch -[dD]" and check-out of the branch using "checkout $branch". I
> wonder if it makes sense to add the "checking" hook into much lower level
> in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
> catch attempts to update "your" current branch by other people.

I don't think so. There are lots of ways to shoot yourself in the foot
at the plumbing level. Besides, this is not about all refs, just local
branches.

Aside, there's nothing wrong with renaming a checked out branch.

> For that
> matter, instead of switch_branches(), would it make more sense to add this
> lock/unlock logic to symbolic_ref() that repoints HEAD to other branch?

I think you mean create_symref()? Looking at it's callers that seems
too low-level.

Maybe you could sketch out how you think this should work, I'm not seeing it.

- Where/how should the lock be recorded?
- Which function(s) should record/release the lock?

j.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]