I’m trying to verify each commit in a sequence, moving from the first to the current tip. It’s not really a git bisect, I don’t expect any problems and the tip works. But I want to make sure each commit is self-contained and correct.
I can use HEAD^ to go back one from the tip but is there a “one forward from where I am” treeish? That is, if I have
o aaabbbccc (tip)
|
o abcdefabc
|
o fedcbafed
|
o abcdabcde
|
o deadbeefe (root)
I want to do:
git checkout deadbeefe
build and test
git checkout current+1
<up two, return>
<up two, return>
But I can’t figure out the treeish for “current+1”.
Git does not store links from parents to children; only links from children to parents. To find a commit’s children, you have to start at the childmost commits in your repository (branch tips, tags, HEAD, etc.) and walk up the chain of parents until you either reach a root node or find the commit in question.
If your commit DAG is linear and
tipis a reference to the childmost commit, you can do something like the following to find the child commit of revisiondeadbeefe:This causes Git to start walking from
tipuntil it reachesdeadbeefeor the root and print out all the commits it comes across. The output is then piped totailto select the last visited commit, which will be the child ofdeadbeefeif the commit history is linear.HEADrefers to the currently checked-out commit, so if you need the child of the current commit instead ofdeadbeefe, useHEAD. Commands that require a commit default toHEADif unspecified, so you can do the following:Again, this only works if the DAG is linear. If the commit history is not linear, you can use the
--ancestry-pathargument torev-list.Doing the above each time you want to move to the next commit would be O(n^2), but Git is so fast that it usually doesn’t matter in practice. If you need it to be O(n), I’d do the following:
And @knittl is correct—the term you want here is commit, not treeish. Some terminology:
HEAD, tags, and/or branches.