* Re: Problems with "git svn clone"
From: K Richard Pixley @ 2016-10-19 20:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20161019204118.GA5982@starla>
On 10/19/16 13:41 , Eric Wong wrote:
> K Richard Pixley <cnp637@zebra.com> wrote:
>> error: git-svn died of signal 11
>>
>> This seems awfully early and blatant for a core dump. What can I do to
>> get this running?
> Can you show us a backtrace? Thanks.
There is none. I ran it in gdb and bt produced no results. Nor did the
thread send bt command.
>> Initially discovered on git-2.7.4, (ubuntu-16.04), but also reproduced
>> on freshly built top of tree git-2.10.1.445.g3cdd5d1.
> This could be a problem with the SVN Perl libraries, and should
> be fixed in newer versions (not sure if it's made it to distros,
> yet):
>
> https://public-inbox.org/git/0BCA1E695085C645B9CD4A27DD59F6FA39AAD5CF@GBWGCEUHUBD0101.rbsres07.net/T/
>
> Seems like it is fixed in latest Debian, maybe it needs to trickle
> into Ubuntu: https://bugs.debian.org/780246
Thanks. I'll try adding that.
Er... which debian would that be? testing? Or sid?
--rich
________________________________
- CONFIDENTIAL-
This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
^ permalink raw reply
* Re: [PATCH] rev-list: restore the NUL commit separator in --header mode
From: Jacob Keller @ 2016-10-19 22:15 UTC (permalink / raw)
To: Dennis Kaarsemaker
Cc: Git mailing list, Jacob Keller, Stefan Beller, Jeff King,
Johannes Sixt
In-Reply-To: <20161019210448.aupphybw5qar6mqe@hurricane>
Hi,
On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker
<dennis@kaarsemaker.net> wrote:
> Commit 660e113 (graph: add support for --line-prefix on all graph-aware
> output) changed the way commits were shown. Unfortunately this dropped
> the NUL between commits in --header mode. Restore the NUL and add a test
> for this feature.
>
Oops! Thanks for the bug fix.
> Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
> ---
> builtin/rev-list.c | 4 ++++
> t/t6000-rev-list-misc.sh | 7 +++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index 8479f6e..cfa6a7d 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -157,6 +157,10 @@ static void show_commit(struct commit *commit, void *data)
> if (revs->commit_format == CMIT_FMT_ONELINE)
> putchar('\n');
> }
> + if (revs->commit_format == CMIT_FMT_RAW) {
> + putchar(info->hdr_termination);
> + }
> +
This seems right to me. My one concern is that we make sure we restore
it for every case (in case it needs to be there for other formats?)
I'm not entirely sure about whether other non-raw modes need this or
not?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v12 3/8] graph: add support for --line-prefix on all graph-aware output
From: Jacob Keller @ 2016-10-19 22:13 UTC (permalink / raw)
To: Dennis Kaarsemaker
Cc: Jacob Keller, Git mailing list, Junio C Hamano, Stefan Beller,
Jeff King, Johannes Sixt
In-Reply-To: <1476908699.26043.9.camel@kaarsemaker.net>
Hi,
On Wed, Oct 19, 2016 at 1:24 PM, Dennis Kaarsemaker
<dennis@kaarsemaker.net> wrote:
> On Wed, 2016-08-31 at 16:27 -0700, Jacob Keller wrote:
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Add an extension to git-diff and git-log (and any other graph-aware
>> displayable output) such that "--line-prefix=<string>" will print the
>> additional line-prefix on every line of output.
>
> This patch breaks git rev-list --header, also breaking gitweb.
>
Oops! Is it possible you have a test case already?
> The NUL between commits has gone missing, causing gitweb to interpret
> the output of git rev-list as one commit.
>
That is obviously not what we want!
> Sorry for not catching this earlier, I actually encountered this early
> september but thought it was caused by us running an ancient gitweb
> with a modern git. Finally managed to upgrade gitweb today, and the bug
> didn't go away. git bisect says 660e113ce is the culprit. Checking out
> 'next' and reverting this single patch makes the problem disappear.
>
Ok.
> Haven't yet tried to fix the bug, but this hunk looks suspicious:
>
> - if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> - buf.len) {
> - fwrite(buf.buf, 1, buf.len, stdout);
> - putchar(info->hdr_termination);
> - }
> + /*
> + * If the message buffer is empty, just show
> + * the rest of the graph output for this
> + * commit.
> + */
> + if (graph_show_remainder(revs->graph))
> + putchar('\n');
Most likely this should have been "putchar(info->hdr_termination);" I
think? Not entirely sure.
If we can get a test case in we can use that to help debug the issue.
Thanks,
Jake
> + if (revs->commit_format == CMIT_FMT_ONELINE)
> +
>
> D.
^ permalink raw reply
* Re: [PATCH] submodules: update documentaion for submodule branches
From: Junio C Hamano @ 2016-10-19 21:42 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller
In-Reply-To: <20161019204254.97659-1-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Update the documentaion for the the special value `.` to indicate that
> it signifies that the tracking branch in the submodule should be the
> same as the current branch in the superproject.
Thanks. Will typofix while extending with info supplied by Stefan
like so:
submodules doc: update documentation for "." used for submodule branches
4d7bc52b17 ("submodule update: allow '.' for branch value",
2016-08-03) adopted from Gerrit a feature to set "." as a special
value of "submodule.<name>.branch" in .gitmodules file to indicate
that it signifies that the tracking branch in the submodule should
be the same as the current branch in the superproject.
Update the documentation to describe this.
^ permalink raw reply
* Re: [PATCH 0/7] Rejecting useless merge bases
From: Junio C Hamano @ 2016-10-19 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <20161019042345.29766-1-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> This is a continuation of
>
> http://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com
I scanned all two-parent merges in git.git leading to 'next' and
'pu' and reproduced them with or without the new --fp-base-only
option. I also did the same experiment in linux.git, but only for
the latest 10,000 merges.
This exercise yielded some interesting numbers.
Among the total 10,995 merges, 10,487 merges had only one merge base
and that merge base was on the first-parent chain, i.e. the result
of reproduction is the same with or without "--fp-base-only".
There were 65 merges with multiple merge-bases but all of these
merge bases were on the first-parent chain, i.e. again the result is
the same with or without "--fp-base-only".
The remaining 443 merges had merge bases that are not on the
first-parent chain. These merges, when recreated with
"--fp-base-only", would use different/reduced set of merge bases to
drive merge-recursive machinery and could produce different results.
Among these 443, "git merge" with or without the "--fp-base-only"
option successfully auto-resolved and produced the same result as
recorded in the real history for 214 of them. They stopped in
conflicts but "git ls-files -s" output in their conflicted states
were the same, i.e. they left the identical conflicts, for 221 of
them.
The remaining 8 merges were auto-resolved the same way with or
without the "--fp-base-only" option, but they were different from
the merge in the real history (i.e. the real history had an evil
merge there to adjust for non-textual conflicts).
The most important numbers was 0. There was no merges whose
reproduction with and without "--fp-base-only" produced different
results.
For linux.git the numbers are:
- total merges looked at: 10,000
- single merge base: 9,705
- multi merge base all on the first parent chain: 123
- fp-base-only eligible: 172
- cleanly resolved the same way w/ or w/o fp-only: 118
- conflicted the same way w/ or w/o fp-only: 54
- evil merges among fp-base-only eligible merges: 0
- fp-base-only mismerges: 0
^ permalink raw reply
* Re: [PATCH 1/2] ref-filter: split ref_kind_from_filter
From: Jeff King @ 2016-10-19 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santiago Torres, git, sunshine, walters, Lukas Puehringer
In-Reply-To: <xmqqd1iwkp7m.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 19, 2016 at 02:23:41PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Subject: Re: [PATCH 1/2] ref-filter: split ref_kind_from_filter
>
> I think you meant ref_kind_from_refname() ;-)
>
> Looks like a good idea.
Heh, I actually meant filter_ref_kind(), which is the original function.
But any name that is actually a real function would do. :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] ref-filter: split ref_kind_from_filter
From: Junio C Hamano @ 2016-10-19 21:23 UTC (permalink / raw)
To: Jeff King; +Cc: Santiago Torres, git, sunshine, walters, Lukas Puehringer
In-Reply-To: <20161019203546.dfqmi2czcxopgj6w@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Subject: Re: [PATCH 1/2] ref-filter: split ref_kind_from_filter
I think you meant ref_kind_from_refname() ;-)
Looks like a good idea.
> This function does two things: if we know we are filtering
> only a certain kind of ref, then we can immediately know
> that we have that kind. If not, then we compute the kind
> from the fully-qualified refname. The latter half is useful
> for other callers; let's split it out.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> ref-filter.c | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index cfbcd73..77ec9de 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1329,7 +1329,7 @@ static struct ref_array_item *new_ref_array_item(const char *refname,
> return ref;
> }
>
> -static int filter_ref_kind(struct ref_filter *filter, const char *refname)
> +static int ref_kind_from_refname(const char *refname)
> {
> unsigned int i;
>
> @@ -1342,11 +1342,7 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
> { "refs/tags/", FILTER_REFS_TAGS}
> };
>
> - if (filter->kind == FILTER_REFS_BRANCHES ||
> - filter->kind == FILTER_REFS_REMOTES ||
> - filter->kind == FILTER_REFS_TAGS)
> - return filter->kind;
> - else if (!strcmp(refname, "HEAD"))
> + if (!strcmp(refname, "HEAD"))
> return FILTER_REFS_DETACHED_HEAD;
>
> for (i = 0; i < ARRAY_SIZE(ref_kind); i++) {
> @@ -1357,6 +1353,15 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
> return FILTER_REFS_OTHERS;
> }
>
> +static int filter_ref_kind(struct ref_filter *filter, const char *refname)
> +{
> + if (filter->kind == FILTER_REFS_BRANCHES ||
> + filter->kind == FILTER_REFS_REMOTES ||
> + filter->kind == FILTER_REFS_TAGS)
> + return filter->kind;
> + return ref_kind_from_refname(refname);
> +}
> +
> /*
> * A call-back given to for_each_ref(). Filter refs and keep them for
> * later object processing.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #04; Mon, 17)
From: Jeff King @ 2016-10-19 21:21 UTC (permalink / raw)
To: brian m. carlson, Junio C Hamano, Lars Schneider, git
In-Reply-To: <20161019202856.7ld3kpsnjwu6dbwl@vauxhall.crustytoothpaste.net>
On Wed, Oct 19, 2016 at 08:28:56PM +0000, brian m. carlson wrote:
> On Wed, Oct 19, 2016 at 03:46:48AM -0400, Jeff King wrote:
> > FWIW, I gave it a fairly thorough read-over (something I'd been meaning
> > to do for quite a while, but kept never quite getting around to). I
> > think overall it is OK for next. I did find one or two nits, but I think
> > they are things we can fix up in-tree if and when they become a problem
> > (e.g., I noticed that test-genrandom gets piped to "perl -pe". I'm not
> > sure if perl will complain about funny multibyte characters on some
> > systems. I suggest we ignore it until somebody demonstrates that it
> > actually matters).
>
> I just looked, and that use is fine. perl -pe is always going to treat
> its data as bytes unless you use -C or explicitly enable Unicode
> functionality.
Thanks. I have vague memories of multibyte warnings, but I think they
may have been on _output_ when passing through binary data that came
on stdin.
-Peff
^ permalink raw reply
* Re: [PATCH] Add a knob to abort on die() (was Re: git checkout crashes after ...)
From: Jeff King @ 2016-10-19 21:15 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Raffael Reichelt
In-Reply-To: <20161019134750.GA7256@ash>
On Wed, Oct 19, 2016 at 08:47:50PM +0700, Duy Nguyen wrote:
> On Wed, Oct 19, 2016 at 08:27:43PM +0700, Duy Nguyen wrote:
> > If you set the environment variable GIT_ALLOC_LIMIT ... git
> > attempts to allocate more than that ... then it's caught and we get
> > a glimpse of how much memory git may need. Unfortunately we can't
> > get a stack trace or anything like that unless you rebuild Git from
> > source.
>
> It's moments like this that I wish we had a knob to force core
> dumps. And I often modify die_builtin() to add '*(char*)0 = 1;' to
> force a core dump when I can't figure out some problem based on the
> error message alone.
>
> So.. how about we do something like this? We could extend it to abort
> on error() as well as die(). Aborting on warning() may be a bit too
> much though. On glibc systems we could even print the back trace
> without aborting, which helps in some cases.
I have been tempted by something like this, too, and have occasionally
resorted to patching in an abort() call to get cores from sub-processes.
I'm not sure how useful it would be in practice in deployed versions of
git, though. You'd have to coach the user into finding the core file and
generating the backtrace from it. Something that called backtrace(3)
automatically would be more seamless (but provides worse information
than gdb), and otherwise it is probably just as easy to ship the user
cut-and-paste instructions to use gdb.
See the previous discussion in this subthread:
http://public-inbox.org/git/20150424201734.GA4747@peff.net/T/#u
-Peff
^ permalink raw reply
* Re: [regression] `make profile-install` fails in 2.10.1
From: Jeff King @ 2016-10-19 21:05 UTC (permalink / raw)
To: Jan Keromnes; +Cc: git
In-Reply-To: <CAA6PgK5vtnZSqqZafMVGoy0Rv38=8e__uQvXaf2SyPePHuPjJA@mail.gmail.com>
On Wed, Oct 19, 2016 at 01:15:56PM +0200, Jan Keromnes wrote:
> - Problem: Is there a way to `make profile-install` but ignore
> occasional test failures, as these are not critical to get a useful
> hardware profile? (Note: In a previous thread, Dennis Kaarsemaker
> mentioned this is fixing a symptom, not the root cause, but it would
> still be great to get a working profile in spite of occasional test
> failures.)
No, there isn't a way currently. I agree with Dennis that we do want to
ultimately fix the flaky tests, but at the same time, it does seem
reasonable to use a partial test run for your profile results.
I suspect you'd need to switch the call to:
$(MAKE) PROFILE=GEN -j1 -k test || true
to make it best-effort.
> - Related problem: `t3700-add.sh` fails again in 2.10.1 for me. More
> details below, and I can provide further debug information if you
> don't already know the problem.
I can't reproduce any problems with raciness there, but there is a known
problem with running the script as root (which I guess you might be
doing from your "make prefix=/usr" call). There's some discussion in
http://public-inbox.org/git/20161010035756.38408-1-jeremyhu@apple.com/T/#u,
but it looks like the patch stalled.
-Peff
^ permalink raw reply
* [PATCH] rev-list: restore the NUL commit separator in --header mode
From: Dennis Kaarsemaker @ 2016-10-19 21:04 UTC (permalink / raw)
To: git; +Cc: jacob.e.keller, stefanbeller, peff, j6t, jacob.keller
In-Reply-To: <1476908699.26043.9.camel@kaarsemaker.net>
Commit 660e113 (graph: add support for --line-prefix on all graph-aware
output) changed the way commits were shown. Unfortunately this dropped
the NUL between commits in --header mode. Restore the NUL and add a test
for this feature.
Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
---
builtin/rev-list.c | 4 ++++
t/t6000-rev-list-misc.sh | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 8479f6e..cfa6a7d 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -157,6 +157,10 @@ static void show_commit(struct commit *commit, void *data)
if (revs->commit_format == CMIT_FMT_ONELINE)
putchar('\n');
}
+ if (revs->commit_format == CMIT_FMT_RAW) {
+ putchar(info->hdr_termination);
+ }
+
strbuf_release(&buf);
} else {
if (graph_show_remainder(revs->graph))
diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
index 3e752ce..a2acff3 100755
--- a/t/t6000-rev-list-misc.sh
+++ b/t/t6000-rev-list-misc.sh
@@ -100,4 +100,11 @@ test_expect_success '--bisect and --first-parent can not be combined' '
test_must_fail git rev-list --bisect --first-parent HEAD
'
+test_expect_success '--header shows a NUL after each commit' '
+ touch expect &&
+ printf "\0" > expect &&
+ git rev-list --header --max-count=1 HEAD | tail -n1 >actual &&
+ test_cmp_bin expect actual
+'
+
test_done
--
2.10.1-449-gab0f84c
--
Dennis Kaarsemaker <dennis@kaarsemaker.net>
http://twitter.com/seveas
^ permalink raw reply related
* Re: Drastic jump in the time required for the test suite
From: Jeff King @ 2016-10-19 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <xmqqbmygmehv.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote:
> > Maybe we should start optimizing the tests...
>
> Yup, two things that come to mind are to identify long ones and see
> if each of them can be split into two halves that can be run in
> parallel, and to go through the tests with fine toothed comb and
> remove the ones that test exactly the same thing as another test.
> The latter would be very time consuming, though.
FWIW, I have made attempts at "split long ones into two" before, and
didn't come up with much. There _are_ some tests that are much longer
than others[1], but they are not longer than the whole suite takes to
run. So running in slow-to-fast order means they start first, are run in
parallel with the other tests, and the CPUs stay relatively full through
the whole run.
Of course YMMV; the long tests on Windows may be different, or
proportionally much longer (I note the worst cases almost all involve
rebase, which as a shell script is presumably worse on Windows than
elsewhere). And of course any reasoning about slow-to-fast order does
not apply if you are not using a tool to do that for you. :)
-Peff
[1] After running "make prove" (time are in seconds):
$ perl -MYAML -e '
$_ = do { local $/; <> };
# prove puts this non-YAML cruft at the end
s/\.\.\.$//s;
my $t = YAML::Load($_)->{tests};
print "$_->[1] $_->[0]\n" for
sort { $b->[1] <=> $a->[1] }
map { [$_, $t->{$_}->{elapsed}] }
keys(%$t);
' .prove | head
43.216765165329 t3404-rebase-interactive.sh
30.6568658351898 t3421-rebase-topology-linear.sh
27.92564702034 t9001-send-email.sh
15.5906939506531 t9500-gitweb-standalone-no-errors.sh
15.4882569313049 t6030-bisect-porcelain.sh
14.487174987793 t7610-mergetool.sh
13.8276169300079 t3425-rebase-topology-merges.sh
12.7450480461121 t3426-rebase-submodule.sh
12.4915001392365 t3415-rebase-autosquash.sh
11.8122401237488 t5572-pull-submodule.sh
^ permalink raw reply
* Re: [PATCH] submodules: update documentaion for submodule branches
From: Stefan Beller @ 2016-10-19 20:45 UTC (permalink / raw)
To: Brandon Williams; +Cc: git@vger.kernel.org
In-Reply-To: <20161019204254.97659-1-bmwill@google.com>
On Wed, Oct 19, 2016 at 1:42 PM, Brandon Williams <bmwill@google.com> wrote:
> Update the documentaion for the the special value `.` to indicate that
> it signifies that the tracking branch in the submodule should be the
> same as the current branch in the superproject.
For reference of other reviewers:
See 4d7bc52b178bffe9e484c4dcd92d5353e2ce716f
as well as https://gerrit-review.googlesource.com/Documentation/user-submodules.html
Thanks,
Stefan
>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> Documentation/git-submodule.txt | 4 +++-
> Documentation/gitmodules.txt | 7 +++++--
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index bf3bb37..d841573 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -259,7 +259,9 @@ OPTIONS
> --branch::
> Branch of repository to add as submodule.
> The name of the branch is recorded as `submodule.<name>.branch` in
> - `.gitmodules` for `update --remote`.
> + `.gitmodules` for `update --remote`. A special value of `.` is used to
> + indicate that the name of the branch in the submodule should be the
> + same name as the current branch in the current repository.
>
> -f::
> --force::
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index 10dcc08..8f7c50f 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -50,8 +50,11 @@ submodule.<name>.update::
>
> submodule.<name>.branch::
> A remote branch name for tracking updates in the upstream submodule.
> - If the option is not specified, it defaults to 'master'. See the
> - `--remote` documentation in linkgit:git-submodule[1] for details.
> + If the option is not specified, it defaults to 'master'. A special
> + value of `.` is used to indicate that the name of the branch in the
> + submodule should be the same name as the current branch in the
> + current repository. See the `--remote` documentation in
> + linkgit:git-submodule[1] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH] submodules: update documentaion for submodule branches
From: Brandon Williams @ 2016-10-19 20:42 UTC (permalink / raw)
To: git; +Cc: sbeller, Brandon Williams
Update the documentaion for the the special value `.` to indicate that
it signifies that the tracking branch in the submodule should be the
same as the current branch in the superproject.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
Documentation/git-submodule.txt | 4 +++-
Documentation/gitmodules.txt | 7 +++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bf3bb37..d841573 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -259,7 +259,9 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
The name of the branch is recorded as `submodule.<name>.branch` in
- `.gitmodules` for `update --remote`.
+ `.gitmodules` for `update --remote`. A special value of `.` is used to
+ indicate that the name of the branch in the submodule should be the
+ same name as the current branch in the current repository.
-f::
--force::
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 10dcc08..8f7c50f 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -50,8 +50,11 @@ submodule.<name>.update::
submodule.<name>.branch::
A remote branch name for tracking updates in the upstream submodule.
- If the option is not specified, it defaults to 'master'. See the
- `--remote` documentation in linkgit:git-submodule[1] for details.
+ If the option is not specified, it defaults to 'master'. A special
+ value of `.` is used to indicate that the name of the branch in the
+ submodule should be the same name as the current branch in the
+ current repository. See the `--remote` documentation in
+ linkgit:git-submodule[1] for details.
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
--
2.10.1
^ permalink raw reply related
* Re: Problems with "git svn clone"
From: Eric Wong @ 2016-10-19 20:41 UTC (permalink / raw)
To: K Richard Pixley; +Cc: git
In-Reply-To: <500ef24a-55f9-1b38-52bb-17347ebaabcd@zebra.com>
K Richard Pixley <cnp637@zebra.com> wrote:
> error: git-svn died of signal 11
>
> This seems awfully early and blatant for a core dump. What can I do to
> get this running?
Can you show us a backtrace? Thanks.
> Initially discovered on git-2.7.4, (ubuntu-16.04), but also reproduced
> on freshly built top of tree git-2.10.1.445.g3cdd5d1.
This could be a problem with the SVN Perl libraries, and should
be fixed in newer versions (not sure if it's made it to distros,
yet):
https://public-inbox.org/git/0BCA1E695085C645B9CD4A27DD59F6FA39AAD5CF@GBWGCEUHUBD0101.rbsres07.net/T/
Seems like it is fixed in latest Debian, maybe it needs to trickle
into Ubuntu: https://bugs.debian.org/780246
^ permalink raw reply
* [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format
From: Jeff King @ 2016-10-19 20:39 UTC (permalink / raw)
To: Santiago Torres; +Cc: git, gitster, sunshine, walters, Lukas Puehringer
In-Reply-To: <20161019203520.zevkb75at2nrogdm@sigill.intra.peff.net>
The ref-filter code generally expects to see fully qualified
refs, so that things like "%(refname)" and "%(refname:short)"
work as expected. We can do so easily from git-tag, which
always works with refnames in the refs/tags namespace. As a
bonus, we can drop the "kind" parameter from
pretty_print_ref() and just deduce it automatically.
Unfortunately, things are not so simple for verify-tag,
which takes an arbitrary sha1 expression. It has no clue if
a refname as used or not, and whether it was in the
refs/tags namespace.
In an ideal world, get_sha1_with_context() would optionally
tell us about any refs we resolved while it was working, and
we could just feed that refname (and then in cases where we
didn't use a ref at all, like a bare sha1, we could fallback
to just showing the sha1 name the user gave us).
Signed-off-by: Jeff King <peff@peff.net>
---
I think you'd really just squash the various bits of this into your
series at the right spots, though I don't mind it on top, either.
The big question is to what degree we should care about the verify-tag
case. I don't think it's any worse off with this change than it is with
your series (its "kind" becomes "OTHER", but I don't think that is
actually used for display at all; the name remains the same). I'd be OK
with leaving it like this, as a known bug, until get_sha1_with_context()
learns to tell us about the ref. It's an unhandled corner case in a
brand-new feature, not a regression in an existing one.
builtin/tag.c | 2 +-
ref-filter.c | 4 ++--
ref-filter.h | 6 +++++-
tag.c | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 49aeb50..18eab7e 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -114,7 +114,7 @@ static int verify_tag(const char *name, const char *ref,
if (fmt_pretty)
flags = GPG_VERIFY_QUIET;
- return verify_and_format_tag(sha1, name, fmt_pretty, flags);
+ return verify_and_format_tag(sha1, ref, fmt_pretty, flags);
}
static int do_sign(struct strbuf *buffer)
diff --git a/ref-filter.c b/ref-filter.c
index 77ec9de..74da17a 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1643,11 +1643,11 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu
}
void pretty_print_ref(const char *name, const unsigned char *sha1,
- const char *format, unsigned kind)
+ const char *format)
{
struct ref_array_item *ref_item;
ref_item = new_ref_array_item(name, sha1, 0);
- ref_item->kind = kind;
+ ref_item->kind = ref_kind_from_refname(name);
show_ref_array_item(ref_item, format, 0);
free_array_item(ref_item);
}
diff --git a/ref-filter.h b/ref-filter.h
index 3d23090..fed2f5e 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -107,7 +107,11 @@ struct ref_sorting *ref_default_sorting(void);
/* Function to parse --merged and --no-merged options */
int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset);
+/*
+ * Print a single ref, outside of any ref-filter. Note that the
+ * name must be a fully qualified refname.
+ */
void pretty_print_ref(const char *name, const unsigned char *sha1,
- const char *format, unsigned kind);
+ const char *format);
#endif /* REF_FILTER_H */
diff --git a/tag.c b/tag.c
index d3512c0..d5a7cfb 100644
--- a/tag.c
+++ b/tag.c
@@ -62,7 +62,7 @@ int verify_and_format_tag(const unsigned char *sha1, const char *name,
free(buf);
if (fmt_pretty)
- pretty_print_ref(name, sha1, fmt_pretty, FILTER_REFS_TAGS);
+ pretty_print_ref(name, sha1, fmt_pretty);
return ret;
}
--
2.10.1.619.g16351a7
^ permalink raw reply related
* Re: [PATCH v4 2/7] ref-filter: add function to print single ref_array_item
From: Jeff King @ 2016-10-19 20:35 UTC (permalink / raw)
To: Santiago Torres; +Cc: git, gitster, sunshine, walters, Lukas Puehringer
In-Reply-To: <20161019170733.ey3d53miykn5t5cq@LykOS.localdomain>
On Wed, Oct 19, 2016 at 01:07:34PM -0400, Santiago Torres wrote:
> > I guess that may complicate things for the caller you add in this
> > series, which may not have a fully-qualified refname (which is obviously
> > how filter_ref_kind() figures it out). I'd argue that is a bug, though,
> > as things like "%(refname)" are generally expected to print out the
> > fully refname ("git tag --format=%(refname)" does so, and you can use
> > "%(refname:short)" if you want the shorter part).
>
> Hmm, I hadn't actually noticed that. Do you have any suggestions in how to
> address this?
>
> In general this feels like a consequence of disambiguating .git/tags/*
> within builtin/tag.c rather than letting ref-filter figure it out.
The partial solution would look like something below. It's not too bad
because git-tag always knows that it's working a ref in the refs/tags
namespace (and we don't even have to qualify it ourselves,
for_each_tag_name already does it for us).
But verify-tag feeds arbitrary sha1 expressions. See the notes in the
second patch.
[1/2]: ref-filter: split ref_kind_from_filter
[2/2]: tag: send fully qualified refnames to verify_tag_and_format
builtin/tag.c | 2 +-
ref-filter.c | 21 +++++++++++++--------
ref-filter.h | 6 +++++-
tag.c | 2 +-
4 files changed, 20 insertions(+), 11 deletions(-)
-Peff
^ permalink raw reply
* [PATCH 1/2] ref-filter: split ref_kind_from_filter
From: Jeff King @ 2016-10-19 20:35 UTC (permalink / raw)
To: Santiago Torres; +Cc: git, gitster, sunshine, walters, Lukas Puehringer
In-Reply-To: <20161019203520.zevkb75at2nrogdm@sigill.intra.peff.net>
This function does two things: if we know we are filtering
only a certain kind of ref, then we can immediately know
that we have that kind. If not, then we compute the kind
from the fully-qualified refname. The latter half is useful
for other callers; let's split it out.
Signed-off-by: Jeff King <peff@peff.net>
---
ref-filter.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index cfbcd73..77ec9de 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1329,7 +1329,7 @@ static struct ref_array_item *new_ref_array_item(const char *refname,
return ref;
}
-static int filter_ref_kind(struct ref_filter *filter, const char *refname)
+static int ref_kind_from_refname(const char *refname)
{
unsigned int i;
@@ -1342,11 +1342,7 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
{ "refs/tags/", FILTER_REFS_TAGS}
};
- if (filter->kind == FILTER_REFS_BRANCHES ||
- filter->kind == FILTER_REFS_REMOTES ||
- filter->kind == FILTER_REFS_TAGS)
- return filter->kind;
- else if (!strcmp(refname, "HEAD"))
+ if (!strcmp(refname, "HEAD"))
return FILTER_REFS_DETACHED_HEAD;
for (i = 0; i < ARRAY_SIZE(ref_kind); i++) {
@@ -1357,6 +1353,15 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
return FILTER_REFS_OTHERS;
}
+static int filter_ref_kind(struct ref_filter *filter, const char *refname)
+{
+ if (filter->kind == FILTER_REFS_BRANCHES ||
+ filter->kind == FILTER_REFS_REMOTES ||
+ filter->kind == FILTER_REFS_TAGS)
+ return filter->kind;
+ return ref_kind_from_refname(refname);
+}
+
/*
* A call-back given to for_each_ref(). Filter refs and keep them for
* later object processing.
--
2.10.1.619.g16351a7
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2016, #04; Mon, 17)
From: brian m. carlson @ 2016-10-19 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Lars Schneider, git
In-Reply-To: <20161019074648.nuk2c2mpvmedjrhb@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Wed, Oct 19, 2016 at 03:46:48AM -0400, Jeff King wrote:
> FWIW, I gave it a fairly thorough read-over (something I'd been meaning
> to do for quite a while, but kept never quite getting around to). I
> think overall it is OK for next. I did find one or two nits, but I think
> they are things we can fix up in-tree if and when they become a problem
> (e.g., I noticed that test-genrandom gets piped to "perl -pe". I'm not
> sure if perl will complain about funny multibyte characters on some
> systems. I suggest we ignore it until somebody demonstrates that it
> actually matters).
I just looked, and that use is fine. perl -pe is always going to treat
its data as bytes unless you use -C or explicitly enable Unicode
functionality.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v12 3/8] graph: add support for --line-prefix on all graph-aware output
From: Dennis Kaarsemaker @ 2016-10-19 20:24 UTC (permalink / raw)
To: Jacob Keller, git
Cc: Junio C Hamano, Stefan Beller, Jeff King, Johannes Sixt,
Jacob Keller
In-Reply-To: <20160831232725.28205-4-jacob.e.keller@intel.com>
On Wed, 2016-08-31 at 16:27 -0700, Jacob Keller wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Add an extension to git-diff and git-log (and any other graph-aware
> displayable output) such that "--line-prefix=<string>" will print the
> additional line-prefix on every line of output.
This patch breaks git rev-list --header, also breaking gitweb.
The NUL between commits has gone missing, causing gitweb to interpret
the output of git rev-list as one commit.
Sorry for not catching this earlier, I actually encountered this early
september but thought it was caused by us running an ancient gitweb
with a modern git. Finally managed to upgrade gitweb today, and the bug
didn't go away. git bisect says 660e113ce is the culprit. Checking out
'next' and reverting this single patch makes the problem disappear.
Haven't yet tried to fix the bug, but this hunk looks suspicious:
- if (revs->commit_format != CMIT_FMT_USERFORMAT ||
- buf.len) {
- fwrite(buf.buf, 1, buf.len, stdout);
- putchar(info->hdr_termination);
- }
+ /*
+ * If the message buffer is empty, just show
+ * the rest of the graph output for this
+ * commit.
+ */
+ if (graph_show_remainder(revs->graph))
+ putchar('\n');
+ if (revs->commit_format == CMIT_FMT_ONELINE)
+
D.
^ permalink raw reply
* Re: Integrating submodules with no side effects
From: Robert Dailey @ 2016-10-19 19:51 UTC (permalink / raw)
To: Stefan Beller; +Cc: Git
In-Reply-To: <CAGZ79kZWaShG9iG565bD3aVYFcb53+opbpnJH-v3G6hrQL2tzA@mail.gmail.com>
On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller <sbeller@google.com> wrote:
> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
> <rcdailey.lists@gmail.com> wrote:
>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbeller@google.com> wrote:
>>> You could try this patch series:
>>> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
>>> (rebased to a newer version; no functional changes:)
>>> https://github.com/stefanbeller/git/tree/submodule-co
>>> (I'll rebase that later to origin/master)
>>>
>>>>
>>>> Do you have any info on how I can prevent that error? Ideally I want
>>>> the integration to go smoothly and transparently, not just for the
>>>> person doing the actual transition (me) but for everyone else that
>>>> gets those changes from upstream. They should not even notice that it
>>>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>>>
>>> It depends on how long you want to postpone the transition, but I plan to
>>> upstream the series referenced above in the near future,
>>> which would enable your situation to Just Work (tm). ;)
>>
>> At first glance, what you've linked to essentially looks like
>> automated `git submodule update` for every `git checkout`. Am I
>> misunderstanding?
>
> Essentially yes, except with stricter rules than the actual submodule update
> IIRC.
>
>>
>> If I'm correct, this is not the same as what I'm talking about. The
>> problem appears to be more internal: When a submodule is removed, the
>> physical files that were there are not removed by Git.
>
> That is also done by that series: submodules ought to be treated as files:
> If you checkout a new version where a file is deleted, the checkout command
> will actually remove the file for you (and e.g. solve any
> directory/file conflicts
> that may happen in the transition.)
>
>> It leaves them
>> there in the working copy as untracked files.
>
> That is the current behavior as checkout tries hard to ignore submodules.
>
>> The next step Git takes
>> (again, just from outside observation) is to add those very same files
>> to the working copy, since they were added to a commit. However, at
>> this point Git fails because it's trying to create (write) files to
>> the working copy when an exact file of that name already exists there.
>> Git will not overwrite untracked files, so at this point it fails.
>>
>> What needs to happen, somehow, is Git sees that the files were
>> actually part of a submodule (which was removed) and remove the
>> physical files as well, assuming that they were not modified in the
>> submodule itself. This will ensure that the next step (creating the
>> files) will succeed since the files no longer block it.
>
> Yep.
It's great we're finally on the same page ;-)
However, I don't see how this problem can be solved with your script,
or solved in general outside of that. Does this mean that Git needs to
change to treat submodules as it does normal files, per your previous
assertion, which means submodules should *not* be left behind in the
working copy as untracked files?
^ permalink raw reply
* Re: Integrating submodules with no side effects
From: Stefan Beller @ 2016-10-19 19:45 UTC (permalink / raw)
To: Robert Dailey; +Cc: Git
In-Reply-To: <CAHd499D_fehBHsNdH9PLQj+H_WAJqbbMhDwv_nCT3fZcX60ENA@mail.gmail.com>
On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
<rcdailey.lists@gmail.com> wrote:
> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbeller@google.com> wrote:
>> You could try this patch series:
>> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
>> (rebased to a newer version; no functional changes:)
>> https://github.com/stefanbeller/git/tree/submodule-co
>> (I'll rebase that later to origin/master)
>>
>>>
>>> Do you have any info on how I can prevent that error? Ideally I want
>>> the integration to go smoothly and transparently, not just for the
>>> person doing the actual transition (me) but for everyone else that
>>> gets those changes from upstream. They should not even notice that it
>>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>>
>> It depends on how long you want to postpone the transition, but I plan to
>> upstream the series referenced above in the near future,
>> which would enable your situation to Just Work (tm). ;)
>
> At first glance, what you've linked to essentially looks like
> automated `git submodule update` for every `git checkout`. Am I
> misunderstanding?
Essentially yes, except with stricter rules than the actual submodule update
IIRC.
>
> If I'm correct, this is not the same as what I'm talking about. The
> problem appears to be more internal: When a submodule is removed, the
> physical files that were there are not removed by Git.
That is also done by that series: submodules ought to be treated as files:
If you checkout a new version where a file is deleted, the checkout command
will actually remove the file for you (and e.g. solve any
directory/file conflicts
that may happen in the transition.)
> It leaves them
> there in the working copy as untracked files.
That is the current behavior as checkout tries hard to ignore submodules.
> The next step Git takes
> (again, just from outside observation) is to add those very same files
> to the working copy, since they were added to a commit. However, at
> this point Git fails because it's trying to create (write) files to
> the working copy when an exact file of that name already exists there.
> Git will not overwrite untracked files, so at this point it fails.
>
> What needs to happen, somehow, is Git sees that the files were
> actually part of a submodule (which was removed) and remove the
> physical files as well, assuming that they were not modified in the
> submodule itself. This will ensure that the next step (creating the
> files) will succeed since the files no longer block it.
Yep.
^ permalink raw reply
* Re: [PATCH v3 5/6] trailer: allow non-trailers in trailer block
From: Junio C Hamano @ 2016-10-19 19:24 UTC (permalink / raw)
To: Jonathan Tan; +Cc: Stefan Beller, git@vger.kernel.org, Jakub Narębski
In-Reply-To: <31cae41d-701c-c657-f04e-3b617c0b1d39@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> Would this work then:
> - at least one trailer line generated by Git ("(cherry picked by" or
> "Signed-off-by: ") or configured in the "trailer" section in
> git config AND at least 25% logical trailer lines
> OR
> - 100% logical trailer lines
Sure.
At that point, I doubt that the latter "100% logical trailer" makes
much difference, though, because at least one of them is likely to
be in the former set, or the users can easily make it so by throwing
what they use like "Bug: ", "Test: " and "Change-ID: " in the
"configured in the trailer section" category. FWIW, I do not think
we mind terribly to tweak the definition of "generated by Git" class
to "commonly used in Git managed projects" to include "Change-ID:"
and friends.
^ permalink raw reply
* Re: Integrating submodules with no side effects
From: Robert Dailey @ 2016-10-19 19:19 UTC (permalink / raw)
To: Stefan Beller; +Cc: Git
In-Reply-To: <CAGZ79kYKdHHcfRxCOJwNuqnOGMjBBeMy3Av5U7_ssuOp-to61w@mail.gmail.com>
On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbeller@google.com> wrote:
> You could try this patch series:
> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
> (rebased to a newer version; no functional changes:)
> https://github.com/stefanbeller/git/tree/submodule-co
> (I'll rebase that later to origin/master)
>
>>
>> Do you have any info on how I can prevent that error? Ideally I want
>> the integration to go smoothly and transparently, not just for the
>> person doing the actual transition (me) but for everyone else that
>> gets those changes from upstream. They should not even notice that it
>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>
> It depends on how long you want to postpone the transition, but I plan to
> upstream the series referenced above in the near future,
> which would enable your situation to Just Work (tm). ;)
At first glance, what you've linked to essentially looks like
automated `git submodule update` for every `git checkout`. Am I
misunderstanding?
If I'm correct, this is not the same as what I'm talking about. The
problem appears to be more internal: When a submodule is removed, the
physical files that were there are not removed by Git. It leaves them
there in the working copy as untracked files. The next step Git takes
(again, just from outside observation) is to add those very same files
to the working copy, since they were added to a commit. However, at
this point Git fails because it's trying to create (write) files to
the working copy when an exact file of that name already exists there.
Git will not overwrite untracked files, so at this point it fails.
What needs to happen, somehow, is Git sees that the files were
actually part of a submodule (which was removed) and remove the
physical files as well, assuming that they were not modified in the
submodule itself. This will ensure that the next step (creating the
files) will succeed since the files no longer block it.
^ permalink raw reply
* Re: [PATCH v4 05/14] i18n: add--interactive: mark plural strings
From: Junio C Hamano @ 2016-10-19 18:40 UTC (permalink / raw)
To: Vasco Almeida
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar
In-Reply-To: <20161010125449.7929-6-vascomalmeida@sapo.pt>
Vasco Almeida <vascomalmeida@sapo.pt> writes:
> @@ -669,12 +669,18 @@ sub status_cmd {
> sub say_n_paths {
> my $did = shift @_;
> my $cnt = scalar @_;
> - print "$did ";
> - if (1 < $cnt) {
> - print "$cnt paths\n";
> - }
> - else {
> - print "one path\n";
> + if ($did eq 'added') {
> + printf(__n("added %d path\n", "added %d paths\n",
> + $cnt), $cnt);
> + } elsif ($did eq 'updated') {
> + printf(__n("updated %d path\n", "updated %d paths\n",
> + $cnt), $cnt);
> + } elsif ($did eq 'reverted') {
> + printf(__n("reverted %d path\n", "reverted %d paths\n",
> + $cnt), $cnt);
> + } else {
> + printf(__n("touched %d path\n", "touched %d paths\n",
> + $cnt), $cnt);
> }
> }
Nice to see you covered all verbs currently in use and then
future-proofed by adding a fallback "touched" here.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox