Re: [PATCH v2 0/3] diff-highlight: add support for git log --graph output.

2016-08-19 Thread Jeff King
On Fri, Aug 19, 2016 at 09:19:44PM +, Eric Wong wrote:

> > I've rebased my changes. Unfortunately, having 3 commits made this somewhat
> > tedious. I also find it weird that my new patch set makes it difficult to 
> > see
> > what changes I've made from my first set. What's the standard workflow here?
> 
> I check out a new branch with the same base as the previous series
> and "git diff previous current"
> 
> (without git, I'd be using interdiff from the patchutils Debian package)
> 
> Sometimes I will rebase against both old+new against Junio's master
> to avoid/reduce conflicts.

You might also try Thomas Rast's topic-branch diff:

  https://github.com/trast/tbdiff

It gives better patch-by-patch differences. And it handles the case that
the topics have different bases (which is handy if you've rebased, or if
Junio happened to apply on a different base than you did).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/3] diff-highlight: add support for git log --graph output.

2016-08-19 Thread Eric Wong
Brian Henderson  wrote:
> On Wed, Aug 10, 2016 at 08:56:35AM +, Eric Wong wrote:
> > "local" is not a portable construct.  It's common for
> > Debian/Ubuntu systems to use dash as /bin/sh instead of bash;
> > (dash is faster, and mostly sticks to POSIX)
> > 
> > The "devscripts" package in Debian/Ubuntu-based systems has a
> > handy "checkbashisms" tool for checking portability of shell
> > scripts.
> 
> checkbashisms didn't output anything, and I found other instances of
> local in some tests. but I removed anyway.

