Junio C Hamano writes:
> Stefan Beller writes:
>
>> The helper function stayed unused for 3 years. A removal of that function
>
> I think it stayed unused for more than that before the previous
> proposal to remove it was written (I do not bother going back to
Stefan Beller writes:
> The helper function stayed unused for 3 years. A removal of that function
I think it stayed unused for more than that before the previous
proposal to remove it was written (I do not bother going back to my
earlier message that identified which exact commit this was
Stefan Beller writes:
> On Tue, Sep 11, 2018 at 11:16 AM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> >> [...] So this should be sufficient.
>> >
>> > Yup.
>> > Thanks for keeping track of this patch, as I lost track
Junio C Hamano writes:
>>> + /*
>>> +* According to RFC 3875, an empty or missing
>>> +* CONTENT_LENGTH means "no body", but RFC 3875
>>> +* precedes HTTP/1.1 and chunked encoding. Apache and
>>
Stefan Beller writes:
>> [...] So this should be sufficient.
>
> Yup.
> Thanks for keeping track of this patch, as I lost track of it.
>
> thanks,
> Stefan
So does the above exchange mean that
<20180904135258.31300-1-phillip.w...@talktalk.net> is ready to go
with your Acked-by?
Jonathan Nieder writes:
> Kicking off the reviews: ;-)
>
> Jonathan Nieder wrote:
>
>> --- a/http-backend.c
>> +++ b/http-backend.c
>> @@ -350,10 +350,25 @@ static ssize_t read_request_fixed_len(int fd, ssize_t
>> req_len, unsigned char **o
>>
>> static ssize_t get_content_length(void)
>
Jonathan Tan writes:
> By "without any objects" in your email subject, do you mean "without
> blob and tree objects"? If yes, there is some code in the
> md/filter-trees branch that can do that with a "--filter=tree:0"
> option.
I too was wondering what the "without any objects" thing meant
Todd Zullinger writes:
> With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
> used in the 'cookies stored in http.cookiefile when http.savecookies
> set' test before comparing it to the expected cookies.
>
> ¹ https://github.com/curl/curl/commit/e2ef8d6fa ("cookies: support
"Stephen P. Smith" writes:
> On Friday, September 7, 2018 3:31:55 PM MST you wrote:
>> Junio C Hamano writes:
>
>> The patch is mostly for illustration of the idea.
>>
>> The result seems to compile and pass the test suite, but I haven't
>> caref
Duy Nguyen writes:
> In the end, there's no variant, only one function that always takes
> 'struct repository *' and I wanted to keep the shorter name 'rerere'.
> But let's go with adding repo_rerere() and deprecating rerere(). If it
> turns out later that repo_rerere is too long (or it's
Nguyễn Thái Ngọc Duy writes:
> ---
> apply.c| 9 ++---
> builtin/checkout.c | 3 ++-
> diff.c | 2 +-
> ll-merge.c | 17 +
> ll-merge.h | 5 -
> merge-blobs.c | 3 ++-
> merge-recursive.c | 3 ++-
> notes-merge.c
Derrick Stolee writes:
> On 9/11/2018 12:04 PM, Derrick Stolee wrote:
>
>> The patch below includes a test that fails on Mac OSX with a segfault.
> ...
> Sorry, nevermind. The test failed for a different reason:
Even if it is for a different reason, segfaulting is not acceptable,
but it seems
Jonathan Nieder writes:
> RFC 3875 (the CGI specification) explains:
>
>The CONTENT_LENGTH variable contains the size of the message-body
>attached to the request, if any, in decimal number of octets. If no
>data is attached, then NULL (or unset).
>
> CONTENT_LENGTH = "" |
Stefan Beller writes:
>> Of course, even though these are 1/2 and 2/2, only one of them and
>> not both would apply.
>
> Or you could squash them once we reach consensus that both are good.
Ah, sorry, I completely misread the first one. I thought that it
was extending the implementation of
Stefan Beller writes:
> I separated this from the other series, making it into 2 patches:
> This first patch adds tracing for string lists and the next patch that
> removes the unused function from the string list API.
> That way we can decide on these two patches separately if needed.
Of
Jonathan Nieder writes:
> Josh Steadmon wrote:
>
>> From: Brandon Williams
>>
>> Update the config documentation to note the value `2` as an acceptable
>> value for the protocol.version config.
>>
>> Signed-off-by: Brandon Williams
>> Signed-off-by: Josh Steadmon
>> ---
>>
Johannes Sixt writes:
>> +#define IS_SBS(ch) (((ch) == '/') || ((ch) == '\\'))
I think you already have mingw_is_dir_sep() and its shorter alias
is_dir_sep() available to you.
>> +/*
>> + * Does the pathname map to the local named pipe filesystem?
>> + * That is, does it have a "//./pipe/"
Stas Bekman writes:
> [include]
> path = .gitconfig
>
> Not realizing that the two were not in the same folder. And probably
> assuming that .git/config was referring to the root of repository, and
> not relative to .git/, which is a reasonable assumption.
>
> Of course he had no way of
Stefan Beller writes:
> On Sun, Sep 9, 2018 at 1:54 AM Nguyễn Thái Ngọc Duy wrote:
>>
>> ---
>
> Junio would have to forge your Sign off here?
> (I just realize this holds true for the whole series,
> but it occurred to me in this patch, as I was looking at
> the diff_setup[_done] part on the
Jeff King writes:
>> Either is fine. I am not moving 'next' beyond what is necessary for
>> this release cycle during the pre-release freeze period, and because
>> I thought that Peff was in favor of squashing in the changes to the
>> original when the next cycle starts, I haven't bothered to
Jonathan Nieder writes:
> Updated proposal:
>
> 1. Treat strings starting or ending with single-quote as worth
> quoting in config.c::write_pair (line 3269). This would already
> help with the original issue, since the config would say
>
> [foo]
> bar = "'baz'"
>
"Eckhard Maaß" writes:
> On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
>> It is neither but if I have to pick one between the two, it is much
>> closer to the former than the latter. The primary source of this is
>> that we have only *one* paths
Jonathan Nieder writes:
> 1. Treat single-quote as worth quoting in config.c::write_pair (line
> 2516). This would already help with the original issue, since the
> config would say
>
> [foo]
> bar = \'baz\'
>
> allowing a quick diagnosis.
I am mildly against
Jiang Xin writes:
> Hi Junio,
>
> The following changes since commit 2f743933341f27603550fbf383a34dfcfd38:
>
> Git 2.19-rc1 (2018-08-28 12:01:01 -0700)
>
> are available in the Git repository at:
>
> git://github.com/git-l10n/git-po tags/l10n-2.19.0-rnd2
>
> for you to fetch changes up
Jeff King writes:
> Not that I'm totally opposed to your patch, but it's a little sad that
> we have to match the specific text used in GIT_TRACE now (and if they
> ever changed we won't even notice, but rather the test will just become
> a silent noop).
>
> I think it would be nice if we could
Ævar Arnfjörð Bjarmason writes:
> Looking at the git-range-diff manpage though it recommends
> over ... when the topic has been rebased, which is
> usually the case for e.g. a topic that's submitted to git.git (usually
> be the time feedback has been gathered & a re-submission has been made
>
Jeff King writes:
> On Sat, Sep 08, 2018 at 11:58:47AM -0700, Stas Bekman wrote:
>
>> This doesn’t:
>>
>> [include]
>> path = '../.gitconfig'
>
> So I think it's been covered elsewhere that single quotes aren't a thing
> in git's config format. I will say that this was actually a minor
SZEDER Gábor writes:
>> } else {
>> -options.head_name = xstrdup("detached HEAD");
>> +free(options.head_name);
>> +options.head_name = NULL;
>
> Please use FREE_AND_NULL(options.head_name) here.
Good; did
Ævar Arnfjörð Bjarmason writes:
> I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when
> building my own package of git, but I think this really should be fixed
> in that branch, either by merging the fix down or reverting the original
> series out of next, I think just merging
Jeff Hostetler writes:
> Yeah, this whole thing is a little under-documented for my tastes.
> Let's leave it as you have it. I'll re-roll with a fix to route
> named pipes to the existing _wopen() code.
OK, I have these two patches in 'next', but let's postpone it for
now. Windows port will
Jeff King writes:
> But that couldn't have been what older versions were doing, since they
> never looked at CONTENT_LENGTH at all, and instead always read to EOF.
> So presumably the original problem wasn't that we tried to read a body,
> but that the empty string caused git_parse_ssize_t to
Jeff King writes:
> Your explanation is correct. To be fair, though, it seems like
> --find-copies-harder is made a lot less useful by the not considering
> the larger set of sources, since that's kind of its point. I'm not sure
> if this behavior actually is intentional, or simply what happens
Jonathan Nieder writes:
> It is late in the release cycle, so revert the whole 3-patch series.
> We can try again later for 2.20.
>
> Reported-by: Allan Sandfeld Jensen
> Helped-by: Stefan Beller
> Signed-off-by: Jonathan Nieder
> ---
> Stefan Beller wrote:
>> Jonathan Nieder wrote:
>
>>> I
Junio C Hamano writes:
> "Stephen P. Smith" writes:
>
>> void wt_status_collect(struct wt_status *s)
>> {
>> +struct wt_status_state state;
>> wt_status_collect_changes_worktree(s);
>>
>> if (s->is_initial)
>> @@
"Stephen P. Smith" writes:
> void wt_status_collect(struct wt_status *s)
> {
> + struct wt_status_state state;
> wt_status_collect_changes_worktree(s);
>
> if (s->is_initial)
> @@ -746,6 +752,11 @@ void wt_status_collect(struct wt_status *s)
> else
>
"Stephen P. Smith" writes:
> A couple of years ago, during a patch review Junio found that the
> commitable bit as implemented in wt-status.c was broken.
>
> Stephen P. Smith (4):
> Move has_unmerged earlier in the file.
> wt-status: rename commitable to committable
> t7501: add test of
"Stephen P. Smith" writes:
> Fix variable spelling error.
>
> Signed-off-by: Stephen P. Smith
> ---
Thanks ;-)
Ben Peart writes:
> +struct load_index_extensions
> +{
> +#ifndef NO_PTHREADS
> + pthread_t pthread;
> +#endif
> + struct index_state *istate;
> + void *mmap;
> + size_t mmap_size;
> + unsigned long src_offset;
If the file format only allows uint32_t on any platform, perhaps
Ben Peart writes:
> The extension consists of:
>
> - 32-bit offset to the end of the index entries
>
> - 160-bit SHA-1 over the extension types and their sizes (but not
> their contents). E.g. if we have "TREE" extension that is N-bytes
> long, "REUC" extension that is M-bytes long, followed by
Ben Peart writes:
> On further investigation with the previous patch, I noticed that my test
> repos didn't contain the cache tree extension in their index. After doing a
> commit to ensure they existed, I realized that in some instances, the time
> to load the cache tree exceeded the time to
Hultqvist writes:
> Considering that the gitdir could be located on a different drive than
> the workdir wouldn't it make more sense to create the temporary files
> in a subdirectory inside the gitdir rather tan in the workdir?
I do not think we intend to create temporary files, whose final
Jeff King writes:
> I guess the question is: is this a thing we would want to make available
> to code to leave in all the time? Or is it just for sticking in
> temporarily for a quick dump?
>
> If the former, then I think it needs the early-return at the least (and
> probably _should_ have the
Jonathan Nieder writes:
> When I think about it this way, I suspect that (B) will provide a
> better experience than (A), so this diff change doesn't seem like a
> step in the wrong direction.
OK, that's fair.
Max Kirillov writes:
> Actually, another reason for the latest issue was that CONTENT_LENGTH
> is parsed for GET requests at all. It should be parsed only for POST
> requests, or, rather, only for upoad-pack and receive-pack requests.
Not really. The layered design of the HTTP protocol means
Max Kirillov writes:
> According to RFC3875, empty environment variable is equivalent to unset,
> and for CONTENT_LENGTH it should mean zero body to read.
>
> However, as discussed in [1], unset CONTENT_LENGTH is also used for
> chunked encoding to indicate reading until EOF, so keep this
SZEDER Gábor writes:
> The test 'disable split index' in 't1700-split-index.sh' runs the
> following pipeline:
>
> cmd | grep | sed s///
>
> Drop that 'grep' from the pipeline, and let 'sed' take over its
> duties.
>
> Signed-off-by: SZEDER Gábor
> ---
Obviously good ;-) Thanks.
>
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
>
> Signed-off-by: Stefan Beller
> ---
>
> This is also part of the other
Jonathan Nieder writes:
> It seems like various commands are gaining --recurse-submodules options
> taking different kinds of arguments:
>
> - clone takes --recurse-submodules=
> - fetch takes --recurse-submodules=
> - after this patch, diff takes --recurse-submodules=
>
> Is there a unifying
Junio C Hamano writes:
> I've rebuilt the collection of topics up to pk/rebase-in-c-6-final
> with these two updated series twice, once doing it manually, like I
> did the last time, and another using "rebase -i -r" on top of the
> updated pk/rebase-in-c-4-opts. The
"Johannes Schindelin via GitGitGadget"
writes:
> This patch series completes the support for all rebase options in the
> builtin rebase, e.g. --signoff, rerere-autoupdate, etc.
>
> It is based on pk/rebase -in-c-3-acts.
... which in turn was based on pk/rebase-in-c-2-basic that just got
Jeff King writes:
> On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
>
>> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
>> /* .. then try the external ones */
>> execv_dashed_external(*argv);
>>
>> -/* It could be
Stefan Beller writes:
> 'calculate_changed_submodule_paths' uses a local list to compute the
> changed submodules, and then produces the result by copying appropriate
> items into the result list.
>
> Instead use the result list directly and prune items afterwards
> using
Stefan Beller writes:
> The `changed_submodule_names` are only used for fetching, so let's make it
> part of the struct that is passed around for fetching submodules.
Yay.
Stefan Beller writes:
> Instead of sorting it after we created an unsorted list, we could insert
> correctly into the list.
It is unclear what problem you are solving, especially with
subjunctive "could" there. We are creating an unsorted list and
then sorting it and you see it as a problem
Stefan Beller writes:
> The submodule subsystem is really bad at staying within 80 characters.
> Fix it while we are here.
>
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
I would think this is a good change even without "as it will turn
out..."
Stefan Beller writes:
> +/* Call fn for each oid, and retain it if fn returns 0, remove it otherwise
> */
> +int oid_array_filter(struct oid_array *array,
> + for_each_oid_fn fn,
> + void *cbdata);
Comparing this with object_array_filter(), which I think this
Stefan Beller writes:
> A string list can be used as a stack, but should we?
verb missing. "We can use a string list as ..., but should we?" is
readable. "A string list can be ..., but should it be?" also is.
> A later patch shows
> how useful this will be.
Instead of all of the above, how
Stefan Beller writes:
> It is a debugging aid, so it should print to the debugging channel.
... and rename it with trace_ prefix.
Use of trace_printf() is nice, as we can control its behavior at
runtime ;-)
> Signed-off-by: Stefan Beller
> ---
> string-list.c | 6 +++---
> string-list.h | 4
Jeff King writes:
>> [1]:
>> https://public-inbox.org/git/20180830075431.gf11...@sigill.intra.peff.net/
>
> Yeah, I'm not sure which is easier for Junio. I figured by replying
> inline, it makes it easy to pick up on top of the others (since it
> really does depend on them and should be in the
Jeff King writes:
>> This is what I've come up with to prevent looping aliases. I'm not too
>> happy with the number of indentations needed, but this seemed to be the
>> easiest way to search an array for a value.
>
> I think this approach is OK, though I wonder if we'd also be fine with
> just:
Derrick Stolee writes:
>>> for (i = 0; i < commits->nr; i++) {
>>> + display_progress(progress, i);
>>> if (commits->list[i]->generation != GENERATION_NUMBER_INFINITY
>>> &&
>>> commits->list[i]->generation != GENERATION_NUMBER_ZERO)
>>>
Stephen & Linda Smith writes:
> Junio -
>
> On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
>> > t7500-commit.sh
>> > t7501-commit.sh
>> > t7502-commit.sh
>> > t7509-commit.sh
>>
>> These seem to have organically g
Stefan Beller writes:
> Presumably you merge the tip of this series (which contains 24/24)
> with the other in-flight topics, that make new uses of
> init_revisions(revs, prefix), which 24/24 allows. Going on either
> parent side of such a merge will have working commits, that compile.
>
> So
Eric Sunshine writes:
> This description mischaracterizes what these changes are about.
Thanks for a replacement text; very much appreciated.
Tim Schumacher writes:
> @@ -691,17 +693,34 @@ static int run_argv(int *argcp, const char ***argv)
> /* .. then try the external ones */
> execv_dashed_external(*argv);
>
> + /* Increase the array size and add the current
> + * command to
Jeff King writes:
> On Wed, Sep 05, 2018 at 09:54:42AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> > So AFAIK this fsck catches everything and yields a non-zero exit in the
>> >> > error case. And it should work for even a singl
Jeff King writes:
>> > So AFAIK this fsck catches everything and yields a non-zero exit in the
>> > error case. And it should work for even a single byte of rubbish.
>>
>> Yes you're right. I forgot about the trailing hash.
>
> Thanks, I was worried that I was missing something. ;)
>
> Maybe it
Eric Sunshine writes:
> On Wed, Sep 5, 2018 at 4:29 AM Ævar Arnfjörð Bjarmason
> wrote:
>> I recently gained access to a Solaris 10 SPARC (5.10) box and discovered
>> that the chainlint.sed implementation in 2.19.0 has more sed portability
>> issues.
>>
>> First, whoever implemented the
Johannes Schindelin writes:
> On Tue, 4 Sep 2018, Junio C Hamano wrote:
>
>> * jc/rebase-in-c-9-fixes (2018-09-04) 1 commit
>> - rebase: re-add forgotten -k that stands for --keep-empty
>> (this branch uses ag/rebase-i-in-c,
>> js/rebase-in-c-5.5-work-with
Johannes Schindelin writes:
> On Tue, 4 Sep 2018, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > + test_must_fail git -c core.editor="grep -q ^pick" \
>> > + rebase -ki --autosquas
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.
Git 2.19-rc2 is out. Hopefully
Stefan Beller writes:
>> The API defines both fixed-field and printf-style functions.
>>
>> The trace2 performance tracing includes thread-specific function
>> nesting and timings.
>
> So this only adds the new API, and we need to merge the TRACE
> into the TRACE2 later?
If this is a rhetorical
Ævar Arnfjörð Bjarmason writes:
> For the reasons explained in the "commit-graph write: add progress
> output" commit leading up to this one, emit progress on "commit-graph
> verify". Since e0fd51e1d7 ("fsck: verify commit-graph", 2018-06-27)
> "git fsck" has called this command if
Ævar Arnfjörð Bjarmason writes:
> Before this change the "commit-graph write" command didn't report any
Please describe the pre-patch state in present tense without "Before
this change".
> progress. On my machine this command takes more than 10 seconds to
> write the graph for linux.git, and
Nguyễn Thái Ngọc Duy writes:
> The three functions init_revisions(), diff_setup() and rerere() are
> prefixed temporarily with repo_ to avoid breaking other topics which
> add new call sites for these functions. This is a temporary
> measure. Once everything is merged, it will be reverted and
Stefan Beller writes:
>> - init_revisions(revs, prefix);
>> + init_revisions(revs, the_repository, prefix);
>
> Thanks for this patch!
>
> At first I wondered why we put the repository as the second argument,
> but that comes down to personal preference, so I wanted to keep it
Matthew DeVore writes:
> @@ -50,6 +50,10 @@ static int gently_parse_list_objects_filter(
> return 0;
> }
>
> + } else if (!strcmp(arg, "tree:0")) {
> + filter_options->choice = LOFC_TREE_NONE;
> + return 0;
> +
This is not wrong
Matthew DeVore writes:
> In some cases in this file, BUG makes more sense than die. In such
> cases, a we get there from a coding error rather than a user error.
>
> 'return' has been removed following some instances of BUG since BUG does
> not return.
>
> Signed-off-by: Matthew DeVore
> ---
Matthew DeVore writes:
> diff --git a/revision.h b/revision.h
> index 51189..2d381e636 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -8,7 +8,11 @@
> #include "diff.h"
> #include "commit-slab-decl.h"
>
> -/* Remember to update object flag allocation in object.h */
> +/* Remember to
Jean-Noël Avila writes:
> On 04/09/2018, Ævar Arnfjörð Bjarmason wrote:On Tue, Sep 4, 2018 at 4:59
> PM Jean-Noel Avila wrote:
>> Your commit message says "dangling dot"...
>
> The dot is dangling on its own line. I don't really catch why this would
> be needed.
>
>>
>>> diff --git
Stefan Beller writes:
> From some offline discussion, maybe we want to adapt a philosophy of
>
> Each patch needs to add a test, that fails when the patch
> is not applied, but succeeds when it is applied. This shows
> that _some_ code in the patch is exercised at least.
>
> (and
Duy Nguyen writes:
> On Tue, Sep 4, 2018 at 1:26 AM brian m. carlson
> wrote:
>>
>> This is the next in the series of improvements to make tests
>> hash-independent.
>
> If it helps, I looked over the series and didn't find anything questionable.
Thanks. I'll tick the message I am resopnding
Jiang Xin writes:
> Jean-Noël Avila 于2018年8月24日周五 上午5:02写道：
>> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
>> index 2bcc70fdfe..b56028ba9d 100644
>> --- a/builtin/submodule--helper.c
>> +++ b/builtin/submodule--helper.c
>> @@ -542,7 +542,7 @@ static void
Duy Nguyen writes:
> Hmm.. no? the commit-slab stores the pointer to the weight, not the
> weight itself, so we still have the ability to check the third case, I
> think.
Good, thanks.
Nguyễn Thái Ngọc Duy writes:
> Index format v4 requires some more computation to assemble a path
> based on a previous one. The current code is not very efficient
> because
>
> - it doubles memory copy, we assemble the final path in a temporary
>first before putting it back to a
630a70ea ("builtin rebase: support `keep-empty` option", 2018-08-08)
forgot that the option comes with a short-and-sweet -k synonym. Add
it back.
Signed-off-by: Junio C Hamano
---
builtin/rebase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rebase.c b/buil
Nguyễn Thái Ngọc Duy writes:
> +static struct cache_entry *create_from_disk(struct index_state *istate,
> struct ondisk_cache_entry *ondisk,
> unsigned long *ent_size,
> -
Tim Schumacher writes:
> I submitted this as RFC because I'm not sure whether disallowing
> nested aliases was an intentional design choice. The done_alias
> check implies that disallowing is intended, but the direct
> recursion check for aliases that call themselves opposes that.
"direct
Duy Nguyen writes:
> t2000-checkout-cache-clash.sh
> t2001-checkout-cache-clash.sh
These date back to 368f99d5 ("[PATCH 2/2] The core GIT tests: recent
additions and fixes.", 2005-05-13) which later were renamed by
f50c9f76 ("Rename some test scripts and describe the naming
convention",
> diff --git a/sequencer.c b/sequencer.c
> index 84bf598c3e..ac5c805c14 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3578,9 +3578,20 @@ static int commit_staged_changes(struct replay_opts
> *opts,
>* the commit message and if there was a squash, let the user
>
Jeff King writes:
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index 2be7bdb331..60f30b3780 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -432,6 +432,7 @@ static const char *prepare_index(int argc, const char
>> **argv, const char *prefix
>> if
Jeff King writes:
> That code isn't lib-ified enough to be run in process, but I think the
> patch below should give similar behavior to what fsck currently does.
> We'd need to tell index-pack to use our fsck.* config for its checks, I
> imagine. The progress here is still per-pack, but I think
Jeff King writes:
> - make it clear to other observers that there's at least one person
> who hopes this is not the norm for this list
Make it at least two by counting me ;-)
> - make a general reminder that collaborating on the Internet is hard,
> but it's worth spending the extra
Jeff King writes:
>> So instead of typing 3 lines, you can just say "yes we use echo that
>> emulates Unix".
>
> I actually found Dscho's response much more informative than a simple
> yes/no.
>
> At any rate, it sounds like we are probably OK with echo, but I think it
> is still worth doing the
Ævar Arnfjörð Bjarmason writes:
> Fix up a logic error in 380efb65df ("push tests: assert re-pushing
> annotated tags", 2018-07-31), where the $tag_type_description variable
> was assigned to but never used, unlike in the subsequently added
> companion test for fetches in 2d216a7ef6 ("fetch
Elijah Newren writes:
>> Suggestions for a better rewrite is very much appreciated.
>
> That makes sense. I'm not sure I can concisely convey all the right
> points, but here's a stab at rewording:
>
> Recent addition of "directory rename" heuristics to the
> merge-recursive backend makes the
Eric Sunshine writes:
> This series replaces Peff's solo patch[1] which updates "make clean" to
> remove doc-diff's temporary directory. Rather than imbuing the Makefile
> with knowledge specific to doc-diff's internals, this series adds a
> "clean" mode to doc-diff which removes its temporary
Paul-Sebastian Ungureanu writes:
> This a new iteration of `stash.c`. What is new?
>
> * Some commits got squashed. The commit related to replacing
> `git apply` child process was dropped since it wasn't the best
> idea.
>
> * In v7, there was a bug [1] related to config `git stash show`
>
Ævar Arnfjörð Bjarmason writes:
> On Fri, Aug 31 2018, Stephen P. Smith wrote:
>
>> In an update to fix a bug with "commit --dry-run" it was found that
>> the commitable flag was broken. The update was, at the time,
>> accepted as it was better than the previous version.
>
> What update is
1001 - 1100 of 27729 matches
Mail list logo
