More reading and some comments: a. Linus et al on git rebase: http://yarchive.net/comp/linux/git_rebase.html.
b. An article in LWN about the topic: http://lwn.net/Articles/328436/ c. In the first reference there are a couple of comments by Linus on "revert" -- including a recipe using rebase that seems natural. d. to revert without rewriting history, I belive "git revert" does the trick. With respect to the "allow rewriting history" vs. "don't allow rewriting history", p lease have a look at the comments by Linus from (a) above. I think he knows what he's talking about. One thing that Linus stresses is that rebasing affects more the people "downstream" than the people "upstream". For instance: if a group is working on some module, we push a series of patches (but I'm still working on subsequent ones), and somewhere in the path between us and the final merge the patches get rewritten, then our work after that may be seriously screwed (meaning: we have to work to adjust, and we don't have history to tell us *how* or *where* the divergence with our codebase. On Tue, Nov 5, 2013 at 10:20 AM, Simon King <simon.k...@uni-jena.de> wrote: > If the commit history was like > A: Basic implementation of a duck (quacks, swims) > B: Added duckumentation > C: Added feature "duck flies" > D: Remove trailing whitespace > E: Fix bad doc formatting > then I believe to *some* extent it makes sense to re-group these commits > (like: (A+C+D)-(B+E)), since, as we have seen, rebasing of dependent > branches does not become more difficult. As Linus says I wouldn't argue for "hard rules" and this may be an exception under some circumstances, but as a general rule I can think of different scenarios where it's ok and where it's not ok to rewrite. In particular I think this is only ok if all A-E have been writing by the same person or a group with tight synchronization, and I guess it also depends on time elapsed between A and E, etc. Example: 1. A, B are posted in ticket 2. purple-sage (or sage-next, or whatever) gets interested in ducks, and decides to merge these experimentally 3. C is posted in ticket 4. review of ticket requests D, E 5. author rewrites history to (A+C+D) , (B+E) 6. merged in master sage as rewritten 7. now purple-sage is screwed up wrt master sage Of course it wouldn't be too bad to resolve this issue for a few tickets, but doing it for a number of them may be quite boring. I would assume one of the features of switching to git would be to ease the exchange of code between sage and other efforts like purple-sage, and/or allow having a "sage-next" branch, or ... (other ideas people may come up with). Different scenario: A is completely broken so no way it can be merged (e.g. breaks compilation); then A is never merged, the author is requested to redo the feature, a new patch A' is posted by the author (based on A, fine) and that's merged. In this scenario purple-sage wouldn't have merged A either (due to compilation broken) or would want it removed anyway. -- As a general rule I would argue for: a. no rewriting of other people patches b. no rewriting of own patches that have been published c. adopt a sensible definition of "published" which allows *some* rewriting that people may want d. empower developers with easy ways to share feature development branches which are not "published" e. allow sensible exceptions when truly necessary For (d) feature branches should be based on stable points anyway and refrain from frequent pulls/merges with master until the feature is merged, etc. Best, Gonzalo -- 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.
