On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
>
> I really hope that it hasn't been broken for 5 years and I am just doing
> something wrong.
On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote:
> I ran "git checkout" on a large repo and averaged the results of 3 runs.
> This clearly demonstrates the benefit of the optimized unpack_trees()
> as even the final "diff-index" is essentially a 3rd call to unpack_trees().
>
> baseline
Alban Gruin writes:
> As pointed out by SZEDER Gábor, git-rebase.sh wrote to to 'quiet' with
> an `echo`:
>
> echo "$GIT_QUIET" > "$state_dir/quiet"
>
> This mean that even if $GIT_QUIET is empty, a newline is written to
> quiet. The rewrite of write_basic_state() changed this behaviour,
Stefan Beller writes:
> On Mon, Jul 30, 2018 at 1:18 PM Junio C Hamano wrote:
>
>> > I already pushed an update to https://github.com/gitgitgadget/git/pull/1.
>>
>> Should I take "pushed to ... GGG" to mean "do not merge what you
>> have to 'next' yet, as there will be an updated series (not
>>
Stefan Beller writes:
> It turns out it doesn't quite do that;
> The parsing code takes the old notation into account and translates any
> [V.A]
> r = ...
> into a lower cased "v.a." for ease of comparison. That happens in
> get_base_var, which would call further into get_extended_base_var
On Tue, Jul 31, 2018 at 09:37:51AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Jul 30 2018, Han-Wen Nienhuys wrote:
>
>
> > + if (sideband_use_color < 0) {
> > + const char *key = "color.remote";
> > + char *value = NULL;
> > + if
Bisecting around, this might be the commit that introduced the breakage.
https://github.com/git/git/commit/d8febde
I really hope that it hasn't been broken for 5 years and I am just doing
something wrong.
On Tue, Jul 31, 2018 at 10:09 AM George Shammas wrote:
> At work, we recently updated
On Mon, Jul 16 2018, Jonathan Tan wrote:
Didn't catch this until this was in next, sorry.
Re-arranged the diff a bit:
> -void fetch_negotiator_init(struct fetch_negotiator *negotiator)
> +void fetch_negotiator_init(struct fetch_negotiator *negotiator,
> +const char
Han-Wen Nienhuys writes:
> On Mon, Jul 30, 2018 at 11:39 PM Junio C Hamano wrote:
>> > + */
>> > +void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
>>
>> I'll make this "static" to this file while queuing.
>
> Does that mean the patch is in?
It depends on your
Luke Diamand writes:
> I think there is an error in the test harness.
>
> On 31 July 2018 at 10:46, SZEDER Gábor wrote:
>>> + test_must_fail git-p4 submit --dry-run >errs 2>&1 &&>
>>> + ! grep "Would apply" err
>
> It writes to the file "errs" but then looks for the
On Tue, Jul 31 2018, Michael Felt wrote:
> I hope a I have a "leap forward"
>
>
> On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
>> Perhaps it's worth taking a step back here and thinking about whether
>> this whole thing is unworkable. It was hard enough to get this to work
>> on the
At work, we recently updated from a massively old version of git (1.7.10)
to 2.18. There are a few code bases that use subtrees, and they seem to
have completely broke when trying to merge in updates.
I have confirmed that it works correctly in 1.7.10. The 2.18 behavior is
clearly incorrect.
I hope a I have a "leap forward"
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> Perhaps it's worth taking a step back here and thinking about whether
> this whole thing is unworkable. It was hard enough to get this to work
> on the combination of Linux, *BSD and Solaris, but I suspect
I think there is an error in the test harness.
On 31 July 2018 at 10:46, SZEDER Gábor wrote:
>> + test_must_fail git-p4 submit --dry-run >errs 2>&1 &&>
>> + ! grep "Would apply" err
It writes to the file "errs" but then looks for the message in "err".
Luke
Calling the test tag "Tag" will make for confusing reading later in
this series when making use of the "git push tag "
feature. Let's call the tag testTag instead.
Changes code initially added in dbfeddb12e ("push: require force for
refs under refs/tags/", 2012-11-29).
Signed-off-by: Ævar
It took me a long time to submit a re-roll for this, but this should
solve all issues noted with v1, see
https://public-inbox.org/git/20180429202100.32353-1-ava...@gmail.com/
for the notes on that.
A range-diff with v1 follows below.
2: a47d861704 ! 1: 77a612e89c push tests: fix logic error
Improve the tests added in dbfeddb12e ("push: require force for refs
under refs/tags/", 2012-11-29) to assert that the same behavior
applies various other combinations of command-line option and
refspecs.
Supplying either "+" in refspec or "--force" is sufficient to clobber
the reference. With
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20), before this
change all tag fetches effectively had --force enabled. See
The test suite only incidentally (and unintentionally) tested for the
current behavior of eager tag clobbering on "fetch". This follow-up to
the previous "push tests: assert re-pushing annotated tags" change
tests for it explicitly.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Change the test that asserts that lightweight tags can only be
clobbered by a force-push to check do the same tests for annotated
tags.
There used to be less exhaustive tests for this with the code added in
40eff17999 ("push: require force for annotated tags", 2012-11-29), but
Junio removed them
Correct a comment referring to the removal of just the branch to also
refer to the tag. This should have been changed in my
ca3065e7e7 ("fetch tests: add a tag to be deleted to the pruning
tests", 2018-02-09) when the tag deletion was added, but I missed it
at the time.
Signed-off-by: Ævar
There's complex rules governing whether a push is allowed to take
place depending on whether we're pushing to refs/heads/*, refs/tags/*
or refs/not-that/*. See is_branch() in refs.c, and the various
assertions in refs/files-backend.c. (e.g. "trying to write non-commit
object %s to branch '%s'").
It should be "is not an empty string" not "is not empty string". This
fixes wording originally introduced in ab9b31386b ("Documentation:
multi-head fetch.", 2005-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/pull-fetch-param.txt | 2 +-
1 file changed, 1 insertion(+), 1
Fix a logic error that's been here since this test was added in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29).
The intent of this test is to force-create a new tag pointing to
HEAD~, and then assert that pushing it doesn't work without --force.
Instead, the code was
Remove an invocation of 'git push' that's exactly the same as the one
on the preceding line. This was seemingly added by mistake in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29) and doesn't affect the result of the test, the second
"push" was a no-op as there was nothing
On Mon, Jul 30, 2018 at 05:38:06PM -0400, Eric Sunshine wrote:
> > I wonder if it should look for something like [A-Z][A-Z_]* to catch
> > all of these.
>
> I considered that, but it doesn't handle nested here-docs, which we
> actually have in the test suite. For instance, from
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> The reason we're in this hole is because we use this
> sha1collisiondetection library to do SHA-1, and the reason we have
> issues with it specifically (not OpenSSL et al) is because its only
> method of detecting endianness is at compile
As pointed out by SZEDER Gábor, git-rebase.sh wrote to to 'quiet' with
an `echo`:
echo "$GIT_QUIET" > "$state_dir/quiet"
This mean that even if $GIT_QUIET is empty, a newline is written to
quiet. The rewrite of write_basic_state() changed this behaviour, which
could lead to problems. This
On Tue, Jul 31, 2018 at 6:46 AM Eric Sunshine wrote:
> Anyhow, thanks for reading over the series. I appreciate it even if
> our "sense of priority" doesn't always align (as evidenced by your
> review comments and my responses).
To be clear, the changes you suggest all make sense, and would be
Hi Eric
On 31/07/18 11:46, Eric Sunshine wrote:
> On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood
> wrote:
>> On 31/07/18 08:33, Eric Sunshine wrote:
>>> Patch 2/4 of this series conflicts with Akinori MUSHA's
>>> 'am/sequencer-author-script-fix' which takes a stab at fixing one of the
>>> four
From: Phillip Wood
The calling code treated NULL as a valid return value, so fix this by
returning and integer and passing in a parameter to receive the author.
Signed-off-by: Phillip Wood
---
sequencer.c | 49 ++---
1 file changed, 26
From: Phillip Wood
Single quotes should be escaped as \' not \\'. Note that this only
affects authors that contain a single quote and then only external
scripts that read the author script and users whose git is upgraded from
the shell version of rebase -i while rebase was stopped. This is
From: Phillip Wood
These build on Eric's patches. The first patch would be better if it
was integrated into Eric's patches. The second is a rebased version of
my previous patch for fixing quoting in the author script with some
additions by Johannes and rebased on top of Eric's fixes. The special
On Mon, Jul 30, 2018 at 11:39 PM Junio C Hamano wrote:
> > + */
> > +void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
>
> I'll make this "static" to this file while queuing.
Does that mean the patch is in?
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood wrote:
> On 31/07/18 08:33, Eric Sunshine wrote:
> > Patch 2/4 of this series conflicts with Akinori MUSHA's
> > 'am/sequencer-author-script-fix' which takes a stab at fixing one of the
> > four (or so) bugs fixed by this series (namely, adding a
A small step back...
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Jul 29 2018, Michael wrote:
On 29/07/2018 22:06, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
On 29/07/2018 21:27, brian m. carlson wrote:
Well, that explains it. I
On Tue, Jul 31, 2018 at 6:02 AM Phillip Wood wrote:
> On 31/07/18 08:33, Eric Sunshine wrote:
> > + /* validate date since fmt_ident() will die() on bad value */
> > + if (parse_date(val[2], )){
> > + warning(_("invalid date format '%s' in '%s'"),
> > +
On Tue, Jul 31, 2018 at 6:01 AM Phillip Wood wrote:
> Now that the author is correct, can we test_cmp() it against its
> expected value to make sure there are no hidden surprises in the name
> and email in the future. (It would be reassuring to test an author with
> "'" in the name as well but
On Tue, Jul 31, 2018 at 5:50 AM Phillip Wood wrote:
> On 31/07/18 08:33, Eric Sunshine wrote:
> > - sq_dequote(in);
> > + if (!sq_dequote(in)) {
> > + warning(_("bad quoting on %s value in '%s'"),
> > + keys[i],
Hi Eric
On 31/07/18 08:33, Eric Sunshine wrote:
This is a re-roll of [1] which fixes sequencer bugs resulting in commit
object corruption when "rebase -i --root" swaps in a new commit as root.
Unfortunately, those bugs made it into v2.18.0 and have already
corrupted at least one repository (a
I have just replied to
https://github.com/cr-marcstevens/sha1collisiondetection/pull/42
I checked a gcc compiler on AIX, and I have the defines for vac.
I do not have access yet to SLES or RHEL (or Ubuntu), just a "free
Debian" on my Power6.
* my conclusions|recommendations:
a) AIX is
On 31/07/18 08:33, Eric Sunshine wrote:
read_author_ident() is careful to handle errors "gently" when parsing
"rebase-merge/author-script" by printing a suitable warning and
returning NULL; it never die()'s. One possible reason that parsing might
fail is that "rebase-merge/author-script" has
On 31/07/18 08:33, Eric Sunshine wrote:
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timestamp by prepending a "@":
author A U Thor @1112912773 -0700
The commit parser is very strict about the format of the "author"
header, and does not allow a
On 31/07/18 08:33, Eric Sunshine wrote:
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timezone by repeating the last digit:
author A U Thor @1112912773 -07000
This is due to two bugs.
First, write_author_script() neglects to add the closing
Ich habe einen Wohltätigkeitsfonds für Sie im Wert von € 4,800,000. Diese
Spende ist
für die ersten 5 Personen, die auf diese E-Mail antworten, die als Form von
Wohltätigkeitshäusern zu Ehren meiner verstorbenen Frau gegeben wird, die an
Krebs
gestorben ist. Kontaktieren Sie meinen Anwalt
Ich habe einen Wohltätigkeitsfonds für Sie im Wert von € 4,800,000. Diese
Spende ist
für die ersten 5 Personen, die auf diese E-Mail antworten, die als Form von
Wohltätigkeitshäusern zu Ehren meiner verstorbenen Frau gegeben wird, die an
Krebs
gestorben ist. Kontaktieren Sie meinen Anwalt
> diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
> index 4849edc4e..2b7baa95d 100755
> --- a/t/t9800-git-p4-basic.sh
> +++ b/t/t9800-git-p4-basic.sh
> @@ -261,6 +261,35 @@ test_expect_success 'unresolvable host in P4PORT should
> display error' '
> )
> '
>
> +# Test
On Mon, Jul 30 2018, Han-Wen Nienhuys wrote:
> + if (sideband_use_color < 0) {
> + const char *key = "color.remote";
> + char *value = NULL;
> + if (!git_config_get_string(key, ))
> + sideband_use_color = git_config_colorbool(key,
read_author_ident() is careful to handle errors "gently" when parsing
"rebase-merge/author-script" by printing a suitable warning and
returning NULL; it never die()'s. One possible reason that parsing might
fail is that "rebase-merge/author-script" has been hand-edited in such a
way which corrupts
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timestamp by prepending a "@":
author A U Thor @1112912773 -0700
The commit parser is very strict about the format of the "author"
header, and does not allow a "@" in that position.
The "@" comes from
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timezone by repeating the last digit:
author A U Thor @1112912773 -07000
This is due to two bugs.
First, write_author_script() neglects to add the closing quote to the
value of GIT_AUTHOR_DATE when
This is a re-roll of [1] which fixes sequencer bugs resulting in commit
object corruption when "rebase -i --root" swaps in a new commit as root.
Unfortunately, those bugs made it into v2.18.0 and have already
corrupted at least one repository (a local project of mine). Patches 3/4
and 4/4 are new.
When "git rebase -i --root" creates a new root commit (say, by swapping
in a different commit for the root), it corrupts the commit's "author"
header with trailing garbage:
author A U Thor @1112912773 -0700...@example.com
This is a result of read_author_ident() neglecting to NUL-terminate
101 - 153 of 153 matches
Mail list logo
