Re: Fwd: git rm

On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote: > Peter writes: > > > I am a lightweigt git user so by all means not a reference, but I was > > wondering why exactly does "git rm" also delete the file (remove it > > from the working tree). I see it as an

[PATCH 1/4] push options: {pre,post}-receive hook learns about push options

The environment variable GIT_PUSH_OPTION_COUNT is set to the number of push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted option. The code is not executed as the push options are set to NULL, nor is the new capability advertised. There was some discussion back and forth

[PATCH 3/4] push: accept push options

This implements everything that is required on the client side to make use of push options from the porcelain push command. Signed-off-by: Stefan Beller --- Documentation/git-push.txt | 8 +++- builtin/push.c | 16 +--- send-pack.c

[PATCH 2/4] receive-pack: implement advertising and receiving push options

The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the

[PATCH 4/4] add a test for push options

The functions `mk_repo_pair` as well as `test_refs` are borrowed from t5543-atomic-push, with additional hooks installed. Signed-off-by: Stefan Beller --- t/t5544-push-options.sh | 101 1 file changed, 101 insertions(+)

[PATCHv3 0/4] Push options in C Git

This is not marked for RFC any more, as I do not recall any open points left for discussion. This addresses the only reply from Eric Wong on patch 3: diff to v2: diff --git a/send-pack.c b/send-pack.c index e328276..c943560 100644 --- a/send-pack.c +++ b/send-pack.c @@ -536,7 +536,8 @@ int

Re: [PATCH v4] Refactor recv_sideband()

