Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list). > > Bernhard R. Link schrieb: >> --prune-tree makes rev-list without paths equivalent to >> "git rev-list $options -- ." (or .. or ../.. and so on, >> if you are in some subdirectory). >> This is the new default for format-patch and rebase > > Why do you need a new option when you can just add "-- ." to the rev-list > invocation? I agree that --[no-]prune-tree options are unnecessary. The patch to builtin-log.c, the second hunk to revision.c, and revision.h would be sufficient and all others should be dropped. Instead, the shell script Porcelains can simply add "-- ." at the end of their rev-list invocations. That way, we don't have to add anything to the documentation either. But I wonder if it is an indication of something screwy in the workflow, if a branch that merges others with "-s ours" is where the patches for upstream submission is taken from with format-patch, or what is rebased and internally gets its patches extracted with format-patch. A branch that merges with "-s ours" is typically done so that others can pull and build against (and "-s ours" is used to cauterize the history of a bad side branch), and good bits merged into it would also have come from a different clean branch that is merged into that branch. It might make more sense to format-patch that clean branch when preparing for upstream submission, than the "aggregated mesh of commits" branch with "-s ours" fix-ups. On the other hand, a branch that will be rebased to keep up with others is by definition private, and I don't see a reason to mark with "-s ours" to cauterize history of an unrelated side branch that tried to do something similar to what the branch is trying to achieve in that setting. You can instead ignore such a side branch and not merge with it. So I don't know how a sane history you are going to rebase ends up containing a "-s ours" merge to begin with. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html