Re: [PATCH v2] difftool: add support for --trust-exit-code
Am 26.10.2014 um 02:38 schrieb David Aguilar:
> diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
> index 7ef36b9..fdbd768 100755
> --- a/git-difftool--helper.sh
> +++ b/git-difftool--helper.sh
> @@ -62,6 +62,8 @@ launch_merge_tool () {
> else
> run_merge_tool "$merge_tool"
> fi
> + status=$?
> + return $status
> }
>
> if ! use_ext_cmd
> @@ -85,5 +87,10 @@ else
> do
> launch_merge_tool "$1" "$2" "$5"
> shift 7
> + if test "$status" != 0 &&
> + test "$GIT_DIFFTOOL_TRUST_EXIT_CODE" = true
> + then
> + exit $status
> + fi
If you insert this new code block before the 'shift 7', you can set
status here and do not have to hide it in the helper function.
> done
> fi
-- Hannes
--
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
difftool--helper: exit when reading a prompt answer fails
An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does
not quit it, but is treated as if 'yes' was answered to the prompt and
all following prompts, which is contrary to the user's intent. Fix the
error check.
Signed-off-by: Johannes Sixt
---
Found while reviewing your latest patch.
I chose the 'foo || return' idiom for the error check, but left the
'if' for the interesting check, because I feel it is more readable
than 'test ... && return'.
-- Hannes
git-difftool--helper.sh | 3 ++-
t/t7800-difftool.sh | 8
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 7ef36b9..aca0413 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -49,7 +49,8 @@ launch_merge_tool () {
else
printf "Launch '%s' [Y/n]: " "$merge_tool"
fi
- if read ans && test "$ans" = n
+ read ans || return
+ if test "$ans" = n
then
return
fi
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index dc30a51..9cf5dc9 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -301,6 +301,14 @@ test_expect_success PERL 'say no to the second file' '
! grep br2 output
'
+test_expect_success PERL 'ending prompt input with EOF' '
+ git difftool -x cat branch output &&
+ ! grep master output &&
+ ! grep branch output &&
+ ! grep m2 output &&
+ ! grep br2 output
+'
+
test_expect_success PERL 'difftool --tool-help' '
git difftool --tool-help >output &&
grep tool output
--
2.0.0.12.gbcf935e
--
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: Feature Proposal: Track all branches from a given remote
Hi Brian: > [remote "origin"] > fetch = refs/heads/*:refs/heads/* Yes, you're right, this works just fine as long as I move out from a branch that's not in the remote in question, for example by doing: git checkout -b nothing git fetch - OR - git pull Do you think there would be any interest in a patch that added this as a simple command line option, though? I guess the idea of this patch then would simply change this line in the .git/config file for the length of the operation (and specified remote), execute the git pull command, and then reset the configuration after the command finished. (There really wouldn't be a need to affect the configuration on the filesystem - simply the effective configuration used while git is running for this operation). Thanks, ~Scott -- 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: Feature Proposal: Track all branches from a given remote
Scott Johnson writes: > Do you think there would be any interest in a patch that added this as > a simple command line option, though? I guess the idea of this patch > then would simply change this line in the .git/config file for the > length of the operation (and specified remote), execute the git pull > command, and then reset the configuration after the command finished. There is no need to modify the configuration, you can pass the fetch spec on the command line. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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: flatten-merge history
Am 26.10.2014 um 06:46 schrieb Christian Couder: Hi,Could you tell us why interactive rebase did not work? First of all i have to admit that i did not i-rebase-merge, but i-rebase-cherrypick. Now i tried it with i-rebase-merge and it didn't work either. Here's my workflow, which i repeated for all commits of 'extern' (in chronological order'). For simplicity let's assume that there is a parent commit for 'A' 1. For P, A is the nearest prior commit on 'master' 2. on master: git rebase -i A^ 3. change A from pick to edit. save. quit 4. git merge P 5. git rebase --continue From the perspective of 'master' this worked. But as all of the commits have been rewritten, the branches b1 and b2 no longer refer to 'master'. Branch b2, for example, still branches off at B and not B'. So after this action, my history looks like this: P - - - Q - - - - - R <-extern \ A'- m - B'- - - C'- D'- - - E' <-master A - - - B - - - C - D \ \ M ... \ <-b1 \ W ... <-b2 A and A' are nearly the same: they only differ in the new GIT_COMITTER_DATE. Now this is what i try to get (after only applying P): P - - - Q - - - - - R <-extern \ A'- m - B'- - - C'- D'- - - E' <-master \ \ M'... \ <-b1 \ W'... <-b2 Regards Henning -- 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: flatten-merge history
Henning Moll writes: > 1. For P, A is the nearest prior commit on 'master' > 2. on master: git rebase -i A^ > 3. change A from pick to edit. save. quit > 4. git merge P > 5. git rebase --continue > > From the perspective of 'master' this worked. But as all of the commits > have been rewritten, the branches b1 and b2 no longer refer to > 'master'. Branch b2, for example, still branches off at B and not B'. You only rebased master, so b1 and b2 were unchanged. If you want to change b1 and b2 you have to rebase them as well. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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] fetch-pack: don't resend known-common refs in find_common
On Wed, Oct 22, 2014 at 10:11:40AM -0700, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote: > >> Dennis Kaarsemaker writes: > >> > >> > By not clearing the request buffer in stateless-rpc mode, fetch-pack > >> > would keep sending already known-common commits, leading to ever bigger > >> > http requests, eventually getting too large for git-http-backend to > >> > handle properly without filling up the pipe buffer in inflate_request. > >> > --- > >> > I'm still not quite sure whether this is the right thing to do, but make > >> > test still passes :) The new testcase demonstrates the problem, when > >> > running t5551 with EXPENSIVE, this test will hang without the patch to > >> > fetch-pack.c and succeed otherwise. > >> > >> IIUC, because "stateless" is just that, i.e. the server-end does not > >> keep track of what is already known, not telling what is known to be > >> common in each request would fundamentally break the protocol. Am I > >> mistaken? > > > > That sounds plausible, but why then does the fetch complete with this > > line removed, and why does 'make test' still pass? > > The fetch-pack program tries to help the upload-pack program(s) > running on the other end find what nodes in the graph both > repositories have in common by sending what the repository on its > end has. Some commits may not be known by the other side (e.g. your > new commits that haven't been pushed there that are made on a branch > forked from the common history), and some others may be known > (i.e. you drilled down the history from the tips of your refs and > reached a commit that you fetched from the common history > previously). The latter are ACKed by the upload-pack process and > are remembered to be re-sent to the _next_ incarnation of the > upload-pack process when stateless RPC is in use. > > With your patch, you stop telling the upload-pack process what these > two programs already found to be common in their exchange. After > the first exchange, fetch-pack and upload-pack may have noticed that > both ends have version 2.0, but because you do not convey that fact > to the other side, the new incarnation of upload-pack may end up > deciding that the version 1.9 is the newest common commit between > the two, and sending commits between 1.9 and 2.0. > > If you imagine an extreme case, it would be easy to see why "the > fetch completes" and "make test passes" are not sufficient to say > anything about this change. Even if you break the protocol in in a > way different from your patch, by not sending any "have", such a > butchered "fetch-pack" will become "fetch everything from scratch", > aka "clone". The end result will still have correct history and > "fetch completes" would be true. > > But I'd prefer deferring a more detailed analysis/explanation to > Shawn, as stateless RPC is his creation. Thanks for the explanation, that makes it quite clear that this approach is wrong. The patch below (apologies for the formatting, I'm not quite sure how to use format-patch in this situation) does it differently: by buffering upload-pack's output until it has read all the input, the new test still succeeds and again 'make test' passes. --- t/t5551-http-fetch-smart.sh | 32 upload-pack.c | 29 +++-- 2 files changed, 51 insertions(+), 10 deletions(-) diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index 6cbc12d..2aac237 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -245,5 +245,37 @@ test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command lin ) ' +test_expect_success EXPENSIVE 'create 50,000 more tags' ' + ( + cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && + for i in `test_seq 50001 10` + do + echo "commit refs/heads/too-many-refs-again" + echo "mark :$i" + echo "committer git $i +" + echo "data 0" + echo "M 644 inline bla.txt" + echo "data 4" + echo "bla" + # make every commit dangling by always + # rewinding the branch after each commit + echo "reset refs/heads/too-many-refs-again" + echo "from :50001" + done | git fast-import --export-marks=marks && + + # now assign tags to all the dangling commits we created above + tag=$(perl -e "print \"bla\" x 30") && + sed -e "s|^:\([^ ]*\) \(.*\)$|\2 refs/tags/$tag-\1|" >packed-refs + ) +' + +test_expect_success EXPENSIVE 'fetch the new tags' ' + ( + cd too-many-refs && + git fetch --tags && + test $(git for-each-ref refs/tags | wc -l) = 10 + ) +' + stop_httpd test_done diff --git a/upload-pack.c b/upload-pack.c index ac9ac15..3d76750 100644 --- a/upload-pack.c +++ b/upload-pack.c
Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
On Wed, Oct 22, 2014 at 05:07:31PM +0700, Duy Nguyen wrote: > On Wed, Oct 22, 2014 at 2:41 PM, Dennis Kaarsemaker > wrote: > > I see two options: > > > > * Turning that interaction into a more cooperative process, with a > > select/poll loop > > * Make upload-pack buffer its entire response when run in stateless_rpc > > mode until it has consumed all of the request > > Or add a helper daemon and support stateful smart http. Or maybe > that's what you meant in the first option. No, I meant that get-http-backend should have a select/poll loop that can read from and write to git-upload-pack at the same time, but option two was easier to implement :) Stateful smart http seems to be against the design goals of smart http if I interpret Documentation/technical/http-protocol.txt correctly though, so that doesn't seem to be the right approach. -- Dennis Kaarsemaker http://twitter.com/seveas -- 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 1/3] git-compat-util.h: Support variadic macros with the XL C compiler
When the XL C compiler is run with an appropriate language level or suboption, it defines a feature test macro to indicate support for variadic macros. This was tested on z/OS, but it should also work on AIX according to IBM documentation. Signed-off-by: David Michael --- git-compat-util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index 2107127..b31cfdd 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -778,7 +778,7 @@ void git_qsort(void *base, size_t nmemb, size_t size, #endif #endif -#if defined(__GNUC__) || (_MSC_VER >= 1400) +#if defined(__GNUC__) || (_MSC_VER >= 1400) || defined(__C99_MACRO_WITH_VA_ARGS) #define HAVE_VARIADIC_MACROS 1 #endif -- 1.9.3 -- 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 2/3] Makefile: Reorder linker flags in the git executable rule
The XL C compiler can fail due to mixing library path and object file arguments, for example when linking git while building with "gmake LDFLAGS=-L$prefix/lib". This moves the ALL_LDFLAGS variable expansion in the git executable rule to be consistent with all the other linking rules. Signed-off-by: David Michael --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index fcd51ac..827006b 100644 --- a/Makefile +++ b/Makefile @@ -1610,8 +1610,8 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \ '-DGIT_INFO_PATH="$(infodir_relative_SQ)"' git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS) - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \ - $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS) + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) git.o \ + $(BUILTIN_OBJS) $(LIBS) help.sp help.s help.o: common-cmds.h -- 1.9.3 -- 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 3/3] compat/bswap.h: Detect endianness from XL C compiler macros
There is no /usr/include/endian.h equivalent on z/OS, but the compiler will define macros to indicate endianness on host and target hardware. This adds a test for these macros as a last resort for determining byte order. Signed-off-by: David Michael --- compat/bswap.h | 4 1 file changed, 4 insertions(+) diff --git a/compat/bswap.h b/compat/bswap.h index f6fd9a6..7fed637 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -122,6 +122,10 @@ static inline uint64_t git_bswap64(uint64_t x) # define GIT_BYTE_ORDER GIT_BIG_ENDIAN # elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN) # define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN +# elif defined(__THW_BIG_ENDIAN__) && !defined(__THW_LITTLE_ENDIAN__) +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN +# elif defined(__THW_LITTLE_ENDIAN__) && !defined(__THW_BIG_ENDIAN__) +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN # else # error "Cannot determine endianness" # endif -- 1.9.3 -- 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 2/3] Makefile: Reorder linker flags in the git executable rule
On Sun, Oct 26, 2014 at 1:33 PM, David Michael wrote: > The XL C compiler can fail due to mixing library path and object Can you explain in the commit message the actual nature of the failure so that readers can understand more precisely how this change helps? > file arguments, for example when linking git while building with > "gmake LDFLAGS=-L$prefix/lib". This moves the ALL_LDFLAGS variable > expansion in the git executable rule to be consistent with all the > other linking rules. > > Signed-off-by: David Michael > --- > Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index fcd51ac..827006b 100644 > --- a/Makefile > +++ b/Makefile > @@ -1610,8 +1610,8 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \ > '-DGIT_INFO_PATH="$(infodir_relative_SQ)"' > > git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS) > - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \ > - $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS) > + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) git.o \ > + $(BUILTIN_OBJS) $(LIBS) > > help.sp help.s help.o: common-cmds.h > > -- > 1.9.3 -- 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] grep: fix match highlighting for combined patterns with context lines
Am 21.10.2014 um 07:56 schrieb Zoltan Klinger: When git grep is run with combined patterns such as '-e p1 --and -e p2' and surrounding context lines are requested, the output contains incorrectly highlighted matches. Consider the following output (highlighted matches are surrounded by '*' characters): $ cat testfile foo a foo b foo bar baz bar foo bar x bar y $ git grep -n -C2 -e foo --and -e bar testfile testfile-1-*foo* a testfile-2-*foo* b testfile:3:*foo* *bar* testfile:4:baz *bar* *foo* testfile-5-*bar* x testfile-6-*bar* y Lines 1, 2, 5 and 6 do not match the combined patterns, they only contain incorrectly highlighted 'false positives'. The old code highlights all search terms, anywhere. I wouldn't call the ones in the context lines false positives. The user might be interested in those occurrences as well (I know I am ;). GNU grep allows coloring to be configured in much greater detail with its GREP_COLORS variable. I didn't think that level of tuning is desirable until now. What your patch does is equivalent to change the default of "ms=01;31:mc=01;31" (color matching string in selected lines and context lines) to "ms=01;31:mc=" (color matching string in selected lines). The difference is only visible with -v or git grep's --not and --and. So, if you really don't want matching string in context lines to be colored, perhaps it's time to add a color.grep.contextmatch for matching text in context lines? René -- 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 2/3] Makefile: Reorder linker flags in the git executable rule
On Sun, Oct 26, 2014 at 01:45:10PM -0400, Eric Sunshine wrote: > On Sun, Oct 26, 2014 at 1:33 PM, David Michael wrote: > > The XL C compiler can fail due to mixing library path and object > > Can you explain in the commit message the actual nature of the failure > so that readers can understand more precisely how this change helps? Based on past experience, it is probably "the compiler complains and refuses to run" (or optionally "the compiler silently ignores your LDFLAGS" depending on how irritating it wants to be). But it would not hurt to be specific. Either way, the patch looks good; the whole point of LDFLAGS versus LIBS is to make this distinction in command-line positioning. -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 3/3] compat/bswap.h: Detect endianness from XL C compiler macros
On Sun, Oct 26, 2014 at 01:34:26PM -0400, David Michael wrote: > diff --git a/compat/bswap.h b/compat/bswap.h > index f6fd9a6..7fed637 100644 > --- a/compat/bswap.h > +++ b/compat/bswap.h > @@ -122,6 +122,10 @@ static inline uint64_t git_bswap64(uint64_t x) > # define GIT_BYTE_ORDER GIT_BIG_ENDIAN > # elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN) > # define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN > +# elif defined(__THW_BIG_ENDIAN__) && !defined(__THW_LITTLE_ENDIAN__) > +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN > +# elif defined(__THW_LITTLE_ENDIAN__) && !defined(__THW_BIG_ENDIAN__) > +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN Out of curiosity, is there ever a case where _both_ are defined? That is, would: diff --git a/compat/bswap.h b/compat/bswap.h index f6fd9a6..b78a0bd 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -122,6 +122,10 @@ static inline uint64_t git_bswap64(uint64_t x) # define GIT_BYTE_ORDER GIT_BIG_ENDIAN # elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN) # define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN +# elif defined(__THW_BIG_ENDIAN__) +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN +# elif defined(__THW_LITTLE_ENDIAN__) +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN # else # error "Cannot determine endianness" # endif be enough, or is that used to mark some other special case? Even if not, there is not much downside to the more thorough conditions you put above, but as a reviewer I wondered if there is something else going on. -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 2/3] Makefile: Reorder linker flags in the git executable rule
On Sun, Oct 26, 2014 at 2:35 PM, Jeff King wrote: > On Sun, Oct 26, 2014 at 01:45:10PM -0400, Eric Sunshine wrote: > >> On Sun, Oct 26, 2014 at 1:33 PM, David Michael wrote: >> > The XL C compiler can fail due to mixing library path and object >> >> Can you explain in the commit message the actual nature of the failure >> so that readers can understand more precisely how this change helps? > > Based on past experience, it is probably "the compiler complains and > refuses to run" (or optionally "the compiler silently ignores your > LDFLAGS" depending on how irritating it wants to be). But it would not > hurt to be specific. Yes, the compiler refuses to run by default when a "-L" option occurs after a source/object file. It tries to interpret it as another file name and fails. I believe I can work around the error with an "export _C89_CCMODE=1", but I thought I'd send the patch since this is the only occurrence of the problem, and the argument order is inconsistent with other linker commands in the file. IBM documentation has this to say on the noted environment variable: "The default behavior of the c89/cc/c++ command is to expect all options to precede all operands. Setting this variable allows compatibility with historical implementations (other cc commands). When set to 1, the c89/cc/c++ command operates as follows: Options and operands can be interspersed. [...]" Do you want me to resend the patch and reference the IBM documentation in the message? Thanks. David -- 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] merge & sequencer: turn "Conflicts:" hint into a comment
On Fri, Oct 24, 2014 at 02:24:37PM -0700, Junio C Hamano wrote:
> Just like other hints such as "Change to be committed" we show in
> the editor to remind the committer what paths were involved in the
> resulting commit to improve their log message, this section is
> merely a reminder. Traditionally, it was not made into comments
> primarily because it has to be generated outside wt-status
> infrastructure, and secondary it was meant as a bit stronger
> reminder than the rest (i.e. explaining how you resolved conflicts
> is much more important than mentioning what you did to every paths
> involved in the commit), but that still does not make this hint a
> hint, which should be commented out by default.
Yay. I like this new behavior much better.
Just to play devil's advocate for a moment, though, are we hurting
people who find it useful to record that information in the commit
message?
For the most part, combined-diff (and --cc) will show the interesting
cases anyway. But if you take a whole file from one side of the merge,
then there is nothing interesting for diff to show. Do people still want
to get that more complete list of potentially interesting files? And if
so, how do they do it? I think there really isn't a great way besides
repeating the merge.
If that is the only casualty, I think it is probably a net-win. We may
want better tooling around viewing the merge later, but that can wait
until somebody steps up with a real use case (because even that conflict
list may not be completely what they want; they may also want the list
of files that were auto-merged successfully, for example). And I think
there was work recently on a diff view for merge commits that involved
recreating the merge (I do not remember the details, though).
> diff --git a/sequencer.c b/sequencer.c
> index 0f84bbe..1d97da3 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -291,13 +291,12 @@ void append_conflicts_hint(struct strbuf *msgbuf)
> {
> int i;
>
> - strbuf_addstr(msgbuf, "\nConflicts:\n");
> + strbuf_addch(msgbuf, '\n');
> + strbuf_commented_addf(msgbuf, "Conflicts:\n");
> for (i = 0; i < active_nr;) {
> const struct cache_entry *ce = active_cache[i++];
> if (ce_stage(ce)) {
> - strbuf_addch(msgbuf, '\t');
> - strbuf_addstr(msgbuf, ce->name);
> - strbuf_addch(msgbuf, '\n');
> + strbuf_commented_addf(msgbuf, "\t%s\n", ce->name);
This ends up adding a space followed by a tab. Besides being redundant,
it makes my editor highlight it as a whitespace error. I realize this is
a pretty minor nit, though.
-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: Sources for 3.18-rc1 not uploaded
Am 23.10.2014 um 03:09 schrieb brian m. carlson: On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote: Junio C Hamano schrieb am 21.10.2014 um 20:14: Michael J Gruber writes: Unfortunately, the git archive doc clearly says that the umask is applied to all archive entries. Is an extended pax header "an archive entry"? I doubt it, and the above is not relevant. The mode bits for the archive entry that it applies to does not come from there. The problem seem to be old tar versions which mis-take the extensions for archive entries, aren't they? Yes. POSIX isn't clear on how unknown entries are to be handled. I've seen some Windows tar implementations extract GNU longlink extensions as files, which leads to a lot of pain. That's by design -- extended headers are meant to be extracted as plain files by implementations that do not understand them. http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html says: "If a particular implementation does not recognize the type, or the user does not have appropriate privilege to create that type, the file shall be extracted as if it were a regular file if the file type is defined to have a meaning for the size field that could cause data logical records to be written on the medium [...]." My question to Brian still stands which existing users he was trying to cater for with his patch. If there indeed are no existing affected users besides the KUP users (as you seem to assume) it's a clear case. Pun intended ;) The pax format is an extension of the tar format. All of the pax implementations I've seen on Linux (OpenBSD's and MirBSD's) don't actually understand the pax headers and emit them as files. 7zip does as well. I expect there are other Unix systems where tar itself doesn't understand pax headers, although I don't have access to anything other than Linux and FreeBSD. NetBSD's tar does as well. It's surprising and sad to see *pax* implementations not supporting pax extended headers in 2014, though. It seems long file names etc. are not common enough. Or perhaps pax is simply not used that much. Since it's very common to extract tar archives in /tmp, I didn't want to leave world-writable files in /tmp (or anywhere else someone might get to them). While the contents probably aren't sensitive, a malicious user might fill someone's quota by "helpfully" appending /dev/zero to the file. And yes, users do these things. The extracted files are only world-writable if umask & 2 == 0 or if -p (preserve permissions) has been used, no? René -- 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: flatten-merge history
On Sun, Oct 26, 2014 at 4:19 PM, Andreas Schwab wrote: > Henning Moll writes: > >> 1. For P, A is the nearest prior commit on 'master' >> 2. on master: git rebase -i A^ >> 3. change A from pick to edit. save. quit >> 4. git merge P >> 5. git rebase --continue >> >> From the perspective of 'master' this worked. But as all of the commits >> have been rewritten, the branches b1 and b2 no longer refer to >> 'master'. Branch b2, for example, still branches off at B and not B'. > > You only rebased master, so b1 and b2 were unchanged. If you want to > change b1 and b2 you have to rebase them as well. Yeah. Henning, when interactively rebasing, in our editor, you should have something like: pick A pick P pick B pick Q pick C pick D pick R pick E which should work without any conflict. And then you can rebase the b1 and b2 branches on the resulting branch. Best, Christian. -- 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 3/3] compat/bswap.h: Detect endianness from XL C compiler macros
On Sun, Oct 26, 2014 at 2:38 PM, Jeff King wrote: > On Sun, Oct 26, 2014 at 01:34:26PM -0400, David Michael wrote: > >> diff --git a/compat/bswap.h b/compat/bswap.h >> index f6fd9a6..7fed637 100644 >> --- a/compat/bswap.h >> +++ b/compat/bswap.h >> @@ -122,6 +122,10 @@ static inline uint64_t git_bswap64(uint64_t x) >> # define GIT_BYTE_ORDER GIT_BIG_ENDIAN >> # elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN) >> # define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN >> +# elif defined(__THW_BIG_ENDIAN__) && !defined(__THW_LITTLE_ENDIAN__) >> +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN >> +# elif defined(__THW_LITTLE_ENDIAN__) && !defined(__THW_BIG_ENDIAN__) >> +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN > > Out of curiosity, is there ever a case where _both_ are defined? That > is, would: > > diff --git a/compat/bswap.h b/compat/bswap.h > index f6fd9a6..b78a0bd 100644 > --- a/compat/bswap.h > +++ b/compat/bswap.h > @@ -122,6 +122,10 @@ static inline uint64_t git_bswap64(uint64_t x) > # define GIT_BYTE_ORDER GIT_BIG_ENDIAN > # elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN) > # define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN > +# elif defined(__THW_BIG_ENDIAN__) > +# define GIT_BYTE_ORDER GIT_BIG_ENDIAN > +# elif defined(__THW_LITTLE_ENDIAN__) > +# define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN > # else > # error "Cannot determine endianness" > # endif > > be enough, or is that used to mark some other special case? Even if not, > there is not much downside to the more thorough conditions you put > above, but as a reviewer I wondered if there is something else going on. I'm not 100% sure if __THW_LITTLE_ENDIAN__ will ever be defined, so I'd be okay with dropping those references completely. There is a recent version of the compiler for little endian Linux distributions, but I haven't found the documentation for it. (The product documentation still seems to only refer to the big endian Linux version.) The compiler's macro may be redundant in this case anyway, since Linux systems should have supplying that information. I only used both macros for completeness; the __THW_BIG_ENDIAN__ macro (defined to 1 on z/OS and AIX) is what I actually needed here. z/OS doesn't seem to have any other compile-time byte order indicator, short of testing for the OS itself. Would you prefer the two-line patch to only test for the big endian macro, or maybe just test for __MVS__ to look at the OS? Thanks. David -- 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: Sources for 3.18-rc1 not uploaded
On Sun, Oct 26, 2014 at 07:59:55PM +0100, René Scharfe wrote: > Am 23.10.2014 um 03:09 schrieb brian m. carlson: > >The pax format is an extension of the tar format. All of the pax > >implementations I've seen on Linux (OpenBSD's and MirBSD's) don't > >actually understand the pax headers and emit them as files. 7zip does > >as well. I expect there are other Unix systems where tar itself doesn't > >understand pax headers, although I don't have access to anything other > >than Linux and FreeBSD. > > NetBSD's tar does as well. > > It's surprising and sad to see *pax* implementations not supporting pax > extended headers in 2014, though. It seems long file names etc. are not > common enough. Or perhaps pax is simply not used that much. The original pax utility didn't specify the pax format, only cpio and ustar. The pax format was first release in POSIX 1003.1-2001. > >Since it's very common to extract tar archives in /tmp, I didn't want to > >leave world-writable files in /tmp (or anywhere else someone might get > >to them). While the contents probably aren't sensitive, a malicious > >user might fill someone's quota by "helpfully" appending /dev/zero to > >the file. And yes, users do these things. > > The extracted files are only world-writable if umask & 2 == 0 or if -p > (preserve permissions) has been used, no? Yes, unless you're the superuser, in which case that's the default. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: flatten-merge history
Am 26.10.2014 um 20:02 schrieb Christian Couder: Yeah. Henning, when interactively rebasing, in our editor, you should have something like: pick A pick P pick B pick Q pick C pick D pick R pick E which should work without any conflict. And then you can rebase the b1 and b2 branches on the resulting branch. Thank you all very much. It worked! I didn't know that i could also introduce new commits in the interactive rebase list. Just for the record, in case others need to do such a task: intial situation: P - - - Q - - - - - R <-extern A - - - B - - - C - D - - - E <-master \ \ M ... \ <-b1 \ W ... <-b2 On master: $ git rebase -i --root (editor opens showing pick A pick B pick C pick D pick E modify this to pick A pick P pick B pick Q pick C pick D pick R pick E save, quit. Now, master is already fixed. Now fix the branches: $ git rebase --onto B' B b1 $ git rebase --onto D' D b2 Just a final question: Is it possible to keep the GIT_COMMITTER_DATE in all those rebases? Thanks again Henning -- 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 1/2] Documentation: refactor common operations into variables
The Makefile performs several very similar tasks to convert AsciiDoc files into either HTML or DocBook. Move these items into variables to reduce the duplication. Signed-off-by: brian m. carlson --- Documentation/Makefile | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 4cdef45..2f6b6aa 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -102,6 +102,10 @@ ASCIIDOC_EXTRA = ASCIIDOC_HTML = xhtml11 ASCIIDOC_DOCBOOK = docbook ASCIIDOC_CONF = -f asciidoc.conf +ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \ + -agit-version=$(GIT_VERSION) +TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML) +TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK) MANPAGE_XSL = manpage-normal.xsl XMLTO = xmlto XMLTO_EXTRA = @@ -309,14 +313,12 @@ clean: $(MAN_HTML): %.html : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b $(ASCIIDOC_HTML) -d manpage $(ASCIIDOC_CONF) \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -d manpage -o $@+ $< && \ mv $@+ $@ $(OBSOLETE_HTML): %.html : %.txto asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b $(ASCIIDOC_HTML) $(ASCIIDOC_CONF) \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -o $@+ $< && \ mv $@+ $@ manpage-base-url.xsl: manpage-base-url.xsl.in @@ -328,13 +330,12 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.xml : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b $(ASCIIDOC_DOCBOOK) -d manpage $(ASCIIDOC_CONF) \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_XML) -d manpage -o $@+ $< && \ mv $@+ $@ user-manual.xml: user-manual.txt user-manual.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b $(ASCIIDOC_DOCBOOK) -d article -o $@+ $< && \ + $(TXT_TO_XML) -d article -o $@+ $< && \ mv $@+ $@ technical/api-index.txt: technical/api-index-skel.txt \ @@ -343,8 +344,7 @@ technical/api-index.txt: technical/api-index-skel.txt \ technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ $(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt asciidoc.conf - $(QUIET_ASCIIDOC)$(ASCIIDOC) -b $(ASCIIDOC_HTML) $(ASCIIDOC_CONF) \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt + $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt XSLT = docbook.xsl XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css @@ -391,7 +391,7 @@ howto-index.txt: howto-index.sh $(wildcard howto/*.txt) mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b $(ASCIIDOC_HTML) $*.txt + $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt WEBDOC_DEST = /pub/software/scm/git/docs @@ -399,7 +399,7 @@ howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ sed -e '1,/^$$/d' $< | \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b $(ASCIIDOC_HTML) - >$@+ && \ + $(TXT_TO_HTML) - >$@+ && \ mv $@+ $@ install-webdoc : html -- 2.1.1 -- 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 2/2] Documentation: remove Asciidoctor linkgit macro
Asciidoctor provides an extension implementing a backend-independent
macro for dealing with manpage links just like the linkgit macro. As
this is more likely to be up-to-date with future changes in Asciidoctor,
prefer using it over reimplementing in Git.
This reverts commit 773ee47c2b9c691d9758b2bea6cac10e3f0c4e12.
---
Documentation/extensions.rb | 39 ---
1 file changed, 39 deletions(-)
delete mode 100644 Documentation/extensions.rb
diff --git a/Documentation/extensions.rb b/Documentation/extensions.rb
deleted file mode 100644
index c33a50d..000
--- a/Documentation/extensions.rb
+++ /dev/null
@@ -1,39 +0,0 @@
-require 'asciidoctor'
-require 'asciidoctor/extensions'
-
-module Git
- module Documentation
-class LinkGitProcessor < Asciidoctor::Extensions::InlineMacroProcessor
- use_dsl
-
- named :chrome
-
- def process(parent, target, attrs)
-if parent.document.basebackend? 'html'
- generate_html(parent, target, attrs)
-elsif parent.document.basebackend? 'docbook'
- generate_docbook(parent, target, attrs)
-end
- end
-
- private
-
- def generate_html(parent, target, attrs)
-section = attrs.has_key?(1) ? "(#{attrs[1]})" : ''
-prefix = parent.document.attr('git-relative-html-prefix') || ''
-%(#{target}#{section}\n)
- end
-
- def generate_docbook(parent, target, attrs)
-%(
-#{target}#{attrs[1]}
-
-)
- end
-end
- end
-end
-
-Asciidoctor::Extensions.register do
- inline_macro Git::Documentation::LinkGitProcessor, :linkgit
-end
--
2.1.1
--
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 0/2] Followup patches for Asciidoctor
This series is essentially the same as the previous v2, but against next instead. It moves most of the AsciiDoc operations into a set of variables (TXT_TO_HTML and TXT_TO_XML) as Junio suggested, and removes the extensions.rb file, as it is not needed. I did note Peff's suggestion to add a macro to enable the use of Asciidoctor, but I want to defer that until a later point. There isn't a released version of Asciidoctor with the necessary changes and I'd like to avoid confusing users by making them think it will work when it probably won't. brian m. carlson (2): Documentation: refactor common operations into variables Documentation: remove Asciidoctor linkgit macro Documentation/Makefile | 22 +++--- Documentation/extensions.rb | 39 --- 2 files changed, 11 insertions(+), 50 deletions(-) delete mode 100644 Documentation/extensions.rb -- 2.1.1 -- 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: difftool--helper: exit when reading a prompt answer fails
On Sun, Oct 26, 2014 at 09:09:20AM +0100, Johannes Sixt wrote:
> An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does
> not quit it, but is treated as if 'yes' was answered to the prompt and
> all following prompts, which is contrary to the user's intent. Fix the
> error check.
>
> Signed-off-by: Johannes Sixt
> ---
> Found while reviewing your latest patch.
Thanks for the careful review.
I have one small question about the test below.
I'll base the reroll of my patch on top of this one so that
I'm including your new test while developing.
Junio, can you please queue this patch before my upcoming v3
patch when I reroll?
I also noticed that I forgot to "git reset --hard" after doing "git add"
in one of the tests I introduced so I'll be adjusting that as well in v3.
> I chose the 'foo || return' idiom for the error check, but left the
> 'if' for the interesting check, because I feel it is more readable
> than 'test ... && return'.
>
> -- Hannes
>
> git-difftool--helper.sh | 3 ++-
> t/t7800-difftool.sh | 8
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
> index 7ef36b9..aca0413 100755
> --- a/git-difftool--helper.sh
> +++ b/git-difftool--helper.sh
> @@ -49,7 +49,8 @@ launch_merge_tool () {
> else
> printf "Launch '%s' [Y/n]: " "$merge_tool"
> fi
> - if read ans && test "$ans" = n
> + read ans || return
> + if test "$ans" = n
> then
> return
> fi
> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
> index dc30a51..9cf5dc9 100755
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -301,6 +301,14 @@ test_expect_success PERL 'say no to the second file' '
> ! grep br2 output
> '
>
> +test_expect_success PERL 'ending prompt input with EOF' '
> + git difftool -x cat branch output &&
> + ! grep master output &&
> + ! grep branch output &&
> + ! grep m2 output &&
> + ! grep br2 output
> +'
Should we use "test_must_fail grep ..." instead of "! grep ..." here?
--
David
--
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
hello+
my name is ming yang,i work with Hang Seng Bank Ltd Hong Kong.i want you to be the next of kin of my late client late Gen. Aadel Akgaal, respond -- 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: difftool--helper: exit when reading a prompt answer fails
On Sun, Oct 26, 2014 at 05:41:49PM -0700, David Aguilar wrote: > On Sun, Oct 26, 2014 at 09:09:20AM +0100, Johannes Sixt wrote: > > An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does > > not quit it, but is treated as if 'yes' was answered to the prompt and > > all following prompts, which is contrary to the user's intent. Fix the > > error check. > > > > Signed-off-by: Johannes Sixt > > --- > > Found while reviewing your latest patch. > > > Thanks for the careful review. > I have one small question about the test below. [snip] > > diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh > > index dc30a51..9cf5dc9 100755 > > --- a/t/t7800-difftool.sh > > +++ b/t/t7800-difftool.sh > > @@ -301,6 +301,14 @@ test_expect_success PERL 'say no to the second file' ' > > ! grep br2 output > > ' > > > > +test_expect_success PERL 'ending prompt input with EOF' ' > > + git difftool -x cat branch output && > > + ! grep master output && > > + ! grep branch output && > > + ! grep m2 output && > > + ! grep br2 output > > +' > > Should we use "test_must_fail grep ..." instead of "! grep ..." here? Nevermind, this is good as-is. Using "! grep" is consistent with the rest of the tests in t7800. What I'll do is add a follow-up patch in my upcoming reroll that swaps all the "! grep" lines to "test_must_fail grep" in one step. -- David -- 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 v3 1/2] t7800-difftool: use "test_must_fail grep" instead of "! grep"
Signed-off-by: David Aguilar --- This patch is new since v2. This series now depends on "difftool--helper: exit when reading a prompt answer fails". t/t7800-difftool.sh | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh index 9cf5dc9..b5b7f62 100755 --- a/t/t7800-difftool.sh +++ b/t/t7800-difftool.sh @@ -288,8 +288,8 @@ test_expect_success PERL 'say no to the first file' ' git difftool -x cat branch output && grep m2 output && grep br2 output && - ! grep master output && - ! grep branch output + test_must_fail grep master output && + test_must_fail grep branch output ' test_expect_success PERL 'say no to the second file' ' @@ -297,16 +297,16 @@ test_expect_success PERL 'say no to the second file' ' git difftool -x cat branch output && grep master output && grep branch output && - ! grep m2 output && - ! grep br2 output + test_must_fail grep m2 output && + test_must_fail grep br2 output ' test_expect_success PERL 'ending prompt input with EOF' ' git difftool -x cat branch output && - ! grep master output && - ! grep branch output && - ! grep m2 output && - ! grep br2 output + test_must_fail grep master output && + test_must_fail grep branch output && + test_must_fail grep m2 output && + test_must_fail grep br2 output ' test_expect_success PERL 'difftool --tool-help' ' -- 2.1.2.557.g1025af0 -- 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 v3 2/2] difftool: add support for --trust-exit-code
Teach difftool to exit when a diff tool returns a non-zero exit
code when either --trust-exit-code is specified or
difftool.trustExitCode is true.
Forward exit codes from invoked diff tools to the caller when
--trust-exit-code is used.
Suggested-by: Adri Farr <14farr...@gmail.com>
Helped-by: Johannes Sixt
Signed-off-by: David Aguilar
---
Changes since v2:
This series now depends on "difftool--helper: exit when reading a prompt answer
fails".
A missing "git reset -- for-diff" was missing from the test.
Setting and testing of the status variable was moved to be
before "shift 7" to make things more cohesive; status setting
was previously buried inside the launch_merge_tool function,
which made it harder to follow.
Documentation/git-difftool.txt | 14 ++
git-difftool--helper.sh| 6 ++
git-difftool.perl | 12
t/t7800-difftool.sh| 44 ++
4 files changed, 76 insertions(+)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 11887e6..333cf6f 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -91,6 +91,15 @@ instead. `--no-symlinks` is the default on Windows.
the default diff tool will be read from the configured
`diff.guitool` variable instead of `diff.tool`.
+--[no-]trust-exit-code::
+ 'git-difftool' invokes a diff tool individually on each file.
+ Errors reported by the diff tool are ignored by default.
+ Use `--trust-exit-code` to make 'git-difftool' exit when an
+ invoked diff tool returns a non-zero exit code.
++
+'git-difftool' will forward the exit code of the invoked tool when
+'--trust-exit-code' is used.
+
See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
@@ -116,6 +125,11 @@ See the `--tool=` option above for more details.
difftool.prompt::
Prompt before each invocation of the diff tool.
+difftool.trustExitCode::
+ Exit difftool if the invoked diff tool returns a non-zero exit status.
++
+See the `--trust-exit-code` option above for more details.
+
SEE ALSO
linkgit:git-diff[1]::
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index aca0413..d4fb6df 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -85,6 +85,12 @@ else
while test $# -gt 6
do
launch_merge_tool "$1" "$2" "$5"
+ status=$?
+ if test "$status" != 0 &&
+ test "$GIT_DIFFTOOL_TRUST_EXIT_CODE" = true
+ then
+ exit $status
+ fi
shift 7
done
fi
diff --git a/git-difftool.perl b/git-difftool.perl
index 598fcc2..7df7c8a 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -342,6 +342,7 @@ sub main
symlinks => $^O ne 'cygwin' &&
$^O ne 'MSWin32' && $^O ne 'msys',
tool_help => undef,
+ trust_exit_code => undef,
);
GetOptions('g|gui!' => \$opts{gui},
'd|dir-diff' => \$opts{dirdiff},
@@ -352,6 +353,8 @@ sub main
'no-symlinks' => sub { $opts{symlinks} = 0; },
't|tool:s' => \$opts{difftool_cmd},
'tool-help' => \$opts{tool_help},
+ 'trust-exit-code' => \$opts{trust_exit_code},
+ 'no-trust-exit-code' => sub { $opts{trust_exit_code} = 0; },
'x|extcmd:s' => \$opts{extcmd});
if (defined($opts{help})) {
@@ -383,6 +386,15 @@ sub main
}
}
+ if (!defined $opts{trust_exit_code}) {
+ $opts{trust_exit_code} =
Git::config_bool('difftool.trustExitCode');
+ }
+ if ($opts{trust_exit_code}) {
+ $ENV{GIT_DIFFTOOL_TRUST_EXIT_CODE} = 'true';
+ } else {
+ $ENV{GIT_DIFFTOOL_TRUST_EXIT_CODE} = 'false';
+ }
+
# In directory diff mode, 'git-difftool--helper' is called once
# to compare the a/b directories. In file diff mode, 'git diff'
# will invoke a separate instance of 'git-difftool--helper' for
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index b5b7f62..7de18dd 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -76,6 +76,50 @@ test_expect_success PERL 'difftool forwards arguments to
diff' '
rm for-diff
'
+test_expect_success PERL 'difftool ignores exit code' '
+ test_config difftool.error.cmd false &&
+ git difftool -y -t error branch
+'
+
+test_expect_success PERL 'difftool forwards exit code with --trust-exit-code' '
+ test_config difftool.error.cmd false &&
+ test_must_fail git difftool -y --trust-exit-code -t error branch
+'
+
+test_expect_success PERL 'difftool honors difftool.trustExitCode = true' '
+ test_config difftool.error.cmd false &&
+ test_config difftool.trustExitCode true &&
+ test_must_
[PATCH] git-svn: disable _rev_list memoization
This memoization appears unneeded as the check_cherry_pick2 cache is
in front of it does enough.
With this change applied, importing from local svn+ssh and http copies
of the R repo[1] takes only 2:00 (2 hours) on my system and the git-svn
process never uses more than 60MB RSS on my x86-64 GNU/Linux system[2].
This 60M measurement is only for the git-svn Perl process itself and
does not include memory used by git subprocesses accessing large packs
(subprocess memory usage _is_ measured by my time(1) tool).
Before this change, an import took longer (2:20) on svn+ssh:// but
git-svn used around 240MB during the imports. Worse yet, git-svn
ballooned to over 400M when writing out the cache to the filesystem.
I also tried removing memoization for `has_no_changes', too, but a
local copy of the R repository(*) was not close to finishing within
10 hours on my system.
[1] http://svn.r-project.org/R
[2] file:// repos causes libsvn to use more memory internally
Signed-off-by: Eric Wong
Cc: Hin-Tak Leung
---
This patch is in my "less-memo" branch of bogomips.org/git-svn.git
Info here:
(not intended as a pull request for Junio, yet)
The following changes since commit fbecd99861ea5795aeba46faf2ac7a8c1b70d485:
Update draft release notes to 2.2 (2014-10-24 15:02:17 -0700)
are available in the git repository at:
git://bogomips.org/git-svn.git less-memo
for you to fetch changes up to 7676aff70973e617c3f58a8633db6d0e3ee99e45:
git-svn: disable _rev_list memoization (2014-10-27 01:39:39 +)
Eric Wong (7):
git-svn: reduce check_cherry_pick cache overhead
git-svn: cache only mergeinfo revisions
git-svn: remove mergeinfo rev caching
git-svn: reload RA every log-window-size
git-svn: remove unnecessary DESTROY override
git-svn: save a little memory as fetch progresses
git-svn: disable _rev_list memoization
Jakob Stoklund Olesen (2):
git-svn: only look at the new parts of svn:mergeinfo
git-svn: only look at the root path for svn:mergeinfo
Sveinung Kvilhaugsvik (1):
git-svn.txt: advertise pushurl with dcommit
Documentation/git-svn.txt | 4 ++
perl/Git/SVN.pm | 121
+-
perl/Git/SVN/Ra.pm| 27 ++-
3 files changed, 94 insertions(+), 58 deletions(-)
perl/Git/SVN.pm | 10 --
1 file changed, 10 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 4364506..5f9d469 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1600,7 +1600,6 @@ sub tie_for_persistent_memoization {
my %lookup_svn_merge_cache;
my %check_cherry_pick2_cache;
my %has_no_changes_cache;
- my %_rev_list_cache;
tie_for_persistent_memoization(\%lookup_svn_merge_cache,
"$cache_path/lookup_svn_merge");
@@ -1622,14 +1621,6 @@ sub tie_for_persistent_memoization {
SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
LIST_CACHE => 'FAULT',
;
-
- tie_for_persistent_memoization(\%_rev_list_cache,
- "$cache_path/_rev_list");
- memoize '_rev_list',
- SCALAR_CACHE => 'FAULT',
- LIST_CACHE => ['HASH' => \%_rev_list_cache],
- ;
-
}
sub unmemoize_svn_mergeinfo_functions {
@@ -1639,7 +1630,6 @@ sub tie_for_persistent_memoization {
Memoize::unmemoize 'lookup_svn_merge';
Memoize::unmemoize 'check_cherry_pick2';
Memoize::unmemoize 'has_no_changes';
- Memoize::unmemoize '_rev_list';
}
sub clear_memoized_mergeinfo_caches {
--
EW
--
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 0/2] Followup patches for Asciidoctor
On Mon, Oct 27, 2014 at 12:13:41AM +, brian m. carlson wrote: > I did note Peff's suggestion to add a macro to enable the use of > Asciidoctor, but I want to defer that until a later point. There isn't > a released version of Asciidoctor with the necessary changes and I'd > like to avoid confusing users by making them think it will work when it > probably won't. Thanks for considering it; your analysis makes sense to me. -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 3/3] compat/bswap.h: Detect endianness from XL C compiler macros
On Sun, Oct 26, 2014 at 04:04:01PM -0400, David Michael wrote: > I'm not 100% sure if __THW_LITTLE_ENDIAN__ will ever be defined, so > I'd be okay with dropping those references completely. There is a > recent version of the compiler for little endian Linux distributions, > but I haven't found the documentation for it. (The product > documentation still seems to only refer to the big endian Linux > version.) The compiler's macro may be redundant in this case anyway, > since Linux systems should have supplying that > information. > > I only used both macros for completeness; the __THW_BIG_ENDIAN__ macro > (defined to 1 on z/OS and AIX) is what I actually needed here. z/OS > doesn't seem to have any other compile-time byte order indicator, > short of testing for the OS itself. Thanks for the explanation. > Would you prefer the two-line patch to only test for the big endian > macro, I think that's OK, as long as the #else case barfs as it does now (i.e., doesn't silently choose little-endian). > or maybe just test for __MVS__ to look at the OS? If the OS's you're testing on all provide a big-endian marker like __THW_BIG_ENDIAN__, that seems preferable to me to use, as it's more explicit. We can deal with similar little-endian systems if and when somebody sees one in the wild (and your explanation that it would probably hit the Linux check first makes sense to me). -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 2/3] Makefile: Reorder linker flags in the git executable rule
On Sun, Oct 26, 2014 at 02:54:56PM -0400, David Michael wrote: > Yes, the compiler refuses to run by default when a "-L" option occurs > after a source/object file. It tries to interpret it as another file > name and fails. Yeah, I think I have seen similar behavior before, but it has been long enough that I no longer remember the compiler in use. > I believe I can work around the error with an "export _C89_CCMODE=1", > but I thought I'd send the patch since this is the only occurrence of > the problem, and the argument order is inconsistent with other linker > commands in the file. I don't think working around it makes sense. That would fix your case, but nobody else's (though given how long it has been that way without complaints, I suspect any other compilers this picky may have died off). > Do you want me to resend the patch and reference the IBM documentation > in the message? I don't think you need to. More interesting than documentation is the real-world breakage you experienced and the analysis of the situation. I'd be fine taking the patch as-is, or if changing anything, mentioning the failure mode in the commit message. -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
Editing git changelog automatically
Hello, git experts Sorry if this is a question already answered, but google search didn't give me anything useful. My question is how to edit dozens of git commit changelogs automatically? Let's say I want to fix a stupid typo in all of these commits, as simply as s/foo/bar/. Usually I use`git rebase -i` and `git commit --amend`, but both of them are interactive, apparently I don't want to edit them one by one. :) I know I can change $EDITOR to something like `sed -e 's/foo/bar/'`, but this seems pretty ugly. Is there a clean way to do that? Thanks! -- 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: Editing git changelog automatically
On zo, 2014-10-26 at 22:27 -0700, Cong Wang wrote: > > My question is how to edit dozens of git commit changelogs > automatically? You can use git filter-branch in --msg-filter mode. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
git ls-files -o seems to ignore .gitignore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm having an issue in that 'git ls-files -o' seems to ignore [parts of] .gitignore whereas other commands, such as 'git status' seem fine. Here is an example: > richard@omnis:/home/richard/src/pkgsrc$ export LANG=C > richard@omnis:/home/richard/src/pkgsrc$ git --version git version > 2.1.2 richard@omnis:/home/richard/src/pkgsrc$ cat .gitignore > pkgchk*.conf* .#* README*.html > richard@omnis:/home/richard/src/pkgsrc$ git status On branch dev > > It took 6.82 seconds to enumerate untracked files. 'status -uno' > may speed it up, but you have to be careful not to forget to add > new files yourself (see 'git help status'). nothing to commit, > working directory clean richard@omnis:/home/richard/src/pkgsrc$ git > ls-files -o |grep -c README 12393 Known issue? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUTeNRAAoJECAB22fHtp27hckH+wdDHV3oZqatSIqNdhUCUxsJ jR8tZpQxoKfV944aPBgH4/CXkCtFFSvnGKfH+plij+Y5ggZwfDQ3lXIg1qOsH3qj 9mvudRuFxwujXfFSTHdReqQxFT8p3roZjB0GdwoiFeBIsQ8CLfGjxfQZDQU18i3/ IfR682UbzuiR6kodhD5oX/I2S5l5dRRuabQq5t2zJL9BHmGleLaBgOjnne7T26PC JpNMt+60J93J9VzBN9kQABAO5BMUE4mN6g2141N9JXlMsg6DSGHPN5vQD7t7IxE1 mtNX9iMrjFa1Hsm2neXqvjb95ZGbZwTnxFcI7To6P3V/+v9QMpKrrBWu/AFNdF0= =84q1 -END PGP SIGNATURE- -- 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: Anomaly with the new code - Re: git-svn performance
Hin-Tak Leung wrote: > On Sat, Oct 25, 2014 00:34 BST Eric Wong wrote: > >0006 is insufficient and incompatible with older SVN. > >I pushed "git-svn: reload RA every log-window-size" > >(commit dfa72fdb96befbd790f623bb2909a347176753c2) instead > >which saves much more memory: > > it is fetching against the new clone taking twice as long and > consuming twice as much memory. Which SVN version are you using? I'm cloning (currently on r373xx) https://svn.r-project.org/R using --stdlayout and unable to see memory growth of the git-svn Perl process beyond 40M (on a 32-bit system). I also tried http:// (not https), svn+ssh:// on my local (64-bit) system and did not see memory growth, either: http://mid.gmane.org/20141027014033.ga4...@dcvr.yhbt.net I'm using svn 1.6.17 on Debian stable in all cases. -- 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: git ls-files -o seems to ignore .gitignore
On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote: > Hash: SHA1 > > I'm having an issue in that 'git ls-files -o' seems to ignore > [parts of] .gitignore whereas other commands, such as 'git status' > seem fine. This is, as far as I am aware, by design. If you want to apply the standard ignore rules to the output of ls-files -o then you can use the --exclude-standard option. -- 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
