Re: [PATCH v4] git-send-pack: fix --all option when used with directory

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v4] git-send-pack: fix --all option when used with directory

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:09:09

Junio C Hamano [off-list ref] writes:
stanislav@assembla.com writes:
quoted
From: Stanislav Kolotinskiy <redacted>

When using git send-pack with --all option
and a target repository specification ([<host>:]<directory>),
usage message is being displayed instead of performing
the actual transmission.

The reason for this issue is that destination and refspecs are being set
in the same conditional and are populated from argv. When a target
repository is passed, refspecs is being populated as well with its value.
This makes the check for refspecs not being NULL to always return true,
which, in conjunction with the check for --all or --mirror options,
is always true as well and returns usage message instead of proceeding.

This ensures that send-pack will stop execution only when --all
or --mirror switch is used in conjunction with any refspecs passed.

Signed-off-by: Stanislav Kolotinskiy <redacted>
---
Thanks, will queue.
By the way, for some reason it was unusually painful to find the
exact breakage by bisecting between maint-2.4 and maint-2.6.  It
somehow ended up on fingering random places like v2.6.0 itself.

The true culprit is 068c77a5 (builtin/send-pack.c: use parse_options
API, 2015-08-19).  I didn't dug deep enough to tell if we recently
broke "git bisect" or if there are something wrong in the shape of
my history.

Re: [PATCH v4] git-send-pack: fix --all option when used with directory

From: Eric Sunshine <hidden>
Date: 2016-06-15 23:09:09

On Thu, Mar 31, 2016 at 6:02 PM, Junio C Hamano [off-list ref] wrote:
By the way, for some reason it was unusually painful to find the
exact breakage by bisecting between maint-2.4 and maint-2.6.  It
somehow ended up on fingering random places like v2.6.0 itself.

The true culprit is 068c77a5 (builtin/send-pack.c: use parse_options
API, 2015-08-19).  I didn't dug deep enough to tell if we recently
broke "git bisect" or if there are something wrong in the shape of
my history.
I had a similar experience a couple months ago where I was bisecting
to find a fix (rather than breakage), and each time I ran bisect, it
seemed (randomly) to arrive at a different commit, often a merge,
rather than the real fix (which I eventually located by manually
examining commits near the commits bisect identified). At the time, I
thought I was doing something wrong (and perhaps I was), but your
descriptions sounds eerily similar to that experience.

Unfortunately, I no longer recall precisely for what I was searching
(other than that someone reported a Git bug which I recalled having
been already fixed, and wanted to use bisect to respond with the exact
commit which fixed the problem), and the bisect "run" script was
throwaway, so I can't consult that for further details.

Re: [PATCH v4] git-send-pack: fix --all option when used with directory

From: Jeff King <hidden>
Date: 2016-06-15 23:09:09

On Thu, Mar 31, 2016 at 03:02:43PM -0700, Junio C Hamano wrote:
By the way, for some reason it was unusually painful to find the
exact breakage by bisecting between maint-2.4 and maint-2.6.  It
somehow ended up on fingering random places like v2.6.0 itself.

The true culprit is 068c77a5 (builtin/send-pack.c: use parse_options
API, 2015-08-19).  I didn't dug deep enough to tell if we recently
broke "git bisect" or if there are something wrong in the shape of
my history.
Weird. I bisected this when v1 was published, and didn't have any
trouble. I guess it's possible I just got lucky in where I landed,
though, if I started at different endpoints than you.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help