Missing features in git

Missing features in git

[linux]

I've been writing some more git docs, and I came across a few
things git does that I'm not sure are desirable.


One thing I noticed is that with ref logs, you've just re-invented the
CVS problem of associating history with a name.  If you want to rename
a branch (say, from "mischacks" to something suitable for publication),
do you rename the log or not?  It's a less virulent form, but it seems
like the same disease.

Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f
overrides -m), but doesn't complain.


One feature that I noticed is missing, is that there's no easy way to do a
"git reset --hard" while doing a "git checkout" style merge.

An example of when you'd want to do this is performing a "git bisect"
with a local "#define DEBUG 1" change.  Particularly if you
hit a non-compiling version and need to back up.

  
The only way to do this currently is somethig like:
        git checkout -b temp HEAD^
        git branch -f bisect temp
        git checkout bisect
        git branch -d temp

or the way git-bisect does it
  
        echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
        git checkout new-bisect || exit
        mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
        GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
  
Either way, it reserves a second branch name, and seems like a bit of
a hack.  I'm already a bit annoyed that "bisect" is reserved but not
clearly documented as such, and note that the branch name "new-bisect",
which we are switched to temporarily, does not match the pattern
"refs/heads/bisect*" that bisect_start checks for.

The only thing I don't know is if this should be a git-checkout
option or a git-reset option.  The former shares far more code,
but the latter might make more logical sense.

  
Personally, I'd prefer if the requirement that HEAD point to
refs/heads were enforced when checking in rather than checking out.
  
Then you could check out an arbitrary version without any of the annoyance
above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
I wouldn't be on a current branch (which would necessitate changing
"git branch" output), so HEAD would simply contain an object ID directly
rather than being a symlink/symref.

It's a bit of a PITA auditing the code base to find everywhere affected
by changing this invariant, but it doesn't conceptually difficult.
Is there anything fundamental that this would break?


The above would make a "-b <newbranch>" option to git-commit more useful,
but it's not a half-bad idea as it is.  It's just one extra command
(git checkout -b newbranch; git commit), but it takes a bit of
thinking to realize that "git checkout", which normally modifies the
working directory, won't touch your ready-to-be-committed changes in

Re: Missing features in git

[Jakub Narebski]

linux@horizon.com wrote:

> One thing I noticed is that with ref logs, you've just re-invented the
> CVS problem of associating history with a name.  If you want to rename
> a branch (say, from "mischacks" to something suitable for publication),
> do you rename the log or not?  It's a less virulent form, but it seems
> like the same disease.

Well, it would be nice to have command to rename branches (with its reflog)
and to rename tags (even in their packed format).

[...] 
> Then you could check out an arbitrary version without any of the annoyance
> above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
> I wouldn't be on a current branch (which would necessitate changing
> "git branch" output), so HEAD would simply contain an object ID directly
> rather than being a symlink/symref.

And what would happen if you want to checkout other branch? Where the ID
in the HEAD would go to? HEAD just _has_ to be reference to _branch_.
 
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Missing features in git

[Karl Hasselström]

On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:

> linux@horizon.com wrote:
>
> > Then you could check out an arbitrary version without any of the
> > annoyance above; I could "git checkout tags/foo" or even "git
> > checkout deadbeef~3". I wouldn't be on a current branch (which
> > would necessitate changing "git branch" output), so HEAD would
> > simply contain an object ID directly rather than being a
> > symlink/symref.
>
> And what would happen if you want to checkout other branch? Where
> the ID in the HEAD would go to? HEAD just _has_ to be reference to
> _branch_.

The id that used to be HEAD would not be saved anywhere. It would
still be reachable from your refs, presumably, just like before you
checked it out. (It would not be the case that you had made commits on
an unnamed branch that would now get lost, because the tool would
refuse to commit until you had created a name for the branch.)

-- 
Karl Hasselström, kha@treskal.com

Re: Missing features in git

[Jakub Narebski]

Karl Hasselström wrote:
> On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
> 
>> linux@horizon.com wrote:
>>
>>> Then you could check out an arbitrary version without any of the
>>> annoyance above; I could "git checkout tags/foo" or even "git
>>> checkout deadbeef~3". I wouldn't be on a current branch (which
>>> would necessitate changing "git branch" output), so HEAD would
>>> simply contain an object ID directly rather than being a
>>> symlink/symref.
>>
>> And what would happen if you want to checkout other branch? Where
>> the ID in the HEAD would go to? HEAD just _has_ to be reference to
>> _branch_.
> 
> The id that used to be HEAD would not be saved anywhere. It would
> still be reachable from your refs, presumably, just like before you
> checked it out. (It would not be the case that you had made commits on
> an unnamed branch that would now get lost, because the tool would
> refuse to commit until you had created a name for the branch.)

