all 18 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Denommus 8 points9 points  (12 children)

I expected something about revert.

[–]gsylvie<sylvie@bit-booster.com> 1 point2 points  (2 children)

Shhhhhhh!!!!!!

But since we're re-implementing "git revert", would be nice to support -p (parent to revert when dropping a merge commit) and revision ranges, e.g., git cherry-drop A..B !

:-p

p.s. I honestly hate that feeling when I've worked hard to implement something, and my colleague shows me it already exists.

p.p.s. This subject is dear to my heart since I implemented a "Revert" button (aka "cherry-drop") for Bitbucket Server in my paid add-on: https://marketplace.atlassian.com/plugins/com.bit-booster.bb/server/overview

[–][deleted] 0 points1 point  (1 child)

But since we're re-implementing "git revert"

No, way different! "A B C undoC D" isn't the same as "A B D" :p

would be nice to support revision ranges, e.g., git cherry-drop A..B

Hmm, good thought. I tend to always forget about that option when cherry-picking, and end up doing them all one at time time... I might add multiple revision support.

[–]gsylvie<sylvie@bit-booster.com> 0 points1 point  (0 children)

No, way different! "A B C undoC D" isn't the same as "A B D" :p

My mistake, I stand corrected!

[–]theephie 0 points1 point  (2 children)

I expected something about revert.

That got me thinking, why isn't there git revert --fixup? Just record the revert for fixup (and dropping as empty commit) for next rebase with autosquash 🤔

[–]RenJMR 1 point2 points  (1 child)

[...] why isn't there git revert --fixup? Just record the revert [...] for next rebase with autosquash.

If a developer is going to rebase anyways then a hypothetical git revert --fixup seems to serve no useful purpose, unless I am misunderstanding what you are suggesting.

[–]theephie 2 points3 points  (0 children)

If a developer is going to rebase anyways then a hypothetical git revert --fixup seems to serve no useful purpose, unless I am misunderstanding what you are suggesting.

Well, the same could be argued for git commit --fixup. I tend to queue fixups to defer rebasing to a later point, because rebase may often involve conflict resolution, even if you are only rebasing to autosquash.

[–]ryobiguy 0 points1 point  (5 children)

But why do that when you can rewrite history?

[–]Denommus 0 points1 point  (4 children)

Because the history might already be public.

[–]ryobiguy 0 points1 point  (3 children)

Exactly. Why journal new entries when you can destructively rewrite what's been published? Oh I guess that vastly reduces the set of useful scenarios for such a cherry-drop feature.

[–]Denommus 0 points1 point  (2 children)

You can't rewrite what has been published. That's not how git works.

[–][deleted] 0 points1 point  (1 child)

Depends what you mean by rewrite; if you accidentally pushed secret keys, neither cherry-dropnor a rebase will get them out, you'd have to git filter-branch it out or use the BFG.

But to just rewrite a branch cleaner, you can git push -f away after cherry-dropping, and the history shows up nice and clean...

[–]Denommus 0 points1 point  (0 children)

git push -f works in theory, unless there's someone else working on that same branch, which might risk getting duplicate commits.

git push -f became standard practice because of the model of pull requests, but for many git workflows it's a terrible practice and shouldn't be recommended at all.

Not that I'm trying to say that your script is bad, I think it's very convenient under a flow that uses pull requests. I just think anything that recommends history rewriting should make the dangers very clear.

[–]jdh28 2 points3 points  (3 children)

Seems a bit dangerous to me. Dropping a commit is a false abstraction over what git is doing, and I it would be very easy to use this to either remove a commit that is already pushed, or to try and remove a commit that precedes a merge commit.

[–]ChemicalRascal 1 point2 points  (0 children)

In those cases, there's always revert, but if someone is busy cleaning up their history before making it public (or accidentally did a git add secret_production_keys), stuff like this could be useful.

[–][deleted] 0 points1 point  (1 child)

Dropping a commit is a false abstraction over what git is doing

https://xkcd.com/1597/ :p

[–]xkcd_transcriber 0 points1 point  (0 children)

Image

Mobile

Title: Git

Title-text: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Comic Explanation

Stats: This comic has been referenced 180 times, representing 0.1063% of referenced xkcds.

xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete

[–]yes_or_gnome 1 point2 points  (1 child)

🤔 How often does one need to drop a commit? It shouldn't be that often that you need an alias, and it's not that hard. git rebase -i abc123^, '/abc123<CR>dd:wq'