On Thu, Jul 08, 2010 at 12:40:11PM -0700, Junio C Hamano wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > > > 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. > > I think this is a sane thing to do, except for the "symlink" part but that > would be just a minor implementation detail. What would you suggest instead of the symlink then ? (knowing that all the workdir is just a full symlink farm at them moment). > > 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. > > Ok. > > ... 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. > > I am personally fine with this, but if there is no way to override this > refusal it may break some people's existing workflow. I dunno. Well it's probably fine to have a switch to override it of course, or like it was suggested to prevent updating the reference instead. But that sounds harder, and if you want to override it, it means that a lot of commands will have to take a new argument (update-ref, commit, reset, rebase, ...). I'm more in favor of having checkout refusing to checkout if the reference is already checkout-ed elsewhere, with a --ignore-workdirs or similar switch to override this. git-checkout would still print out a warning about the fact that /maybe/ the user is doing something crazy, and then he'll be on his own. Plus it doesn't slow references updates for the workdir case, only the branch switch which is way nicer. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org -- 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