On Fri, Aug 8, 2025 at 3:15 PM Julia Evans via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > Thanks for the review comments, here are the new changes which: > > * make the intro to the man page less dry, with the suggested wording > * clarify the merge conflict resolution explanation & fix the HTML > formatting issues > * move the explanation of the git rebase <upstream> <branch> syntax up into > the intro > > I'm still curious about the intention for the git rebase master topic > syntax, since I'd never heard of it before. Is it just to save on typing, > since it's fewer characters than git switch topic and then git rebase > master? I ask because someone mentioned to me on Mastodon > (https://hachyderm.io/@simontatham/114988051822317920) that they sometimes > use git rebase HEAD main as part of their workflow, which is not equivalent > to git checkout main && git rebase HEAD. That made me think that there might > be some broader intent to enable rebases that wouldn't otherwise be possible > without that syntax. I think the intent really is "shortcut." It's existed since the first version of rebase (59e6b23ace ([PATCH] git-rebase-script: rebase local commits to new upstream head., 2005-06-25), https://lore.kernel.org/git/7v4qboejp6.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx/). I didn't look too closely at that mailing list thread for any justification of the shortcut, though. The example mentioned on Mastodon is still a shortcut, it's just more like a function than a macro (that is, the arguments are evaluated first, then the shortcut applied): git rebase HEAD main becomes (in shell syntax) head=$(git rev-parse HEAD) git switch --detach main git rebase $head rather than git switch --detach main git rebase HEAD # too late, HEAD has changed
