Expand a compact case/esac statement for a later change that'll add
more logic to the body of the "*" case. This is a whitespace-only
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/t/t5510-fetch.sh b
In a subsequent commit this function will learn to test for tag
pruning, prepare for that by making space for more variables, and
making it clear that "expected" here refers to branches.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 9 ++---
1 file changed, 6 insertions(+), 3
Trivially refactor an assignment to make a subsequent patch
smaller. The "ref_nr" variable is initialized to 0 earlier, just as
"j" is, and "j" is only incremented in that loop, so this change isn't
a logic error.
This change simplifies a subsequent change, which will split the
incrementing of "re
Stop redundantly NULL-ing the last element of the refs structure,
which was retrieved via calloc(), and is thus guaranteed to be
pre-NULL'd.
This code dates back to b888d61c83 ("Make fetch a builtin",
2007-09-10), where wasn't any reason to do this back then either, it's
just boilerplate left over
Amend the documentation for fetch.prune, fetch..prune and
--prune to link to the recently added PRUNING section.
I'd have liked to link directly to it with "<>" from
fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt
also includes it, but doesn't include that option). However ma
Add a new section to canonically explain how remote reference pruning
works, and how users should be careful about using it in conjunction
with tag refspecs in particular.
A subsequent commit will update the git-remote documentation to refer
to this section, and details the motivation for writing
When a remote URL is supplied on the command-line the internals of the
fetch are different, in particular the code in get_ref_map(). An
earlier version of the subsequent fetch.pruneTags patch hid a segfault
because the difference wasn't tested for.
Now all the tests are run as both of the variants
The "git remote prune " command uses the same machinery as "git
fetch --prune", and shares all the same caveats, but its
documentation has suggested that it'll just "delete stale
remote-tracking branches under ".
This isn't true, and hasn't been true since at least v1.8.5.6 (the
oldest version I
Re-arrange the arguments to the test_configured_prune() function used
in this test to pass the arguments to --fetch last. A subsequent
change will test for more elaborate fetch arguments, including long
refspecs. It'll be more readable to be able to wrap those on a new
line of their own.
Signed-of
Add a tag to be deleted to the fetch --prune tests. The tag is always
kept for now, which is the expected behavior, but now I can add a test
for tag pruning in a later commit.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 93 ---
Add a --prune-tags option to git-fetch, along with fetch.pruneTags
config option and a -P shorthand (-p is --prune). This allows for
doing any of:
git fetch -p -P
git fetch --prune --prune-tags
git fetch -p -P origin
git fetch --prune --prune-tags origin
Or simply:
git config
The fetch.pruneTags configuration doesn't exist yet, but will be added
in a subsequent commit. Since testing for it requires adding new
parameters to the test_configured_prune function it's easier to review
this patch first to assert that no functional changes are introduced
yet.
Signed-off-by: Æv
Make the new --prune-tags option work properly when git-fetch is
invoked with a parameter instead of a
parameter.
This change is split off from the introduction of --prune-tags due to
the relative complexity of munging the incoming argv, which is easier
to review as a separate change.
Signed-of
On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote:
> From: "Robert P. J. Day"
> >
> > writing a short tutorial on "git bisect" and, all the details of
> > special exit code 125 aside, if one wanted to locate the first
> > unbuildable commit, would it be sufficient to just run?
> >
> > $ git bis
From: "Robert P. J. Day"
writing a short tutorial on "git bisect" and, all the details of
special exit code 125 aside, if one wanted to locate the first
unbuildable commit, would it be sufficient to just run?
$ git bisect run make
as i read it, make returns either 0, 1 or 2 so there doesn'
Ævar Arnfjörð Bjarmason writes:
>>> + key=$(echo $1 | sed -e 's/^remote\.origin/fetch/')
>>
>> Faster (thus more Windows-friendly) assuming that $1 always starts
>> with "remote.origin":
>>
>> key=fetch${u#remote.origin}
>
> Tests fail with this and I'm not excited to be the fir
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>> I think you / Nguyễn may not have seen my
>> <87d11omi2o@evledraar.gmail.com>
>> (https://public-inbox.org/git/87d11omi2o@evledraar.gmail.com/)
>>
>> As noted there I think it's best to proceed without the "d
Note the caveat where 2.17 is stricter about index validation
potentially causing "could not open directory" warnings when git is
upgraded. See the preceding "dir.c: stop ignoring opendir() error in
open_cached_dir()" change.
This caused some mayhem when I upgraded git to a version with this
serie
On Thu, Feb 08 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted:
>>
>>> As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I
>>> noticed in v3 where it would segfault on some git-fetch invocations,
>>> but the
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
+ key=$(echo $1 | sed -e 's/^remote\.origin/fetch/')
>>>
>>> Faster (thus more Windows-friendly) assuming that $1 always starts
>>> with "remote.origin":
>>>
>>> key=fetch${u#remote.origin}
>>
>> Tests fail with th
On Fri, Feb 9, 2018 at 3:27 PM, Jeff King wrote:
> On Fri, Feb 09, 2018 at 09:05:00PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >> + key=$(echo $1 | sed -e 's/^remote\.origin/fetch/')
>> >
>> > Faster (thus more Windows-friendly) assuming that $1 always starts
>> > with "remote.origin
On 02/09/2018 09:20 PM, Joey Hess wrote:> Yes; my patches are under the
same GPL-2 as the rest of git.
Thanks! So here comes my patch series, heavily based on yours.
There are some things to bear in mind while reviewing it:
* This is my first real attempt at contributing to git, which means I
c
Ævar Arnfjörð Bjarmason writes:
> When users upgrade to 2.17 they're going to have git yelling at them
> (as my users did) on existing checkouts, with no indication whatsoever
> that it's due to the UC or how to fix it.
Wait. Are you saying that the new warning is "warning" against a
condition
From: Léo Gaspard
The tweak-fetch hook is fed lines on stdin for all refs that were
fetched, and outputs on stdout possibly modified lines. Its output is
then parsed and used when `git fetch` updates the remote tracking refs,
records the entries in FETCH_HEAD, and produces its report.
The modifi
From: Léo Gaspard
No behavior changes yet, only some groundwork for the next change.
The refs_result structure combines a status code with a ref map, which
can be NULL even on success. This will be needed when there's a
tweak-fetch hook, because it can filter out all refs, while still
succeeding
Ævar Arnfjörð Bjarmason writes:
> +Before 2.17, the untracked cache had a bug where replacing a directory
> +with a symlink to another directory could cause it to incorrectly show
> +files tracked by git as untracked. See the "status: add a failing test
> +showing a core.untrackedCache bug" comm
On Thu, Feb 08 2018, Leo Gaspard jotted:
> On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I
> guess I'll try to update the patch when I get some time to
>>> delve into git's internals, as my use case (forbidding some fetches)
>>> couldn't afaik be covered by a wrapper hook.
Stefan Beller writes:
> Patch generated by
>
> 2. Applying the semantic patch contrib/coccinelle/packed_git.cocci
> to adjust callers.
About this part...
> diff --git a/contrib/coccinelle/packed_git.cocci
> b/contrib/coccinelle/packed_git.cocci
> new file mode 100644
> index 00..d
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> When users upgrade to 2.17 they're going to have git yelling at them
>> (as my users did) on existing checkouts, with no indication whatsoever
>> that it's due to the UC or how to fix it.
>
> Wait. Are you sayi
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> +Before 2.17, the untracked cache had a bug where replacing a directory
>> +with a symlink to another directory could cause it to incorrectly show
>> +files tracked by git as untracked. See the "status: add a fa
On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also
have some intermediate step between these two, where
>>> e.g. your refspec for "origin" is
>>> "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default
>>> "+refs/heads/*:refs/remotes/origin/*", you fetch all ref
On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote:
> One thing that's not discussed yet, and I know just enough about for it
> to tingle my spidey sense, but not enough to say for sure (CC'd Jeff &
> Brandon who know more) is that this feature once shipped might cause
> highe
Leo Gaspard writes:
> From: Léo Gaspard
>
> No behavior changes yet, only some groundwork for the next change.
>
> The refs_result structure combines a status code with a ref map, which
> can be NULL even on success.
Sorry, but I have absolutely no idea what this sentence wants to do
by being
Leo Gaspard writes:
> +tweak-fetch
> +~~~
> +
> +This hook is invoked by 'git fetch' (commonly called by 'git pull'), after
> refs
> +have been fetched from the remote repository. It is not executed, if nothing
> was
> +fetched.
Need to tighten explanation of "nothing was fetched". If
From: "Robert P. J. Day"
On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote:
(apologies for using the fancy letters after the name ID...)
From: "Robert P. J. Day"
>
> writing a short tutorial on "git bisect" and, all the details of
> special exit code 125 aside, if one wanted to locate the
Jeff King writes:
> The negotiation for future fetches uses the existing refs as the
> starting point. And if we don't know that we have the objects because
> there are no refs pointing at them, they're going to get transferred
> again. That's extra load no the server, and extra time for the user
Ævar Arnfjörð Bjarmason writes:
>> Will queue with the above typofix, together with the other one. I
>> am not sure if we want to say "Before 2.17", though.
>
> I'm just keeping in mind the user who later on upgrades git from say
> 2.14 to 2.18 or something, and is able to find in the docs when/
On Fri, Feb 09 2018, Leo Gaspard jotted:
> On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also
> have some intermediate step between these two, where
e.g. your refspec for "origin" is
"+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default
"+refs
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Will queue with the above typofix, together with the other one. I
>>> am not sure if we want to say "Before 2.17", though.
>>
>> I'm just keeping in mind the user who later on upgrades git from say
>> 2.14 to 2
"brian m. carlson" writes:
>> +#include "strbuf.h"
>> +#include "sha1-array.h"
>> +
>> +struct alternates {
>> +struct alternate_object_database *list;
>> +struct alternate_object_database **tail;
>> +};
>> +#define ALTERNATES_INIT { NULL, NULL }
>
> I was surprised to find that this patc
This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will
currently resolve as a ref, which may not be true in the future with
different ref backends. I don't think it locks us in to supporting
resolving other worktree HEADs with this syntax, as I view the
user-visible error message as
This patchset adds checking of other worktree HEADs to fsck.
The reason I've marked this RFC is that I'm worried my incidental
reliance on "worktrees/$WORKTREE/HEAD" resolving as a ref (in patch 3)
might raise some flags for others. In particular, in [1] Peff said
that this refname resolves right
This will make it easier to check the HEAD of other worktrees from fsck.
Signed-off-by: Elijah Newren
---
builtin/fsck.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 04846d46f9..4132034170 100644
--- a/bui
Stefan Beller writes:
> @@ -32,7 +31,15 @@ struct object_store {
>* Objects that should be substituted by other objects
>* (see git-replace(1)).
>*/
> - struct replace_objects replacements;
> + struct replace_objects {
> + /*
> + * An array
Signed-off-by: Elijah Newren
---
t/t1450-fsck.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index cb4b66e29d..fa94c59458 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -102,6 +102,33 @@ test_expect_success 'HEAD link p
On 02/09/2018 11:30 PM, Jeff King wrote:
> On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> One thing that's not discussed yet, and I know just enough about for it
>> to tingle my spidey sense, but not enough to say for sure (CC'd Jeff &
>> Brandon who know more) is that
On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
> > I tend to agree with the direction of thinking you outlined: you're
> > generally better off completing the fetch to a local namespace that
> > tracks the other side completely, and then manipulating the local refs
> > as you see fit
On 02/10/2018 01:13 AM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
>> So the changes that are required are:
>> * Adding a notification-only post-fetch hook
>> * For handling tags, there is a need to have a refmap for tags. Maybe
>> adding a remote.my-remote.fe
From: Lars Schneider
In ade546be47 (worktree: invoke post-checkout hook (unless
--no-checkout), 2017-12-07) we taught Git to run the post-checkout hook
in worktrees. Unfortunately, the environment of the hook was not made
aware of the worktree. Consequently, a 'git rev-parse --show-toplevel'
call
I am contacting you in respect of our late client who deposited fund
valued at the sum of $6,200,000.00 in my bank,he died with his family
in an auto accident. I have contacted you to stand as his heir and
inherit the funds, after the success of this transaction, we should
share the total funds 50
> On 09 Feb 2018, at 21:09, Junio C Hamano wrote:
>
> Documentation has core.checkRoundtripEncoding while t0028 and a
> comment in convert.c capitalize it differently. I suspect that it
> would be more reader-friendly to update the documentation to match.
Agreed. I will wait a little for addit
Leo Gaspard writes:
> On 02/10/2018 01:13 AM, Jeff King wrote:
>> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
>>> So the changes that are required are:
>>> * Adding a notification-only post-fetch hook
Maybe I missed a very early part of the discussion, but why does
this even ne
> On 10 Feb 2018, at 02:01, lars.schnei...@autodesk.com wrote:
>
> From: Lars Schneider
>
> In ade546be47 (worktree: invoke post-checkout hook (unless
> --no-checkout), 2017-12-07) we taught Git to run the post-checkout hook
> in worktrees. Unfortunately, the environment of the hook was not mad
On 02/10/2018 02:08 AM, Junio C Hamano wrote:
> Leo Gaspard writes:
>
>> On 02/10/2018 01:13 AM, Jeff King wrote:
>>> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:
So the changes that are required are:
* Adding a notification-only post-fetch hook
>
> Maybe I missed a ve
101 - 155 of 155 matches
Mail list logo
