Hi Ralf, On 2013-11-05, Ralf Hemmecke <hemme...@gmail.com> wrote: >> So, what simple and easy-to-use command does git offer to create a >> "negative commit"? That's to say, if I have commits A-B-C and want to >> "remove" B, how can I make git create a commit D for me such that >> A-B-C-D results in the same code as A-C? > > https://www.kernel.org/pub/software/scm/git/docs/git-revert.html
"Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." Yes, this seems to be the right thing to do. > OK, now we have > > A B C = master X = ticket/456 > o ------> o ------> o -------> o ----------> o > | > | > +------------------> o > C' = ticket/123 > > I must say, I don't quite understand what it means that ticket/456 and > ticket/456new are identical? Do they correspond to the same (git-)sha1? Yes. I did "git checkout -b ticket/456new ticket/456", simply to be able to test two methods of rebasing X on top of the changed ticket/123. > I assume what you want as a result is this: > > A B C = master > o ------> o ------> o -------> o > | > | > +------------------> o ---------------> o > C' = ticket/123 X = ticket/456 > > > To achieve this from the above situation, you do > > git rebase --onto ticket/123 master ticket/456 Good to know! I did not test yet. Is there any manual intervention needed, if X is disjoint from the changes introduced in B? To summarize: 1. Adding a commit that reverts the effects of earlier commits is not more difficult than to do "hg qdelete <patch-name>" 2. There is a tool that rebases dependent commits in such a way that even a "proper" (Volker would say: an improper...) deletion of a commit (such as A-C' replacing A-B-C) is correctly dealt with. 1. means that Volker's mantra "thou shalt not change a branch except by adding commits" is feasible. I still believe that the outcome with all the back and forth and "we add this feature in commit B" and "we revert the feature from commit B by commit D" is just ugly, though. 2. means (to me, at least) that changing the history on a branch attached to a trac ticket *should* be allowed. Something that is on trac but is not merged into a released version of Sage is (by definition) work in progress. Hence, if someone uses a branch from trac as a starting point for his/her own work, then he/she should know that the branch from trac can change, and he/she can then easily cope with it by doing "git rebase --onto". After all, if branch ticket/123 changes by adding a new commit D (reverting commit B), then branch ticket/456 needs to be rebased (by merging) too. So, why would one say that rebasing X on top of A-B-C-D is fine, but rebasing X on top of A-C' (that results in the same code as A-B-C-D!) is too much to ask for? I have asked other questions (on the workflow, not on git) that haven't been answered yet. - Could it be implemented in trac (and do you think it should be implemented) that authors of ticket B get an automated mail if the code provided by a dependency ticket A changes, stating that a rebase and a new review are needed? - Could it be implemented in trac (and do you think it should be implemented) to automatically rebase the branch of ticket B (e.g., by git rebase --onto), if the branch of dependency ticket A changes but the changes are only cosmetical (say, folded commits, changed commit messages) and do not change the code? I guess if the code on ticket A does not change then (a) automatic rebase of the branch of ticket B is safe, and (b) a new review of ticket B is not needed. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
