update git obliterate

[spacewander]

For #203
git obliterate is (still) dangerous, so don't play with it until you know the full implications.

[nicolaiskogheim]

I played with it without knowing the full implications :)

Removed the Readme of a project. Worked wonderfully.
Somehow I thought I could test it in a branch, and throw it away, but it of course rewrote all the branches (and the remote ?).

Ref 'refs/heads/master' was rewritten
Ref 'refs/heads/more-pages' was rewritten
Ref 'refs/heads/test-obliterate' was rewritten
Ref 'refs/remotes/origin/master' was rewritten                     # <-- It's rewritten..
WARNING: Ref 'refs/remotes/origin/master' is unchanged  # .. or not
Ref 'refs/stash' was rewritten

I've got two new brances it seems. Don't know what they are for.

refs/original/refs/remotes/origin/master
refs/original/refs/heads/master

I had stashed some stuff, which I think got rewritten too. Again, I don't know if I want that or not.
But, I know I don't want the stash to be messed up. I am not sure what happened with the stash,

This is an image of the two entries in my stash after obliterateing. (as in git show stash@{0})
The original (now rewritten somehow) entry on the right.
A new entry on the left.

It looks like the original (to the right, look at the double +) is messed up (but it's not, I think), and what's with the new one?

$ git stash apply stash@{0}    # The new entry
'stash@{0}' is not a stash-like commit

Point of all this: Answer the questions somehow in the man page, and/or make it so the questions doesn't arise, as in e.g. not touching the stash (at least not put in a new entry that cannot be applied).

[spacewander]

Thank you for careful testing and review!

1. The defualt behaviour of git obliterate will rewrite all the commits in your local machines. New commit object will replace the old one even nothing was changed. It is dangerous, you can specify a range for it to let it less dangerous.
2. As the link says, those refs like

refs/original/refs/remotes/origin/master
refs/original/refs/heads/master

is for backup.

1. I think the double '+' means

   one line that was added does not appear in either file1 or file2

Admittedly，I don't know why this happended... Could you explain the change with stash? (e.g. The way to figure out the unapply stash)

[nicolaiskogheim]

I've done a little bit of fiddling with this, and arrived at the conclusion that it is the --prune-empty that messes up the stash. But I have no idea why. If I have one stash entry, then it gets rewritten, but I can still apply it if I want, but the new stash element that gets added, does not apply at all. It isn't even a real stash-element, so it can't be dropped. I don't know what we can do about this, but we should mention it in the man page, that you shouldn't have stashed stuff when you run obliterate.

On another note, why --tag-name-filter cat? That's not doing anything. @petersohn

[spacewander]

Oh right, just updated the documentation to mention the side effect on stash.

As the other question, --tag-name-filter cat may be used to update tags rather than the commits pointed to.

[nicolaiskogheim]

Good 👍

I know what --tag-name-filter does, but as it is now it does not do anything, and the user cannot change that either. The code would do the same with or without it as it is now.

[petersohn]

My guess is that if you leave out --tag-name-filter then tags won't be transformed. Thus, if you want to leave it as is, you have to use an identity transformation, i.e. cat.

[nicolaiskogheim]

Ah, I see. I thought the tags would be left untouched, but they are removed if there is no --tag-name-filter.

[spacewander]

Yes, if we don't use --tag-name-filter, the tags will still point to old commit. In the view of new(rewritten) commits, they lost.

[hemanth]

What's the status of this?

[hemanth]

@spacewander ?

[spacewander]

The previous version of git-obliterate will rewrite all commits, with this pr we can specify a range for it. Both the previous one and the new one have a side effect: the stash will broke since its parent has been rewritten.(warned in the documentation)