(no title)
pluies
|
1 year ago
Is it that awful? Each option is nicely explained, and the documentation is exactly where you need it, when you need it. I personally found it extremely helpful during my first interactive rebase, and still give it a glance from time to time when I forget the difference between squash and fixup.
quibono|1 year ago
On another note, is it possible not to lose the commit description when trying to split a commit? I'm talking about 1) marking commit as `e` to edit it 2) git reset HEAD~ to move back 3) split the change however you want 4) commit again whenever I do it I always lose the original commit message. I'm not sure if it's me being stupid or if there is just no simple way to do it.
000ooo000|1 year ago
There's 2 cases: 1) extract changes into a commit that comes before the original commit, and 2) extract changes into a commit that comes after the original commit.
In both, instead of editing the commit you want to split, `break` before that commit, and then use `git checkout <hash_of_commit_to_edit> <path_to_files_of_interest>` to pull the changes of interest out into an new, earlier commit. `git checkout -p` is worth a look here. Alternatively if the changes are simple enough, you could use exec instead of break before the target commit.
For 1) you can commit those extracted changes with a new message and then `git rebase --continue`. The original commit will then lack the extracted changes, and have the original commit message. If you did want to adjust it, reword that commit.
e.g.
For 2) reference the target commit's message as the new, earlier commit's message. Keep in mind that the git invocation in this exec here still supports git aliases so if this was something you do often, you could create an alias for retrieving the next commit message and that last part of the exec could just be `.. && git getnextcommitmessage`e.g.
skirmish|1 year ago