Junio C Hamano <gitster@xxxxxxxxx> wrote: >> The pseudo ref certainly has an appeal. For people very familiar with >> Git's peculiarities such as FETCH_HEAD. Such as myself. >> For users, it is probably substantially worse an experience than having a >> cmdmode like --show-patch in the very command they were just running. > I tend to agree with that assessment. FETCH_HEAD was a required > mechanism for commands in the toolchain to communicate and wasn't > meant as a mechanism for end-users. I do not think it is a good > idea to add to the pile to these special files the users would need > to look at, when we do not need to. > Even if the internal implementation uses such a file, wrapping it > with a documented command mode would make a better UI. I disagree with that as I had: | [alias] | original-commit = !git show $(cat .git/rebase-apply/original-commit) for a long time in my ~/.gitconfig :-) (until I realized that Git accepted "rebase-apply/original-commit" everywhere; for single-commit branches I always just used ORIG_HEAD). This meant that whenever I wanted to look at the lay of the land upon which the original commit was built, I had to do "git original-commit" and copy & paste the SHA1 (without my alias, I had to "git log ORIG_HEAD", pick hopefully the cor- rect commit and copy & paste its SHA1). Only with this SHA1 I could then run "git diff", "git show", "git grep", "git blame", etc., etc., etc. because in my use cases looking at the patch alone was usually not sufficient: I needed to know why there was a conflict, i. e. how the file(s) the patch changed looked before they had been altered upstream. To me, this type of "algebra" is what makes Git so powerful: I do not have to build a pipe that gets the SHA1 of a branch's tip and xargs it to "git show", I can just say "git show $branch". Having a SHA1 with a special meaning that has no easy way to access it by "git rev-parse" breaks this UI IMHO. Tim
