* Re: [PATCH 1/2] pathspec magic: add '^' as alias for '!'
From: Cornelius Weig @ 2017-02-08 13:23 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.20.1702072113040.25002@i7.lan>
As Duy pointed out, the glossary needs an update too.
For this one, the cange can be minimal I think:
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 8ad29e6..f127fe9 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -386,7 +386,7 @@ Glob magic is incompatible with literal magic.
exclude;;
After a path matches any non-exclude pathspec, it will be run
- through all exclude pathspec (magic signature: `!`). If it
+ through all exclude pathspec (magic signature: `!` or `^`). If it
matches, the path is ignored.
--
^ permalink raw reply related
* Re: Git clonebundles
From: Johannes Schindelin @ 2017-02-08 14:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Shawn Pearce, Stefan Saasen, Git Mailing List
In-Reply-To: <xmqqzihxyb66.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Tue, 7 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> If people think it might be useful to have it around to experiment, I
> >> can resurrect and keep that in 'pu' (or rather 'jch'), as long as it
> >> does not overlap and conflict with other topics in flight. Let me try
> >> that in today's integration cycle.
> >
> > I would like to remind you of my suggestion to make this more publicly
> > visible and substantially easier to play with, by adding it as an
> > experimental feature (possibly guarded via an explicit opt-in config
> > setting).
>
> I do not understand why you want to give this topic undue prominence
> ovver any other random topic that cook in 'pu' [...]
Since you ask so nicely for an explanation: clonebundles got a really
lively and active discussion at the Contributors' Summit. So it is not
your run of the mill typo fix, the bundle issue is something that clearly
receives a lot of interest in particular from developers who are
unfamiliar with the idiosynchracies of the code Git development.
And I got the very distinct impression that Git would benefit a lot from
these developers, *in particular* since they come with fresh perspectives.
Now, we can make it hard for them (e.g. expecting them to sift through a
few months' worth of What's Cooking mails, to find out whether there has
been any related work, and what is the branch name, if any, and where to
find that branch), and we can alternatively make it easy for them to help
us make Git better.
I would like us to choose the easier route for them. Because it would
benefit us.
Ciao,
Johannes
^ permalink raw reply
* Re: GSoC 2017: application open, deadline = February 9, 2017
From: Matthieu Moy @ 2017-02-08 14:54 UTC (permalink / raw)
To: Jeff King
Cc: git, Pranit Bauva, Lars Schneider, Christian Couder,
Carlos Martín Nieto, Johannes Schindelin, Thomas Gummerer,
Siddharth Kannan
In-Reply-To: <20170125204504.ebw2sa4uokfwwfnt@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 23, 2017 at 04:02:02PM +0100, Matthieu Moy wrote:
>
>> * We need to write the application, i.e. essentially polish and update
>> the text here: https://git.github.io/SoC-2016-Org-Application/ and
>> update the list of project ideas and microprojects :
>> https://git.github.io/SoC-2017-Ideas/
>> https://git.github.io/SoC-2016-Microprojects/
>
> That can be done incrementally by people who care (especially mentors)
> over the next week or so, and doesn't require any real admin
> coordination. If it happens and the result looks good, then the
> application process is pretty straightforward.
>
> If it doesn't, then we probably ought not to participate in GSoC.
OK, it seems the last message did not raise a lot of enthousiasm (unless
I missed some off-list discussion at Git-Merge?).
The application deadline is tomorrow. I think it's time to admit that we
won't participate this year, unless someone steps in really soon.
If we don't participate, I'll add a disclaimer at the top of the
SoC-related pages on git.github.io to make sure students don't waste
time preparing an application.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] difftool: fix bug when printing usage
From: Johannes Schindelin @ 2017-02-08 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, Git ML, Denton Liu
In-Reply-To: <xmqqd1etzrxj.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Tue, 7 Feb 2017, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >>> > Likewise, this would become
> >>> >
> >>> > GIT_CEILING_DIRECTORIES="$PWD/not" \
> >>> > test_expect_code 129 git -C not/repo difftool -h >output &&
> >>> > grep ^usage: output
> >>>
> >>> I agree with the intent, but the execution here is "Not quite".
> >>> test_expect_code being a shell function, it does not take the
> >>> "one-shot environment assignment for this single invocation," like
> >>> external commands do.
> >>
> >> So now that we know what is wrong, can you please enlighten me about
> >> what is right?
> >
> > David's original is just fine, isn't it?
>
> I've also seen people use "env VAR=VAL git command" as the command to be
> tested in t/ scripts. You can run that under test_expect_code,
> methinks.
That is exactly what David ended up sending out as follow-up patches.
I did not mean to be critical, I just found it to be more helpful to
accompany "that does not work" comments with "but this does" in the past.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 1/5] add SWAP macro
From: Johannes Schindelin @ 2017-02-08 15:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Jeff King, Brandon Williams, Johannes Sixt,
Git List
In-Reply-To: <xmqqr339y6q3.fsf@gitster.mtv.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
Hi Junio & René,
On Tue, 7 Feb 2017, Junio C Hamano wrote:
> René Scharfe <l.s.r@web.de> writes:
>
> > Swapping between different types would then still have to be done
> > manually, but I wonder how common that is -- couldn't find such a case
> > in our tree.
>
> I do not think it is a common thing to do, and more importantly, I doubt
> we want to hide such a swap inside a macro. And that is why I said the
> seemingly extra "type" thing may be an improvement over your original
> SWAP() thing if it gives us more type safety.
>
> It seems that the thread has been quite for a while. Perhaps people are
> happy enough with your patches? If so, let's move it forward, but I'll
> wait for a while in case follow-up discussion appears soonish. The
> changes are fairly well isolated and I do not think we are in a hurry.
I am still unhappy about choosing to complicate things and lean heavily on
the compiler to make things right again.
But it appears that I am the only one with this concern, so go ahead. I
promise not to say "I told you so" in case that it breaks things or that
certain platforms are experiencing a disadvantage.
Ciao,
Johannes
^ permalink raw reply
* Re: GSoC 2017: application open, deadline = February 9, 2017
From: Jeff King @ 2017-02-08 15:43 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, Pranit Bauva, Lars Schneider, Christian Couder,
Carlos Martín Nieto, Johannes Schindelin, Thomas Gummerer,
Siddharth Kannan
In-Reply-To: <vpq37fowx5q.fsf@anie.imag.fr>
On Wed, Feb 08, 2017 at 03:54:25PM +0100, Matthieu Moy wrote:
> >> * We need to write the application, i.e. essentially polish and update
> >> the text here: https://git.github.io/SoC-2016-Org-Application/ and
> >> update the list of project ideas and microprojects :
> >> https://git.github.io/SoC-2017-Ideas/
> >> https://git.github.io/SoC-2016-Microprojects/
> >
> > That can be done incrementally by people who care (especially mentors)
> > over the next week or so, and doesn't require any real admin
> > coordination. If it happens and the result looks good, then the
> > application process is pretty straightforward.
> >
> > If it doesn't, then we probably ought not to participate in GSoC.
>
> OK, it seems the last message did not raise a lot of enthousiasm (unless
> I missed some off-list discussion at Git-Merge?).
Nope, there was no discussion that I'm aware of.
> The application deadline is tomorrow. I think it's time to admit that we
> won't participate this year, unless someone steps in really soon.
Yes, I'd agree with that.
Outreachy folks asked if we were interested in participating, but I
think it has roughly the same pre-requisite lists for ideas and
microprojects.
> If we don't participate, I'll add a disclaimer at the top of the
> SoC-related pages on git.github.io to make sure students don't waste
> time preparing an application.
Good idea.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
From: Matthieu Moy @ 2017-02-08 14:40 UTC (permalink / raw)
To: Siddharth Kannan
Cc: Junio C Hamano, git, pranit.bauva, peff, pclouds, sandals
In-Reply-To: <20170207191450.GA5569@ubuntu-512mb-blr1-01.localdomain>
Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> Making a change in sha1_name.c will touch a lot of commands
> (setup_revisions is called from everywhere in the codebase), so, I am
> still trying to figure out how to do this such that the rest of the
> codepath remains unchanged.
Changing sha1_name.c is the way to go *if* we want all commands to
support this. Just like other ways to name a revision...
> I hope that you do not mind this side-effect, but rather, you intended
> for this to happen, right? More commands will start supporting this
> shorthand, suddenly. (such as format-patch, whatchanged, diff to name
> a very few).
... but: the initial implementation of this '-' shorthand was
special-casing a single command (IIRC, "git checkout") for which the
shorthand was useful.
In a previous discussion, I made an analogy with "cd -" (which is the
source of inspiration of this shorthand AFAIK): "-" did not magically
become "the last visited directory" for all Unix commands, just for
"cd". And in this case, I'm happy with it. For example, I never need
"mkdir -", and I'm happy I can't "rm -fr -" by mistake.
So, it's debatable whether it's a good thing to have all commands
support "-". For example, forcing users to explicitly type "git branch
-d @{1}" and not providing them with a shortcut might be a good thing.
I don't have strong opinion on this: I tend to favor consistency and
supporting "-" everywhere goes in this direction, but I think the
downsides should be considered too. A large part of the exercice here is
to write a good commit message!
Another issue with this is: - is also a common way to say "use stdin
instead of a file", so before enabling - for "previous branch", we need
to make sure it does not introduce any ambiguity. Git does not seem to
use "- for stdin" much (most commands able to read from stdin have an
explicit --stdin option for that), a quick grep in the docs shows only
"git blame --contents -" which is OK because a revision wouldn't make
sense here anyway.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: init --separate-git-dir does not set core.worktree
From: Stefan Beller @ 2017-02-08 16:14 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Duy Nguyen, Git Mailing List
In-Reply-To: <877f55r0mk.fsf@kyleam.com>
> [*] https://github.com/magit/magit/issues/460#issuecomment-36035787.
I would agree with the thinking in that issue.
^ permalink raw reply
* Re: init --separate-git-dir does not set core.worktree
From: Stefan Beller @ 2017-02-08 16:13 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Kyle Meyer, Git Mailing List
In-Reply-To: <CACsJy8C=owNPpND4Ab7bFE24kpWBr5fQdob21DEDCckCXu0Mng@mail.gmail.com>
On Fri, Feb 3, 2017 at 5:38 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer <kyle@kyleam.com> wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer <kyle@kyleam.com> wrote:
>>>>
>>>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,
>>>> 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree
>>>> (test below). Based on the commit message and the corresponding thread
>>>> [1], I don't think this change in behavior was intentional, but I wasn't
>>>> able to understand things well enough to attempt a patch.
>>>
>>> I'm missing some context. Why does --separate-git-dir have to set
>>> core.worktree? What fails for you exactly?
>>
>> Sorry for not providing enough information. I haven't run into a
>> failure.
>>
>> In Magit, we need to determine the top-level of the working tree from
>> COMMIT_EDITMSG. Right now that logic [*1*] looks something like this:
>
> This is much better :)
>
>> * COMMIT_EDITMSG in .git/modules/<module>/: set working tree to the
>> output of "git rev-parse --show-toplevel"
.git/modules/<module>/ itself is a fully fledged git directory, making use of
the core.worktree variable to have the working tree at an "unusual" place.
"git rev-parse --show-toplevel" is the correct place of the working tree
>>
>> * COMMIT_EDITMSG in .git/worktrees/<wtree>/: set working tree to the
>> path in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git"
(in worktree/<wtree>:) "git rev-parse --show-toplevel"s output is empty,
but the gitdir file exists unlike in the other cases.
>>
>> * COMMIT_EDITMSG in .git: set working tree to the parent directory
(in .git:) "git rev-parse --show-toplevel"s output is empty.
>>
>> This fails for a repo set up with --separate-git-dir [*2*], where the
>> last step will go out into an unrelated repo. If core.worktree was set
>> and "git rev-parse --show-toplevel" returned the working tree like it
>> did for submodules, things would work.
When using --separate-git-dir you cannot tell where the working tree is from
within the git dir, despite knowing it has to be *somewhere*:
[core]
bare = false
So I would hope we'll set core.worktree again in this case. Otherwise how
would we discover the working tree?
>
> OK. If I read this right, given a path of any text file somewhere
> within ".git" directory. you are tasked to find out where the
> associated worktree is? I.e. this is not an emacsclient executed as
> part of "git commit", correct?
I always assumed core.worktree is precisely that analogy, i.e.
core.worktree is the backwards pointer to the .git file (which
is true coming from a submodule background).
>
> So you need some sort of back-link to ".git" location. And
> unfortunately there's no such thing for .git file (unless it points to
> .git/worktrees/...). I'm hesitant to set core.worktree unless it's
> absolutely needed since it may have unexpected interaction with
> $GIT_WORK_TREE and others (not sure if it has any interaction with
> submodules too). I think adding a new file "gitdir" would be a safer
> option.
How would "gitdir" (should it be called worktree/workingtree instead?)
work together with core.worktree set?
Would it point at the .git file or the root level of the working tree?
>
> I'm not entirely sure if enforcing "one worktree - one repository" is
> safe though. The first two bullet points are very specific and we can
> assume that, but ".git" files alone can be used for anything. In
> theory you can always create a secondary worktree (that's not managed
> by "git worktree") by setting GIT_WORK_TREE and "git checkout -f"
> somewhere. But I guess those would be temporary and nobody would want
> magic to point back to them.
>
> As a fall-back mechanism, I think after magit has found the worktree,
> it should verify the found location is the correct worktree, with "git
> rev-parse --git-dir" or something, and alert the user otherwise. I
> think "git rev-parse --git-path COMMIT_MSG" should give back the same
> COMMIT_MSG path (and it applies for any files in .git dir, covering
> all three cases). The user could add some magit-specific files to tell
> magit where the actual worktree is when they hit corner cases.
>
> If the use case is limited to editing COMMIT_EDITMSG only (after it's
> generated by git), it may be best to add `pwd` as a comment to that
> file. You won't have to go through all the magic rules to find it out
> (*). And it helps non-magic users too.
>
> (*) well, you do, because you probably can't expect everybody to have
> latest git version.
>
>> Of course, the issue above isn't a reason that --separate-git-dir should
>> set core.worktree, but the submodule behavior is why we were wondering
>> if it should.
>
> I'm not a submodule person, so I'll pass that "why" question to Stefan.
Good question. As said above I always assumed it is the backlink to know where
the working tree of the submodule is.
Digging through history I found d75219b4a, which explains why that is:
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. To make that work the git directory has
the core.worktree configuration set in its config file to point back to
the work tree.
I remember reading this some time ago and wondered what the
"to make that work" implies though and IIRC there was nothing I found by
experimentation.
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-08 17:11 UTC (permalink / raw)
To: René Scharfe; +Cc: git-mailing-list
In-Reply-To: <271989d5-c383-0c0d-bfcb-f4118f9fa2aa@web.de>
Thanks Rene, but you seem to have missed the point. NOTHING is
working. No matter what I put there, it doesn't seem to get matched.
Just to be sure, I tested your regex and again it didn't work.
Someone on the SO site stated they could get it to work on FreeBSD and
I'm on Windows, so this might be a platform thing. Can anyone else on
Windows please confirm?
Thanks,
A
On Tue, Feb 7, 2017 at 6:18 PM, René Scharfe <l.s.r@web.de> wrote:
> Am 07.02.2017 um 20:21 schrieb Jack Adrian Zappa:
>>
>> I'm trying to setup a hunk header for .natvis files. For some reason,
>> it doesn't seem to be working. I'm following their instructions from
>> here, which doesn't say much in terms of restrictions of the regex,
>> such as, is the matched item considered the hunk header or do I need a
>> group? I have tried both with no success. This is what I have:
>>
>> [diff "natvis"]
>> xfuncname = "^[\\\t ]*<Type[\\\t ]+Name=\"([^\"])\".*$"
>
>
> The extra "\\" allow backslashes to be used for indentation as well as
> between Type and Name, which is probably not what you want. And your
> expression only matches single-char Name attributes. Try:
>
> xfuncname = "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
>
> René
^ permalink raw reply
* Re: Fwd: Possibly nicer pathspec syntax?
From: Junio C Hamano @ 2017-02-08 17:39 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <CACsJy8AQmg+oRYATU8_gR6zY-=sPN3m9PKtk-kytkSKGK+GG1g@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> Two-patch series to follow.
>
> glossary-content.txt update for both patches would be nice.
I am no longer worried about it as I saw somebody actually sent
follow-up patches on this, but I want to pick your brain on one
thing that is related to this codepath.
We have PATHSPEC_PREFER_CWD and PATHSPEC_PREFER_FULL bits in flags,
added at fc12261fea ("parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}
flags", 2013-07-14), and I think the intent is some commands when
given no pathspec work on all paths in the current subdirectory
while others work on the full tree, regardless of where you are.
"grep" is in the former camp, "log" is in the latter. And there is
a check to catch a bug in a caller that sets both.
I am wondering about this hunk (this is from the original commit
that added it):
if (!entry) {
static const char *raw[2];
+ if (flags & PATHSPEC_PREFER_FULL)
+ return;
+
+ if (!(flags & PATHSPEC_PREFER_CWD))
+ die("BUG: PATHSPEC_PREFER_CWD requires arguments");
+
pathspec->items = item = xmalloc(sizeof(*item));
memset(item, 0, sizeof(*item));
item->match = prefix;
... returns a single entry pathspec to cover cwd ...
The BUG message is given when
- The command got no pathspec from the caller; and
- PATHSPEC_PREFER_FULL is not set; and
- PATHSPEC_PREFER_CWD is NOT set.
but the message says that the caller must have args when it sets
prefer-cwd. Is this a simple typo? If so what should it say?
die("BUG: one of PATHSPEC_PREFER_FULL or _CWD must be set");
If that were the case, we are expressing only one bit of information
(do we limit to cwd, or do we work on full-tree?), but there must
have been a reason why we added two bits and made them mutually
incompatible so that we can express three possibilities.
Does this third possibility (i.e. a caller is allowed to pass
"flags" that does not prefer either) exist to support a command
where the caller MUST have at least one pathspec? If that were the
case, this wouldn't be a BUG but an end-user error, e.g.
die("at least one pathspec element is required");
If you know offhand which callers pass neither of the two
PATHSPEC_PREFER_* bits and remember for what purpose you allowed
them to do so, please remind me. I'll keep digging in the meantime.
Thanks.
^ permalink raw reply
* Re: "disabling bitmap writing, as some objects are not being packed"?
From: Junio C Hamano @ 2017-02-08 17:44 UTC (permalink / raw)
To: Duy Nguyen; +Cc: David Turner, Git Mailing List, Jeff King
In-Reply-To: <CACsJy8C4DO-GYREUhED3YU_WetoTZaB3MUq1kGfRjA3e-FOLYQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On second thought, perhaps gc.autoDetach should default to false if
> there's no tty, since its main point it to stop breaking interactive
> usage. That would make the server side happy (no tty there).
Sounds like an idea, but wouldn't that keep the end-user coming over
the network waiting after accepting a push until the GC completes, I
wonder. If an impatient user disconnects, would that end up killing
an ongoing GC? etc.
^ permalink raw reply
* Re: [PATCH] push options: fail properly in the stateless case
From: Junio C Hamano @ 2017-02-08 18:11 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, jrnieder
In-Reply-To: <20170208010954.19478-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> When using non-builtin protocols relying on a transport helper
> (such as http), push options are not propagated to the helper.
>
> Fix this by propagating the push options to the transport helper and
The description up to this point is VERY readable and sensible. But
that makes the title sound a bit strange. I read it as if it were
saying "stateless case can never support push-options so fail if the
caller attempts to use one", but that does not seem to be what is
going on.
> adding a test that push options using http fail properly.
Sounds sensible. What end-user visible effect does this fix have?
IOW, what feature do we use "push-option" for?
Ahh, OK, so you need to describe that there are two issues in order
to be understood by the readers:
(1) the helper protocol does not propagate push-option
(2) the http helper is not prepared to handle push-option
You fix (1), and you take advantage of the fact (2) to ensure that
(1) is fixed in the new test.
With such an understanding, the title makes (sort of) sense and you
wouldn't have to be asked "what end-user visible effect/benefit does
this have?"
> +'option push-option <c-string>::
> + Transmit this push option.
> +
There is no "c-string" in the current documentation used or
defined. The closest thing I found is
... that field will be quoted in the manner of a C string ...
in git-status page, but I do not think you send the value for an
push-option after running quote_c_style(), so I am puzzled.
I'd rather see 'option push-option <string>' as the bullet item, and
in its description say how arbitrary values (if you allow them, that
is) can be used, e.g. "Transmit <string> encoded in such and such
way a the value of the push-option".
^ permalink raw reply
* Re: [PATCH RFC 0/2] Kill manual ref parsing code in worktree.c
From: Junio C Hamano @ 2017-02-08 18:18 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Michael Haggerty
In-Reply-To: <20170208113144.8201-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> A hundred years ago I added this code because a "standalone" ref
> parsing code was not available from refs.c and the file was going through
> some heavy changes that refactoring its ref parsing code out was not
> an option. I promised to kill this parse_ref() eventually. I'm
> fulfilling it today (or soon).
;-)
Thanks. And thanks for looping Michael in. I'd appreciate his
input in this area.
> I would really like to you double check the approach I'm using here
> (using submodule interface for accessing refs from another worktree)
> since that may be the way forward to fix the "gc losing objects" in
> multi worktrees. I've given it lots of thoughts in the last 24 hours.
> Still can't find any fundamental flaw...
I see that you posted a separate message outlining the idea
yesterday and I didn't see any response (and I was sick and lacked
energy to think it through); I think the basic approach to use "an
API to bring set of refs hidden from your normal view" is sensible.
Except for the unfortunate naming of the interface that makes it
sound as if it is only to access submodules, but that is where the
feature original came from, so let's not complain too loudly ;-)
> Nguyễn Thái Ngọc Duy (2):
> refs.c: add resolve_ref_submodule()
> worktree.c: use submodule interface to access refs from another worktree
>
> branch.c | 3 +-
> refs.c | 20 +++++++++----
> refs.h | 3 ++
> worktree.c | 99 +++++++++++++++-----------------------------------------------
> worktree.h | 2 +-
> 5 files changed, 44 insertions(+), 83 deletions(-)
^ permalink raw reply
* Software Freedom Conservancy donations
From: Jeff King @ 2017-02-08 18:34 UTC (permalink / raw)
To: git
The recent thread about the git-scm.com website raised some discussion
about money, and a lot of people offered financial assistance. As I said
in that thread, we _don't_ have a dire need for money to keep hosting
the site.
But we do sometimes need money for other things (like conference
travel), and we rely on services (like accounting and legal advice)
provided by the Software Freedom Conservancy which are free to us, but
funded ultimately by donations.
I went into detail on our project activities and finances recently at:
http://public-inbox.org/git/20170202024501.57hrw4657tsqerqq@sigill.intra.peff.net/
If you are interested in contributing financially, you can either donate
to the Git project (10% of which goes to Conservancy's general fund, and
the rest ends up in Git's account):
https://git-scm.com/sfc
Or you can donate directly to Conservancy's general fund:
https://sfconservancy.org/donate/
They also have an annual Supporter program, which includes the
all-important t-shirt:
https://sfconservancy.org/supporter/
Through February 13th, there's an anonymous donor matching all Supporter
signups and renewals, so any donation you make before then will go twice
as far.
-Peff
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: René Scharfe @ 2017-02-08 18:37 UTC (permalink / raw)
To: Jack Adrian Zappa; +Cc: git-mailing-list
In-Reply-To: <CAKepmagp2mXNviA2VdT=3EQtZi2LkA_5oG6=AbfkBGKP9Hqiiw@mail.gmail.com>
Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
> Thanks Rene, but you seem to have missed the point. NOTHING is
> working. No matter what I put there, it doesn't seem to get matched.
I'm not so sure about that. With your example I get this diff without
setting diff.natvis.xfuncname:
diff --git a/a.natvis b/a.natvis
index 7f9bdf5..bc3c090 100644
--- a/a.natvis
+++ b/a.natvis
@@ -19,7 +19,7 @@ xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<!-- Non-blank line -->
- <Item Name="added var">added_var</Item>
+ <Item Name="added var">added_vars</Item>
<Item Name="var2">var2</Item>
Note the XML namespace in the hunk header. It's put there by the
default rule because "xmlns" starts at the beginning of the line. Your
diff has nothing there, which means the default rule is not used, i.e.
your user-defined rule is in effect.
Come to think of it, this line break in the middle of the AutoVisualizer
tab might have been added by your email client unintentionally, so that
we use different test files, which then of course results in different
diffs. Is that the case?
Anyway, if I run the following two commands:
$ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
$ echo '*.natvis diff=natvis' >.gitattributes
... then I get this, both on Linux (git version 2.11.1) and on Windows
(git version 2.11.1.windows.1):
diff --git a/a.natvis b/a.natvis
index 7f9bdf5..bc3c090 100644
--- a/a.natvis
+++ b/a.natvis
@@ -19,7 +19,7 @@ test
<!-- Non-blank line -->
- <Item Name="added var">added_var</Item>
+ <Item Name="added var">added_vars</Item>
<Item Name="var2">var2</Item>
> Just to be sure, I tested your regex and again it didn't work.
At this point I'm out of ideas, sorry. :( The only way I was able to
break it was due to mistyping the extension as "netvis" several times
for some reason.
René
^ permalink raw reply related
* Re: [PATCH] rev-parse --git-path: fix output when running in a subdirectory
From: Junio C Hamano @ 2017-02-08 18:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <50fe3ea3302c40f4c96eaa5a568837e3334f9dc4.1486555851.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> The problem lies deeper, much deeper...
> ... but it bought us many, many problems.
I think you are making a mountain out of molehill here.
This looks like as an opposite problem of a bug that forgets to
prepend the prefix to relative pathnames given by the end user.
I do agree that some calling scripts may find it more convenient if
the output were relative to their current directory, and in that
sense, this is worth addressing.
However.
How long has "rev-parse --git-path" been around? Had scripts in the
wild chance to learn to live with the "output is relative to the top
of the working tree" reality? I think the answers are "since 2.5" and
"yes".
I do not think we can make this unconditionally without breaking
users. We instead need something like a new "--git-path-relative"
option, similar in the spirit that output from "git diff" can be
made relative to the current directory with the "--relative" option.
Assuming that we are discussing the new behaviour that is
conditionally triggered, let's see the implementation.
> - puts(git_path("%s", argv[i + 1]));
> + path = git_path("%s", argv[i + 1]);
> + if (prefix && !is_absolute_path(path))
> + path = real_path(path);
> + puts(path);
Duy, want to help me out here? I am wondering if using a logic
similar to what is used by "cd t && git grep -e foo :/" to emit
paths as "../Documentation/CodingGuidelines" as relative to the
current working directory is more appropriate than forcing the
absolute path output here (and if so, it may be preferrable to use
the relative_path() helper to do so), or the paths to files in
$GIT_DIR are conceptually different enough from paths to files in
the working tree and it will be more robust to have the output as an
absolute path.
I am leaning toward the latter (i.e. the above use of real_path() is
simple and good), but I haven't thought things through and since we
have an area expert here in the thread...
^ permalink raw reply
* Re: "disabling bitmap writing, as some objects are not being packed"?
From: Jeff King @ 2017-02-08 19:08 UTC (permalink / raw)
To: David Turner; +Cc: Junio C Hamano, Duy Nguyen, Git Mailing List
In-Reply-To: <1486580742.1938.52.camel@novalis.org>
On Wed, Feb 08, 2017 at 02:05:42PM -0500, David Turner wrote:
> On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote:
> > Duy Nguyen <pclouds@gmail.com> writes:
> >
> > > On second thought, perhaps gc.autoDetach should default to false if
> > > there's no tty, since its main point it to stop breaking interactive
> > > usage. That would make the server side happy (no tty there).
> >
> > Sounds like an idea, but wouldn't that keep the end-user coming over
> > the network waiting after accepting a push until the GC completes, I
> > wonder. If an impatient user disconnects, would that end up killing
> > an ongoing GC? etc.
>
> Regardless, it's impolite to keep the user waiting. So, I think we
> should just not write the "too many unreachable loose objects" message
> if auto-gc is on. Does that sound OK?
I thought the point of that message was to prevent auto-gc from kicking
in over and over again due to objects that won't actually get pruned.
I wonder if you'd want to either bump the auto-gc object limit, or
possibly reduce the gc.pruneExpire limit to keep this situation from
coming up in the first place (or at least mitigating the amount of time
it's the case).
-Peff
^ permalink raw reply
* Re: gitconfig get out of sync with submodule entries on branch switch
From: Stefan Beller @ 2017-02-08 19:07 UTC (permalink / raw)
To: Benjamin Schindler; +Cc: git@vger.kernel.org
In-Reply-To: <7e54658a-dcb2-64a7-3c67-0c4fa221b2fb@gmail.com>
On Mon, Feb 6, 2017 at 4:17 AM, Benjamin Schindler
<beschindler@gmail.com> wrote:
>
>
> On 06.02.2017 11:35, Stefan Beller wrote:
>>
>> Answering the original email, as I feel we're going down the wrong rabbit
>> hole in the existing thread.
>>
>> On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
>> <beschindler@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> Consider the following usecase: I have the master branch where I have a
>>> submodule A. I create a branch where I rename the submodule to be in the
>>> directory B. After doing all of this, everything looks good.
>>> Now, I switch back to master. The first oddity is, that it fails to
>>> remove
>>> the folder B because there are still files in there:
>>>
>>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
>>> master
>>> warning: unable to rmdir other_submodule: Directory not empty
>>> Switched to branch 'master'
>>
>>
>> checkout currently doesn't support submodules, so it should neither
>> try to delete B nor try to repopulate A when switching back to master.
>> checkout ought to not even touch the existing submodule B.
>
>
> Well, it tried to remove the folder (the rmdir warning) but it failed so in
> some sense you are right. Is there a technical reason for this default
> though? Here, I frequently have to point out to people that they need to
> initialize/update the submodule on e.g. clone.
The reasoning is more based on historical momentum.
Back then when gitlinks/submodules were invented (git repositories
inside other git repositories! How frickin' cool is that?) nobody quite knew
how they were going to be used eventually. So the safe play at the time was
to not touch them at all. (Also easy to implement, but that was not the point
as I learned).
And now we have a lot of people expecting just that. So we cannot change
the behavior overnight. So we'd first implement the alternative (e.g. the
--recurse-submodules flag for checkout) and then once we do a major
release we may want to flip the default.
>
>>
>>>
>>> Git submodule deinit on B fails because the submodule is not known to git
>>> anymore (after all, the folder B exists only in the other branch). I can
>>> easily just remove the folder B from disk and initialize the submodule A
>>> again, so all seems good.
>>
>>
>> by initializing you mean populating(?), i.e.
>>
>> git submodule update
>>
>> would work without the --init flag or preceding "git submodule init A".
>> That ought to not redownload A, but just put files back in the working
>> tree
>> from the submodule git directory inside the superprojects git dir.
>>
>>>
>>> However, what is not good is that the submodule b is still known in
>>> .git/config.
>>
>>
>> Oh, I see. You did not just rename the path, but also the name
>> in the .gitmodules?
>
>
> I wasn't even aware that the submodule name was something different from the
> path because the name is by default set to be the path to it. So yes, I
> didn't just relocate it, it had a different name.
Yeah the path/name is tricky and usually only differs when you move the
submodule inside the working tree. (As the name stays constant we know
where the git directory is expected: .git/modules<name> so we can check there
instead of re-cloning to the "new" submodule-path.)
>
>>
>>> This is in particular a problem for us, because I know a number
>>> of tools which use git config to retrieve the submodule list. Is it
>>> therefore a bug that upon branch switch, the submodule gets deregistered,
>>> but its entry in .git/config remains?
>>
>>
>> The config remains as it indicates that you express(ed) interest in
>> submodule A, such that when switching branches
>>
>> master->renamedToB->master
>>
>> then we'd still care about A. As for the tools, I'd rather see them use
>>
>> git submodule status/summary
>>
>> instead of directly looking at the config, because the config may
>> change in the future.
>
>
> That was my feeling but its good to know to have more solid reasons why that
> would be.
The reasons here are backward/forward compatibility.
When trying to change the behavior of submodule related things, there is no
clear distinction of plumbing/porcelain as we have in the rest of Git.
So even in gits own test suite we sometimes rely on things that may change
later on, and that makes it very hard to move forward, which is why I try to
have an opinion on how to do things properly.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree
From: Stefan Beller @ 2017-02-08 19:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael Haggerty
In-Reply-To: <20170208113144.8201-3-pclouds@gmail.com>
On Wed, Feb 8, 2017 at 3:31 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> (**) At this point, we may want to rename refs *_submodule API to
> something more neutral, maybe s/_submodule/_remote/
I agree on (**), except that I am not sure if /_remote/ is a better name,
because there is already a concept of a "remote" as well as
"remote-tracking" in Git. (Usually it is not reachable on the same
FS, but resides on another machine).
So if we were to do s/_submodule/_remote/, we'd have e.g.
for_each_ref_remote
which could mean that we do networking things to obtain the
actual remote refs or just talk about remote tracking refs.
My gut reaction would be to s/submodule/alternative/ here,
but we also have a thing called alternates already.
So we're looking for a name that describes refs for both
worktrees as well as submodules. (Not sure if we can generalize
to also include alternates, too)
And the one thing they share is that they have their refs
"not at the usual place", e.g. not at .git/refs but rather at
.git/{modules,worktrees}.
Recently we had a tangential discussion in submodule land
about the different places, when adding the
"git submodule absorbgitdirs" command, that moves
the submodule/.git directory into .git/modules/<name>.
We chose "absorb" here as the name, because it
was moved into the .git/ area.
So maybe one of:
s/submodule_ref/unusual_ref/
(to emphasize it is not a regular ref inside the repo, so:)
s/submodule_ref/irregular_ref/
s/resolve_ref_submodule/resolve_ref_out_of_place/
s/resolve_ref_submodule/resolve_ref_gitlink_pointed/
s/resolve_ref_submodule/resolve_ref_linked_pointer/
would be my current thinking.
Thanks,
Stefan
^ permalink raw reply
* Re: [RFC] mailmap.blob overrides default .mailmap
From: Jeff King @ 2017-02-08 19:50 UTC (permalink / raw)
To: Cornelius Weig; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <53836bcd-1d4d-13fb-a523-1258017d19c9@tngtech.com>
On Tue, Feb 07, 2017 at 11:45:31PM +0100, Cornelius Weig wrote:
> On the other hand, a checked-in .mailmap file and a mailmap-blob are
> both as in-history as the other to me. Now consider the following
> settings:
I think it depends how you use them. You could point mailmap.blob to
some other ref entirely (even one that you fetched from another
repository).
I'd expect normal use to point it to HEAD:.mailmap, though (and that was
certainly the use case I wrote it for). On the other hand, the point of
pointing it to that particular blob is that it works even when you
_don't_ have a checkout (and this kicks in automatically in a bare
repo).
> $ git config --unset mailmap.file
> $ git config mailmap.blob HEAD:.mailmap
> $ sed -i 's:peff@peff.com:no-valid-address:' .mailmap
> $ git log -1 --author 'Jeff King'
In case anybody wants to experiment, there are a bunch of things that
make this a non-working example (at least on git.git):
- my address is actually peff.net :)
- There mailmap which mentions peff.net maps peff@github.com to
peff.net, so this change would require --author=peff@github.com.
- We don't apply mailmaps for the default output of "git log". You can
format with "%aN %aE", or just use "git shortlog -ns --author=peff"
which does map.
But that aside, yeah, you can make an argument to expect one way or the
other, depending on the situation you set up. I don't have a strong
feeling about it, but my gut feeling is that no ordering is
significantly better than the other, and that puts me in favor of
leaving it as-is purely out of inertia and backwards-compatibility.
-Peff
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: Samuel Lijin @ 2017-02-08 20:24 UTC (permalink / raw)
To: René Scharfe; +Cc: Jack Adrian Zappa, git-mailing-list
In-Reply-To: <1aa20b4e-782f-a650-eab8-51218b838337@web.de>
On Windows 7, it works for me in both CMD and Git Bash:
$ git --version
git version 2.11.0.windows.3
$ git diff HEAD^ --word-diff
diff --git a/test.natvis b/test.natvis
index 93396ad..1233b8c 100644
--- a/test.natvis
+++ b/test.natvis
@@ -18,6 +18,7 @@ test
<!-- Non-blank line -->
{+<Item Name="added var">added_var</Item>+}
<Item Name="var2">var2</Item>
On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l.s.r@web.de> wrote:
> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>> Thanks Rene, but you seem to have missed the point. NOTHING is
>> working. No matter what I put there, it doesn't seem to get matched.
>
> I'm not so sure about that. With your example I get this diff without
> setting diff.natvis.xfuncname:
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
>
>
> <!-- Non-blank line -->
> - <Item Name="added var">added_var</Item>
> + <Item Name="added var">added_vars</Item>
>
>
> <Item Name="var2">var2</Item>
>
> Note the XML namespace in the hunk header. It's put there by the
> default rule because "xmlns" starts at the beginning of the line. Your
> diff has nothing there, which means the default rule is not used, i.e.
> your user-defined rule is in effect.
>
> Come to think of it, this line break in the middle of the AutoVisualizer
> tab might have been added by your email client unintentionally, so that
> we use different test files, which then of course results in different
> diffs. Is that the case?
>
> Anyway, if I run the following two commands:
>
> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
> $ echo '*.natvis diff=natvis' >.gitattributes
>
> ... then I get this, both on Linux (git version 2.11.1) and on Windows
> (git version 2.11.1.windows.1):
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ test
>
>
> <!-- Non-blank line -->
> - <Item Name="added var">added_var</Item>
> + <Item Name="added var">added_vars</Item>
>
>
> <Item Name="var2">var2</Item>
>
>> Just to be sure, I tested your regex and again it didn't work.
>
> At this point I'm out of ideas, sorry. :( The only way I was able to
> break it was due to mistyping the extension as "netvis" several times
> for some reason.
>
> René
^ permalink raw reply related
* [PATCH] diff: print line prefix for --name-only output
From: Jeff King @ 2017-02-08 20:31 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Davide Del Vento, Git Mailing List
In-Reply-To: <CACsJy8BmxpTW5pCLNEQa9sm8teU0O+_Xu+td+uh1K0Bn=yu=yw@mail.gmail.com>
On Wed, Feb 08, 2017 at 01:24:34PM +0700, Duy Nguyen wrote:
> On Wed, Feb 8, 2017 at 6:11 AM, Davide Del Vento <ddvento@ucar.edu> wrote:
> > `git log --graph --name-only` works fine, but the name is not
> > properly indented as it is for `git log --graph --name-status`
> >
> > I tested this in git v1.9.1 the only one I have access at the moment
>
> Confirmed still happens on master. --stat plays nicely with --graph
> though, so it's probably just some small fixes somewhere in diff*.c.
Yep. Looks like every format except --name-only handles this correctly.
-- >8 --
Subject: diff: print line prefix for --name-only output
If you run "git log --graph --name-only", the pathnames are
not indented to go along with their matching commits (unlike
all of the other diff formats). We need to output the line
prefix for each item before writing it.
The tests cover both --name-status and --name-only. The
former actually gets this right already, because it builds
on the --raw format functions. It's only --name-only which
uses its own code (and this fix mirrors the code in
diff_flush_raw()).
Note that the tests don't follow our usual style of setting
up the "expect" output inside the test block. This matches
the surrounding style, but more importantly it is easier to
read: we don't have to worry about embedded single-quotes,
and the leading indentation is more obvious.
Signed-off-by: Jeff King <peff@peff.net>
---
diff.c | 1 +
t/t4202-log.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/diff.c b/diff.c
index d91a34490..a79f3408d 100644
--- a/diff.c
+++ b/diff.c
@@ -4450,6 +4450,7 @@ static void flush_one_pair(struct diff_filepair *p, struct diff_options *opt)
name_a = p->two->path;
name_b = NULL;
strip_prefix(opt->prefix_length, &name_a, &name_b);
+ fprintf(opt->file, "%s", diff_line_prefix(opt));
write_name_quoted(name_a, opt->file, opt->line_termination);
}
}
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 08ea725de..48b55bfd2 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -1212,6 +1212,54 @@ test_expect_success 'log --line-prefix="*** " --graph with diff and stats' '
test_i18ncmp expect actual.sanitized
'
+cat >expect <<-\EOF
+* reach
+|
+| A reach.t
+* Merge branch 'tangle'
+* Merge branch 'side'
+|\
+| * side-2
+|
+| A 2
+* Second
+|
+| A one
+* sixth
+
+ D a/two
+EOF
+
+test_expect_success 'log --graph with --name-status' '
+ git log --graph --format=%s --name-status tangle..reach >actual &&
+ sanitize_output <actual >actual.sanitized &&
+ test_cmp expect actual.sanitized
+'
+
+cat >expect <<-\EOF
+* reach
+|
+| reach.t
+* Merge branch 'tangle'
+* Merge branch 'side'
+|\
+| * side-2
+|
+| 2
+* Second
+|
+| one
+* sixth
+
+ a/two
+EOF
+
+test_expect_success 'log --graph with --name-only' '
+ git log --graph --format=%s --name-only tangle..reach >actual &&
+ sanitize_output <actual >actual.sanitized &&
+ test_cmp expect actual.sanitized
+'
+
test_expect_success 'dotdot is a parent directory' '
mkdir -p a/b &&
( echo sixth && echo fifth ) >expect &&
--
2.12.0.rc0.371.ga6cf8653b
^ permalink raw reply related
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-08 20:39 UTC (permalink / raw)
To: René Scharfe; +Cc: git-mailing-list
In-Reply-To: <1aa20b4e-782f-a650-eab8-51218b838337@web.de>
> I'm not so sure about that. With your example I get this diff without
setting diff.natvis.xfuncname:
So, to make sure we are on the same page, I removed the
diff.natvis.xfuncname from the .gitconfig and .git/config. My output
was:
C:\Users\adrianh\Documents\tmp>git diff
diff --git a/test.natvis b/test.natvis
index 93fd5b4..351301f 100644
--- a/test.natvis
+++ b/test.natvis
@@ -18,6 +18,7 @@
<!-- test text -->
+ <Item Name="added var">added_var</Item>
<Item Name="var2">var2</Item>
So I didn't get the default output that your specified.
I've been modifying the .gitconfig file directly, but I tried your command:
git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
and still had the same results. I.e. NOTHING. :(
On Wed, Feb 8, 2017 at 1:37 PM, René Scharfe <l.s.r@web.de> wrote:
> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>> Thanks Rene, but you seem to have missed the point. NOTHING is
>> working. No matter what I put there, it doesn't seem to get matched.
>
> I'm not so sure about that. With your example I get this diff without
> setting diff.natvis.xfuncname:
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
>
>
> <!-- Non-blank line -->
> - <Item Name="added var">added_var</Item>
> + <Item Name="added var">added_vars</Item>
>
>
> <Item Name="var2">var2</Item>
>
> Note the XML namespace in the hunk header. It's put there by the
> default rule because "xmlns" starts at the beginning of the line. Your
> diff has nothing there, which means the default rule is not used, i.e.
> your user-defined rule is in effect.
>
> Come to think of it, this line break in the middle of the AutoVisualizer
> tab might have been added by your email client unintentionally, so that
> we use different test files, which then of course results in different
> diffs. Is that the case?
>
> Anyway, if I run the following two commands:
>
> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
> $ echo '*.natvis diff=natvis' >.gitattributes
>
> ... then I get this, both on Linux (git version 2.11.1) and on Windows
> (git version 2.11.1.windows.1):
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ test
>
>
> <!-- Non-blank line -->
> - <Item Name="added var">added_var</Item>
> + <Item Name="added var">added_vars</Item>
>
>
> <Item Name="var2">var2</Item>
>
>> Just to be sure, I tested your regex and again it didn't work.
>
> At this point I'm out of ideas, sorry. :( The only way I was able to
> break it was due to mistyping the extension as "netvis" several times
> for some reason.
>
> René
^ permalink raw reply related
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-08 20:42 UTC (permalink / raw)
To: Samuel Lijin; +Cc: René Scharfe, git-mailing-list
In-Reply-To: <CAJZjrdXjnDMi8gMY6f_UDbMZrZJ=AoPM+g01hqPCO2pB9csoOw@mail.gmail.com>
Thanks Samuel,
So, the question is, what is causing this problem on my system?
Anyone have an idea to help diagnose this problem?
On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> On Windows 7, it works for me in both CMD and Git Bash:
>
> $ git --version
> git version 2.11.0.windows.3
>
> $ git diff HEAD^ --word-diff
> diff --git a/test.natvis b/test.natvis
> index 93396ad..1233b8c 100644
> --- a/test.natvis
> +++ b/test.natvis
> @@ -18,6 +18,7 @@ test
>
>
> <!-- Non-blank line -->
> {+<Item Name="added var">added_var</Item>+}
>
>
> <Item Name="var2">var2</Item>
>
> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l.s.r@web.de> wrote:
>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>> Thanks Rene, but you seem to have missed the point. NOTHING is
>>> working. No matter what I put there, it doesn't seem to get matched.
>>
>> I'm not so sure about that. With your example I get this diff without
>> setting diff.natvis.xfuncname:
>>
>> diff --git a/a.natvis b/a.natvis
>> index 7f9bdf5..bc3c090 100644
>> --- a/a.natvis
>> +++ b/a.natvis
>> @@ -19,7 +19,7 @@ xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
>>
>>
>> <!-- Non-blank line -->
>> - <Item Name="added var">added_var</Item>
>> + <Item Name="added var">added_vars</Item>
>>
>>
>> <Item Name="var2">var2</Item>
>>
>> Note the XML namespace in the hunk header. It's put there by the
>> default rule because "xmlns" starts at the beginning of the line. Your
>> diff has nothing there, which means the default rule is not used, i.e.
>> your user-defined rule is in effect.
>>
>> Come to think of it, this line break in the middle of the AutoVisualizer
>> tab might have been added by your email client unintentionally, so that
>> we use different test files, which then of course results in different
>> diffs. Is that the case?
>>
>> Anyway, if I run the following two commands:
>>
>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
>> $ echo '*.natvis diff=natvis' >.gitattributes
>>
>> ... then I get this, both on Linux (git version 2.11.1) and on Windows
>> (git version 2.11.1.windows.1):
>>
>> diff --git a/a.natvis b/a.natvis
>> index 7f9bdf5..bc3c090 100644
>> --- a/a.natvis
>> +++ b/a.natvis
>> @@ -19,7 +19,7 @@ test
>>
>>
>> <!-- Non-blank line -->
>> - <Item Name="added var">added_var</Item>
>> + <Item Name="added var">added_vars</Item>
>>
>>
>> <Item Name="var2">var2</Item>
>>
>>> Just to be sure, I tested your regex and again it didn't work.
>>
>> At this point I'm out of ideas, sorry. :( The only way I was able to
>> break it was due to mistyping the extension as "netvis" several times
>> for some reason.
>>
>> René
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox