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

[Petr Baudis <pasky@ucw.cz>]

Dear diary, on Tue, Jun 07, 2005 at 11:59:36AM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> On 6/7/05, Petr Baudis <pasky@ucw.cz> wrote:
> > 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.

> > (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