* Re: [PATCH v4] tag: generate useful reflog message
From: Junio C Hamano @ 2017-02-08 21:28 UTC (permalink / raw)
To: cornelius.weig; +Cc: git, karthik.188, peff, bitte.keine.werbung.einwerfen
In-Reply-To: <20170206222416.28720-2-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> When tags are created with `--create-reflog` or with the option
> `core.logAllRefUpdates` set to 'always', a reflog is created for them.
> So far, the description of reflog entries for tags was empty, making the
> reflog hard to understand. For example:
> 6e3a7b3 refs/tags/test@{0}:
>
> Now, a reflog message is generated when creating a tag, following the
> pattern "tag: tagging <short-sha1> (<description>)". If
> GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
> (<description>)" instead. If the tag references a commit object, the
> description is set to the subject line of the commit, followed by its
> commit date. For example:
> 6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
>
> If the tag points to a tree/blob/tag objects, the following static
> strings are taken as description:
>
> - "tree object"
> - "blob object"
> - "other tag object"
>
> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
> Reviewed-by: Junio C Hamano <gitster@pobox.com>
This last line is inappropriate, as I didn't review _THIS_ version,
which is different from the previous one, and I haven't checked if
the way the comments on the previous review were addressed in this
version is agreeable.
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 072e6c6..894959f 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -80,10 +80,24 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
> test_must_fail git reflog exists refs/tags/mytag
> '
>
> +git log -1 > expected \
> + --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
We do not want to do this kind of thing outside the
test_expect_success immediately below, unless there is a good
reason, and in this case I do not see any.
Also write redirection operator and redirection target pathname
without SP in between.
> test_expect_success 'creating a tag with --create-reflog should create reflog' '
> test_when_finished "git tag -d tag_with_reflog" &&
> git tag --create-reflog tag_with_reflog &&
> - git reflog exists refs/tags/tag_with_reflog
> + git reflog exists refs/tags/tag_with_reflog &&
> + sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
> + test_cmp expected actual
> +'
In other words, something like:
test_expect_success 'creating a tag with --create-reflog should create reflog' '
git log -1 \
--format="format:tag: tagging %h (%s, %cd)%n" \
--date=format:%Y-%m-%d >expected &&
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog >actual &&
test_cmp expected actual
'
Even though %F may be shorter, spelling it out makes what we expect
more explicit, and what is what I did in the above example.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Document the --no-gui option in difftool
From: Junio C Hamano @ 2017-02-08 21:30 UTC (permalink / raw)
To: Denton Liu; +Cc: git, davvid
In-Reply-To: <20170207063207.GA12746@arch-attack.localdomain>
Denton Liu <liu.denton@gmail.com> writes:
> Prior to this, the `--no-gui` option was not documented in the manpage.
> This commit introduces this into the manpage
>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
Looks good, thanks.
> Documentation/git-difftool.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index 224fb3090..96c26e6aa 100644
> --- a/Documentation/git-difftool.txt
> +++ b/Documentation/git-difftool.txt
> @@ -86,10 +86,11 @@ instead. `--no-symlinks` is the default on Windows.
> Additionally, `$BASE` is set in the environment.
>
> -g::
> ---gui::
> +--[no-]gui::
> When 'git-difftool' is invoked with the `-g` or `--gui` option
> the default diff tool will be read from the configured
> - `diff.guitool` variable instead of `diff.tool`.
> + `diff.guitool` variable instead of `diff.tool`. The `--no-gui`
> + option can be used to override this setting.
>
> --[no-]trust-exit-code::
> 'git-difftool' invokes a diff tool individually on each file.
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-08 21:12 UTC (permalink / raw)
To: Samuel Lijin; +Cc: git-mailing-list
In-Reply-To: <CAJZjrdUcxe_K91CQXz_TgGHgXMsKaddwG5+JEWJ53pv5_GO1zw@mail.gmail.com>
That was it. I have a .gitattributes file in my home directory.
Ahhh, but it's not in my %userprofile% directory, but in my ~
directory.
A bit confusing having 2 home directories. I made a link to my
.gitconfig, but forgot to make a link to my .gitattributes.
Thanks.
A
On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> Double check .gitattributes?
>
> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh.bsc@gmail.com> wrote:
>>
>> Thanks Samuel,
>>
>> That example showed that there must be something wrong in my .git
>> directory, because with it, I'm getting the correct output. Moving
>> the same lines to my .git/config didn't work.
>>
>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>> >
>> > Try cloning and then for any of config1 thru 3,
>> >
>> > $ cp configX .git/config
>> > $ git diff HEAD^ -- test.natvis
>> >
>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>> > <adrianh.bsc@gmail.com> wrote:
>> >> 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
* [PATCHv2] push options: pass push options to the transport helper
From: Stefan Beller @ 2017-02-08 22:04 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, Stefan Beller
In-Reply-To: <xmqqpoiswo0l.fsf@gitster.mtv.corp.google.com>
When using non-builtin protocols relying on a transport helper
(such as http), push options are not propagated to the helper.
The user could ask for push options and a push would seemingly succeed,
but the push options would never be transported to the server,
misleading the users expectation.
Fix this by propagating the push options to the transport helper.
This is only addressing the first issue of
(1) the helper protocol does not propagate push-option
(2) the http helper is not prepared to handle push-option
Once we fix (2), the http transport helper can make use of push options
as well, but that happens as a follow up. (1) is a bug fix, whereas (2)
is a feature, which is why we only do (1) here.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Documentation/gitremote-helpers.txt | 4 ++++
t/t5545-push-options.sh | 15 +++++++++++++++
transport-helper.c | 7 +++++++
3 files changed, 26 insertions(+)
diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
index 9e8681f9e1..23474b1eab 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -462,6 +462,10 @@ set by Git if the remote helper has the 'option' capability.
'option pushcert {'true'|'false'}::
GPG sign pushes.
+'option push-option <string>::
+ Transmit <string> as a push option. As the a push option
+ must not contain LF or NUL characters, the string is not encoded.
+
SEE ALSO
--------
linkgit:git-remote[1]
diff --git a/t/t5545-push-options.sh b/t/t5545-push-options.sh
index ea813b9383..9a57a7d8f2 100755
--- a/t/t5545-push-options.sh
+++ b/t/t5545-push-options.sh
@@ -3,6 +3,8 @@
test_description='pushing to a repository using push options'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-httpd.sh
+start_httpd
mk_repo_pair () {
rm -rf workbench upstream &&
@@ -100,4 +102,17 @@ test_expect_success 'two push options work' '
test_cmp expect upstream/.git/hooks/post-receive.push_options
'
+test_expect_success 'push option denied properly by http remote helper' '\
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions false &&
+ git -C upstream config http.receivepack true &&
+ cp -R upstream/.git "$HTTPD_DOCUMENT_ROOT_PATH"/upstream.git &&
+ git clone "$HTTPD_URL"/smart/upstream test_http_clone &&
+ test_commit -C test_http_clone one &&
+ test_must_fail git -C test_http_clone push --push-option=asdf origin master &&
+ git -C test_http_clone push origin master
+'
+
+stop_httpd
+
test_done
diff --git a/transport-helper.c b/transport-helper.c
index 91aed35ebb..1258d6aedd 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -826,6 +826,13 @@ static void set_common_push_options(struct transport *transport,
if (set_helper_option(transport, TRANS_OPT_PUSH_CERT, "if-asked") != 0)
die("helper %s does not support --signed=if-asked", name);
}
+
+ if (flags & TRANSPORT_PUSH_OPTIONS) {
+ struct string_list_item *item;
+ for_each_string_list_item(item, transport->push_options)
+ if (set_helper_option(transport, "push-option", item->string) != 0)
+ die("helper %s does not support 'push-option'", name);
+ }
}
static int push_refs_with_push(struct transport *transport,
--
2.12.0.rc0.1.g018cb5e6f4
^ permalink raw reply related
* Re: [PATCH] refs-internal.c: make files_log_ref_write() static
From: Junio C Hamano @ 2017-02-08 22:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, David Turner
In-Reply-To: <20170208094558.23712-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10)
> but probably never used outside refs-internal.c
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
It's been more than a year, so let's declare that when somebody
needs it it can easily be turned into extern again and take this
patch.
Thanks.
> refs/files-backend.c | 3 +++
> refs/refs-internal.h | 4 ----
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index c041d4ba21..6a0bf94bf1 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -165,6 +165,9 @@ static struct ref_entry *create_dir_entry(struct files_ref_store *ref_store,
> const char *dirname, size_t len,
> int incomplete);
> static void add_entry_to_dir(struct ref_dir *dir, struct ref_entry *entry);
> +static int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
> + const unsigned char *new_sha1, const char *msg,
> + int flags, struct strbuf *err);
>
> static struct ref_dir *get_ref_dir(struct ref_entry *entry)
> {
> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> index 25444cf5b0..4c9215d33f 100644
> --- a/refs/refs-internal.h
> +++ b/refs/refs-internal.h
> @@ -220,10 +220,6 @@ struct ref_transaction {
> enum ref_transaction_state state;
> };
>
> -int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
> - const unsigned char *new_sha1, const char *msg,
> - int flags, struct strbuf *err);
> -
> /*
> * Check for entries in extras that are within the specified
> * directory, where dirname is a reference directory name including
^ permalink raw reply
* Re: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns
From: Junio C Hamano @ 2017-02-08 21:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.20.1702072113380.25002@i7.lan>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> @@ -546,10 +546,16 @@ void parse_pathspec(struct pathspec *pathspec,
> pathspec->magic |= item[i].magic;
> }
>
> - if (nr_exclude == n)
> - die(_("There is nothing to exclude from by :(exclude) patterns.\n"
> - "Perhaps you forgot to add either ':/' or '.' ?"));
> -
> + /*
> + * If everything is an exclude pattern, add one positive pattern
> + * that matches everyting. We allocated an extra one for this.
> + */
> + if (nr_exclude == n) {
> + if (!(flags & PATHSPEC_PREFER_CWD))
> + prefixlen = 0;
> + init_pathspec_item(item + n, 0, prefix, prefixlen, "");
> + pathspec->nr++;
> + }
>
> if (pathspec->magic & PATHSPEC_MAXDEPTH) {
> if (flags & PATHSPEC_KEEP_ORDER)
Thanks. Even though the current code does not refer to the original
prefixlen after the added hunk, I'd prefer not to destroy it to
avoid future troubles, so I'll queue with a bit of tweak there,
perhaps like the attached.
Also this has an obvious fallout to the tests, whose (minimum) fix
is rather trivial.
Thanks.
pathspec.c | 7 +++----
t/t6132-pathspec-exclude.sh | 6 ++++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index d8f78088c8..b961f00c8c 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -522,7 +522,7 @@ void parse_pathspec(struct pathspec *pathspec,
}
pathspec->nr = n;
- ALLOC_ARRAY(pathspec->items, n+1);
+ ALLOC_ARRAY(pathspec->items, n + 1);
item = pathspec->items;
prefixlen = prefix ? strlen(prefix) : 0;
@@ -551,9 +551,8 @@ void parse_pathspec(struct pathspec *pathspec,
* that matches everyting. We allocated an extra one for this.
*/
if (nr_exclude == n) {
- if (!(flags & PATHSPEC_PREFER_CWD))
- prefixlen = 0;
- init_pathspec_item(item + n, 0, prefix, prefixlen, "");
+ int plen = (!(flags & PATHSPEC_PREFER_CWD)) ? 0 : prefixlen;
+ init_pathspec_item(item + n, 0, prefix, plen, "");
pathspec->nr++;
}
diff --git a/t/t6132-pathspec-exclude.sh b/t/t6132-pathspec-exclude.sh
index d51595cf6b..9dd5cde5fc 100755
--- a/t/t6132-pathspec-exclude.sh
+++ b/t/t6132-pathspec-exclude.sh
@@ -25,8 +25,10 @@ EOF
test_cmp expect actual
'
-test_expect_success 'exclude only should error out' '
- test_must_fail git log --oneline --format=%s -- ":(exclude)sub"
+test_expect_success 'exclude only no longer errors out' '
+ git log --oneline --format=%s -- . ":(exclude)sub" >expect &&
+ git log --oneline --format=%s -- ":(exclude)sub" >actual &&
+ test_cmp expect actual
'
test_expect_success 't_e_i() exclude sub' '
^ permalink raw reply related
* Re: "disabling bitmap writing, as some objects are not being packed"?
From: David Turner @ 2017-02-08 22:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Duy Nguyen, Git Mailing List
In-Reply-To: <20170208190858.rjoqehbhyizlwg5q@sigill.intra.peff.net>
On Wed, 2017-02-08 at 14:08 -0500, Jeff King wrote:
> 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).
Auto-gc might not succeed in pruning objects, but it will at least
reduce the number of packs, which is super-important for performance.
I think the intent of automatic gc is to have a git repository be
relatively low-maintenance from a server-operator perspective. (Side
note: it's fairly trivial for a user with push access to mess with the
check simply by pushing a bunch of objects whose shas start with 17).
It seems odd that git gets itself into a state where it refuses to do
any maintenance just because at some point some piece of the maintenance
didn't make progress.
Sure, I could change my configuration, but that doesn't help the other
folks (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813084 )
who run into this.
I have three thoughts on this:
Idea 1: when gc --auto would issue this message, instead it could create
a file named gc.too-much-garbage (instead of gc.log), with this message.
If that file exists, and it is less than one day (?) old, then we don't
attempt to do a full gc; instead we just run git repack -A -d. (If it's
more than one day old, we just delete it and continue anyway).
Idea 2 : Like idea 1, but instead of repacking, just smash the existing
packs together into one big pack. In other words, don't consider
dangling objects, or recompute deltas. Twitter has a tool called "git
combine-pack" that does this:
https://github.com/dturner-tw/git/blob/dturner/journal/builtin/combine-pack.c
That's less space-efficient than a true repack, but it's no worse than
having the packs separate, and it's a win for read performance because
there's no need to do a linear search over N packs to find an object.
Idea 3: As I suggested last time, separate fatal and non-fatal errors.
If gc fails because of EIO or something, we probably don't want to touch
the disk anymore. But here, the worst consequence is that we waste some
processing power. And it's better to occasionally waste processing power
in a non-interactive setting than it is to do so when a user will be
blocked on it. So non-fatal warnings should go to gc.log, and fatal
errors should go to gc.fatal. gc.log won't block gc from running. I
think this is my preferred option.
^ permalink raw reply
* Automatically Add .gitignore Files
From: Thangalin @ 2017-02-08 19:05 UTC (permalink / raw)
To: git
I frequently forget to add .gitignore files when creating new .gitignore files.
I'd like to request a command-line option to always add .gitignore
files (or, more generally, always add files that match a given file
specification).
Replicate
0. git init ...
1. echo "*.bak" >> .gitignore
2. touch file.txt
3. git add file.txt
4. git commit -a -m "..."
5. git push origin master
Expected Results
The .gitignore file is also added to the repository. (This is probably
the 80% use case.)
Actual Results
The .gitignore file is not added to the repository.
Additional Details
At step 4, there should be a prompt, warning, or (preferably) either a
command-line or configuration option to add the .gitignore file prior
to commit, automatically. Such as:
git commit --include-all-gitignore-files -a -m "..."
Or:
echo "**/.gitignore" >> .git/config/add-before-commit
^ permalink raw reply
* Re: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns
From: Linus Torvalds @ 2017-02-08 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqk290uywp.fsf@gitster.mtv.corp.google.com>
On Wed, Feb 8, 2017 at 1:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Thanks. Even though the current code does not refer to the original
> prefixlen after the added hunk, I'd prefer not to destroy it to
> avoid future troubles, so I'll queue with a bit of tweak there,
> perhaps like the attached.
Yeah, I considered that. Along with just passing in a NULL prefix
string too for that case. Not that it matters.
So ack on that change,
Linus
^ permalink raw reply
* Re: [PATCH v4] tag: generate useful reflog message
From: Cornelius Weig @ 2017-02-08 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, karthik.188, peff, bitte.keine.werbung.einwerfen
In-Reply-To: <xmqqshnov0c4.fsf@gitster.mtv.corp.google.com>
On 02/08/2017 10:28 PM, Junio C Hamano wrote:
> cornelius.weig@tngtech.com writes:
>
>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>
>> When tags are created with `--create-reflog` or with the option
>> `core.logAllRefUpdates` set to 'always', a reflog is created for them.
>> So far, the description of reflog entries for tags was empty, making the
>> reflog hard to understand. For example:
>> 6e3a7b3 refs/tags/test@{0}:
>>
>> Now, a reflog message is generated when creating a tag, following the
>> pattern "tag: tagging <short-sha1> (<description>)". If
>> GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
>> (<description>)" instead. If the tag references a commit object, the
>> description is set to the subject line of the commit, followed by its
>> commit date. For example:
>> 6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
>>
>> If the tag points to a tree/blob/tag objects, the following static
>> strings are taken as description:
>>
>> - "tree object"
>> - "blob object"
>> - "other tag object"
>>
>> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
>> Reviewed-by: Junio C Hamano <gitster@pobox.com>
>
> This last line is inappropriate, as I didn't review _THIS_ version,
> which is different from the previous one, and I haven't checked if
> the way the comments on the previous review were addressed in this
> version is agreeable.
Sorry for that confusion. I'm still not used to when adding what
sign-off is appropriate. I thought that adding you as reviewer is also a
question of courtesy.
A version with revised tests will follow.
^ permalink raw reply
* Re: [PATCH 1/2] pathspec magic: add '^' as alias for '!'
From: Brandon Williams @ 2017-02-08 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.20.1702072113040.25002@i7.lan>
On 02/07, Linus Torvalds wrote:
>
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 7 Feb 2017 21:05:28 -0800
> Subject: [PATCH 1/2] pathspec magic: add '^' as alias for '!'
>
> The choice of '!' for a negative pathspec ends up not only not matching
> what we do for revisions, it's also a horrible character for shell
> expansion since it needs quoting.
>
> So add '^' as an alternative alias for an excluding pathspec entry.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> pathspec.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/pathspec.c b/pathspec.c
> index 7ababb315..ecad03406 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -224,6 +224,12 @@ static const char *parse_short_magic(unsigned *magic, const char *elem)
> char ch = *pos;
> int i;
>
> + /* Special case alias for '!' */
> + if (ch == '^') {
> + *magic |= PATHSPEC_EXCLUDE;
> + continue;
> + }
> +
> if (!is_pathspec_magic(ch))
> break;
I like adding '^' to be an alias for excluding patterns. There have
been numerous times where I have wanted to use exclude patterns and
forgotten that I've needed to do some escape magic to get my shell to
leave '!' alone.
The only issue I see with doing this is that if a user supplies an
exclude pattern for a command which doesn't support exclude pathspec
magic the unsupported_magic() function will have slightly cryptic
output.
git cmd -- :^dir
would produce some output which says:
':^dir': pathspec magic not supported by this command: 'exclude' (mnemonic: '!')
And the user may scratch their head for a second since they didn't
supply the '!' character, but rather '^'. That being said I think it
should be fine since the long name of the magic is also printed so the
user should be able to figure out what's wrong. I also don't think
there are any users of pathspecs which disallow exclude magic so this
may not even be an issue.
--
Brandon Williams
^ permalink raw reply
* Re: Fwd: Possibly nicer pathspec syntax?
From: Junio C Hamano @ 2017-02-08 21:11 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <xmqqy3xgwpiq.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> 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.
Answering my own questions, here are my findings so far and a
tentative conclusion.
With or without the patch in this thread, parse_pathspec() behaves
the same way for either CWD or FULL if you feed a non-empty
pathspec with at least one positive element. IOW, if a caller feeds
a non-empty pathspec and there is no "negative" element involved, it
does not matter if we feed CWD or FULL.
There are only a handful of callers that pass neither preference
bits to parse_pathspec(). Here are my observations on them that
tells me that most of them are OK if we change them to prefer
either CWD or FULL:
- archive.c::path_exists() feeds a pathspec with a single element
to see if read_tree_recursive() finds any matching paths, to
allow its caller to iterate over the original pathspec and see
if there is a typo (i.e. an element that matches nothing). It
should prefer FULL to match what parse_pathspec_arg(), its
caller, uses.
The caller probably should refrain from passing ones with
negative magic. I.e. "git archive -- t :\!t/perf" errors out
because checking each element independently in the loop means
that ":\!t/perf" is checked alone, triggering "there is nothing
to exclude from".
- blame.c::find_origin() feeds a pathspec with a single element,
which is a path in the history and does so as a literal, hence
no room for "negative" to kick in.
- builtin/check-ignore.c::check_ignore(), when argc==0, does not
call parse_pathspec(). It does not take any magic other than
FROMTOP, so "negative" won't come into the picture.
- builtin/checkout.c::cmd_checkout(), when argc==0, does not call
parse_pathspec(). This codepath will get affected by Linus's
change ("cd t && git checkout :\!perf" would try to check out
everything except t/perf, but what is a reasonable definition of
"everything" in the context of this command). We need to
decide, and I am leaning towards preferring CWD for this case.
- revision.c::setup_revisions() calls parse_pathspec() only when
the caller gave a non-empty pathspec. This pathspec is used for
pruning log traversal (e.g. "only show commits that touch these
paths") and is affected by Linus's change. It should favor
FULL.
- tree-diff.c::try_to_follow_renames() feeds a pathspec with a
single element as a literal, hence no room for "negative" to
kick in.
So, I am tempted to suggest us doing the following:
* Leave a NEEDSWORK comment to archive.c::path_exists() that is
used for checking the validation of pathspec elements. To fix it
properly, we need to be able to skip a negative pathspec to be
passed to this function by the caller, and to do so, we need to
expose a helper from the pathspec API that gets a single string
and returns what magic it has, but that is of lower priority.
* Retire the PATHSPEC_PREFER_CWD bit and replace its use with the
lack of the PATHSPEC_PREFER_FULL bit.
* Keep most of the above callsites that currently do not pass
CWD/FULL as they are, except the ones that should take FULL (see
above).
Comments?
^ permalink raw reply
* Re: Bug with fixup and autosquash
From: Junio C Hamano @ 2017-02-08 22:55 UTC (permalink / raw)
To: Ashutosh Bapat
Cc: git, Johannes Schindelin, Michael Haggerty, Michael J Gruber,
Matthieu Moy
In-Reply-To: <CAFjFpRe8zqxs4OLbCrjnuEzF=75sbBJ+HuZqek49B=O=TFHq8A@mail.gmail.com>
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> I have been using git rebase heavily these days and seem to have found a bug.
>
> If there are two commit messages which have same prefix e.g.
> yyyyyy This is prefix
> xxxxxx This is prefix and message
>
> xxxxxx comitted before yyyyyy
>
> Now I commit a fixup to yyyyyy using git commit --fixup yyyyyy
> zzzzzz fixup! This is prefix
>
> When I run git rebase -i --autosquash, the script it shows me looks like
> pick xxxxxx This is prefix and message
> fixup zzzzzz fixup! This is prefix
> pick yyyyyy This is prefix
>
> I think the correct order is
> pick xxxxxx This is prefix and message
> pick yyyyyy This is prefix
> fixup zzzzzz fixup! This is prefix
>
> Is that right?
Because "commit" pretends as if it took the exact commit object name
to be fixed up (after all, it accepts "yyyyyy" that is a name of the
commit object), it would be nice if the fixup is applied to that
exact commit, even if you had many commits that share exactly the
same title (i.e. not just shared prefix).
Unfortunately, "rebase -i --autosquash" reorders the entries by
identifying the commit by its title, and it goes with prefix match
so that fix-up commits created without using --fixup option but
manually records the title's prefix substring can also work.
We could argue that the logic should notice that there is one exact
match and another non-exact prefix match and favor the former, and
certainly such a change would make your made-up example (you didn't
actually have a commit whose title is literally "This is prefix")
above work better.
But I am not sure if adding such heuristics would really help in
general. It would not help those whose commits are mostly titled
ultra-vaguely, like "fix", "bugfix", "docfix", etc.
Another possibility is to teach "commit --fixup" to cast exact
commit object name in stone. That certainly would solve your
immediate problem, but it has a grave negative impact when the user
rebases the same topic many times (which happens often).
For example, I may have a series of commits A and B, notice that A
could be done a bit better and have "fixup A" on top, build a new
commit C on it, and then realize that the next step (i.e. D) would
need support from a newer codebase than where I started (i.e. A^).
At that point, I would have a 4-commit series (A, B, "fixup A", and
C), and I would rebase them on top of something newer. I am
undecided if that "fixup A" is really an improvement or unnecessary,
when I do this, but I do know that I want to build the series on top
of a different commit. So I do rebase without --autosquash (I would
probably rebase without --interactive for this one).
Then I keep working and add a new commit D on top. After all that,
I would have a more-or-less completed series and would be ready to
re-assess the whole series. I perhaps decide that "fixup A" is
really an improvement. And then I would "rebase -i" to squash the
fix-up into A.
But notice that at this point, what we are calling A has different
object name than the original A the fixup was written for, because
we rebased once on top of a newer codebase. That commit can still
be identified by its title, but not with its original commit object
name.
I think that is why "commit --fixup <commit>" turns the commit
object name (your "yyyyyy") into a string (your "This is prefix")
and that is a reasonable design decision [*1*].
So from that point of view, if we were to address your issue, it
should happen in "rebase -i --autosquash" side, not "commit --fixup"
side.
Let's hear from some of those (Cc'ed) who were involved in an
earlier --autosquash thread.
https://public-inbox.org/git/cover.1259934977.git.mhagger@alum.mit.edu/
[Footnote]
*1* "rebase -i --autosquash" does understand "fixup! yyyyyy", so if
you are willing to accept the consequence of not being able to
rebase twice, you could instead do
$ git commit -m "fixup! yyyyyy"
I would think.
^ permalink raw reply
* Re: "disabling bitmap writing, as some objects are not being packed"?
From: Jeff King @ 2017-02-08 23:00 UTC (permalink / raw)
To: David Turner; +Cc: Junio C Hamano, Duy Nguyen, Git Mailing List
In-Reply-To: <1486592043.1938.82.camel@novalis.org>
On Wed, Feb 08, 2017 at 05:14:03PM -0500, David Turner wrote:
> > 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).
>
> Auto-gc might not succeed in pruning objects, but it will at least
> reduce the number of packs, which is super-important for performance.
Right, I mean to bump the loose-object limit but keep the
gc.autoPackLimit at 50. If you couple that with setting
transfer.unpackLimit, then each push creates a single pack, and you
repack after 50 pushes.
You don't have to care about loose objects, because you know you only
get them when a "gc" ejects loose objects (so they're not as efficient,
but nothing actually accesses them; they just hang around until their
mtime grace period is up).
> I think the intent of automatic gc is to have a git repository be
> relatively low-maintenance from a server-operator perspective. (Side
> note: it's fairly trivial for a user with push access to mess with the
> check simply by pushing a bunch of objects whose shas start with 17).
> It seems odd that git gets itself into a state where it refuses to do
> any maintenance just because at some point some piece of the maintenance
> didn't make progress.
In my experience, auto-gc has never been a low-maintenance operation on
the server side (and I do think it was primarily designed with clients
in mind).
At GitHub we disable it entirely, and do our own gc based on a throttled
job queue (one reason to throttle is that repacking is memory and I/O
intensive, so you really don't want to a bunch of repacks kicking off
all at once). So basically any repo that gets pushed to goes on the
queue, and then we pick the worst cases from the queue based on how
badly they need packing[1].
I wish regular Git were more turn-key in that respect. Maybe it is for
smaller sites, but we certainly didn't find it so. And I don't know that
it's feasible to really share the solution. It's entangled with our
database (to store last-pushed and last-maintenance values for repos)
and our job scheduler.
[1] The "how bad" thing is a heuristic, and we found it's generally
proportional to the number of bytes stored in objects _outside_ of
the big "main" pack. So 2 big pushes may need maintenance more
than 10 tiny pushes, because they have more objects (and our goal
with maintenance isn't just saving disk space or avoiding the linear
pack search, but having up-to-date bitmaps and good on-disk deltas
to make serving fetches as cheap as possible).
> Sure, I could change my configuration, but that doesn't help the other
> folks (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813084 )
> who run into this.
Yeah, I'm certainly open to improving Git's defaults. If it's not clear
from the above, I mostly just gave up for a site the size of GitHub. :)
> Idea 1: when gc --auto would issue this message, instead it could create
> a file named gc.too-much-garbage (instead of gc.log), with this message.
> If that file exists, and it is less than one day (?) old, then we don't
> attempt to do a full gc; instead we just run git repack -A -d. (If it's
> more than one day old, we just delete it and continue anyway).
I kind of wonder if this should apply to _any_ error. I.e., just check
the mtime of gc.log and forcibly remove it when it's older than a day.
You never want to get into a state that will fail to resolve itself
eventually. That might still happen (e.g., corrupt repo), but at the
very least it won't be because Git is too dumb to try again.
> Idea 2 : Like idea 1, but instead of repacking, just smash the existing
> packs together into one big pack. In other words, don't consider
> dangling objects, or recompute deltas. Twitter has a tool called "git
> combine-pack" that does this:
> https://github.com/dturner-tw/git/blob/dturner/journal/builtin/combine-pack.c
We wrote something similar at GitHub, too, but we never ended up using
it in production. We found that with a sane scheduler, it's not too big
a deal to just do maintenance once in a while.
Also, our original problem was that repos which have gotten out of
hand (say, 5000 packs) repacked _very_ slowly with a normal repack. So
a "fast pack" followed by a real pack was a viable way out of that. In
the end, I just made pack-objects handle this case better, and we
don't need the fast-pack.
> That's less space-efficient than a true repack, but it's no worse than
> having the packs separate, and it's a win for read performance because
> there's no need to do a linear search over N packs to find an object.
Over the long term you may end up with worse packs, because the true
repack will drop some delta opportunities between objects in the same
pack (reasoning that they weren't made into deltas last time, so it's
not worth trying again). You'd probably need to use "-f" periodically.
This is all speculation, though. We never did it in production, so I was
never able to measure the real impact over time.
> Idea 3: As I suggested last time, separate fatal and non-fatal errors.
> If gc fails because of EIO or something, we probably don't want to touch
> the disk anymore. But here, the worst consequence is that we waste some
> processing power. And it's better to occasionally waste processing power
> in a non-interactive setting than it is to do so when a user will be
> blocked on it. So non-fatal warnings should go to gc.log, and fatal
> errors should go to gc.fatal. gc.log won't block gc from running. I
> think this is my preferred option.
This seems like your (1), except that it handles more than one type of
non-fatal error. So I like it much better.
I'm still not sure if it's worth making the fatal/non-fatal distinction.
Doing so is perhaps safer, but it does mean that somebody has to decide
which errors are important enough to block a retry totally, and which
are not. In theory, it would be safe to always _try_ and then the gc
process can decide when something is broken and abort. And all you've
wasted is some processing power each day.
-Peff
^ permalink raw reply
* Re: [PATCH] push options: fail properly in the stateless case
From: Junio C Hamano @ 2017-02-08 23:01 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org, Jonathan Nieder
In-Reply-To: <CAGZ79kaszczpnu+VEV3y+61qgji-0+vRFVLk8Q1+BbSDgiHz1Q@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
>>> +'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.
>
> When implementing push options, we discussed that and according to
> Documentation/git-push:
>
> The given string must not contain a NUL or LF character.
OK, so "Transmit <string> as a push option" is sufficient, as the
string is sent as-is. OK.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] rev-list-options.txt: update --all about HEAD
From: Jeff King @ 2017-02-08 23:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20170208060641.13793-1-pclouds@gmail.com>
On Wed, Feb 08, 2017 at 01:06:41PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This is the document patch for f0298cf1c6 (revision walker: include a
> detached HEAD in --all - 2009-01-16).
>
> Even though that commit is about detached HEAD, as Jeff pointed out,
> always adding HEAD in that case may have subtle differences with
> --source or --exclude. So the document mentions nothing about the
> detached-ness.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> v2 drops "detached".
Thanks. Seems like an obvious improvement to me.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] pathspec magic: add '^' as alias for '!'
From: Junio C Hamano @ 2017-02-08 23:05 UTC (permalink / raw)
To: Brandon Williams; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20170208223532.GB108686@google.com>
Brandon Williams <bmwill@google.com> writes:
> git cmd -- :^dir
>
> would produce some output which says:
> ':^dir': pathspec magic not supported by this command: 'exclude' (mnemonic: '!')
>
> And the user may scratch their head for a second since they didn't
> supply the '!' character, but rather '^'.
Yup, I am tempted to tweak Cornelius's glossary fixup and squash
this into the series, for two purposes.
- it makes it clear that '^' and '!' mean the same thing (and
clearer than Cornelius's original, "! or ^", which could leave
the reader wondering "ok there are two ways to say negative; do
they subtly mean different things?").
- it hints that '!' is the more official spelling, making the
output you showed above acceptable.
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 8ad29e61a9..822ca83264 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -386,8 +386,8 @@ 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
- matches, the path is ignored.
+ through all exclude pathspec (magic signature: `!` or its
+ synonym `^`). If it matches, the path is ignored.
--
[[def_parent]]parent::
^ permalink raw reply related
* Re: [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree
From: Junio C Hamano @ 2017-02-08 23:19 UTC (permalink / raw)
To: Stefan Beller
Cc: Nguyễn Thái Ngọc Duy, git@vger.kernel.org,
Michael Haggerty
In-Reply-To: <CAGZ79kZk1Chq1R-anz0RC+0GDEubGm5kEQOsy5bz9zwCYEi9nw@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> 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).
I agree with you that the concept of remote is quite detached from
the concept of wt and submodule whose refs need to be peeked at from
the local repository. After all, "remote" tracking branches are
part of local repository's refs.
> My gut reaction would be to s/submodule/alternative/ here,
> but we also have a thing called alternates already.
... and I tend to think that is far closer a concept. You borrow
objects from your alternate object store, and that alternate object
store may have its own set of refs you would need to peek when you
are computing reachability from refs.
Also don't we already enumerate such refs that pin objects in the
alternate object store when doing object transfer negotiation in
order to send ".have" entries for their tips? What API do we use to
do that, I wonder.
^ permalink raw reply
* Re: [PATCH 2/2] worktree.c: use submodule interface to access refs from another worktree
From: Junio C Hamano @ 2017-02-08 23:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Michael Haggerty
In-Reply-To: <20170208113144.8201-3-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> As such, we can just linked worktree's path as a submodule. We just need
Lack of verb made me read this three times. "We can just treat
linked worktree's path as if it were a submodule"?
I agree with you that the "submodule" in the name is misleading. We
would want to be able to walk refs from other local repositories
(and repository-like entities, like the .git/ thing in a liked
worktree), like our own submodule, or the repository we borrow
objects from via the alternate mechanism.
^ permalink raw reply
* [PATCH v5] tag: generate useful reflog message
From: cornelius.weig @ 2017-02-08 22:41 UTC (permalink / raw)
To: git; +Cc: Cornelius Weig, gitster, bitte.keine.werbung.einwerfen
In-Reply-To: <xmqqshnov0c4.fsf@gitster.mtv.corp.google.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:
Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging <short-sha1> (<description>)". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
(<description>)" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)
If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:
- "tree object"
- "blob object"
- "other tag object"
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
---
Notes:
Interdiff v4..v5
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 894959f..1a3230f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -80,9 +80,10 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
test_must_fail git reflog exists refs/tags/mytag
'
-git log -1 > expected \
- --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
test_expect_success 'creating a tag with --create-reflog should create reflog' '
+ git log -1 \
+ --format="format:tag: tagging %h (%s, %cd)%n" \
+ --date=format:%Y-%m-%d >expected &&
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
@@ -90,9 +91,10 @@ test_expect_success 'creating a tag with --create-reflog should create reflog' '
test_cmp expected actual
'
-git log -1 > expected \
- --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
test_expect_success 'annotated tag with --create-reflog has correct message' '
+ git log -1 \
+ --format="format:tag: tagging %h (%s, %cd)%n" \
+ --date=format:%Y-%m-%d >expected &&
test_when_finished "git tag -d tag_with_reflog" &&
git tag -m "annotated tag" --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
builtin/tag.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t7004-tag.sh | 18 +++++++++++++++++-
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..bca890f 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -302,6 +302,54 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
+static void create_reflog_msg(const unsigned char *sha1, struct strbuf *sb)
+{
+ enum object_type type;
+ struct commit *c;
+ char *buf;
+ unsigned long size;
+ int subject_len = 0;
+ const char *subject_start;
+
+ char *rla = getenv("GIT_REFLOG_ACTION");
+ if (rla) {
+ strbuf_addstr(sb, rla);
+ } else {
+ strbuf_addstr(sb, _("tag: tagging "));
+ strbuf_add_unique_abbrev(sb, sha1, DEFAULT_ABBREV);
+ }
+
+ strbuf_addstr(sb, " (");
+ type = sha1_object_info(sha1, NULL);
+ switch (type) {
+ default:
+ strbuf_addstr(sb, _("object of unknown type"));
+ break;
+ case OBJ_COMMIT:
+ if ((buf = read_sha1_file(sha1, &type, &size)) != NULL) {
+ subject_len = find_commit_subject(buf, &subject_start);
+ strbuf_insert(sb, sb->len, subject_start, subject_len);
+ } else {
+ strbuf_addstr(sb, _("commit object"));
+ }
+ free(buf);
+
+ if ((c = lookup_commit_reference(sha1)) != NULL)
+ strbuf_addf(sb, ", %s", show_date(c->date, 0, DATE_MODE(SHORT)));
+ break;
+ case OBJ_TREE:
+ strbuf_addstr(sb, _("tree object"));
+ break;
+ case OBJ_BLOB:
+ strbuf_addstr(sb, _("blob object"));
+ break;
+ case OBJ_TAG:
+ strbuf_addstr(sb, _("other tag object"));
+ break;
+ }
+ strbuf_addch(sb, ')');
+}
+
struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +383,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+ struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -494,6 +543,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
+ create_reflog_msg(object, &reflog_msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +555,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
- NULL, &err) ||
+ reflog_msg.buf, &err) ||
ref_transaction_commit(transaction, &err))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +565,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release(&err);
strbuf_release(&buf);
strbuf_release(&ref);
+ strbuf_release(&reflog_msg);
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..1a3230f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -81,9 +81,25 @@ test_expect_success 'creating a tag using default HEAD should succeed' '
'
test_expect_success 'creating a tag with --create-reflog should create reflog' '
+ git log -1 \
+ --format="format:tag: tagging %h (%s, %cd)%n" \
+ --date=format:%Y-%m-%d >expected &&
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
- git reflog exists refs/tags/tag_with_reflog
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
+'
+
+test_expect_success 'annotated tag with --create-reflog has correct message' '
+ git log -1 \
+ --format="format:tag: tagging %h (%s, %cd)%n" \
+ --date=format:%Y-%m-%d >expected &&
+ test_when_finished "git tag -d tag_with_reflog" &&
+ git tag -m "annotated tag" --create-reflog tag_with_reflog &&
+ git reflog exists refs/tags/tag_with_reflog &&
+ sed -e "s/^.* //" .git/logs/refs/tags/tag_with_reflog > actual &&
+ test_cmp expected actual
'
test_expect_success '--create-reflog does not create reflog on failure' '
--
2.10.2
^ permalink raw reply related
* Re: Automatically Add .gitignore Files
From: Junio C Hamano @ 2017-02-08 23:39 UTC (permalink / raw)
To: Thangalin; +Cc: git
In-Reply-To: <CAANrE7rmUZcJkw+thMczv3D=7sqcUHBsorzvEZgYg=6AEfrU=w@mail.gmail.com>
Thangalin <thangalin@gmail.com> writes:
> I frequently forget to add .gitignore files when creating new .gitignore files.
>
> I'd like to request a command-line option to always add .gitignore
> files (or, more generally, always add files that match a given file
> specification).
That is essentially what "Untracked files" listing in the editor
buffer given to you when you type "git commit" is about. By not
saying you ignore .gitattributes, .gitignore, .gitmodules, etc., you
are reminded if you forgot to add them. "git status" does the same,
and perhaps you want to make it a habit to run it before committing.
I am tempted to say that there should be a way to somehow forbid use
of the "-m" option to "git commit" by default, until the user gains
more familiarity with use of Git. That way, they will learn to pay
more attention to the "Untracked" and "Changes not staged" sections
;-)
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-09 0:00 UTC (permalink / raw)
Cc: git-mailing-list
In-Reply-To: <CAKepmahcaV1Ro_wObkFxezrZntL6JQ_ft+06_3ZSrxEz-yNjzA@mail.gmail.com>
Well, it mostly works, but I'm getting some weirdness where it has
grabbed a line at 126 and is using that for the hunk header. Strange
thing is, I move the file to another repository, commit it, make a
change to the fileand do a diff, and it gets the correct hunk header.
I'm at a loss. :(
On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
> That was it. I have a .gitattributes file in my home directory.
> Ahhh, but it's not in my %userprofile% directory, but in my ~
> directory.
>
> A bit confusing having 2 home directories. I made a link to my
> .gitconfig, but forgot to make a link to my .gitattributes.
>
> Thanks.
>
>
> A
>
> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>> Double check .gitattributes?
>>
>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh.bsc@gmail.com> wrote:
>>>
>>> Thanks Samuel,
>>>
>>> That example showed that there must be something wrong in my .git
>>> directory, because with it, I'm getting the correct output. Moving
>>> the same lines to my .git/config didn't work.
>>>
>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>> >
>>> > Try cloning and then for any of config1 thru 3,
>>> >
>>> > $ cp configX .git/config
>>> > $ git diff HEAD^ -- test.natvis
>>> >
>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>> > <adrianh.bsc@gmail.com> wrote:
>>> >> 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
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-09 0:01 UTC (permalink / raw)
To: Jack Adrian Zappa; +Cc: git-mailing-list
In-Reply-To: <CAKepmaidYd4tMRwSNoTTga8s6ji-pc87fZqtxdeDcDVpFhcPWA@mail.gmail.com>
Tried to copy the .git/config file over to the non-working repository
and it didn't seem to do anything. Could the git database be
partially corrupted?
On Wed, Feb 8, 2017 at 7:00 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
> Well, it mostly works, but I'm getting some weirdness where it has
> grabbed a line at 126 and is using that for the hunk header. Strange
> thing is, I move the file to another repository, commit it, make a
> change to the fileand do a diff, and it gets the correct hunk header.
>
> I'm at a loss. :(
>
> On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
>> That was it. I have a .gitattributes file in my home directory.
>> Ahhh, but it's not in my %userprofile% directory, but in my ~
>> directory.
>>
>> A bit confusing having 2 home directories. I made a link to my
>> .gitconfig, but forgot to make a link to my .gitattributes.
>>
>> Thanks.
>>
>>
>> A
>>
>> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>> Double check .gitattributes?
>>>
>>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh.bsc@gmail.com> wrote:
>>>>
>>>> Thanks Samuel,
>>>>
>>>> That example showed that there must be something wrong in my .git
>>>> directory, because with it, I'm getting the correct output. Moving
>>>> the same lines to my .git/config didn't work.
>>>>
>>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>>> >
>>>> > Try cloning and then for any of config1 thru 3,
>>>> >
>>>> > $ cp configX .git/config
>>>> > $ git diff HEAD^ -- test.natvis
>>>> >
>>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>>> > <adrianh.bsc@gmail.com> wrote:
>>>> >> 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
* Re: Automatically Add .gitignore Files
From: Stephan Beyer @ 2017-02-09 0:01 UTC (permalink / raw)
To: Junio C Hamano, Thangalin; +Cc: git
In-Reply-To: <xmqqmvdwtfq8.fsf@gitster.mtv.corp.google.com>
> I am tempted to say that there should be a way to somehow forbid use
> of the "-m" option to "git commit" by default, until the user gains
> more familiarity with use of Git.
Since I am using git, I am tempted to say that "git commit -m" should be
abolished. If I tell somebody how to use git, I never mention "git
commit -m". Unluckily they find it out themselves... ;D
The typical observations I have when people use "git commit -m":
* The commit messages are either too long (in one line!) or
too meaningless.
* People don't check what they added and commit wrong stuff.
* People make fast temporary commits with "asdafsd" commit messages.
Then they get distracted for some time and work on another branch.
When they turn back to the old branch they don't know what "asdafsd"
was...
Thanks to git rebase -i and/or git commit --amend, it is all not too bad
after all ;D
Best
Stephan
^ permalink raw reply
* Re: Trying to use xfuncname without success.
From: Jack Adrian Zappa @ 2017-02-09 0:10 UTC (permalink / raw)
Cc: git-mailing-list
In-Reply-To: <CAKepmagSysE_31Y3JJwhOKvD_kGfiyEXikep62g=cn9+=v_fZA@mail.gmail.com>
> where it has grabbed a line at 126 and is using that for the hunk header.
When I say that, I mean that it is using that line for *every* hunk
header, for every change, regardless if it has passed a hunk head that
it should have matched.
On Wed, Feb 8, 2017 at 7:01 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
> Tried to copy the .git/config file over to the non-working repository
> and it didn't seem to do anything. Could the git database be
> partially corrupted?
>
> On Wed, Feb 8, 2017 at 7:00 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
>> Well, it mostly works, but I'm getting some weirdness where it has
>> grabbed a line at 126 and is using that for the hunk header. Strange
>> thing is, I move the file to another repository, commit it, make a
>> change to the fileand do a diff, and it gets the correct hunk header.
>>
>> I'm at a loss. :(
>>
>> On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh.bsc@gmail.com> wrote:
>>> That was it. I have a .gitattributes file in my home directory.
>>> Ahhh, but it's not in my %userprofile% directory, but in my ~
>>> directory.
>>>
>>> A bit confusing having 2 home directories. I made a link to my
>>> .gitconfig, but forgot to make a link to my .gitattributes.
>>>
>>> Thanks.
>>>
>>>
>>> A
>>>
>>> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>>> Double check .gitattributes?
>>>>
>>>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh.bsc@gmail.com> wrote:
>>>>>
>>>>> Thanks Samuel,
>>>>>
>>>>> That example showed that there must be something wrong in my .git
>>>>> directory, because with it, I'm getting the correct output. Moving
>>>>> the same lines to my .git/config didn't work.
>>>>>
>>>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
>>>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>>>> >
>>>>> > Try cloning and then for any of config1 thru 3,
>>>>> >
>>>>> > $ cp configX .git/config
>>>>> > $ git diff HEAD^ -- test.natvis
>>>>> >
>>>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>>>> > <adrianh.bsc@gmail.com> wrote:
>>>>> >> 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