Jonathan Nieder writes:
> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
> support it). See t/t3600-rm.sh for an example of a portable way to do
Is that "too recent"? I thought it was bashism, not even in POSIX,
but I may be mistaken.
Quite honestly, our tests are
Max Kirillov writes:
> On Sat, Aug 04, 2018 at 08:34:08AM +0200, Duy Nguyen wrote:
>> On Fri, Jul 27, 2018 at 5:50 AM Max Kirillov wrote:
>>> + if (max_request_buffer < req_len) {
>>> + die("request was larger than our maximum size (%lu): "
>>> + "%"
Duy Nguyen writes:
> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder wrote:
>> My main concern is not about them but about other
>> people building from source in order to run (instead of to develop)
>> Git, and by extension, the people they go to for help when it doesn't
>> work. I have lots
Stefan Beller writes:
> Try it out via
> ./git-format-patch --mark-moved 15ef69314d^..15ef69314d
> to see if you like it.
>
> This separates the coloring decision from the detection of moved lines.
> When giving --mark-moved, move detection is still performed and the output
> markers are
Stefan Beller writes:
> This builds on top of sb/range-diff-colors, which builds on js/range-diff.
As another round of js/range-diff is expected, according to
I will refrain from queuing this right now. Possible conflict
resolution that won't be reusable when the base one is rerolled and
Edward Thomson writes:
> In any case, it sounds like you're not particularly interested in
> this, although I certainly appreciate you taking the time to suggest
> improvements despite that. There's some good feedback there.
Not in its current shape. But do not take this in a wrong way. It
Edward Thomson writes:
> Introduce git-recover, a simple script to aide in restoration of deleted
> worktree files. This will look for unreachable blobs in the object
> database and prompt users to restore them to disk, either interactively
> or on the command-line.
> ---
> git-recover.sh |
Elijah Newren writes:
> This test description looks like it was written with the originally
> observed behavior ("causes segfault") rather than the desired and now
> current behavior ("does not cause segfault"). Fix it.
GOod.
>
> Signed-off-by: Elijah Newren
> ---
>
Elijah Newren writes:
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git diff command, i.e. that grep
Andrei Rybak writes:
> Tests for "git am --[no-]scissors" [1] work in the following way:
>
> 1. Create files with commit messages
> 2. Use these files to create expected commits
> 3. Generate eml file with patch from expected commits
> 4. Create commits using git am with these eml files
>
Stefan Beller writes:
> * Introduce new patch
> "submodule--helper: replace connect-gitdir-workingtree by
> ensure-core-worktree"
> that resolves the conflict with earlier versions of this series with
> sb/submodule-core-worktree
> * This series is based on master, which already contains
Eric Sunshine writes:
>> + shift; break ;;
>> + *)
>> + usage ;;
>
> There doesn't seem to a usage() function defined anywhere (and
> OPTIONS_SPEC doesn't seem to be used).
Isn't this using the parse-options thing git-sh-setup gives us for
free?
Stefan Beller writes:
> - The second part of having an immediate plan is *very* nice
> to see, though I would argue that it could be improved
> by having these updates in the thread instead of summarized
> unrelated to that thread.
>
> We do not do this for now due to tooling issues, I
"Johannes Schindelin via GitGitGadget"
writes:
> + /*
> + * Insert after every pick. Here, fixup/squash chains
> + * are considered part of the pick, so we insert the commands *after*
> + * those chains if there are any.
> + */
> + insert_final_commands = 1;
> +
Brandon Williams writes:
> [1]
> https://public-inbox.org/git/cagz79kygs4dvoetygx01cinrxxlcqgxovsplhmgyz8b51lz...@mail.gmail.com/
> This mail seems to counter that indicating that the "What's Cooking"
> emails should not be used as a status update.
You are the second one who were negatively
Junio C Hamano writes:
> "brian m. carlson" writes:
>
>> On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
>>> "brian m. carlson" writes:
>>>
>>> >
"brian m. carlson" writes:
> On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
>> >> -
Jeff Hostetler writes:
> Another thing to keep in mind is that the collision could be because
> of case folding (or other such nonsense) on a directory in the path.
> I mean, if someone on Linux builds a commit containing:
>
> a/b/c/D/e/foo.txt
> a/b/c/d/e/foo.txt
>
> we'll get a similar
"brian m. carlson" writes:
> On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
>> --
>> [New Topics]
>
> I had expected to see
> <20180729192803.1047050-1-sand...@crustytoothpaste.net> (the r
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The idea of `--exec` is to append an `exec` call after each `pick`.
>
> Since the introduction of fixup!/squash! commits, this idea was extended
> to apply to "pick, possibly followed by a fixup/squash chain", i.e.
Santiago Torres writes:
> Now that I think about it though, verify tag can verify more than one
> tag. I assume that this would make it difficult to propagate individual
> errors in trusting. I honestly don't know what's the best way to modify
> this behavior then.
I am not sure if changing the
Duy Nguyen writes:
> Another friendly ping. I really need to know if I need to update (or
> drop) this part before moving on to part 3.
Easier is to resend and see if it sticks this time (that is how I
landed format-patch back when I was just an individual contributor
;-)
I will see if I can
Phillip Wood writes:
> ... [I'm beginning to see why all the other programs I tried while
> writing this (tig, gitg, gitk and mercurial's version of add -i)
> don't make any attempt to stage modified lines correctly, though I
> think git should have some way of doing it.]
Yes, this is a kind of
Jonathan Nieder writes:
> Sorry for the slow review. I finally got a chance to look this over
> again.
>
> My main nits are about the commit message: I think it still focuses
> too much on the process instead of the usual "knowing what I know now,
> here's the clearest explanation for why we
Antonio Ospite writes:
> The rationale behind the change is to close the circle started with 04
> and 05 and stop referring to .gitmodules explicitly by file path in git
> commands. The change is not strictly needed for the series, it's for
> consistency sake.
Sorry, but I am still not quite
Pratik Karki writes:
> Hi Junio,
>
> On Fri, Aug 3, 2018 at 4:47 AM Junio C Hamano wrote:
>>
>> * pk/rebase-in-c (2018-07-30) 3 commits
>> - builtin/rebase: support running "git rebase "
>> - rebase: refactor common shell functions into thei
Stefan Beller writes:
> On Thu, Aug 2, 2018 at 4:02 PM Junio C Hamano wrote:
>
>> * sb/config-write-fix (2018-08-01) 3 commits
>> - git-config: document accidental multi-line setting in deprecated syntax
>> - config: fix case sensitive subsection names on writing
>&
Jeff King writes:
> This is returning the value of git_config_from_file(), which is 0/-1. I
> think it should be left where it is in the original, and not part of
> this block of functions.
>
> Other than that, the patch seems sane to me (I think the 0/1 return
> value from these "get" functions
Eric Sunshine writes:
> I think this patch can be simplified considerably by shifting one's
> perspective. If we admit that read_author_ident() is already correctly
> reporting an error by returning NULL (which is exactly what it is
> doing), then the bug is is purely on the calling side;
Stefan Beller writes:
> And *technically* the two level is old style, so I figured it's ok.
If we call the bit not after the recentness of the style but after
what it is about, e.g. "is the section name as a whole (including
its possible subsection part) case insensitive?", then yes, a
René Scharfe writes:
> Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>>> patch of mine and replace it with something René came up wi
René Scharfe writes:
> Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
>>
>> Straying sideways into a tangent, but do we know if any locale wants
>> to use something other than "<>" as an enclosing braket around a
>> placeholder?
>
> Bulga
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.
Many topics have moved to
ction not to stop at the first
match but find the match with the highest precedence.
This is based on an earlier work, which special cased only the exact
matches, by Jonathan Tan.
Helped-by: Jonathan Tan
Helped-by: Jonathan Nieder
Signed-off-by: Junio C Hamano
---
* OK, with the NUM_REV_
Ramsay Jones writes:
>> OPT_BOOL( 0 , "ignore-missing", _missing, N_("check if - even
>> missing - files are ignored in dry run")),
>> -OPT_STRING( 0 , "chmod", _arg, N_("(+/-)x"), N_("override the
>> executable bit of the listed files")),
>> +{ OPTION_STRING, 0, "chmod", _arg,
Andrei Rybak writes:
> On 2018-08-02 21:17, René Scharfe wrote:
>> Don't translate the argument specification for --chmod; "+x" and "-x"
>> are the literal strings that the commands accept.
>> > [...]
>>
>> -OPT_STRING( 0 , "chmod", _arg, N_("(+/-)x"), N_("override the
>> executable bit of
Jeff King writes:
> I also wonder if Windows could return some other file-unique identifier
> that would work in place of an inode here. That would be pretty easy to
> swap in via an #ifdef's helper function. I'd be OK shipping without that
> and letting Windows folks fill it in later (as long
Ævar Arnfjörð Bjarmason writes:
> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
> patch of mine and replace it with something René came up with (I have
> not yet read his 1-6 patches submitted on this topic, so maybe they're
> not mutually exclusive).
I think the
René Scharfe writes:
> diff --git a/parse-options.c b/parse-options.c
> index 7db84227ab..3b874a83a0 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const char
> *prefix,
> static int usage_argh(const struct option
René Scharfe writes:
> Am 02.08.2018 um 18:54 schrieb Jeff King:
>> PS I actually would have made the rule simply "does it begin with a
>> '<'", which seems simpler still. If people accidentally write "> forgetting to close their brackets, that is a bug under both the
>> old and new
Stefan Beller writes:
>> Am I correct to understand that this patch is a "FIX" for breakage
>> introduced by that commit? The phrasing is not helping me to pick
>> a good base to queue these patches on.
>
> Please pick 4f4d0b42bae (Merge branch 'js/empty-config-section-fix',
> 2018-05-08)
> as
Eric Sunshine writes:
> On Thu, Aug 2, 2018 at 1:37 PM Junio C Hamano wrote:
>> Johannes Schindelin writes:
>> > ACK!
>>
>> Did you write a buggy caller that would have been caught or helped
>> with this change? You did not write the callee that is made mor
Antonio Ospite writes:
> Add a --stage option to the 'submodule--helper config' command so that
> the .gitmodules file can be staged without referring to it explicitly by
> its file path.
Sorry, but I have no clue what the above is trying to say.
The original 's--h config []' is quite
SZEDER Gábor writes:
>> Tests 5 and 8 in t/t7411-submodule-config.sh add two commits with
>> invalid lines in .gitmodules but then only the second commit is removed.
>>
>> This may affect future subsequent tests if they assume that the
>> .gitmodules file has no errors.
>>
>> Since those
Christian Couder writes:
> Looking at the code of the patches again, I can't see any simple way
> to improve on the way it is done.
Thanks.
Han-Wen Nienhuys writes:
> The colorization is controlled with the config setting "color.remote".
> ...
> Finally, this solution is backwards compatible: many servers already
> prefix their messages with "error", and they will benefit from this
> change without requiring a server update. By
Johannes Schindelin writes:
> Hi Eric,
>
> On Thu, 2 Aug 2018, Eric Sunshine wrote:
>
>> want_color_fd() is designed to work only with standard input, output,
>> and error file descriptors, and stores information about each descriptor
>> in an array. However, it doesn't verify that the passed-in
Han-Wen Nienhuys writes:
> ---
> config.h | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Should I forge your sign-off on this patch?
>
> diff --git a/config.h b/config.h
> index b95bb7649..41700f40b 100644
> --- a/config.h
> +++ b/config.h
> @@ -178,10 +178,16 @@ struct
Phillip Wood writes:
> From: Phillip Wood
>
> Single quotes should be escaped as \' not \\'. The bad quoting breaks
> the interactive version of 'rebase --root' (which is used when there is
> no '--onto' even if the user does not specify --interactive) for authors
> that contain "'" as
Duy Nguyen writes:
>> But even if inum is unreliable, we should be able to use other
>> clues, perhaps the same set of fields we use for cached stat
>> matching optimization we use for "diff" plumbing commands, to
>> implement the error report. The more important part of the idea is
>> that we
René Scharfe writes:
> Am 02.08.2018 um 17:44 schrieb Junio C Hamano:
>> Subject: [PATCH] push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced
>> brackets
>> From: Ævar Arnfjörð Bjarmason
>> Date: Thu, 02 Aug 2018 00:31:33 +0200
>> ...
>> offic
Stefan Beller writes:
> On Wed, Aug 1, 2018 at 12:13 PM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > Stefan Beller (8):
>> > test_decode_color: understand FAINT and ITALIC
>> > t3206: add color test for range-diff --dual-col
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>>> + /* N_() will get "<>" around, resulting in
>>> ":" */
>>
>> ...but this comment isn't accurate at all, N_() doesn't wrap the string
>> with <>
René Scharfe writes:
> We could check if argh comes with its own angle brackets already and
> not add a second pair in that case, making PARSE_OPT_LITERAL_ARGHELP
> redundant in most cases, including the one above. Any downsides?
> Too magical?
Hmph.
> -- >8 --
> Subject: [PATCH]
Ævar Arnfjörð Bjarmason writes:
> On Thu, Aug 02 2018, René Scharfe wrote:
>
>> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
>>> But looking at this again it looks like this whole thing should just be
>>> replaced by:
>>>
>>> diff --git a/builtin/push.c b/builtin/push.c
>>>
Jonathan Nieder writes:
>> +const int num_rules = ARRAY_SIZE(ref_rev_parse_rules) - 1;
>
> This is assuming ref_rev_parse_rules consists exactly of its items
> followed by a NULL terminator, which is potentially a bit subtle. I
> wonder if we should put
>
> static const char
Stefan Beller writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
Perhaps
s/use/user/
s/case indentation issues/section mix-up/
> ... However we do not have a test for writing out config correctly with
Ramsay Jones writes:
> On 01/08/18 20:34, Stefan Beller wrote:
>> A use reported a submodule issue regarding strange case indentation
>
> s/use/user/ ?
True. Also s/indentation/something else/ ?
Insufficient proofreading, perhaps?
Brandon Williams writes:
> ..., I expect we may need to do a bit more work on the whole
> fetching stack to get what we'd want in that case (because we would want
> to avoid this issue again).
Amen. Thanks all.
Derrick Stolee writes:
> On 7/25/2018 6:13 PM, Junio C Hamano wrote:
>> * ds/multi-pack-index (2018-07-20) 23 commits
>> ...
>> Ready to move to 'next', with some known issues to be followed up?
>> cf.
> I'm not sure if there is anything actionable for me to do
Derrick Stolee writes:
>> Stuck in review?
>> cf. <20180723203500.231932-1-jonathanta...@google.com>
>
> This comments on the initial values of 'struct ref_filter' (that are
> not used). All we need is the diff below squashed into "test-reach:
> test commit_contains".
>
>> cf.
Ævar Arnfjörð Bjarmason writes:
>> + /* N_() will get "<>" around, resulting in
>> ":" */
>
> ...but this comment isn't accurate at all, N_() doesn't wrap the string
> with <>'s, as can be seen by applying this patch:
I know. It is a short-hand for "what's inside N_() we see
Junio C Hamano writes:
> Jeff King writes:
>
>>> Presumably we are already in an error codepath, so if it is
>>> absolutely necessary, then we can issue a lstat() to grab the inum
>>> for the path we are about to create, iterate over the previously
>>>
Stefan Beller writes:
> Stefan Beller (8):
> test_decode_color: understand FAINT and ITALIC
> t3206: add color test for range-diff --dual-color
> diff.c: simplify caller of emit_line_0
> diff.c: reorder arguments for emit_line_ws_markup
> diff.c: add set_sign to emit_line_0
> diff:
Johannes Schindelin writes:
>> If any other issue arises, I do not mind taking an update, either,
>> but I think at this point the topic is reaching the point of
>> diminishing returns and should switch to incremental.
>
> Thomas had a couple of good suggestions, still, and I am considering to
>
m wasting time just like I
did ;-)
Signed-off-by: Junio C Hamano
---
builtin/push.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/push.c b/builtin/push.c
index 9cd8e8cd56..9608b0cc4f 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -558,6 +558,7 @@ int cmd_push(in
Jonathan Tan writes:
>> +test_expect_success 'LHS of refspec follows ref disambiguation rules' '
>> +mkdir lhs-ambiguous &&
>> +(
>> +cd lhs-ambiguous &&
>> +git init server &&
>> +test_commit -C server unwanted &&
>> +test_commit -C server
Han-Wen Nienhuys writes:
> On Wed, Aug 1, 2018 at 5:41 PM Junio C Hamano wrote:
>
>> Hmm, do we actually say things like "Error: blah"? I am not sure if
>> I like this strncasecmp all that much.
>
> this is for the remote end, so what we (git-core) says isn'
Chen Bin writes:
> The `p4-pre-submit` hook is executed before git-p4 submits code.
> If the hook exits with non-zero value, submit process won't start.
>
> Signed-off-by: Chen Bin
> ---
I see that the only difference between this and what has been queued
on 'pu', i.e.
ction not to stop at the first
match but find the match with the highest precedence.
This is based on an earlier work, which special cased only the exact
matches, by Jonathan Tan.
Signed-off-by: Junio C Hamano
---
* This time, with a log message, updated "precedence" number, a
Eric Sunshine writes:
> On Tue, Jul 31, 2018 at 1:37 PM Han-Wen Nienhuys wrote:
>> Highlight keywords in remote sideband output.
>
> Prefix with the module you're touching, don't capitalize, and drop the
> period. Perhaps:
>
> sideband: highlight keywords in remote sideband output
Yup (I
Phillip Wood writes:
>> Is the:
>>
>> ...for some reason sq_dequote() called by read_author_ident()
>> seems to handle the broken quoting correctly.
>>
>> bit outdated? We know now from patch 2/4 of my series[1] that
>> read_author_ident() wasn't handling it correctly at all. It was
chen bin writes:
> I updated the patch. But for some reason the test keep failing at this line,
> `test_must_fail git p4 submit --dry-run >errs 2>&1 &&`.
>
> If I change this line to `test_must_fail git-p4 submit --dry-run >errs
> 2>&1 &&` the test will pass.
Hmph. I somehow suspect that the
Jonathan Tan writes:
> This looks good to me. I've checked that refname_match (and
> branch_merge_matches(), which returns the result of refname_match()
> directly) is only used in "if" contexts, so making it return a value
> other than 1 is fine.
Yes, the log message should say that existing
Junio C Hamano writes:
> In order to resolve this correctly with the precedence rules, I
> think you need to make refname_match() return the precedence number
> (e.g. give 1 to "%.*s", 2 to "refs/%.*s", etc., using the index in
> ref_rev_parse_rules[] array
Jonathan Tan writes:
> When matching a non-wildcard LHS of a refspec against a list of refs,
> find_ref_by_name_abbrev() returns the first ref that matches using the
> DWIM rules used by refname_match() in refs.c, even if an exact match
> occurs later in the list of refs.
When you have
Jeff King writes:
> On Mon, Jul 30, 2018 at 03:56:01PM -0700, Jonathan Tan wrote:
>
>> Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
>> 2018-06-28) allows transports to report the refs that they have fetched
>> in a new out-parameter "fetched_refs". If they do so,
>>
Jeff King writes:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> ...
> So here it is fixed, and with a commit message. I'm not happy to omit a
> regression test, but I actually couldn't come up with a minimal one that
> tickled the problem, because we're playing around with
Jeff King writes:
>> Presumably we are already in an error codepath, so if it is
>> absolutely necessary, then we can issue a lstat() to grab the inum
>> for the path we are about to create, iterate over the previously
>> checked out paths issuing lstat() and see which one yields the same
>>
Stefan Beller writes:
> The 'expect'ed outcome has been taken by running the 'range-diff | decode'.
>
> Signed-off-by: Stefan Beller
> ---
> t/t3206-range-diff.sh | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/t/t3206-range-diff.sh
Stefan Beller writes:
> A use reported a submodule issue regarding strange case indentation
> issues, but it could be boiled down to the following test case:
>
> $ git init test && cd test
> $ git config foo."Bar".key test
> $ git config foo."bar".key test
> $ tail -n 3 .git/config
>
Jeff King writes:
> On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> ...
>> collapses two (or more) paths if we go that way. We only need to
>> report "we tried to check out X but it seems your filesystem equates
>> something else that is also in th
Ben Peart writes:
> The biggest change in this version was suggested in feedback to the last
> patch. I have turned on the optimzation by default if sparse-checkout is
> not on so that most users do not have to set anything and they will get the
> benefit of the optimization.
Sounds like a
Han-Wen Nienhuys writes:
> The highlighting is done on the client-side. Supported keywords are
> "error", "warning", "hint" and "success".
>
> The colorization is controlled with the config setting "color.remote".
>
> Co-authored-by: Duy Nguyen
> Signed-off-by: Han-Wen Nienhuys
Thanks. I'll
Alban Gruin writes:
> This patch series rewrite the interactive rebase from shell to C.
Thanks.
> It is based on ffc6fa0e39 ("Fourth batch for 2.19 cycle", 2018-07-24).
> The v4 was based on b7bd9486 ("Third batch for 2.19 cycle", 2018-07-18).
> I wanted to make sure my series works well with
Elijah Newren writes:
> Is it worth attempting to also warn about paths that only differ in
> UTF-normalization on relevant MacOS systems?
I hate to bring up a totally different approach this late in the
party, but I wonder if it makes more sense to take advantage of
"clone" being a command
Nguyễn Thái Ngọc Duy writes:
> Another thing we probably should do is catch in "git checkout" too,
> not just "git clone" since your linux/unix colleage colleague may
> accidentally add some files that your mac/windows machine is not very
> happy with.
Then you would catch it not in checkout
1: 00f94a8b41 t1015: demonstrate directory/file conflict
>> recovery failures
>> @@ -14,7 +14,6 @@
>>
>> Signed-off-by: Elijah Newren
>> Signed-off-by: Junio C Hamano
>> -Message-Id: <20180713163331.22446-2-new...@gmail.com>
>&
Ævar Arnfjörð Bjarmason writes:
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 97d3217df9..5b624caf58 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -49,11 +49,16 @@ endif::git-pull[]
>
> -f::
> --force::
Ævar Arnfjörð Bjarmason writes:
> 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 writes:
> The is often the name of the branch you would want to push, but
> -it can be any arbitrary "SHA-1 expression", such as `master~4` or
> -`HEAD` (see linkgit:gitrevisions[7]).
> +it can be any arbitrary expression to a commit, such as `master~4` or
> +`HEAD`
Junio C Hamano writes:
> As the number of his or her own topics each contributor needs to
> keep track of by definition is the number of all topics I need to
s/is the/is smaller than the/;
Sorry for the noise X-<.
> take care of, I do not want to have to keep track of things m
Jeff King writes:
> +...
> + } else if (cmp > 0) {
> /* path2 does not appear in one */
> + score += score_missing(two.entry.mode, two.entry.path);
> + update_tree_entry();
> + continue;
> +
Jeff King writes:
> The problem introduced in that commit is that each iteration through the
> loop advances the tree pointers.
Ah, indeed.
The original used tree_entry_extract() and update_tree_entry()
separately, but the update does tree_entry() on both sides.
> So the assertion in that
Alban Gruin writes:
>> Hmph, from reading your other message
>>
>>
>> https://public-inbox.org/git/dce8c99b-51e9-4ed1-8ae4-28049cb6e...@gmail.com/
>>
>> I got an impression that a rerolled version is coming anyway. Is
>> this fix so urgent that it needs tobe squashed in in the meantime
>>
George Shammas writes:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
Interesting. I've never used the "-s subtree" strategy without
"-Xsubtree=..." to explicitly tell where the thing should go for a
long time, so I am
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 t
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
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.
>
> Do
1401 - 1500 of 27729 matches
Mail list logo
