3 ms·

> If all you have is a single commit with no parent, you cannot rebase it. Well, of course what you want to do here depends. You can squash onto it, edit it, o

by arjie 10y ago

> If all you have is a single commit with no parent, you cannot rebase it. Well, of course what you want to do here depends. You can squash onto it, edit it, or reorder it. You're commonly going to have conflicts if your first commit created a file and the rest edit it. If you reorder you can't edit a file that doesn't exist yet. Here are a couple of videos to illustrate: https://gfycat.com/GrizzledPartialAntelopegroundsquirrel https://gfycat.com/GrizzledPartialAntelopegroundsquirrel https://streamable.com/1chg https://streamable.com/1chg This wasn't always possible through the UI but it's possible now. If this doesn't do the trick, would you mind sharing what your use case is?

kazinator 10y ago
The use case is that when I'm making a new repo, I want to be able to do: git rebase -i <first-commit-sha>^ git reset --patch <first-commit-sha>^ git checkout --patch <first-commit-sha>^ I can do all this if the first commit is actually the second and the first is a dummy empty one.
- arjie 10y ago
  I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.
  - deleted 10y ago
    [deleted]
  - kazinator 10y ago
    If you plant a NIL commit in your repo before doing anything else, and tag it as NIL, then absolutely all git commands that take a ref (including ones you don't even know yet) will Just Work without any special arguments or modifications for the root case. You don't need to memorize yet more special cases for yet one more corner case in git. In existing old repos or other people's repos that do not have NIL, I don't need it, because I won't be rewriting their history (let alone all of it back from the empty state!) It's handy, when a repo is brand new, to be able to massage the newly created master branch using the same workflows that are rehearsed daily, rather than special cases.

by arjie 10y ago

kazinator 10y ago

The use case is that when I'm making a new repo, I want to be able to do: git rebase -i <first-commit-sha>^ git reset --patch <first-commit-sha>^ git checkout --patch <first-commit-sha>^ I can do all this if the first commit is actually the second and the first is a dummy empty one.

arjie 10y ago
I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.
- deleted 10y ago
  [deleted]
- kazinator 10y ago
  If you plant a NIL commit in your repo before doing anything else, and tag it as NIL, then absolutely all git commands that take a ref (including ones you don't even know yet) will Just Work without any special arguments or modifications for the root case. You don't need to memorize yet more special cases for yet one more corner case in git. In existing old repos or other people's repos that do not have NIL, I don't need it, because I won't be rewriting their history (let alone all of it back from the empty state!) It's handy, when a repo is brand new, to be able to massage the newly created master branch using the same workflows that are rehearsed daily, rather than special cases.