"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The test script t6501-freshen-objects.sh has some tests that care
> if 'git gc' has any output to stderr. This is intended to say that
> no warnings occurred related to broken links. However, when we
> have operations that
Jonathan Tan writes:
> Suppose a server has the following commit graph:
>
> A B
> \ /
>O
>
> We create a client by cloning A from the server with depth 1, and add
> many commits to it (so that future fetches span multiple requests due to
> lengthy negotiation). If it then fetches B
Matthew DeVore writes:
> The tree:0 filter does not need to traverse the trees that it has
> filtered out, so optimize list-objects and list-objects-filter to skip
> traversing the trees entirely. Before this patch, we iterated over all
> children of the tree, and did nothing for all of them,
Ramsay Jones writes:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> Since I didn't get any adverse comments, this version has the RFC
> label removed. Also, given that it seems the vcs-svn directory is
> not going away soon, I have included those headers this time as well.
>
> [Note: my
"Derrick Stolee via GitGitGadget" writes:
> The commit-graph feature is starting to stabilize. Based on what is in
> master right now, we have:
>
> Git 2.18:
>
> * Ability to write commit-graph (requires user interaction).
>
>
> * Commit parsing is faster when commit-graph exists.
>
Jeff King writes:
> Whereas for the new config variable, you'd probably set it not because
> you want it quiet all the time, but because you want to get some time
> savings. So there it does make sense to me to explain.
>
> Other than that, this seems like an obvious and easy win. It does feel a
Jeff King writes:
> I'd probably call it something verbose and boring like
> --use-default-with-uninteresting or --default-on-negative.
> I dunno.
These two names are improvement, but there needs a hint that the
change we are interested in is to use default even when revs are
given as long as
Jonathan Tan writes:
>> By doing so we'll have access to the util pointer for longer that
>> contains the commits that we need to fetch, which will be
>> useful in a later patch.
>
> It seems that the main point of this patch is so that the OIDs be stored
> in changed_submodule_names, because
Stefan Beller writes:
> This is based on ao/submodule-wo-gitmodules-checked-out.
Thanks. I had an impression that we were not entirely happy with
the topic and are expecting a reroll, but let's hope that the part
we expect to be updated won't have much overlaps.
> A range-diff below shows how
Jonathan Nieder writes:
> The rule says
>
> install-html: html
> $(INSTALL) -d -m 755 $(DESTDIR)$(htmldir)
> $(INSTALL) -m 644 $^ $(DESTDIR)$(htmldir)
>
> and $^ substitutes to "html" after this change.
Sorry about that.
From: Junio C Hamano
Date:
Jonathan Nieder writes:
>> -install-html: $(GIT_SUBTREE_HTML)
>> +install-html: html
>
> This broke the build for me:
>
> make[2]: Entering directory '/build/git-2.19.1+next.20181016/contrib/subtree'
> install -m 644 html
> /build/git-2.19.1+next.20181016/debian/tmp/usr/share/doc/git/html
>
Ævar Arnfjörð Bjarmason writes:
>> sites could do the same polling and mirroring. I am just too lazy
>> to open a new account at yet another hosting site to add that for
>> loop, but I may choose to when I am absolutely bored and nothing
>> else to do ;-).
>
> Do you mind if I squat
Ævar Arnfjörð Bjarmason writes:
>> This is all to say: having a maximum size is good. 512 is big enough
>> to cover _most_ commits, but not so big that we may store _really_ big
>> filters.
>
> Makes sense. 512 is good enough to hardcode initially, but I couldn't
> tell from briefly skimming the
Duy Nguyen writes:
> Just fyi I also have some wip changes that add the forth "precious"
> class in addition to tracked, untracked and ignored [1]. If someone
> has time it could be another option to pick up.
It is much more sensible than gaining the ability to express
precious by trading away
Johannes Schindelin writes:
>> In any case, you can use "http..$variable" to say "I want the
>> http.$variable to be in effect but only when I am talking to ".
>> Does it make sense for this new variable, too? That is, does it
>> benefit the users to be able to do something like this?
>>
>>
I expect to be offline for most of today during the day, so here
is the usual report but sent at an unusual time.
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
Josh Steadmon writes:
> The first two patches (test cleanup and packet_reader refactor) are OK,
> but the latter two will break the archive command when an old client
> attempts to talk to a new server (due to the version advertisement
> problem noted in [1]). Sorry that I didn't catch that
Eric Sunshine writes:
>> +test_expect_success 'git branch `--show-current` works properly when tag
>> exists' '
>> + cat >expect <<-\EOF &&
>> + branch-and-tag-name
>> + EOF
>> + test_when_finished "git branch -D branch-and-tag-name" &&
>> + git checkout -b
René Scharfe writes:
> Apart from that the macro is simple and doesn't use any tricks or
> added checks. It just sets up boilerplate functions to offer type-safe
> sorting.
> ...
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5f2e90932f..491230fc57 100644
> --- a/git-compat-util.h
Christian Hesse writes:
> From: Christian Hesse
>
> Now that we have build targets let the install targets depend on them.
> Also make the targets phony.
>
> Signed-off-by: Christian Hesse
> ---
> contrib/subtree/Makefile | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Thanks,
Rasmus Villemoes writes:
> This series extends the logic in git-send-email so that addresses
> appearing in various *-by: trailers (e.g. Reviewed-by, Acked-by,
> Tested-by) are picked up and added to the Cc list, in addition to the
> current logic that picks up Cc: and Signed-off-by: lines.
Rasmus Villemoes writes:
>> It may be surprising to existing users that
>> the command now suddenly adds more addresses the user did not think
>> would be added, but it would probably be easy enough for them to
>> work around.
>
> Yeah, I thought about that, but unfortunately the whole auto-cc
stead...@google.com writes:
> From: Josh Steadmon
>
> V2 of this series pulls the compiler flags out of the Makefile, to be
> provided by the user depending on the combination of compiler and
> fuzzing engine in use. This also makes it more compatible with
> OSS-Fuzz's build process.
Thanks,
Daniels Umanovskis writes:
> +test_expect_success 'git branch `--show-current` works properly with
> worktrees' '
> + cat >expect <<-\EOF &&
> + branch-one
> + branch-two
> + EOF
> + git checkout branch-one &&
> + git worktree add worktree branch-two &&
> + (
> +
Rasmus Villemoes writes:
>> I wonder if it would make it easier to grok if we made the logic
>> inside out, i.e.
>>
>> if ($sc eq $sender) {
>> ...
>> } else {
>> if ($what =~ /^Signed-off-by$/i) {
>> next if $suppress_cc{'sob'};
>>
"Johannes Schindelin via GitGitGadget"
writes:
> Also, we make use of the shiny new feature we just introduced where the
> test suite can output JUnit-style .xml files. This information is made
> available in a nice UI that allows the viewer to filter by phase and/or
> test number, and to see
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The name is hard-coded to reflect that we use Travis CI for continuous
> testing.
>
> In the next commits, we will extend this to be able use Azure DevOps,
> too.
>
> So let's adjust the name to make it more generic.
Jonathan Nieder writes:
>> git config submodule.active .
>> git submodule update
>> fatal: repository '../plugins/codemirror-editor' does not exist
>> fatal: clone of '../plugins/codemirror-editor' into submodule path
>> '/tmp/gerrit/plugins/codemirror-editor' failed
>> Failed to clone
Junio C Hamano writes:
> Christian Hesse writes:
>
>> Junio C Hamano on Wed, 2018/10/10 11:26:
>>> As 'contrib' material without real maintenance, I do not care too
>>> deeply, but shouldn't this change be more like this to avoid
>>> duplicating the list
Johannes Schindelin writes:
> AFAIR Junio does not push to github.com/git/git, it is an automatic
> mirror.
>
> GitLab could easily do the same.
It used to be in the early days but these days git/git and
gitster/git are updated in a same for loop that pushes to various
destinations. You are
Ævar Arnfjörð Bjarmason writes:
> I have not reviewed this in any detail, but incorporating this in some
> form or other seems like a no-brainer to me.
>
> If we have "free" (from the perspective of the project) CPU being
> offered by various CI setups let's use it.
Somebody else said in a
Derrick Stolee writes:
> 2. The filters are sized according to the number of changes in each
> commit, with a minimum of one 64-bit word.
> ...
> 6. When we compute the Bloom filters, we don't store a filter for
> commits whose first-parent diff has more than 512 paths.
Just being curious but
Luke Diamand writes:
> This is the same as my earlier patch other than fixing the
> documentation to reflect the change to the destination branch,
> as noticed by Junio.
Also you set up when-finished driver for clean-up before running
clone, which I think is a good change, too.
Will replace.
"Brendan Forster via GitGitGadget" writes:
> Note: an earlier iteration tried to use the config setting
> http.schannel.checkRevoke, but the http.* config settings can be limited
> to specific URLs via http..* (which would mistake `schannel` for a
> URL).
Yeah, "http.schannel.anything" would
"brian m. carlson" writes:
> t/t0014-hash.sh | 54
> create mode 100755 t/t0014-hash.sh
If I am not mistaken, 0014 is already used by another topic in
flight, and will cause test-lint failure on 'pu'.
"Johannes Schindelin via GitGitGadget"
writes:
> +char *mingw_query_user_email(void)
> +{
> + return get_extended_user_info(NameUserPrincipal);
> +}
> +
> ...
>
> +#ifndef query_user_email
> +#define query_user_email() NULL
> +#endif
The three patches look sensible to me; will queue.
You
Thomas Gummerer writes:
> On 10/15, Paul-Sebastian Ungureanu wrote:
>> Hello,
>>
>> This is a new iteration of `git stash`, based on the last review.
>> This iteration fixes some code styling issues, bring some changes
>> to `do_push_stash()` and `do_create_stash()` to be closer to API by
>>
Elijah Newren writes:
> Would you like me to edit the commit message to include this more
> difficult case?
Neither. If the "marker length" change is required in a separate
series that will build on top of the current 4-patch series, I think
dropping this step from the current series and make
Michał Górny writes:
>> OK, so the whole thing makes sense to me.
>>
>> Having said that, if we wanted to short-circuit, I think
>>
>> for (each line) {
>> for (each sigcheck_gpg_status[]) {
>> if (not the one on line)
>>
Christian Hesse writes:
> Junio C Hamano on Wed, 2018/10/10 11:26:
>> As 'contrib' material without real maintenance, I do not care too
>> deeply, but shouldn't this change be more like this to avoid
>> duplicating the list of targets?
>
> Probably, yes.
> Do you w
"brian m. carlson" writes:
> I realize the increase to GIT_MAX_HEXSZ will result in an increase in
> memory usage, but we're going to need to do it at some point, and the
> sooner the code is in the codebase, the sooner people can play around
> with it and test it.
Thanks.
"brian m. carlson" writes:
> Since the commit-graph code wants to serialize the hash algorithm into
> the data store, specify a version number for each supported algorithm.
> Note that we don't use the values of the constants themselves, as they
> are internal and could change in the future.
>
>
"brian m. carlson" writes:
> diff --git a/cache.h b/cache.h
> index d508f3d4f8..a13d14ce0a 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1361,9 +1361,9 @@ extern int get_oid_hex(const char *hex, struct
> object_id *sha1);
> extern int hex_to_bytes(unsigned char *binary, const char *hex, size_t
Elijah Newren writes:
> The correct order usually comes naturally and for free, but with renames
> we often have data in the form {rename_branch, other_branch}, and
> working relative to the rename first (e.g. for rename/add) is more
> convenient elsewhere in the code. Address the slight
Elijah Newren writes:
> Each individual file involved in a rename could have also been modified
> on both sides of history, meaning it may need to have content merges.
> If two such files are renamed into the same location, then on top of the
> two natural auto-merging messages we also have to
Elijah Newren writes:
> When using merge.conflictstyle=diff3 to have the "base version" be shown
> in conflicts, there is the possibility that the base version itself has
> conflicts in it. This comes about when there are more than one merge
> base, and the merging of those merge bases produces
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>> Most of our semantic patches in 'contrib/coccinelle/object_id.cocci'
>> turn calls of SHA1-specific functions into calls of their
>> corresponding object_id counterparts, e.g. sha1_to_hex() to
>> oid_to_hex()
Ramsay Jones writes:
>>
>> For the record, I am not opposed to including the comment _and_ using
>> xsize_t() to do the cast, giving us an assertion that the comment is
>> correct.
>
> Heh, I haven't found any enthusiasm tonight. Let's see if there
> are any more comments/opinions.
OK, in the
Jeff King writes:
> I'm in favor of normalizing even the ones that aren't illegal, though
> I'm OK either way on the vcs-svn bits if they're going away anyway.
I'm in favour of normalizing even the ones that aren't illegal, too.
Junio C Hamano writes:
> Matthew DeVore writes:
>
>> Here is a re-roll-up since I haven't received any additional corrections for
>> almost a week.
>
> Sorry, but doesn't this topic already sit in 'next'? If so, please make
> these small clean-ups as incremental
Michał Górny writes:
> GnuPG supports creating signatures consisting of multiple signature
> packets. If such a signature is verified, it outputs all the status
> messages for each signature separately. However, git currently does not
> account for such scenario and gets terribly confused over
Thanks, will take a look.
Matthew DeVore writes:
> Here is a re-roll-up since I haven't received any additional corrections for
> almost a week.
Sorry, but doesn't this topic already in 'next'? If so, please make
these small clean-ups as incremental patches.
Thansk.
SZEDER Gábor writes:
> Most of our semantic patches in 'contrib/coccinelle/object_id.cocci'
> turn calls of SHA1-specific functions into calls of their
> corresponding object_id counterparts, e.g. sha1_to_hex() to
> oid_to_hex(). These semantic patches look something like this:
>
> @@
>
Matthew DeVore writes:
> The long-term goal at the end of this is to allow a partial clone to
> eagerly fetch an entire directory of files by fetching a tree and
> specifying =1. This, for instance, would make a build operation
> fast and convenient
This would reduce round-trip, as you do not
Matthew DeVore writes:
> -List commits that are reachable by following the `parent` links from the
> -given commit(s), but exclude commits that are reachable from the one(s)
> -given with a '{caret}' in front of them. The output is given in reverse
> -chronological order by default.
> +List
Matthew DeVore writes:
> The tree:0 filter does not need to traverse the trees that it has
> filtered out, so optimize list-objects and list-objects-filter to skip
> traversing the trees entirely. Before this patch, we iterated over all
> children of the tree, and did nothing for all of them,
Duy Nguyen writes:
>> Our matching function comes from rsync originally, whose manpage says:
>>
>> use ’**’ to match anything, including slashes.
>>
>> I believe this is accurate as far as the implementation goes.
>
> No. "**" semantics is not the same as from rsync. The three cases
> "**/",
Sergey Andreenko writes:
> git.exe diff --numstat "C:\diff" "C:\base"
> ...
> output will be:
>
> 0 1 {iff => ase}/1.txt
>
> So (folder_name_length) symbols were cut from the path (“C:\\d” and “C:\\b”).
>
> Is any way to avoid that? I have checked several git versions
Johannes Sixt writes:
> Am 12.10.18 um 08:33 schrieb Junio C Hamano:
>> "Derrick Stolee via GitGitGadget" writes:
>>> +struct topo_walk_info {};
>>> +
>>> +static void init_topo_walk(struct rev_info *revs)
>>> +{
>>> + struct top
Lily Ballard writes:
> I haven’t checked any other commands that the glossary lists as
> taking pathspecs (except `git add`, which does properly list it as
> taking pathspecs), so I don’t know if any of the other commands
> incorrectly list themselves as taking files when they take
> pathspecs.
Jonathan Nieder writes:
> Josh Steadmon wrote:
>> On 2018.10.12 16:32, Jonathan Nieder wrote:
>>> Josh Steadmon wrote:
>
For now, I'm going to try adding an --allowed_versions flag for the
remote helpers, but if anyone has a better idea, let me know.
>>>
>>> I forgot to mention: the
Ævar Arnfjörð Bjarmason writes:
> Yeah, that's me :) I have some WIP gc cleanup, but want to sit on it a
> bit before I submit it to think about the best way to do things.
>
> So in the meantime I was sending out a few WIP bits that I expected
> could be reviewed stand-alone.
I dunno. Unless
Stefan Beller writes:
>> * sb/submodule-recursive-fetch-gets-the-tip (2018-10-11) 9 commits
>> . builtin/fetch: check for submodule updates for non branch fetches
>> . fetch: retry fetching submodules if needed objects were not fetched
>> . submodule: fetch in submodules git directory instead
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.
Quite a lot of topics have been
or hundreds of times in a run of the
> script, the additional wait time is unaccepatable. Replacing the command
> with git rev-parse resulted in significantly increased performance, with
> the command in question returning instantly.
>
> Signed-off-by: Roger Strain
> Thanks-to:
"Johannes Schindelin via GitGitGadget"
writes:
> @@ -3293,6 +3312,9 @@ static int pick_commits(struct todo_list *todo_list,
> struct replay_opts *opts)
> unlink(rebase_path_stopped_sha());
> unlink(rebase_path_amend());
>
"Johannes Schindelin via GitGitGadget"
writes:
> This patch introduces that, based on ag/rebase-i-in-c.
>
> Changes since v2:
>
> * Fixed two typos.
> * When interrupting the rebase, break now outputs a message.
I was about to merge the whole collection of topics to 'next', but
this came to
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 12 Oct 2018, Junio C Hamano wrote:
>
>> From: Martin Koegler
>> Date: Thu, 10 Aug 2017 20:13:08 +0200
>>
>> Signed-off-by: Martin Koegler
>> Signed-off-by: Junio C Hamano
>> ---
>>
>
Luke Diamand writes:
> The branch detection code looks for branches under refs/remotes/p4/...
> and can end up getting confused if there are unshelved changes in
> there as well. This happens in the function p4BranchesInGit().
>
> Instead, put the unshelved changes into
Phillip Wood writes:
> It would be nice if the parsing used starts_with(option_name, user_text)
> rather than strcmp() as well. Also I think --color-moved=no is valid as
> a synonym of --no-color-moved but --color-moved-ws=no is not supported.
I am not sure about starts_with(). Do you mean we
Johannes Schindelin writes:
> On Sun, 7 Oct 2018, Junio C Hamano wrote:
>
>> And then there is an unnamed misdesigned language that has a
>> regmatch() function, which takes a string that contains a regular
>> expression, but somehow requires that string to begin
Roger Strain writes:
> After doing some testing at scale, determined that one call was
> taking too long; replaced that with an alternate call which
> returns the same data significantly faster.
Curious where the time goes. Do you know?
> Also, if anyone has any other feedback on these I'd
From: Martin Koegler
Date: Thu, 10 Aug 2017 20:13:08 +0200
Signed-off-by: Martin Koegler
Signed-off-by: Junio C Hamano
---
* I made minimal adjustments to make the change apply to today's
codebase. I still find some choices and mixing of off_t and
size_t done by the patch a bit iffy
"Derrick Stolee via GitGitGadget" writes:
> * revs->limited implies we run limit_list() to walk the entire
> reachable set. There are some short-cuts here, such as if we
> perform a range query like 'git rev-list COMPARE..HEAD' and we
> can stop limit_list() when all queued commits are
SZEDER Gábor writes:
>> for (i = 0; i < oids->nr; i++) {
>> +display_progress(progress, ++j);
>> commit = lookup_commit(the_repository, >list[i]);
>>
>> if (commit && !parse_commit(commit))
>> @@ -611,19 +624,28 @@ static void close_reachable(struct
Jeff King writes:
> On Fri, Sep 21, 2018 at 10:39:30AM -0700, Derrick Stolee via GitGitGadget
> wrote:
>
>> From: Derrick Stolee
>>
>> The rev-list command is critical to Git's functionality. Ensure it
>> works in the three commit-graph environments constructed in
>> t6600-test-reach.sh. Here
I'll do the s/octu/octo/; again on the title while queuing.
Let's merge this to 'next'.
Thanks.
Ævar Arnfjörð Bjarmason writes:
> On Thu, Oct 11 2018, SZEDER Gábor wrote:
>
>> Fourth and hopefully final round of fixing occasional test failures when
>> run with 'GIT_TEST_SPLIT_INDEX=yes'. The only code change is the
>> extraction of a helper function to compare two cache entries' content,
Ben Peart writes:
> From: Ben Peart
>
> Fixed issues identified in review the most impactful probably being plugging
> some leaks and improved error handling. Also added better error messages
> and some code cleanup to code I'd touched.
>
> The biggest change in the interdiff is the impact of
Rasmus Villemoes writes:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help cmd".
>
> v3: Add some additional comments in patch 1 and avoid
"Derrick Stolee via GitGitGadget" writes:
> CHANGES IN V4: I reduced the blame output using -s which decreases the
> width. I include a summary of the commit authors at the end to help people
> see the lines they wrote. This version is also copied into a build
> definition in the public Git
Junio C Hamano writes:
> Olga Telezhnaya writes:
These three patches seem to cause t6300 to fail with an attempt to
free an invalid pointer in "git for-each-ref --format='%(push)'"
(6300.25)
*** Error in `/home/gitster/w/git.git/git': free(): invalid pointer:
0x000
Stefan Beller writes:
> Noticed-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
>
>
>There is no "ignore-any" supported by the feature---I think that
>the parser for the option should have noticed and barfed, but it
>did not. It merely
Stefan Beller writes:
> I think we should add these tweaks, such that
> color-moved-ws implies color-moved (both config and CLI options)
> and --color-moved implies --color (command line only)
I am not sure what you mean by "both config and". I'd find it
entirely sensible for a user to say "I
Stefan Beller writes:
> Additionally each patch adds a semantic patch, that would port from the old to
> the new function. These semantic patches are all applied in the very last
> patch,
> but we could omit applying the last patch if it causes too many merge
> conflicts
> and trickl in the
Daniels Umanovskis writes:
> +static void print_current_branch_name(void)
Thanks for fixing this (I fixed this in the previous round in my
tree but forgot to tell you about it).
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index ee6787614..8d2020aea 100755
> ---
Ævar Arnfjörð Bjarmason writes:
> On Wed, Oct 10 2018, Jeff King wrote:
>
>> This is much better, and I love the customized behavior based on the
>> object type.
>>
>> I wonder if we could reword the first paragraph to be a little less
>> confusing, and spell out what we tried already. E.g.,
Phillip Wood writes:
> On 10/10/2018 06:43, Junio C Hamano wrote:
>> 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 '.'
Ævar Arnfjörð Bjarmason writes:
> On Wed, Oct 10 2018, Lucas De Marchi wrote:
>
>> Do like it's done in grep so mode doesn't end up as
>> 016, which means range-diff doesn't work if one has
>> "submodule.diff = log" in the configuration. Without this
>> while using range-diff I only get a
>>
Rasmus Villemoes writes:
> So, it seems you're ok with this tightening, but some comment on the
> non-interactive use case should be made in the commit log? Or am I
> misunderstanding?
I do not think we need any immediate action on this step. I was
just wondering if we want two classes of "I
Eric Sunshine writes:
> On Wed, Oct 10, 2018 at 4:54 AM Johannes Schindelin via GitGitGadget
> wrote:
>> We had not documented previously what happens when an `exec` command in
>> an interactive rebase fails. Now we do.
>>
>> Signed-off-by: Johannes Schindelin
>> ---
>> diff --git
Daniels Umanovskis writes:
> +static void print_current_branch_name()
> +{
> + const char *refname = resolve_ref_unsafe("HEAD", 0, NULL, NULL);
> + const char *shortname;
> + if (refname == NULL || !strcmp(refname, "HEAD"))
> + return;
Is it a normal situation to have
Ævar Arnfjörð Bjarmason writes:
>> It also means that we no longer need the inet_pton() and inet_ntop()
>> emulation, which is nice.
>
> Earlier in this series you add a:
>
> #if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x600
> ...
> #endif
>
> Shouldn't that now be something like:
>
> #if
Rasmus Villemoes writes:
> @@ -1681,7 +1681,7 @@ sub process_file {
> # Now parse the message body
> while(<$fh>) {
> $message .= $_;
> - if (/^(Signed-off-by|Cc): (.*)/i) {
> + if (/^([a-z-]*-by|Cc): (.*)/i) {
So this picks up anything-by not
Rasmus Villemoes writes:
> I considered that (and also had a version where I simply insisted on a @
> being present), but that means the user no longer would get prompted
> about the cases where the address was just slightly obfuscated, e.g. the
>
> Cc: John Doe
>
> cases, which would be a
Johannes Schindelin writes:
> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
> fixup! builtin rebase: support `-C` and `--whitespace=`
For c7ee2134d4 (rebase-in-c-4-opts); a single liner that is
obviously correct.
>
Junio C Hamano writes:
> From: Johannes Schindelin
> Date: Thu, 27 Sep 2018 14:48:17 +0200
>
> The `--gpg-sign` option takes an *optional* argument, not a mandatory
> one.
>
> This was discovered as part of the investigation of
> https://github.com/git-for-windows/git
From: Johannes Schindelin
Date: Thu, 27 Sep 2018 14:48:17 +0200
The `--gpg-sign` option takes an *optional* argument, not a mandatory
one.
This was discovered as part of the investigation of
https://github.com/git-for-windows/git/issues/1836.
Signed-off-by: Johannes Schindelin
---
* I am
Stefan Beller writes:
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.
OK.
>> * sb/strbuf-h-update (2018-09-29) 1 commit
> The patch as-is just adds names everywhere.
> I'd be happy to resend with either
> (a) not enforcing names everywhere, but only
601 - 700 of 27729 matches
Mail list logo
