Chris Webb [off-list ref] writes:
The first is whether there's a clever symbolic way to refer to the root of
the current branch, rather than tailing git log output? gitrevisions(7)
doesn't obviously suggest one.
There is not, for a few good reasons.
The very first commit is no more special than any other commit in
the history. Some projects may start with "the first working
version", in which case there may be some value to be able to refer
to it, while some other projects may start with "the initial
snapshot" whose specialness comes _only_ from it being the first
one.
"The first working version" specialness may deserve to be tagged,
and in that case you would already have a name to refer to it. If
on the other hand the first one isn't even worth to be tagged, it
does not deserve to waste a short-hand to refer to it at the
machinery level. So there is nothing listed in the gitrevisions(7)
for it.
Also there is a more important question: Which root commit? There
does not necessarily have to be a single "the root" commit in the
history.
git checkout --orphan rewritten
git rm -rf
git rebase --interactive --root --onto rewritten master
The argument to "--onto" must be a commit, but "checkout --orphan"
is not a way to create a commit; it is a way to bring you to a state
without any commit.
I personally think "git rebase -i --root" should be made to just
work without requiring "--onto" and let you "edit" even the first
one in the history. It is understandable that nobody bothered, as
people are a lot less often rewriting near the very beginning of the
history than otherwise.
Even though I wouldn't bother doing this myself, I wouldn't mind
reviewing a patch series ;-)
Junio C Hamano [off-list ref] writes:
[symbolic reference to root commit]
Also there is a more important question: Which root commit? There
does not necessarily have to be a single "the root" commit in the
history.
Ah yes, very good point. Anything with a subtree merge would have several
roots, for example.
I suppose the thing that makes root commits special is their lack of
parents, so the most direct way to get a list of root commits for the
current branch would just be
git rev-list --max-parents=0 HEAD
making the recipe
ROOT=$(git rev-list --max-parents=0 master)
git checkout "$ROOT" -- # will fail if more than one root
git commit --amend
git rebase [--interactive] --onto HEAD "$ROOT" master
I personally think "git rebase -i --root" should be made to just
work without requiring "--onto" and let you "edit" even the first
one in the history. It is understandable that nobody bothered, as
people are a lot less often rewriting near the very beginning of the
history than otherwise.
Even though I wouldn't bother doing this myself, I wouldn't mind
reviewing a patch series ;-)
Okay, I'll take a look when I finish my current project!
Best wishes,
Chris.
Chris Webb [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
Even though I wouldn't bother doing this myself, I wouldn't mind
reviewing a patch series ;-)
Okay, I'll take a look when I finish my current project!
I had a bit of spare time this morning and had a quick look through
git-rebase--interactive.sh.
Apart from the validation, message and reflog code in git-rebase.sh and
git-rebase--interactive.sh that would need fixing up to know about this
case, the essence of this seems to be starting with an orphan commit instead
of a commit descended from $onto right at the end of --interactive.
I'd love to write something like
git checkout ${onto:---orphan}
(or a variant) but can git be persuaded to have an orphan detached HEAD like
that?
An orphan branch appears to involve HEAD containing 'ref: refs/heads/foo'
where refs/heads/foo doesn't exist yet, but I get 'not a git repo' instead
of an orphan detached HEAD with either :>.git/HEAD or rm .git/HEAD.
Cheers,
Chris.