Junio C Hamano wrote, on 16.6.2016 20:25:
> "as long as >(N) can be used as Duy claims as a workaround to
> get the original behaviour, it is good to allow using >|(N)
> for this new output format; I didn't check if >(N) does behave
> that way, though"
Yes, it can be used in such way.
Example:
Duy Nguyen writes:
> Ah ok. This command with this series (using %>(n))
>
> ~/w/git/git log --format='%>(50,trunc)%s' --graph -15 origin/pu
>
> and the system one at version 2.7.3 (using %>|(n))
>
> /usr/bin/git log --format='%>|(50,trunc)%s' --graph -15 origin/pu
>
> both produce the same output
On Thu, Jun 16, 2016 at 11:25:28AM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > The first patch was from a long time ago. The concern was it may be
> > breaking existing user expectation [1]. I still maintain that it's a good
> > thing to do and should not break anything. He
Nguyễn Thái Ngọc Duy writes:
> The first patch was from a long time ago. The concern was it may be
> breaking existing user expectation [1]. I still maintain that it's a good
> thing to do and should not break anything. Hence the resubmission.
I do not think "it's a good feature to have" was a
The first patch was from a long time ago. The concern was it may be
breaking existing user expectation [1]. I still maintain that it's a good
thing to do and should not break anything. Hence the resubmission.
The second patch adds negative column specifier to >|() and friends.
A positive number 'n
5 matches
Mail list logo
