Jeff King [off-list ref] writes:
And then the "push to current branch" problem is neatly solved: you have
no current branch.
So:
$ git checkout new/branch/to/test^0
$ make, configure, etc
Exactly.
I keep a handful pseudo worktrees around (created with git-new-workdir on
top of a single repository) for quick patch test and build purposes. I do
not push into them but pushing into a non-bare repository and checking out
the same branch twice in such a setup share exactly the same issue, and I
keep their HEADs all detached for exactly the same reason.
On Thu, Nov 13, 2008 at 1:14 AM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
And then the "push to current branch" problem is neatly solved: you have
no current branch.
So:
$ git checkout new/branch/to/test^0
$ make, configure, etc
Exactly.
I keep a handful pseudo worktrees around (created with git-new-workdir on
top of a single repository) for quick patch test and build purposes. I do
not push into them but pushing into a non-bare repository and checking out
the same branch twice in such a setup share exactly the same issue, and I
keep their HEADs all detached for exactly the same reason.
I guess the issue comes down to a UI complication. It would very easy
for me to tell somebody how to check out and test their branch in my
testbed if I'm not around, except for that little bit of arcane
syntax. Moreover, the consequences if they forget are really
frustrating and hard to figure out. It's also very easy with a GUI to
do the simple *rightclick branch, click "Checkout"*, but would be much
harder to do the detached HEAD checkout correctly.
If it didn't involve reconfiguring a lot of other people's
repositories, I might consider having them push to "refs/remotes/*".
In theory that's actually much closer to what I'm doing anyways. That
would force any checkouts to be bare, but it would require lots of
git-foo on the pushing side. Perhaps some way to "git push" which
asks the remote repository where it wants the stuff?
Alternatively, it might be possible to add ref attributes or a config
option to force detached HEAD checkouts.
Cheers,
Kyle Moffett
On Thu, Nov 13, 2008 at 08:58:50AM -0500, Kyle Moffett wrote:
I guess the issue comes down to a UI complication. It would very easy
for me to tell somebody how to check out and test their branch in my
testbed if I'm not around, except for that little bit of arcane
syntax. Moreover, the consequences if they forget are really
If the problem is merely the syntax, then perhaps that argues for "git
checkout -d" to force detaching.
frustrating and hard to figure out. It's also very easy with a GUI to
do the simple *rightclick branch, click "Checkout"*, but would be much
harder to do the detached HEAD checkout correctly.
And again, perhaps this argues for a "Detach" option in the GUI.
But I have to admit, this is a pretty infrequently-used use-case. I
detach all the time when looking at non-branches, but I can't think of
the last time I used "ref^0" to detach intentionally.
If it didn't involve reconfiguring a lot of other people's
repositories, I might consider having them push to "refs/remotes/*".
In theory that's actually much closer to what I'm doing anyways. That
would force any checkouts to be bare, but it would require lots of
git-foo on the pushing side. Perhaps some way to "git push" which
asks the remote repository where it wants the stuff?
Or git-receive could even just silently munge the incoming refs when
writing them out (i.e., it exposes "refs/test/*" as "refs/heads/*", and
when you ask to write "refs/heads/foo" it writes "refs/test/foo"
instead).
Though that sort of lying feels a little wrong to me, since the pushing
side will incorrectly update its tracking branches. It wouldn't so bad
if the "fetch" side respected the munging, too.
But again, this seems uncommon enough that it is not worth trying to
implement something too clever.
Alternatively, it might be possible to add ref attributes or a config
option to force detached HEAD checkouts.
I think that is a more sensible solution. Your workflow is not about
"sometimes I want to detach the HEAD" but rather "in this particular
repo, we should _always_ detach the HEAD." Which a config option
represents very nicely.
-Peff