Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > Stolee, you definitely want to inspect those changes (`git log --check` >> > was introduced to show you whitespace problems). If all of those >> > whitespace issues are unintentional, you can fix them using `git rebase >> > --whitespace=fix` in the most efficient way. >> >> Another way that may be easier (depending on the way Derrick works) >> is to fetch from me and start working from there, as if they were >> the last set of commits that were sent to the list. "git log >> --first-parent --oneline master..pu" would show where the tip of the >> topic is. > > That is not really easier. We had that discussion before. Stolee would > have to remove your Signed-off-by: lines *manually*. In return, all the whitespace fixes (and other fixes if any) I did on my end can be reused free by the submitter, instead of having to redo it *manually*. If a reroll of the series does not touch one specific commit, that commit can be left as-is; I do not see a need to remove anybody's sign-off or add yet another of your own, if the last two sign-offs are from you and your upstream maintainer, if you did not change anythning in what you got from the latter. This depends on what tool is used to work on refinement, but with "rebase -i", you'd leave "pick" as "pick" and not "edit" or "reword" and it would do the right thing. If you did refine, you get an editor when you record that refinement, so it is just a few key strokes, either "dd" or \C-k, to do that removal *manually*. So I am not sure why you are making a mountain out of this molehill. If you do want to remove the last two sign-off (i.e. penultimate one by the author done during the initial submission, plus the last one by me), well, "rebase -i" is open source. We can add features to the tool to help everybody collaborate better. Extending changes like planned addition of --signoff by Phillip, it is not all that far-fetched to add a mechanism that notices a project-specific trailer rewrite rules in-tree and uses that in between each step to rewrite the trailer block of the commit message, for example, and the rule > I understand that it is a trade-off between time you have to spend and > that others have to spend, and since you do not scale, that trade-off has > to be in your favor. That tradeoff may exist, but it does not weigh in the picture above at all. Perhaps it is better to try to actually think of a way to work together better, instead of just whining.