On Wed, 6 Jul 2016, Junio C Hamano wrote: > Thanks; will apply with a miniscule fix. > > > - >8 > > Subject: sideband.c: small optimization of strbuf usage > > > > Signed-off-by: Nicolas Pitre > > ... > > @@ -97,7 +97,7 @@ int recv_sideband(const char *me, int in_stream,

What's cooking in git.git (Jul 2016, #02; Wed, 6)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The first few batches for this

Re: [PATCH v2 00/17] Use merge_recursive() directly in the builtin am

Johannes Schindelin writes: > This is the second iteration of the long-awaited re-roll of the attempt to > avoid spawning merge-recursive from the builtin am and use merge_recursive() > directly instead. I wanted to queue this in 'pu', but an unfortunate series that

Re: [PATCH v2 11/17] am: counteract gender bias

Johannes Schindelin writes: > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for > almost 11 years already,... > ...Let's start changing that by using the variable name "her_tree" for an > equal number of years out of fairness, and change to the

Re: [PATCH v4] Refactor recv_sideband()

Nicolas Pitre writes: > Here's a patch on top of it providing small optimizations. Thanks; will apply with a miniscule fix. > - >8 > Subject: sideband.c: small optimization of strbuf usage > > Signed-off-by: Nicolas Pitre > ... > @@ -97,7 +97,7 @@ int

[PATCH v4 6/6] bisect--helper: `bisect_write` shell function in C

Reimplement the `bisect_write` shell function in C and add a `bisect-write` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--bisect-write` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported,

[PATCH v4 3/6] wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()

is_empty_file() can help to refactor a lot of code. This will be very helpful in porting "git bisect" to C. Suggested-by: Torsten Bögershausen Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva

[PATCH v4 4/6] bisect--helper: `bisect_reset` shell function in C

Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `bisect_reset` subcommand is a temporary measure to port shell functions to C so as to use the existing test suite. As more functions are ported, this

[PATCH v4 2/6] t6030: explicitly test for bisection cleanup

Add test to explicitly check that 'git bisect reset' is working as expected. This is already covered implicitly by the test suite. Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva

[PATCH v4 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Reimplement `is_expected_rev` & `check_expected_revs` shell function in C and add a `--check-expected-revs` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--check-expected-revs` subcommand is a temporary measure to port shell functions to C so as to use the existing

[PATCH v4 1/6] bisect--helper: `bisect_clean_state` shell function in C

Reimplement `bisect_clean_state` shell function in C and add a `bisect-clean-state` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--bisect-clean-state` subcommand is a measure to port shell function to C so as to use the existing test suite. As more functions are

[PATCH v4 0/6] convert various shell functions in git-bisect to C

Some minor nits. Previous version can be found here[1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/298263 The inter-diff is : diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c index e946ba9..c2f3cee 100644 --- a/builtin/bisect--helper.c +++

Re: Over-/underquoting, was Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

On Wed, Jul 6, 2016 at 6:16 AM, Johannes Schindelin wrote: >> Johannes Schindelin venit, vidit, dixit 06.07.2016 09:01: >> OTOH, I often have to look up the original message because people cut >> too much, or because they take one sentence out of context. > > And

Re: [PATCH] config.c: fix potential number truncation in git_parse_signed()

Nguyễn Thái Ngọc Duy writes: > clang -Wabsolute-value on IA-32 architecture complains that "absolute > value function 'labs' given an argument of type 'intmax_t' (aka 'long > long') but has parameter of type 'long' which may cause truncation of > value". Very unlikely for

Re: [PATCH v2 2/2] cache-tree: do not generate empty trees as a result of all i-t-a subentries

Nguyễn Thái Ngọc Duy writes: > @@ -426,6 +433,15 @@ int cache_tree_update(struct index_state *istate, int > flags) > i = update_one(it, cache, entries, "", 0, , flags); > if (i < 0) > return i; > + /* > + * Top dir can become empty if all

Re: [PATCH] t7610 test for mktemp existence

Junio C Hamano writes: >> -test_expect_success 'temporary filenames are used with >> mergetool.writeToTemp' ' >> +test_lazy_prereq MKTEMP ' >> +tempdir=$(mktemp -d -t foo.XXX) && >> +test -d "$tempdir" >> +' > > This makes me wonder what would happen to the leftover

Re: [PATCH 2/2] t3404: add a test for the --gpg-sign option

Johannes Schindelin writes: > Okay, so here is the deal: on the development machine where this was > developed, I do not have gpg installed. So please take this test case just > to make sure that things work as intended for the moment. > > Before sending the last

Re: [PATCH] t7610 test for mktemp existence

On Wed, Jul 06, 2016 at 11:23:51AM -0700, Junio C Hamano wrote: > > -test_expect_success 'temporary filenames are used with > > mergetool.writeToTemp' ' > > +test_lazy_prereq MKTEMP ' > > + tempdir=$(mktemp -d -t foo.XXX) && > > + test -d "$tempdir" > > +' > > This makes me wonder what

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

On Wed, Jul 6, 2016 at 8:02 PM, Christoph Michelbach wrote: > I now created a repo on a 64 bit system (same command as before), then > duplicated it. One copy I applied git gc to on the 64 bit host system, > the other copy I gave to my 32 bit virtual machine to apply git

[PATCH v2 2/2] cache-tree: do not generate empty trees as a result of all i-t-a subentries

If a subdirectory contains nothing but i-t-a entries, we generate an empty tree object and add it to its parent tree. Which is wrong. Such a subdirectory should not be added. We ignore i-t-a files _and_ directories. Note that this has a cascading effect. If subdir 'a/b/c' contains nothing but

[PATCH v2 1/2] cache-tree.c: fix i-t-a entry skipping directory updates sometimes

Commit 3cf773e (cache-tree: fix writing cache-tree when CE_REMOVE is present - 2012-12-16) skips i-t-a entries when building trees objects from the index. Unfortunately it may skip too much. The code in question checks if an entry is an i-t-a one, then no tree entry will be written. But it does

[PATCH v2 0/2] cache-tree building fix in the presence of ita entries

1/2 is the same as before with some test fixups from Junio. 2/2 fixes the empty tree generation found by Junio. I split it out because the commit message in 1/2 is already long. And because it can happen even without 1/2 (i.e. yet another bug :( though really hard to happen). Suppose a/b/c

Re: [PATCH] t7610 test for mktemp existence

Armin Kunaschik writes: > Subject: t7610: test for mktemp before test execution > > mktemp is not available on all platforms, so the test > 'temporary filenames are used with mergetool.writeToTemp' > fails there. > This patch does not replace mktemp but just disables >

Re: [PATCH] git-svn: clone: Fail on missing url argument

Eric Wong writes: > Christopher Layne wrote: >> * cmd_clone should detect a missing $url arg before using it otherwise >> an uninitialized value error is emitted in even the simplest case of >> 'git svn clone' without arguments. > > Thanks, this patch

Re: [PATCH v14 00/21] index-helper/watchman

David Turner writes: > This addresses comments on v13: > removed unnecessary no_mmap ifdef > add an ifdef in unix-socket > OS X fix for select() > test improvement Thanks. It seems that what used to be 809fd05a (read-cache.c: fix constness of verify_hdr(), 2016-06-26) is

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

I now created a repo on a 64 bit system (same command as before), then duplicated it. One copy I applied git gc to on the 64 bit host system, the other copy I gave to my 32 bit virtual machine to apply git gc to it. The 64 bit host uses git from the Ubuntu repositories, the 32 bit virtual machine

Re: [PATCH v14 21/21] mailmap: use main email address for dturner

David Turner writes: > Signed-off-by: David Turner > --- > .mailmap | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.mailmap b/.mailmap > index e5b4126..edcae89 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -46,6 +46,7 @@ David D. Kilzer

Re: [PATCH] cache-tree.c: fix i-t-a check skipping directory updates sometimes

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> Fix it by making sure we only skip i-t-a entries when the entry in >> question is actual an index entry, not a directory. > > Aha. Good catch. > > However, this makes me wonder if subdir has only

Re: git patch format for rename

On Wed, Jul 6, 2016 at 9:00 AM, nadya.zabrod...@jetbrains.com wrote: > Hi, > > could you please explain to me why ‘rename from & rename to’ information is > added to git patch? > Is there any reason why git can’t recognize and apply rename-change which > looks

Re: [PATCH] cache-tree.c: fix i-t-a check skipping directory updates sometimes

Nguyễn Thái Ngọc Duy writes: > Commit 3cf773e (cache-tree: fix writing cache-tree when CE_REMOVE is > present - 2012-12-16) skips i-t-a entries when building trees objects > from the index. Unfortunately it may skip too much. > > The code in question checks if an entry is an

Re: [PATCH v13 11/20] index-helper: use watchman to avoid refreshing index with lstat()

Duy Nguyen gmail.com> writes: > > First step would be enabling that because besides directory > traversing, this code does a lot of string processing that's hopefully > eliminated by untracked cache extension. I cut git-status' time in > half with it. The side effect though, is that it creates

Re: Fwd: git rm

Peter writes: > I am a lightweigt git user so by all means not a reference, but I was > wondering why exactly does "git rm" also delete the file (remove it > from the working tree). I see it as an unintended behaviour as git is > written in a way that it preserves the most

git patch format for rename

Hi, could you please explain to me why ‘rename from & rename to’ information is added to git patch? Here is the patch created by `git format-patch`: diff --git a/before.txt b/after.txt similarity index 100% rename from before.txt rename to after.txt Is there any reason why

Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

Junio C Hamano writes: > Duy Nguyen writes: > >> What can I say, gettext is smart. In gc.c we already have this >> >> die(_("gc is already running on machine '%s' pid %"PRIuMAX" (use >> --force if not)"), name, (uintmax_t)pid); >> >> and vi.po shows >> >>

Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

Duy Nguyen writes: > What can I say, gettext is smart. In gc.c we already have this > > die(_("gc is already running on machine '%s' pid %"PRIuMAX" (use > --force if not)"), name, (uintmax_t)pid); > > and vi.po shows > > #: builtin/gc.c:397 > #, c-format > msgid "" > "gc is

Re: [PATCH 0/5] consistent setup code for external commands

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > I think that amounts to the following single patch, which I cherry > picked from the topic in Dscho's repository he mentioned earlier. That patch would be fine by me, too. Thanks, Dscho -- To unsubscribe from this list: send the line

Re: [PATCH 2/2] t3404: add a test for the --gpg-sign option

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Of course I agree that it would be very nice to have a test at a later > > stage that does exercise GPG if it is available. But would it really > > be so terrible to have a

Re: [PATCH v14 15/21] index-helper: kill mode

On Wed, Jul 6, 2016 at 10:20 AM, Johannes Schindelin wrote: > BTW I am in the middle of trying to abstract out a "simple server" that > will allow me to back the inter-process communication by a pure Windows > solution (named pipes) instead of the Unix sockets. It

Re: What's cooking in git.git (Jul 2016, #01; Fri, 1)

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 1 Jul 2016, Junio C Hamano wrote: > > > >> * jc/t2300-setup (2016-06-22) 1 commit > >> (merged to 'next' on 2016-06-28 at 62b902a) > >> + t2300: "git --exec-path" is

Re: [PATCH v2 02/17] Report bugs consistently

On Tue, Jul 5, 2016 at 1:23 PM, Johannes Schindelin wrote: > The vast majority of error messages in Git's source code which report a > bug use the convention to prefix the message with "BUG:". > > As part of cleaning up merge-recursive to stop die()ing except in case

Re: [PATCH 2/9] merge-recursive: clarify code in was_tracked()

Johannes Schindelin writes: > To understand why we're not done yet, the crucial point is *not* that the > return value encodes the insert position. The crucial point is that > despite asking for an index entry matching a specific name, we might not > find one, *even

Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

On Tue, Jul 5, 2016 at 10:25 PM, Johannes Sixt wrote: > Am 05.07.2016 um 19:05 schrieb Nguyễn Thái Ngọc Duy: >> >> + die(Q_("premature end of pack file, %"PRIuMAX" >> byte missing", >> + "premature end of pack file, %"PRIuMAX" >>

Re: [PATCH 0/5] consistent setup code for external commands

Jeff King writes: > On Fri, Jul 01, 2016 at 03:19:37PM -0700, Junio C Hamano wrote: > >> > Here they are: >> > >> > [1/5]: add an extra level of indirection to main() >> > [2/5]: common-main: call git_extract_argv0_path() >> > [3/5]: common-main: call sanitize_stdfds() >> >

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: > At some point inside the merge, Git calls read-cache.c/ce_compare_data(), > to check if the path named "file" is clean. > According to the tree information, the path "file" has the sha1 99b633. > #Note: > #sha1 99b633 is "first line\nsame

Re: [PATCH 2/2] t3404: add a test for the --gpg-sign option

Johannes Schindelin writes: > Of course I agree that it would be very nice to have a test at a later > stage that does exercise GPG if it is available. But would it really be so > terrible to have a (simpler, not as complete) test that is exercised > *also* when GPG

Re: What's cooking in git.git (Jul 2016, #01; Fri, 1)

Johannes Schindelin writes: > Hi Junio, > > On Fri, 1 Jul 2016, Junio C Hamano wrote: > >> * jc/t2300-setup (2016-06-22) 1 commit >> (merged to 'next' on 2016-06-28 at 62b902a) >> + t2300: "git --exec-path" is not usable in $PATH on Windows as-is >> >>

Over-/underquoting, was Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

Hi Michael, On Wed, 6 Jul 2016, Michael J Gruber wrote: > Johannes Schindelin venit, vidit, dixit 06.07.2016 09:01: > > > BTW Jacob, would you terribly mind cutting the quoted parts properly (I > > cut 112 lines)? It may not seem like much, but I seem to spend more and > > more of my email time

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

Johannes Schindelin venit, vidit, dixit 06.07.2016 09:01: > Hi Peff & Jacob, > > On Tue, 5 Jul 2016, Jacob Keller wrote: > >> On Tue, Jul 5, 2016 at 1:44 PM, Jeff King wrote: >>> On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote: >>> >>> Something like the patch below.

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

On Wed, Jul 06, 2016 at 09:03:44AM +0200, Johannes Schindelin wrote: > > By the way, I notice that the error message when concat fails is just: > > > > if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra)) > > die(_("program error")); > > > > Should this become: > > > >

Re: [PATCH v14 15/21] index-helper: kill mode

Hi Dave, On Sun, 3 Jul 2016, David Turner wrote: > @@ -357,10 +359,29 @@ static const char * const usage_text[] = { > NULL > }; > > +static void request_kill(void) > +{ > + int fd = unix_stream_connect(git_path("index-helper.sock")); > + > + if (fd >= 0) { > +

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

Hi Peff, On Tue, 5 Jul 2016, Jeff King wrote: > + ALLOC_ARRAY(ret, st_add3(a_len, b_len, 1)); > + for (i = 0; i < a_len; i++) > + ret[i] = a[i]; > + for (i = 0; i < b_len; i++) > + ret[a_len + i] = b[i]; > + ret[a_len + b_len] = b[b_len]; /* final

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

Hi Peff, On Tue, 5 Jul 2016, Jeff King wrote: > By the way, I notice that the error message when concat fails is just: > > if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra)) > die(_("program error")); > > Should this become: > > die("BUG: not enough room to

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

Hi Peff & Jacob, On Tue, 5 Jul 2016, Jacob Keller wrote: > On Tue, Jul 5, 2016 at 1:44 PM, Jeff King wrote: > > On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote: > > > > Something like the patch below. > > > > I admit this isn't buggy _now_, so this is potentially just