On Wed, Mar 27, 2019 at 3:27 AM Michael Platings wrote:
> I think it's really important that we make this dead easy for everyone
> to use. The ultimate in ease of use would be for git blame to
> automatically pick up ignore settings without the user having to even
> know that it's happening. But t
On Tue, Mar 26, 2019 at 12:56 AM Denton Liu wrote:
>
> Robert Dailey reported confusion on the mailing list about a recursive
> tag which was most likely created by mistake. Jeff King noted that this
> isn't a very common case so, most likely, creating a tag-to-a-tag is a
> user-error.
>
> Prevent
Hi,
I wrote:
> Jeff King wrote:
>> That seems like a bug in asciidoctor, which ought to be quoting the "<".
>> We certainly can't quote it ourselves (we don't even know that our
>> backend output is going to a format that needs angle brackets quoted).
>
> Yep, it seems so. I filed this upstream:
On Tue, Mar 26, 2019 at 3:20 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> > >
> > > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> > >
> > > > How about changing "git show -p M" t
On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
> On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> >
> > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> >
> > > How about changing "git show -p M" to output "diff -p M^ M" rather than
> > > "diff-tree --cc M" for
When running a command like "git show" or "git diff" in a partial clone,
batch all missing blobs to be fetched as one request.
This is similar to c0c578b33c ("unpack-trees: batch fetching of missing
blobs", 2017-12-08), but for another command.
Signed-off-by: Jonathan Tan
---
Here's an improveme
On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
> > How about changing "git show -p M" to output "diff -p M^ M" rather than
> > "diff-tree --cc M" for merge commits? It's really surprising specifying
> > -p has no visible effec
Hi,
On Tue, Mar 26, 2019 at 2:10 PM Mooga wrote:
>
> Hi,
> I am still a bit confused about the task itself
>
> it’s just text replacing for example:
> t1400-update-ref.sh , line 194 -> `test_path_is_missing` has to be
> ‘test_path_is_file’
>
> Thanks
There are several places in the code that u
Hi Ævar,
On Tue, Mar 26, 2019 at 09:35:48PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Mar 26 2019, Denton Liu wrote:
>
> > Hi Ævar,
> >
> > On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Sat, Mar 23 2019, Denton Liu wrote:
> >>
> >> > This series te
Hi,
I am still a bit confused about the task itself
it’s just text replacing for example:
t1400-update-ref.sh , line 194 -> `test_path_is_missing` has to be
‘test_path_is_file’
Thanks
On Tue, Mar 26 2019, Denton Liu wrote:
> Hi Ævar,
>
> On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sat, Mar 23 2019, Denton Liu wrote:
>>
>> > This series teaches rebase the --keep-base option.
>> >
>> > 'git rebase --keep-base ' is equivalent to
>> > 'git re
> Obviously this isn't as automated as saying "ignore commit X, it's just
> variable renaming". But it also eliminates the need to a priori figure
> out all such X that affect the lines you care about. You get an answer,
> your human mind says "nope, that's not interesting", and you press a
> butto
On Sun, Mar 24, 2019 at 5:56 PM SZEDER Gábor wrote:
>
> On Fri, Mar 22, 2019 at 08:22:31PM -0300, Matheus Tavares wrote:
> > From: Ævar Arnfjörð Bjarmason
> >
> > Add tests for what happens when we perform a local clone on a repo
> > containing odd files at .git/object directory, such as symlinks
In fetch_pack(), be clearer that there is no shallow information before
the fetch when v2 is used - memset the struct shallow_info to 0 instead
of calling prepare_shallow_info().
This patch is in preparation for a future patch in which a v2 fetch
might call prepare_shallow_info() after shallow inf
Peff says in [1]:
> But isn't this line:
>
> > + if (version == protocol_v2) {
> > +- if (shallow && shallow->nr)
> > ++ if (shallow->nr)
> > BUG("Protocol V2 does not provide shallows at
> > this point in the fetch");
>
>
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the former
"shallow" lines, bu
>> Labels in Perforce are not global, but can be placed on a particular
>> view/subdirectory.
>> This might pose difficulties when importing only parts of Perforce depot
>> into a git repository.
>> For example:
>> 1. Depot layout is as follows:
>> //depot/metaproject/branch1/subprojectA/...
On Tue, Mar 26, 2019 at 06:35:57PM +0100, Daniel Kahn Gillmor wrote:
> But I don't see how to use --format with "git tag -v" at all. Can you
> show me what i'm doing wrong? git-tag(1) says that --format defaults to
> '%(refname:strip=2)', but git tag -v behaves differently when i specify
> that
On Tue, Mar 26, 2019 at 10:53:26AM -0700, Jonathan Tan wrote:
> @@ -1625,6 +1649,7 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
> {
> struct ref *ref_cpy;
> struct shallow_info si;
> + struct oid_array shallows_scratch = OID_ARRAY_INIT;
>
> fetch_pack_setup();
>
On Tue, Mar 26, 2019 at 10:53:24AM -0700, Jonathan Tan wrote:
> Updated to remove the unnecessary NULL check and memory leak that Peff
> noticed [1].
>
> (Only commit 2/2 is changed, so the range-diff only shows 1 commit.)
But isn't this line:
> + if (version == protocol_v2) {
>
On Tue, Mar 26, 2019 at 10:37:06AM -0700, Jonathan Tan wrote:
> > Perhaps it's worth passing down the shallows array we get from the
> > caller of fetch_pack(). Something like the patch below (I think it is
> > never NULL, which means in your patch 1 you can simplify the conditional
> > for the BU
In fetch_pack(), be clearer that there is no shallow information before
the fetch when v2 is used - memset the struct shallow_info to 0 instead
of calling prepare_shallow_info().
This patch is in preparation for a future patch in which a v2 fetch
might call prepare_shallow_info() after shallow inf
In protocol v0, when sending "shallow" lines, the server distinguishes
between lines caused by the remote repo being shallow and lines caused
by client-specified depth settings. Unless "--update-shallow" is
specified, there is a difference in behavior: refs that reach the former
"shallow" lines, bu
Updated to remove the unnecessary NULL check and memory leak that Peff
noticed [1].
(Only commit 2/2 is changed, so the range-diff only shows 1 commit.)
[1] https://public-inbox.org/git/20190326052011.gb1...@sigill.intra.peff.net/
Jonathan Tan (2):
fetch-pack: call prepare_shallow_info only if
Hi Ævar,
On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Mar 23 2019, Denton Liu wrote:
>
> > This series teaches rebase the --keep-base option.
> >
> > 'git rebase --keep-base ' is equivalent to
> > 'git rebase --onto ... ' or
> > 'git rebase --onto $(git me
> On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
>
> > In protocol v0, when sending "shallow" lines, the server distinguishes
> > between lines caused by the remote repo being shallow and lines caused
> > by client-specified depth settings. Unless "--update-shallow" is
> > specified
On Mon 2019-03-25 11:27:06 +0900, Junio C Hamano wrote:
> Daniel Kahn Gillmor writes:
>
>> What do you think of my updated proposal for tag.verifyNameMatch ?
>
> Meh to slightly negative for hard-coding project-specific preference
> to the core tools. "We give you --format so go wild in your proj
On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> How about changing "git show -p M" to output "diff -p M^ M" rather than
> "diff-tree --cc M" for merge commits? It's really surprising specifying
> -p has no visible effect.
That's because "-p" is already the default, and the forma
On Sun, Mar 24, 2019 at 10:55:28PM +0100, SZEDER Gábor wrote:
> The first three patches fix formatting issues with Asciidoctor; they
> are the same patches that I sent earlier today, except some commit
> message updates (now they mention the Asciidoctor version which
> started to issue the warning
On Tue, Mar 26, 2019 at 12:53:14AM -0700, Denton Liu wrote:
> Peff said:
> > Yeah, that's probably a good idea. Now we just need somebody to write
> > the patch...
>
> Hey would you look at that, somebody wrote the patch!
The system works. :)
> Earlier in the mailing list[1], Robert Dailey repo
On Tue, Mar 26, 2019 at 10:48 PM Elijah Newren wrote:
> > > > PS. git-reset shares the same behavior, but it's in a different boat,
> > > > I think. Or maybe I should scrap/replace that one as well.
> > >
> > > reset has traditionally been the home of
> > > how-to-clear-in-progress-state. e.g. ab
On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen wrote:
> On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren wrote:
> Yeah.. --ignore-in-process does not necessarily mean aborting
> something when you just want to get out to examine some other commit.
> And I agree doing nothing seems like the best (or le
On Tue, Mar 26, 2019 at 10:18 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote:
>
> > > That seems like the best we can do without the protocol change. And even
> > > if we adjust the protocol, we need some fallback behavior for existing
> > > v2 servers, so this
On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren wrote:
>
> On Tue, Mar 26, 2019 at 5:50 AM Duy Nguyen wrote:
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > > "git checkout" doing too many things is a source of confusion fo
On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote:
> > That seems like the best we can do without the protocol change. And even
> > if we adjust the protocol, we need some fallback behavior for existing
> > v2 servers, so this is worth doing.
>
> Are people actually doing this (i.e. clon
On Tue, Mar 26, 2019 at 5:50 AM Duy Nguyen wrote:
> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> wrote:
> > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > "git checkout" doing too many things is a source of confusion for many
> > > users (and it even bites old timers sometimes). To rem
On Mon, Mar 25 2019, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Since 7ded055401 (build: do not install git-remote-testgit, 2013-06-07),
> we do not install it. Therefore it makes no sense to document it,
> either.
>
> Signed-off-by: Johannes Schindelin
> ---
>
Hi,
On Mon, 25 Mar 2019, Johannes Schindelin via GitGitGadget wrote:
> Johannes Schindelin (5):
> docs: move gitremote-helpers into section 7
> docs: do not document the `git remote-testgit` command
> check-docs: really look at the documented commands again
> check-docs: do not expect gui
On Sat, Mar 23 2019, Denton Liu wrote:
> This series teaches rebase the --keep-base option.
>
> 'git rebase --keep-base ' is equivalent to
> 'git rebase --onto ... ' or
> 'git rebase --onto $(git merge-base HEAD) ' .
>
> This seems to be a common case that people (including myself!) run into; I
Hi Mike,
On Tue, 26 Mar 2019, Mike Hommey wrote:
> Recently, I've noticed that whenever the auto-gc message shows up about
> being spawned in the background, it still takes a while for git to
> return to the shell.
>
> I've finally looked at what it was stuck on, and it's
> `git reflog expire --a
Hi Gábor,
On Mon, 25 Mar 2019, SZEDER Gábor wrote:
> On Mon, Mar 25, 2019 at 10:28:21PM +0100, Johannes Schindelin wrote:
>
> > I like the rest of the patch series, but this patch, I am not so sure
> > about...
> >
> > On Sun, 24 Mar 2019, SZEDER Gábor wrote:
> >
> > > When our '.travis.yml' was
Hi Denton,
On Mon, 25 Mar 2019, Denton Liu wrote:
> On Mon, Mar 25, 2019 at 07:50:38PM +0100, Johannes Schindelin wrote:
>
> > P.S.: Did you run the test suite before submitting your patches?
>
> Usually I'm more diligent about running tests but I wrote this patchset
> in the back of a car when I
On Tue, Mar 26, 2019 at 07:50:28AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Unfortunately making it faster is hard. To handle expiring unreachable
> > items, it has to know what's reachable. Which implies walking the commit
> > graph. I don't recall offhand whether setting unreachable-expiration
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > "git checkout" doing too many things is a source of confusion for many
> > users (and it even bites old timers sometimes). To remedy that, the
> > command will be split into two new ones: swi
The description of --reset stays true to the first implementation in
438195cced (git-read-tree: add "--reset" flag, 2005-06-09). That is,
--reset discards unmerged entries. Or at least true to the commit
message because I can't be sure about read-tree's behavior regarding
local changes.
But in fcc
On Tue, Mar 26 2019, Duy Nguyen wrote:
> On Tue, Mar 26, 2019 at 1:29 PM Ævar Arnfjörð Bjarmason
> wrote:
>> I don't see how a new "abbreviatedOptions" is plausibly going to crowd
>> out anything else, sounds pretty unambiguous to me.
>
> By crowded I mean a lot of configuration variables under
On 21/03/2019 06:53, Denton Liu wrote:
Since we implemented get_cleanup_mode, we had some duplicate code in
git_sequencer_config which essentially performed the same operations.
Refactor git_sequencer_config to take advantage of the logic already in
get_cleanup_mode.
Note that we had to intro
On Tue, Mar 26 2019, Denton Liu wrote:
> Signed-off-by: Denton Liu
> ---
> Documentation/git-tag.txt | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
> index a74e7b926d..7e7eb9a7e9 100644
> --- a/Documentation/
On Tue, Mar 26, 2019 at 12:20 PM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
>
> > In protocol v0, when sending "shallow" lines, the server distinguishes
> > between lines caused by the remote repo being shallow and lines caused
> > by client-specified depth
On Tue, Mar 26 2019, Denton Liu wrote:
> Add tests to ensure that recursive tags are disallowed unless the
> "--allow-recursive-tag" option is provided.
>
> Signed-off-by: Denton Liu
> ---
> t/t7004-tag.sh | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/t/t7004-tag.sh b/t/t700
On Tue, Mar 26 2019, Denton Liu wrote:
> static const char * const git_tag_usage[] = {
> - N_("git tag [-a | -s | -u ] [-f] [-m | -F ]
> []"),
> + N_("git tag [-a | -s | -u ] [-f] [-m | -F ]
> [--allow-recursive-tag]\n"
> + "\t\t []"),
> N_("git tag -d ..."),
> -
The current wildmatch() call for includeIf's gitdir pattern does not
pass the WM_PATHNAME flag. Without this flag, '*' is treated _almost_
the same as '**' (because '*' also matches slashes) with one exception:
'/**/' can match a single slash. The pattern 'foo/**/bar' matches
'foo/bar'.
But '/*/'
On Tue, Mar 26, 2019 at 12:53:18AM -0700, Denton Liu wrote:
> Robert Dailey reported confusion on the mailing list about a recursive
> tag which was most likely created by mistake. Jeff King noted that this
> isn't a very common case so, most likely, creating a tag-to-a-tag is a
> user-error.
>
>
Signed-off-by: Denton Liu
---
Documentation/git-tag.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index a74e7b926d..7e7eb9a7e9 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -10,7 +10,
Robert Dailey reported confusion on the mailing list about a recursive
tag which was most likely created by mistake. Jeff King noted that this
isn't a very common case so, most likely, creating a tag-to-a-tag is a
user-error.
Prevent mistakes by erroring and providing advice on recursive tags,
unl
Peff said:
> Yeah, that's probably a good idea. Now we just need somebody to write
> the patch...
>
> -Peff
Hey would you look at that, somebody wrote the patch!
---
Earlier in the mailing list[1], Robert Dailey reported confusion over
some recursive tags.
Peff noted that he hasn't seen a tag-
Add tests to ensure that recursive tags are disallowed unless the
"--allow-recursive-tag" option is provided.
Signed-off-by: Denton Liu
---
t/t7004-tag.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 7a7c0ccee9..5297da952d 100755
--- a/t/t7004
On Tue, Mar 26, 2019 at 1:29 PM Ævar Arnfjörð Bjarmason
wrote:
> I don't see how a new "abbreviatedOptions" is plausibly going to crowd
> out anything else, sounds pretty unambiguous to me.
By crowded I mean a lot of configuration variables under "core"
> By my count out of the the existing GIT_
58 matches
Mail list logo
