Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list

Dear diary, on Tue, Jun 07, 2005 at 11:59:36AM CEST, I got a letter
where Jon Seymour [off-list ref] told me that...

On 6/7/05, Petr Baudis [off-list ref] wrote:

quoted

I'd prefer just --wrt-author and --exclude-author to take an argument on
their own.

The reason I don't want to do this is that it doesn't really make
sense in the context of the change to specify one author for
--wrt-author and another for --exclude-author. In normal use --author
defaults to GIT_AUTHOR_EMAIL or the locally derived user@host.domain.
The  intention is simply to override this default derivation.

Hmm, then why not make it --wrt-author[=AUTHOR] ? Similar to the
--pretty option. BTW, can it do multiple author excludes now? The
commandline would look especially horrifying in that case now, I guess.

I'd prefer --stop-at-author from the choices you offer in your other
mail.

quoted

(Note that I don't endorse this patch and the --wrt-author behaviour in
particular seems strange. I don't have enough time to comment on it
sensibly now, though. I'm just focusing on style here since I'd like to
still be able to read git's source code few weeks from now on.)

The rationale for the change is as follows:

During parallel development, one is aware of ones own
changes...everyone else changes haven't happened yet as far as you are
concerned. Only when they appear in a future merge that incorporates
one's own changes do the other changes appear in your own workspace.

As far as you are concerned, these changes occurred after you made
your own - your changes were not dependent on those changes, only on
those that came before. So the linearisation reflects that perceived
ordering of changes.

--wrt-author helps to reconstruct the merge-history from the
perspective of each individual committer.

Yes, such motivation makes sense. But is the author field the right one?
If you are integrating a lot of other people's patches in particular, I
think it makes no sense whatsoever - you already reviewed and
consciously applied them, but your option will regard them as something
alien and merged from outside, right?

And, after all, the other branches might be _quite_ long-lived. I think
it would be confusing for the user if the commit graph looked like

  a1 -- a2 -- a3 -- a4 -- a5 -- a6 -- a7 -- a8 -- a9 -- a10
     \           /           /     \                 /
      - b1 -- b2 -- b3 -- b4 -- b5 -- b6 -- b7 -- b8 -- b9

If your patch first chooses b1, it then shows all of it, completely
ignoring a2, right? I can't see how that would be right - the subsequent
merges from a should be shown.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor