Re: Why can't git-rebase back up?

[linux@horizon.com]

>> [[ This is because core git won't allow the checked-out HEAD to point
>> to anything but a branch,

> Yes it will. That's how "git reset" works (i.e. pointing HEAD to some 
> random object). Think of branches and tags as short and humanly 
> understandable names for certain points in the history. You can visit 
> any point in history without having a special short name for it.

Er... say again?  git reset doesn't touch the .git/HEAD symlink;
it overwrites the file that .git/HEAD points to.

If you know a way to make the core git tools produce a .git/HEAD that
is either not a symlink or does NOT begin with "refs/heads/", I'm quite
curious.

>> and checking out something without having
>> HEAD point to it is fragile and delicate.  Cogito lets you do this with
>> cg-seek. ]]

> It's more than delicate. It's impossible (even for Cogito). You can take 
> snapshots of how the tree looked at a certain state and export that 
> using git-tar-tree if you wish, but other than that it's impossible to 
> visit a certain point in history without pointing HEAD to it (that's how 
> visiting that point is done, actually).

Actually, you're right... Cogito uses refs/heads/cg-seek-point.
But you can do it by hand with git-read-tree and git-checkout-index.
(Very little in git is impossible; some things are just a Really Bad
Idea.)

> Now, if I want to migrate to a newer base version, I can always use
> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
> Preferable is to use git-rebase v2.6.16-rc3, which will preserve
> any local edits.
> 
> (I could also do it as a merge, but that seems like unnecessary history
> clutter.  It's not like local edits are common, anyway.)
> 
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2.  "git-rebase v2.6.16-rc2" does nothing.  After a bit
> of thought, I realize why, but sometime I do want to back up.
> 

> I'd suggest doing something like this when changing base version (of any 
> project, really).

[Use separate branch names for the two build versions.]

That's certainly a possibility, but kind of annoying to remember what
the "current" version is.  Typically, there are no local changes,
and I'm just using "build" as a conventional name to let me check
out the version.  Just like cg-seek-point.

> However, branches and tags are cheap to create, efficient to use, easy 
> to remove once you're done with them. They make life easier. Use them. 
> You'll be glad you did.

I don't really *want* a branch at all.  I just want to export the
right source tree and compile it.  Local changes are more likely a
mistake than anything else, but core git doesn't have Cogito's "blocked"
flag.  I'm just trying to avoid getting
into the habit of typing "git reset --hard" a lot because that's
dangerous.

It's sort of along the lines of "any workflow that makes you type
'rm -rf *' on a regular basis is a recipe for disaster".

The usual solution, of course, is to write a shell script wrapper with
some safety checking.  For example, I could see if git-name-rev --tags
can come up with a name for the branch head before unleashing git-reset
on it.

But I thought I'd check if the tool already existed.