Ah, I guess "checkbashisms --posix" is required nowadays
since Debian policy deviated from POSIX, here
(we don't blindly follow POSIX, either).

Anyways, some people still care about ksh93 as of a few months
ago; so I think avoiding "local" is preferable:

  https://public-inbox.org/git/?q=ksh93:..20160801

I think all of our other "local" uses are limited
to bash-specific parts: bash completion, mingw tests



> I've rebased my changes. Unfortunately, having 3 commits made this somewhat
> tedious. I also find it weird that my new patch set makes it difficult to see
> what changes I've made from my first set. What's the standard workflow here?

I check out a new branch with the same base as the previous series
and "git diff previous current"

(without git, I'd be using interdiff from the patchutils Debian package)

Sometimes I will rebase against both old+new against Junio's master
to avoid/reduce conflicts.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/3] diff-highlight: add support for git log --graph output.

2016-08-17 Thread Brian Henderson
Changes made per Eric.

On Wed, Aug 10, 2016 at 08:56:35AM +, Eric Wong wrote:
> Brian Henderson  wrote:
> 
> Hi Brian,
> 
> A few minor portability/style nits below, but contrib/ probably
> (still?) has laxer rules than the rest of git...
> 
> I think we still require Signed-off-by lines in contrib,
> though...

added

> 
> > +++ b/contrib/diff-highlight/t/Makefile
> > @@ -0,0 +1,19 @@
> > +-include ../../../config.mak.autogen
> > +-include ../../../config.mak
> > +
> > +T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
> > +
> > +all: test
> > +test: $(T)
> > +
> > +.PHONY: help clean all test $(T)
> > +
> > +help:
> > +   @echo 'Run "$(MAKE) test" to launch test scripts'
> > +   @echo 'Run "$(MAKE) clean" to remove trash folders'
> > +
> > +$(T):
> > +   @echo "*** $@ ***"; sh $@ $(GIT_TEST_OPTS)
> 
> Probably:
> 
>   @echo "*** $@ ***"; '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
> 
> like we do in t/Makefile in case we need to override 'sh'.
> 

done, although I basically had to copy the SHELL_PATH_SQ logic from t/Makefile

> > +
> > +clean:
> > +   $(RM) -r 'trash directory'.*
> > diff --git a/contrib/diff-highlight/t/t9400-diff-highlight.sh 
> > b/contrib/diff-highlight/t/t9400-diff-highlight.sh
> > new file mode 100644
> > index 000..ca7605f
> > --- /dev/null
> > +++ b/contrib/diff-highlight/t/t9400-diff-highlight.sh
> > @@ -0,0 +1,63 @@
> > +#!/bin/sh
> > +#
> > +# Copyright (C) 2016
> 
> IANAL, but I think your name (or who you represent) needs to be
> in the copyright.

diff-highlight doesn't have a copyright, so I just removed it. ok?

> 
> > +
> > +test_description='Test diff-highlight'
> > +
> > +. ./test-diff-highlight.sh
> > +. $TEST_DIRECTORY/test-lib.sh
> 
> TEST_DIRECTORY ought to be quoted since it could contain
> shell-unfriendly chars (we intentionally name 'trash directory'
> this way to trigger errors).

done

> 
> > +
> > +# PERL is required, but assumed to be present, although not necessarily 
> > modern
> > +# some tests require 5.8
> > +
> > +test_expect_success 'diff-highlight highlightes the beginning of a line' '
> 
> You can declare a prereq for PERL::
> 
>   test_expect_success PERL 'name' 'true'

done

> 
> And spelling: "highlights" (there's other instances of this, too)

oops, thanks

> 
> > +  dh_test \
> > +"aaa\nbbb\nccc\n" \
> > +"aaa\n0bb\nccc\n" \
> > +"
> 
> We use tabs for shell indentation.

done



> > +
> > +dh_diff_test() {
> > +  local a="$1" b="$2"
> 
> "local" is not a portable construct.  It's common for
> Debian/Ubuntu systems to use dash as /bin/sh instead of bash;
> (dash is faster, and mostly sticks to POSIX)
> 
> The "devscripts" package in Debian/Ubuntu-based systems has a
> handy "checkbashisms" tool for checking portability of shell
> scripts.

checkbashisms didn't output anything, and I found other instances of local in 
some tests. but I removed anyway.

> 
> > +
> > +  printf "$a" > file
> > +  git add file
> > +
> > +  printf "$b" > file
> > +
> > +  git diff file > diff.raw
> 
> Commands should be '&&'-chained here since any of them could fail
> ("git add"/printf/etc could run out of space or fail on disk errors)

I wasn't totally sure what to do here. I added some checks for empty files and
&& chained them with the last command to verify I wasn't diffing 2 empty files.
Hope that is sufficient.

> 
> Also, our redirect style is:  command >file
> without a space between '>' and destination.

done

> 
> See Documentation/CodingGuidelines for more details.
> Unfortunately, the reasoning is not explained for '>NOSPACE'
> and I'm not sure exactly why, either...
> 
> > +  if test "$#" = 3

done

> 
> Better to use -eq for numeric comparisons: test $# -eq 3
> Quoting $# doesn't seem necessary unless your shell is
> hopelessly buggy :)
> 
> > +  then
> > +# remove last newline
> > +head -n5 diff.raw | head -c -1 > diff.act
> 
> "head -c" isn't portable, fortunately Jeff hoisted it out for
> use as test_copy_bytes in commit 48860819e8026
> https://public-inbox.org/git/20160630090753.ga17...@sigill.intra.peff.net/

It didn't look like his version supported a negative number, so I rolled my own.

> 
> > +printf "$3" >> diff.act
> > +  else
> > +cat diff.raw > diff.act
> > +  fi
> > +
> > +  < diff.raw $CMD > diff.exp
> 
> $CMD probably needs to be quoted.  However, by the time I got
> here I had to ask myself:  What is $CMD again?
> A: Oh, look up at the top!
> 
> *shrug*  My attention span is tiny and my fonts are gigantic.
> 
> Perhaps using:
> 
>   DIFF_HIGHLIGHT="$CURR_DIR"/../diff-highlight
> 
> Would be more-readable?

good, done.

> 
> > +
> > +  diff diff.exp diff.act
> 
> Maybe use test_cmp to avoid depending external diff.
> (or "git diff -b --no-index" in your later test)
> 
> Same comments for the rest of the series, I think.
> 
> Typically, we expect a reroll in a few days, and I guess there's
> no rush (so you can squash your comment patch in addressing
> Junio's concern into 3/3).
>