Small changes in messages to fit the style and typography of rest
Reuse already translated messages if possible
Do not translate messages aimed at developers of git
Fix unit tests depending on the original string
Use `test_i18ngrep` for tests with translatable strings
Change and verifyrest of tests
Hi all,
Continuing with ths suggestions for improvements.
Racap since last time:
Eric Sunshine:
1. Use 'test_i18ngrep' rather than 'grep'
Jeff King:
2. Fix t1506
Previous changes:
Johannes Sixt:
1. Lower-case letters at the beginning of error messages
2. Past tense to present tense
Am 09.02.2018 um 07:11 schrieb Sergey Organov:
Johannes Schindelin writes:
Let me explain the scenario which comes up plenty of times in my work with
Git for Windows. We have a thicket of some 70 branches on top of git.git's
latest release. These branches often include fixup! and squash! commit
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> fetch: make the --fetch-prune work with
Do you mean s/--fetch-prune/--prune-tags/ ?
> Make the new --prune-tags option work properly when git-fetch is
> invoked with a parameter instead of a
> parameter.
>
> This change is spli
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> Add a --fetch-prune option to git-fetch, along with fetch.pruneTags
> config option. [...]
>
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> @@ -592,6 +592,15 @@ test_configured_p
Johannes Schindelin writes:
[...]
> With this patch, the goodness of the Git garden shears comes to `git
> rebase -i` itself. Passing the `--recreate-merges` option will generate
> a todo list that can be understood readily, and where it is obvious
> how to reorder commits. New branches can be i
Hi,
Johannes Schindelin writes:
> On Wed, 7 Feb 2018, Sergey Organov wrote:
>> Johannes Schindelin writes:
>> > +--recreate-merges::
>> > + Recreate merge commits instead of flattening the history by replaying
>> > + merges. Merge conflict resolutions or manual amendments to merge
>> > + comm
On Thu, Feb 08, 2018 at 02:23:33PM -0500, Ben Peart wrote:
[]
> -
> +test_expect_success CASE_INSENSITIVE_FS 'add directory (with different
> case)' '
> + git reset --hard initial &&
> + mkdir -p dir1/dir2 &&
> + echo > dir1/dir2/a &&
> + echo > dir1/dir2/b &&
Thanks for working
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> 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
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> 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.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> 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 differe
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> 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 cha
On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason
wrote:
> 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.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
> diff --git a/builtin/fetch.c
On Fri, Feb 9, 2018 at 4:16 AM, Eric Sunshine wrote:
> On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote:
>> Instead of 'test_must_fail git cmd... 2>output.err', which redirects
>> the standard error of the 'test_must_fail' helper function as well,
>> causing various issues as discussed in the p
On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote:
> Instead of 'test_must_fail git cmd... 2>output.err', which redirects
> the standard error of the 'test_must_fail' helper function as well,
> causing various issues as discussed in the previous patch.
ECANTPARSE: This either wants to say:
On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote:
> To check that a git command fails and to inspect its error message we
> usually execute a command like this throughout our test suite:
>
> test_must_fail git command --option 2>output.err
>
> Note that this command doesn't limit the redirecti
Since 'test_might_fail' is implemented as a thin wrapper around
'test_must_fail', it also accepts the same options. Mention this in
the docs as well.
Signed-off-by: SZEDER Gábor
---
t/README| 14 --
t/test-lib-functions.sh | 10 ++
2 files changed, 22 inserti
To check that a git command fails with the expected error message, we
usually execute a command like this:
test_must_fail git command --option 2>output.err
Alas, this command doesn't limit the redirection to the git command,
but it redirects the standard error of the
Instead of 'test_must_fail git cmd... 2>output.err', which redirects
the standard error of the 'test_must_fail' helper function as well,
causing various issues as discussed in the previous patch.
With this patch t1404 succeeds when run with '-x', even with shells
not supporting $BASH_XTRACEFD.
Si
To check that a git command fails and to inspect its error message we
usually execute a command like this throughout our test suite:
test_must_fail git command --option 2>output.err
Note that this command doesn't limit the redirection to the git
command, but it redirects the standard error of t
Jan Viktorin writes:
> since Git 2.16.1, I've noticed a bad behaviour of git rebase -i -p. It
> screws up merge commits created with --log (or config merge.log = true)
> in my history. A good merge commit with message like:
>
> Merge branch 'test'
>
> * test:
> c
> b
>
>
Hello dear ,
I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In Benin
Republic as a Principal Director with Federal Ministry Of Works and Housing
here .
I will be delighted to invest with you there in your country into lucrative
investments under your management as far as you co
Hello,
since Git 2.16.1, I've noticed a bad behaviour of git rebase -i -p. It
screws up merge commits created with --log (or config merge.log = true)
in my history. A good merge commit with message like:
Merge branch 'test'
* test:
c
b
is changed after rebase (without to
Derrick Stolee writes:
> +'read'::
> +
> +Read a graph file given by the graph-head file and output basic
> +details about the graph file.
"a graph file", assuming that there must be only one in the
specified place? Or if there are more than one, read all of them?
Or is it an error to have more
Derrick Stolee writes:
> I wanted to have the smallest footprint as possible in the objects
> directory, and the .git/objects directory currently only holds
> folders.
When we cull stale files from pack directory, we rely on the related
files to share pack-.* pattern. It is better not to contam
Derrick Stolee writes:
> You're right that this data is redundant. It is easy to describe the
> width of the tables using the OID length, so it is convenient to have
> that part of the format. Also, it is good to have 4-byte alignment
> here, so we are not wasting space.
>
> There isn't a strong
On Thu, Feb 8, 2018 at 4:38 PM, Jeff King wrote:
> Subject: [PATCH] CodingGuidelines: mention "static" and "extern"
> [...]
>
> Signed-off-by: Jeff King
> ---
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> @@ -386,6 +386,11 @@ For C programs:
> + - Variables and
gregory.herr...@oracle.com writes:
> Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git
> merge`"), commit message of the merge commit being rebased is passed to
> the merge command using a subshell executing 'git rev-parse --sq-quote'.
>
> Double quotes are needed around this subsh
On Thu, Feb 08, 2018 at 05:26:33PM -0500, Eric Sunshine wrote:
> > I think the point is that "var" is a quad-state variable (yes, no, auto,
> > or "unknown") and we are converting to a boolean. This would probably be
> > a lot more clear if GIT_COLOR_* were all enum values and not #defines,
> > an
On Thu, Feb 8, 2018 at 3:43 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
>> +/*
>> + * Resolve the constants as returned by git_config_colorbool()
>> + * (specifically "auto") to a boolean answer.
>> + */
>> +extern int want_color(int var);
>
> This explana
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.
>
> Per my reading of
> https://public-inbox.org
Linus Torvalds writes:
> In that rewrite, removing some temporary files seems to have been left
> out. At least one: .git/COMMIT_EDITMSG.
>
> In the original commit.sh shell script, we can find this:
>
> rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
>
> after creat
Derrick Stolee writes:
> +char* get_commit_graph_filename_hash(const char *pack_dir,
Asterisk sticks to the identifier, not type, in our codebase.
> + struct object_id *hash)
> +{
> + size_t len;
> + struct strbuf path = STRBUF_INIT;
> + strbuf_addst
This may be intentional, but if so, it's not obvious..
Back long long ago, the original "git commit" shell script got rewritten in C.
In that rewrite, removing some temporary files seems to have been left
out. At least one: .git/COMMIT_EDITMSG.
In the original commit.sh shell script, we can find
On Thu, Feb 8, 2018 at 1:21 PM, Stefan Beller wrote:
> On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine
> wrote:
>> On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote:
>>> +die __("When a batch size is given, the relogin delay must be set\n")
>>> + if defined $relogin_delay and not defined
On Thu, Feb 8, 2018 at 1:38 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote:
>
>> You may sense a pattern here: I currently have the very firm understanding
>> we use the extern keyword in our codebase.
>>
>> And I can also attest that this was not always the c
On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote:
> You may sense a pattern here: I currently have the very firm understanding
> we use the extern keyword in our codebase.
>
> And I can also attest that this was not always the case, as back in the
> day I remember writing patches wit
On 2/8/2018 4:27 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Teach git the 'commit-graph' builtin that will be used for writing and
reading packed graph files. The current implementation is mostly
empty, except for a '--pack-dir' option.
Why do we want to use "pack" dir, when this is spe
On 2/8/2018 4:21 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Add document specifying the binary format for commit graphs. This
format allows for:
* New versions.
* New hash functions and hash lengths.
It still is unclear, at least to me, why OID and OID length are
stored as if they can
Derrick Stolee writes:
> Teach git the 'commit-graph' builtin that will be used for writing and
> reading packed graph files. The current implementation is mostly
> empty, except for a '--pack-dir' option.
Why do we want to use "pack" dir, when this is specifically designed
not tied to packfile?
Derrick Stolee writes:
> Add document specifying the binary format for commit graphs. This
> format allows for:
>
> * New versions.
> * New hash functions and hash lengths.
It still is unclear, at least to me, why OID and OID length are
stored as if they can be independent. If a reader does not
On Mon, Jan 8, 2018 at 11:34 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +color.blame.repeatedMeta::
>> + Use the customized color for the part of git-blame output that
>> + is repeated meta information per line (such as commit id,
>> + author name, date and timezone). Defa
On Thu, Feb 08 2018, Leo Gaspard jotted:
> On 02/08/2018 04:30 PM, Joey Hess wrote:
>> Leo Gaspard wrote:
>>> That said, I just came upon [1] (esp. the description [2] and the patch
>>> [3]), and wondered: it looks like the patch was abandoned midway in
>>> favor of a hook refactoring. Would you
On Thu, Feb 8, 2018 at 12:43 PM, Jeff King wrote:
> On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
>
>> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
>> {
>> va_list args;
>> diff --git a/color.h b/color.h
>> index fd2b688dfb..8c7e6c41c2 100644
>> ---
On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote:
> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
> {
> va_list args;
> diff --git a/color.h b/color.h
> index fd2b688dfb..8c7e6c41c2 100644
> --- a/color.h
> +++ b/color.h
> @@ -72,26 +72,50 @@ extern int
From: Gregory Herrero
Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git
merge`"), commit message of the merge commit being rebased is passed to
the merge command using a subshell executing 'git rev-parse --sq-quote'.
Double quotes are needed around this subshell so that, newlines
Teach git-commit-graph to inspect the objects only in a certain list
of pack-indexes within the given pack directory. This allows updating
the commit graph iteratively, since we add all commits stored in a
previous commit graph.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.tx
Teach git-commit-graph to delete the graph files in the pack directory
that were not referenced by 'graph_head' during this process. This cleans
up space for the user while not causing race conditions with other running
Git processes that may be referencing the previous graph file.
To delete old g
Add Documentation/technical/commit-graph.txt with details of the planned
commit graph feature, including future plans.
Signed-off-by: Derrick Stolee
---
Documentation/technical/commit-graph.txt | 189 +++
1 file changed, 189 insertions(+)
create mode 100644 Documenta
Teach git-commit-graph to read commit graph files and summarize their contents.
Use the read subcommand to verify the contents of a commit graph file in the
tests.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.txt | 16
builtin/commit-graph.c | 71 +
Teach git-commit-graph to read commits from stdin when the
--stdin-commits flag is specified. Commits reachable from these
commits are added to the graph. This is a much faster way to construct
the graph than inspecting all packed objects, but is restricted to
known tips.
For the Linux repository,
Teach Git to write a commit graph file by checking all packed objects
to see if they are commits, then store the file in the given pack
directory.
Signed-off-by: Derrick Stolee
---
Makefile | 1 +
commit-graph.c | 368 +
commit-grap
Teach git-commit-graph to write graph files. Create new test script to verify
this command succeeds without failure.
Signed-off-by: Derrick Stolee
---
Documentation/git-commit-graph.txt | 39 +
builtin/commit-graph.c | 43 +++
t/t5318-commit-graph.sh
The commit graph feature is controlled by the new core.commitGraph config
setting. This defaults to 0, so the feature is opt-in.
The intention of core.commitGraph is that a user can always stop checking
for or parsing commit graph files if core.commitGraph=0.
Signed-off-by: Derrick Stolee
---
D
Teach Git to delete the current 'graph_head' file and the commit graph
it references. This is a good safety valve if somehow the file is
corrupted and needs to be recalculated. Since the commit graph is a
summary of contents already in the ODB, it can be regenerated.
Signed-off-by: Derrick Stolee
It is possible to have multiple commit graph files in a pack directory,
but only one is important at a time. Use a 'graph_head' file to point
to the important file. Teach git-commit-graph to write 'graph_head' upon
writing a new commit graph file.
Signed-off-by: Derrick Stolee
---
Documentation/
Teach write_commit_graph() to walk all parents from the commits
discovered in packfiles. This prevents gaps given by loose objects or
previously-missed packfiles.
Also automatically add commits from the existing graph file, if it
exists.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 37 +++
Teach Git to inspect a commit graph file to supply the contents of a
struct commit when calling parse_commit_gently(). This implementation
satisfies all post-conditions on the struct commit, including loading
parents, the root tree, and the commit date. The only loosely-expected
condition is that t
Teach git the 'commit-graph' builtin that will be used for writing and
reading packed graph files. The current implementation is mostly
empty, except for a '--pack-dir' option.
Signed-off-by: Derrick Stolee
---
.gitignore | 1 +
Documentation/git-commit-graph.txt | 11 ++
Thanks to everyone who gave comments on v1 and v2.
Hopefully the following points have been addressed:
* Fixed inter-commit problems where certain fixes did not arrive until
later commits.
* Converted from submode flags ("git commit-graph --write") to
subcommands ("git commit-graph write").
Add document specifying the binary format for commit graphs. This
format allows for:
* New versions.
* New hash functions and hash lengths.
* Optional extensions.
Basic header information is followed by a binary table of contents
into "chunks" that include:
* An ordered list of commit object IDs
Jonathan Tan writes:
> On Thu, 8 Feb 2018 02:56:14 +
> "brian m. carlson" wrote:
>
>> Existing trailers are extracted from the input message by looking for
>> -a group of one or more lines that (i) are all trailers, or (ii) contains at
>> -least one Git-generated or user-configured trailer
Add documentation explaining the functions in color.h.
While at it, mark them extern and migrate the function `color_set`
into grep.c, where the only callers are.
Signed-off-by: Stefan Beller
---
This used to be part of sb/blame-color, but I realized this is
not strictly needed for that serie
Æ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 there were not tests anywhere that caught that.
>
> ...and
Correct the pointer arithmetic in adjust_dirname_case() so that it calls
find_dir_entry() with the correct string length. Previously passing in
"dir1/foo" would pass a length of 6 instead of the correct 4. This resulted in
find_dir_entry() never finding the entry and so the subsequent memcpy that
Hello, I’m very beginner and literally a grandma. Would like Tomatoes for my
Netgear X8 R8500 router. Very misleading netgear product saying OpenVPN and had
no idea about client or I would have to do all this stuff and the netgear
security vulnerabilities are horrid. Was told to shut it down. I
On Thu, Feb 08, 2018 at 01:47:50PM -0500, Jon Simons wrote:
> The packet_read_line() function will die if it sees any
> protocol or socket errors. But it will return NULL for a
> flush packet; some callers which are not expecting this may
> dereference NULL if they get an unexpected flush. This wo
From: Jeff King
The packet_read_line() function dies if it gets an
unexpected EOF. It only returns NULL if we get a flush
packet (or technically, a zero-length "0004" packet, but
nobody is supposed to send those, and they are
indistinguishable from a flush in this interface).
Let's correct error
The packet_read_line() function will die if it sees any
protocol or socket errors. But it will return NULL for a
flush packet; some callers which are not expecting this may
dereference NULL if they get an unexpected flush. This would
involve the other side breaking protocol, but we should
flag the
Included here are a couple of fixes and cleanups for
handling NULL return values from 'packet_read_line'.
Jeff King (1):
correct error messages for NULL packet_read_line()
Jon Simons (1):
always check for NULL return from packet_read_line()
builtin/archive.c | 2 +-
fetch-pack.c | 4 ++
Hello Dear Friend,
Greetings and how are you doing?
I want to know if you are kind to be my
partner in claiming the fund of $13.6
MillionUSD left by a late client. If you're
interested please Revert for more details.
You can visit the web for more details.
http://newswww.bbc.net.uk/2/hi/uk_news/en
Torsten Bögershausen writes:
> My personal favorite would be to spell out what we expect and run a diff.
> When it fails, we can see what fails, and the function would look
> like this:
I'd rather not to have the "sort" there; output from ls-files is
meant to be stable; passing it through sort w
On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine wrote:
> On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote:
>> [...]
>> Error out for now instead of potentially confusing the user.
>> As 5453b83bdf (send-email: --batch-size to work around some SMTP
>> server limit, 2017-05-21) lays out, we rathe
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 there were not tests anywhere that caught that.
...and of course this whole submission this time
Ben Peart writes:
> Correct the pointer arithmetic in adjust_dirname_case() so that it calls
> find_dir_entry() with the correct string length. Previously passing in
> "dir1/foo" would pass a length of 6 instead of the correct 4. This resulted
> in
> find_dir_entry() never finding the entry an
On Thu, 8 Feb 2018 02:56:14 +
"brian m. carlson" wrote:
> Existing trailers are extracted from the input message by looking for
> -a group of one or more lines that (i) are all trailers, or (ii) contains at
> -least one Git-generated or user-configured trailer and consists of at
> +a group
On 2/8/2018 12:21 PM, Torsten Bögershausen wrote:
On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote:
[]
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index b29d749bb7..219c96594c 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -80,7 +80,17 @@ test_expect
On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote:
[]
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index b29d749bb7..219c96594c 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -80,7 +80,17 @@ test_expect_success 'merge (case change)' '
> git
On 02/08/2018 04:30 PM, Joey Hess wrote:
> Leo Gaspard wrote:
>> That said, I just came upon [1] (esp. the description [2] and the patch
>> [3]), and wondered: it looks like the patch was abandoned midway in
>> favor of a hook refactoring. Would you happen to know whether the hook
>> refactoring ev
On Thu, Feb 08, 2018 at 04:56:47PM +0100, SZEDER Gábor wrote:
> This is the second version of 'sg/test-i18ngrep'.
>
> To recap, this patch series fixes a couple of bogus 'test_i18ngrep'
> invocations (patches 1-4), tries to prevent similar bugs in the future
> (patch 8), teaches 'test_i18ngrep' t
On Thu, Feb 08, 2018 at 04:56:55PM +0100, SZEDER Gábor wrote:
> Prevent similar mistakes in the future by validating 'test_i18ngrep's
> parameters requiring that
>
> - The last parameter names an existing file to be read, effectively
> forbiding piping into 'test_i18ngrep'.
s/forbiding/for
> On 08 Feb 2018, at 17:19, Kevin Daudt wrote:
>
> On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>>
>>> On 08 Feb 2018, at 12:13, Lars Schneider wrote:
>>>
>>>
On 08 Feb 2018, at 09:50, Jeff King wrote:
On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneid
On Thu, Jan 11 2018, Ævar Arnfjörð Bjarmason jotted:
> I recently disabled gc.auto=0 and my nightly aggressive repack script on
> our big monorepo across our infra, relying instead on git gc --auto in
> the background to just do its thing.
>
> I didn't want users to wait for git-gc, and I'd writt
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 macro with the refspec string "refs/tags/*:refs/tags/*". There's
been a pre-defined struct version of this since e0aaa29ff3 ("Have a
constant extern refspec for "--tags"", 2008-04-17), but nothing that
could be passed to e.g. add_fetch_refspec().
This will be used in subsequent commits to av
Add a test for the interaction between explicitly provided refspecs
and fetch.prune.
There's no point in adding this boilerplate to every combination of
unset/false/true, it's instructive and sufficient to show that no
matter if the variable is unset, false or true the refspec on the
command-line
If the $cmdline variable contains arguments with spaces they won't be
interpolated correctly, since the body of the test is single quoted,
and because test-lib.sh does its own eval().
This will be used in a subsequent commit to pass arguments that need
to be quoted to git-fetch, i.e. a file:// pat
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
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
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
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
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
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
Add a --fetch-prune option to git-fetch, along with fetch.pruneTags
config option. 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 fetch.prune true &&
git confi
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
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
Access the "remote" variable passed to the fetch_one() directly rather
than through the gtransport wrapper struct constructed in this
function for other purposes.
This makes the code more readable, as it's now obvious that the remote
struct doesn't somehow get munged by the prepare_transport() fun
On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>
> > On 08 Feb 2018, at 12:13, Lars Schneider wrote:
> >
> >
> >> On 08 Feb 2018, at 09:50, Jeff King wrote:
> >>
> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> >>
> 1. You have $LESS in your enviro
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 ---
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 makes a subsequent change which splits the incrementing of
"ref_nr" into
1 - 100 of 129 matches
Mail list logo