Revert policy

[Kubuxu]

When some change is introduced and we decide that it isn't beneficial and/or it causes problems we need to revert it.

To make later review process easier and the changes easier I propose that we always you git's revert command to revert some changes.

This suits few purposes. First, it is much easier to see if some change was reverted by just looking into history of the file. Imagine commit with title: Add feature C, there are many ways one could form the title for commit reverting it but by using git revert it will be Revert: "Add feature C" and thus very clear.
Second is that using git revert we are sure that all changes were reverted, it is much easier to star again for state 0 and apply changes on it, than try to see if some transformation transforms state 1 to state 0.

Q&A

What if commit that is supposed to be reverted contains changes that are also good?

This usually means that commit wasn't granular enough, if you are person that initially created the commit, in future try to make commits that focus on just a one aspect.

This doesn't mean that you should skip using git revert. Use it, then use git cherry-pick --no-commit to pull changes into your working tree and use interactive add to commit just the wanted ones. If interactive add is not enough to split the changes, still use interactive add to stage super set of wanted changes and use git checkout -- <file> to remove unstaged changes. Then proceed to edit files to remove all unwanted changes, add wanted changed and commit them only.

This way your log will look like:

AAAAAA Revert "Fix bug C in A"
BBBBBB Re-add feature A tests that were added in "Fix bug C in A"

Sounds good to you? This is just a proposal of what we should do. We can totally rework the idea.
If you have more questions, just post them, I will try to answer them.

[kevina]

I agree, git gui is very useful for doing interactive adds.

[whyrusleeping]

@Kubuxu can this issue be moved to ipfs/notes, or ipfs/support or somewhere else?

[Kubuxu]

I think it is quite meta to go-ipfs. I don't know if others want to apply it to their projects.
If we reach agreement it would be better to move it to go-ipfs contribution guidelines or something like that.

[jbenet]

Yes, I think we should do this community wide. Thanks for write up @Kubuxu
On Fri, Sep 2, 2016 at 5:53 AM Jakub Sztandera [email protected]
wrote:

I think it is quite meta to go-ipfs. I don't know if others want to apply
it to their projects.
If we reach agreement it would be better to move it to go-ipfs
contribution guidelines or something like that.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3166 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoSzu8b9YF1K68SrgKH4brFCynVGTks5ql0lhgaJpZM4Jy1Db
.

[Stebalien]

(closing due to age)