Re: [git] Re: git log -M -- filename is not working?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On May 12, Jeff King wrote:
> On Sat, May 08, 2010 at 03:08:53AM -0400, Eli Barzilay wrote:
> 
> > So I think that it would really help if (1) the diff options in the
> > git-log man page move to after its own options, and (2) they appeared
> > after a title saying that these are the diff options, (3) `--follow'
> > moves up before the few preceding options that seem to me less
> > important.  To clarify, I added a simple patch to the end of this
> > message.  (`git-format-patch' has the same thing, but there it looks
> > more sensible to leave it as is.)
> 
> I have no opinion on moving --follow around, but I definitely agree that
> more clearly marking the diff-options (and including them after
> revision traversal options) is much better.

Should I send that reorganization as a proper patch then?


> > diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
> > index fb184ba..6bc7064 100644
> > --- a/Documentation/git-log.txt
> > +++ b/Documentation/git-log.txt
> > @@ -24,7 +24,6 @@ OPTIONS
> >  -------
> >  
> >  :git-log: 1
> > -include::diff-options.txt[]
> 
> This ":git-log: 1" magic should probably follow the include. It sets up
> an attribute for diff-options.txt to conditionally include some
> log-specific bits.

It seemed like it's a definition that could be used elsewhere too (eg,
in other includes that could be added in the future).


> > How about these options:
> > 
> >   git config log.follow if-single-file
> >     makes it use --follow only when there's a single file path given,
> >     ignoring it otherwise (with no confusion about it now)
> > 
> >   git config log.follow if-possible
> >     makes it do the same, but might also do it for more cases if/when
> >     they become available (so this is the "do the best you can"
> >     option)
> > 
> >   git config log.follow true
> >     invalid until it is always possible to use --follow
> 
> I'm not thrilled with it. It still leaves the confusing behavior,
> but because we forced the user to pick the confusing behavior, we
> get to claim it is their fault. So while we may be guilt-free, I'm
> not happy with an option that produces such confusing behavior.

Well, yes -- it leaves that potential source of confusion, which could
result if someone recommends to just use the `if-single-file' thing,
and I do that while being unaware of what it actually does.  But OTOH,
it helps with the apparently popular confusion that makes people panic
and send "WHERE DID MY HISTORY GO???" emails.  (It's been about 2-3
weeks since we migrated from svn to git, and I had at least three
people do exactly that.)


> I really wonder if it would be that hard to just fix the code to follow
> several files. [...]

That would obviously be a better solution...

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]