If HEAD would contain an commit ID directly, then you shouldn't be able
to commit at all. Not very useful, it is.
-- 
Jakub Narebski

Re: Missing features in git

[Karl Hasselström]

On 2006-11-14 18:15:23 +0100, Jakub Narebski wrote:

> Karl Hasselström wrote:

> > On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
>
> > > And what would happen if you want to checkout other branch?
> > > Where the ID in the HEAD would go to? HEAD just _has_ to be
> > > reference to _branch_.
> >
> > The id that used to be HEAD would not be saved anywhere. It would
> > still be reachable from your refs, presumably, just like before
> > you checked it out. (It would not be the case that you had made
> > commits on an unnamed branch that would now get lost, because the
> > tool would refuse to commit until you had created a name for the
> > branch.)
>
> If HEAD would contain an commit ID directly, then you shouldn't be
> able to commit at all.

I agree. You aren't on a branch, so you can't commit. (Of course,
creating a branch for the commit you're on is trivial: "git checkout
-b <branchname>".)

> Not very useful, it is.

Well, as long as you only want to visit the past, not change it, it
can be useful. For example, we could skip the "bisect" branch, since
you aren't supposed to commit to that anyway.

-- 
Karl Hasselström, kha@treskal.com

Re: Missing features in git

[Jakub Narebski]

Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisał:
>
> For example, we could skip the "bisect" branch, since
> you aren't supposed to commit to that anyway.

Well, to have "branch" to which you could not commit, just put ref
outside refs/heads. 

Another solution would be to be able to put non-head ref in HEAD,
but allow to commit only if the prefix is refs/heads/
-- 
Jakub Narebski

Re: Missing features in git

[Shawn Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> >
> > For example, we could skip the "bisect" branch, since
> > you aren't supposed to commit to that anyway.
> 
> Well, to have "branch" to which you could not commit, just put ref
> outside refs/heads. 
> 
> Another solution would be to be able to put non-head ref in HEAD,
> but allow to commit only if the prefix is refs/heads/

That's not a bad idea.  Then you can checkout a tag and have
'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
$(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
as their current branch, reminding them they are looking at the past.

Doing bisect branch in refs/bisect rather than refs/heads/bisect
would then likewise remind the user that they are bisecting, and
since neither matches refs/heads/* you cannot commit.

-- 

Re: Missing features in git

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1410 bytes --]



On Tue, 14 Nov 2006, Shawn Pearce wrote:

> Jakub Narebski <jnareb@gmail.com> wrote:
> > Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> > >
> > > For example, we could skip the "bisect" branch, since
> > > you aren't supposed to commit to that anyway.
> > 
> > Well, to have "branch" to which you could not commit, just put ref
> > outside refs/heads. 
> > 
> > Another solution would be to be able to put non-head ref in HEAD,
> > but allow to commit only if the prefix is refs/heads/
> 
> That's not a bad idea.  Then you can checkout a tag and have
> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
> as their current branch, reminding them they are looking at the past.

I agree. This would probably be a good way to do "read-only branches".

Allowing people to do a "git checkout" on anything committish, but then 
not allowing them to commit to that, is probably the right thing to do.

Together with a nice readable error message from "git commit" (and merge, 
and pull - although you might well allow "fetch" to update the thing that 
current HEAD points to, though), this would be a lot easier to use for 
people who just follow somebody elses branch.

Junio, what do you think? It wouldn't even be backwards incompatible, 
because we're strictly allowing a superset of what we used to..

			Linus

Re: Missing features in git

[Petr Baudis]

On Tue, Nov 14, 2006 at 07:40:30PM CET, Linus Torvalds wrote:
> On Tue, 14 Nov 2006, Shawn Pearce wrote:
> 
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > > Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> > > >
> > > > For example, we could skip the "bisect" branch, since
> > > > you aren't supposed to commit to that anyway.
> > > 
> > > Well, to have "branch" to which you could not commit, just put ref
> > > outside refs/heads. 
> > > 
> > > Another solution would be to be able to put non-head ref in HEAD,
> > > but allow to commit only if the prefix is refs/heads/
> > 
> > That's not a bad idea.  Then you can checkout a tag and have
> > 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
> > $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
> > as their current branch, reminding them they are looking at the past.

  There's been a brief discussion on a related topic in

	http://news.gmane.org/find-root.php?message_id=%3cPine.LNX.4.58.0507120938240.17536%40g5.osdl.org%3e

(apparently the Linus-has-another-totally-awesome-idea kind (no irony
(*))).  Before, Cogito did basically what's proposed above to permit
again: storing a random sha1 in the HEAD when it is seeked away to some
historical commit. It switched to using a temporary branch for this
purpose, but I'm not sure about the Linus' reasoning that

	"in order for a "git checkout" to not get confused and possibly
	throwing a cogito temporary head away ..."

which has been apparently clear to me back then. :-(

> I agree. This would probably be a good way to do "read-only branches".
> 
> Allowing people to do a "git checkout" on anything committish, but then 
> not allowing them to commit to that, is probably the right thing to do.

  So, the basic relaxation is that "again after a year, HEAD does not
have to be a ref at all".

> Together with a nice readable error message from "git commit" (and merge, 
> and pull - although you might well allow "fetch" to update the thing that 
> current HEAD points to, though), this would be a lot easier to use for 
> people who just follow somebody elses branch.

  Hmm, so that there would be something like refs/tracking/master as an
alternative to refs/heads/master? I'm not really sure if it is a good
idea. On one hand, you can relax my favorite fastforward restrictions on
those tracking branches, but I think the net worth is negative since you
will have to burden new users with yet another concept of "readonly
branches", tell them things like "either do git clone --no-tracking or
the first time you will want to commit something locally, create a
'head' using git checkout -b master HEAD" (you are already on a "master"
branch but it's a different "master", you know?) etc.


  (*) You never are ironical about Linus, the Chuck Norris of CS. (And a
hero, too!)

-- 
				Petr "Pasky the Wow Pruit Igoe is
					Awesome Too!" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

Re: Missing features in git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Tue, 14 Nov 2006, Shawn Pearce wrote:
>> That's not a bad idea.  Then you can checkout a tag and have
>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
>> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
>> as their current branch, reminding them they are looking at the past.
>
> I agree. This would probably be a good way to do "read-only branches".
> ...
> Junio, what do you think? It wouldn't even be backwards incompatible, 
> because we're strictly allowing a superset of what we used to..

(late reply -- just came back from a clinic)

I do not see any fundamental reason not to allow HEAD to be a
commit that you cannot commit on top of because you are not on
any branch, and I agree it is the right way to go.

I am not sure how much pain we are talking about yet though.

Re: Missing features in git

[Karl Hasselström]

On 2006-11-14 08:49:58 -0500, linux@horizon.com wrote:

> One feature that I noticed is missing, is that there's no easy way
> to do a "git reset --hard" while doing a "git checkout" style merge.
>
> An example of when you'd want to do this is performing a "git
> bisect" with a local "#define DEBUG 1" change. Particularly if you
> hit a non-compiling version and need to back up.

Yes, this feature would be good to have. StGIT makes it a little less
painful to hack around this limitation, but you still have to remember
popping your patches before running "git bisect good|bad".

Then again, in StGIT's case this could be solved by creating an "stg
bisect" command that takes care of this for you. But I still agree
with you that it would be a win if regular git could do as you
describe.

-- 
Karl Hasselström, kha@treskal.com

Re: Missing features in git

[Edgar Toernig]

linux@horizon.com wrote:
>
> Personally, I'd prefer if the requirement that HEAD point to
> refs/heads were enforced when checking in rather than checking out.
>   
> Then you could check out an arbitrary version without any of the annoyance
> above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
> I wouldn't be on a current branch (which would necessitate changing
> "git branch" output), so HEAD would simply contain an object ID directly
> rather than being a symlink/symref.

I wholeheartedly agree.  For the casual user it's IMHO the most
annoying behaviour of git that you can't simply checkout an arbitrary
commit without creating a new (most of the time temporary) branch first.
Often you don't plan to change the checked out tree and giving it a
new branch name ahead is cumbersome, especially as you know that you'll
never commit into it and have to delete the branch before checking out
another tag.  I would prefer this behaviour:

	$ git checkout v2.6.16
	... i.e. check whether it builds
	$ git checkout v2.6.17
	... test this one
	$ git checkout v2.6.18
	... change something
	$ git commit
	error: can't commit.  not on any branch.
	use "git commit -b <new-branch-name>" to commit into a new one.
	$ git commit -b my-v2.6.18

Re: Missing features in git

[linux]

>>> Another solution would be to be able to put non-head ref in HEAD,
>>> but allow to commit only if the prefix is refs/heads/
>> 
>> That's not a bad idea.  Then you can checkout a tag and have
>> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
>> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
>> as their current branch, reminding them they are looking at the past.

> I agree. This would probably be a good way to do "read-only branches".
> 
> Allowing people to do a "git checkout" on anything committish, but then 
> not allowing them to commit to that, is probably the right thing to do.
> 
> Together with a nice readable error message from "git commit" (and merge, 
> and pull - although you might well allow "fetch" to update the thing that 
> current HEAD points to, though), this would be a lot easier to use for 
> people who just follow somebody elses branch.

This certainly seems like a popular idea.  I think the vote is to symlink
(symref) to a non-refs/heads/ object if possible, but allow an arbitrary
object ID as well.  In either case, commits would be forbidden.

The only reason I had avoided symlinking before was in case the tag was
deleted, but that can be fixed easily enough.  (Either make git-tag -d/-f
fail, or have it replace the HEAD symref with a raw hex object.
Actually, you could do the same with git branch -d.  Any opinions?)

I can try to write the patch if there are no better volunteers, although
it'll take me a lot longer that someone more comfortable with the code.

Um.. for example, I'm not sure what the git fetch problem could
possibly be.  It only updates heads, no?  Or are you thinking
of the new refs/remotes thing that I'm not familiar with?

I'll have to examine the callers of git-symbolic-ref to see what
it should do.  Return the hex object ID and fail are the obvious
possibilities.


Note that NOT having any sort of bisect label (and just using HEAD
itself as a raw pointer) solves the "git reset --hard" problem; I can
"git checkout HEAD^" and have debug hacks preserved.

It also removes a paragraph of excuses from some "using git" docs
I'm writing.  It's a lot easier to explain why you can't commit
if you're not on a branch than to explain why you can't not be
on a branch.

Oh, and as I mentioned, not that "git checkout -b <newbranch>" is
exactly painful, but I think a "-b <newbranch>" option to git-commit
would be a convenience.  (An interesting question is whether it should
create the new branch even if there is nothing to.  I'm thinking "yes"

Re: Missing features in git

[Karl Hasselström]

On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:

> It also removes a paragraph of excuses from some "using git" docs
> I'm writing. It's a lot easier to explain why you can't commit if
> you're not on a branch than to explain why you can't not be on a
> branch.

This is precisely why writing documentation is such a good idea: It is
in many cases easier to fix the warts than finding a pedagogical way
to explain them. :-)

(Well, then there's the secondary benefit that users can learn from
the docs ...)

-- 
Karl Hasselström, kha@treskal.com

Re: Missing features in git

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1021 bytes --]



On Wed, 15 Nov 2006, Karl Hasselström wrote:

> On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:
> 
> > It also removes a paragraph of excuses from some "using git" docs
> > I'm writing. It's a lot easier to explain why you can't commit if
> > you're not on a branch than to explain why you can't not be on a
> > branch.
> 
> This is precisely why writing documentation is such a good idea: It is
> in many cases easier to fix the warts than finding a pedagogical way
> to explain them. :-)

Heh. Pretty much all of the early git plumbing came about when I started 
to try to demonstrate git to others, and wrote some of the early 
tutorials. So yeah, trying to explain something to others (whether by 
documentation or through examples) is a good way to show what has bad 
interfaces.

Even if it's easy to use for yourself (I had my own scripts to do 
everything _I_ wanted to do), trying to explain why something is done some 
way to somebody who doesn't know the internals is always a good exercise.

		Linus

Re: Missing features in git

[Junio C Hamano]

linux@horizon.com writes:

> One thing I noticed is that with ref logs, you've just re-invented the
> CVS problem of associating history with a name.  If you want to rename
> a branch (say, from "mischacks" to something suitable for publication),
> do you rename the log or not?  It's a less virulent form, but it seems
> like the same disease.

I do not think we currently rename the log but it is probably a
bug.  Renaming tag should also be made easier.

> Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f
> overrides -m), but doesn't complain.

It should be made to complain.

> An example of when you'd want to do this is performing a "git bisect"
> with a local "#define DEBUG 1" change.  Particularly if you
> hit a non-compiling version and need to back up.
> or the way git-bisect does it
>   
>         echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
>         git checkout new-bisect || exit
>         mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
>         GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect

The name new-bisect is really temporary the code just shows it
punts on a situation it does not expect (it essentially expects
a clean tree and working with a local change is by accident) and
being ony half helpful to the user while recovering from that
unexpected situation.  In other words, that's a room for
improvement.  We should be rewrite the above with something like
what we have in the else clause in git-checkout around line 150.
It might make sense to make it a shell function and sharable
between checkout and bisect (perhaps there are other uses).
Then we do not need the temporary branch.

> Either way, it reserves a second branch name, and seems like a bit of
> a hack.

You are correct to call it a hack.  git-bisect started as a
technology demonstration of the underlying rev-list --bisect
feature.  The thing is that the technology was so nice and
useful that we started using it before cleaning up these
implementation details.  I think instead of documenting the duct
tape that holds git-bisect together ("rev-list --bisect" is
great, and what "git-bisect" does is basically great but with
minor glitches like you noticed and with hacky implementation
details; I am calling the latter "duct tape"), we should redo
the hackish part.

Enough with bisect.  And jumping the head while forward/back
porting the local change would also involve the same kind of
change, so "git reset --merge-local-change" might be a good
addition, but I am not sure about the details yet.