Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for drop!/reword! commits to git rebase -i #259

Open
dscho opened this issue Jun 6, 2019 · 12 comments
Open

Add support for drop!/reword! commits to git rebase -i #259

dscho opened this issue Jun 6, 2019 · 12 comments
Labels

Comments

@dscho
Copy link
Member

dscho commented Jun 6, 2019

This was already discussed briefly on the Git mailing list: https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/

In short, the reword! semantics are relatively easy in my mind: it would be called as

git commit --reword <commit>

would take staged changes (if any), otherwise implicitly --allow-empty,
then create a commit message to be edited in this style:

reword! <original-oneline>

<original-oneline>

<original-body>

This would be presented to the user in an editor (similar to git commit --amend).

Upon rebase --autosquash, it would work like a squash! but comment out all
previous commit messages, and also comment out the reword! line and the
empty line after that.

In case of multiple reword!, the last one would win, and it would
naturally integrate in any fixup!/squash! workflow.

What is more difficult is something else I frequently need: drop!
. That is, I want to explicitly mark a commit to be excluded in
subsequent rebase --autosquash. I guess the best way would be to
implement a

git revert --drop <commit>

that would work as if you called git revert -n <commit> && git commit -m 'drop! '"$(git show -s --oneline <commit>)", and upon rebase --autosquash, it would reorder like fixup!/squash!/reword!, replace the pickof the previous line (if it was apick) by dropand comment out the currentpick drop! ` line.

The reason why the semantics are more difficult in that case is that drop!
does not mix well with fixup!/squash!/reword!.

@Hasaber8
Copy link

Hasaber8 commented Mar 8, 2020

Has this project already been taken up or is still available to be worked upon?
-Rohan

@dscho
Copy link
Member Author

dscho commented Mar 8, 2020

I am unaware of any effort so far, so go right ahead!

@Hasaber8
Copy link

Hasaber8 commented Mar 9, 2020

Correct me if I'm wrong , currently even if we try and skip a single commit in git rebase -i it gets squashed, without it been shown in th editor.

@dscho
Copy link
Member Author

dscho commented Mar 9, 2020

Correct me if I'm wrong , current even if we try and skip a single commit in git rebase -i it gets squashed, without it been shown in th editor.

If I understand your question right, you're asking whether git rebase --skip still applies the currently-picked commit? It does not...

@Hasaber8
Copy link

Hasaber8 commented Mar 9, 2020

Correct me if I'm wrong , current even if we try and skip a single commit in git rebase -i it gets squashed, without it been shown in th editor.

If I understand your question right, you're asking whether git rebase --skip still applies the currently-picked commit? It does not...

The drop! semantics if executed properly will be a very good thing to use! This surely will be an interesting project to do!

@phillipwood
Copy link

I've got some patches that implement the reword! part of this as amend! They need a little work - adding documentation, checking the test coverage and adjusting them to accommodate the recent changes to handling empty commits if anyone wants to pick them up

@phillipwood
Copy link

phillipwood commented Sep 18, 2020

git revert --drop <commit>

that would work as if you called git revert -n <commit> && git commit -m 'drop! '"$(git show -s --oneline <commit>)",

Do we need to actually do the revert? - If we want to drop the commit can't we use an empty commit (git commit -m 'drop! '"$(git show -s --oneline <commit>)")? If we actually try to revert the commit there is the potential for conflicts when running revert which would create unnecessary work for the user.

Edit: We need the revert so that the effects of the dropped commit are reversed for any commits we build on top of the drop! commit before we rebase.

@dscho
Copy link
Member Author

dscho commented Sep 23, 2020

git revert --drop <commit>

that would work as if you called git revert -n <commit> && git commit -m 'drop! '"$(git show -s --oneline <commit>)",

Do we need to actually do the revert?

Yes. The point of dropping a given commit is to drop its changes, too, and that's a revert. Otherwise the tree after git revert --drop <commit> would not have dropped the changes!

@LemmingAvalanche
Copy link

Isn’t all of this implemented now?

@dscho
Copy link
Member Author

dscho commented Sep 29, 2024

Isn’t all of this implemented now?

I might have missed it, is the drop! part implemented now?

@LemmingAvalanche
Copy link

@dscho Oh no sorry, I just tested (git version 2.46.2) and git rebase -i --autosquash does not translate drop! commits to the drop command in the todo editor.

Disregard that.

@dscho
Copy link
Member Author

dscho commented Sep 30, 2024

All good. Thank you for keeping better tabs on these here tickets than I manage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants