Re: [RFH - Tcl/Tk] use of procedure before declaration?

On Tue, 17 Jan 2017 12:29:23 +0100 (CET) Johannes Schindelin wrote: > > In > > https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242 > > the procedure `_unset_recentrepo` is called, however the procedure > > isn't declared until line 248. My

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Am 17.01.2017 um 20:17 schrieb Junio C Hamano: So... can we move this forward? I have no objects anymore. -- Hannes

difflame

Hi! For a very long time I had wanted to get the output of diff to include blame information as well (to see when something was added/removed). I just created a very small (and rough) tool for that purpose. It's written in python and if it gets to something better than a small tool, I think it

[PATCH] gitk: remove translated message from comments

"make update-po" fails because a previously untranslated string has now been translated: Updating po/sv.po po/sv.po:1388: duplicate message definition... po/sv.po:380: ...this is the location of the first definition Remove the duplicate message definition. Reported-by:

"git diff --ignore-space-change --stat" lists files with only whitespace differences as "changed"

A bug report: I noticed that "git diff --ignore-space-change --stat" lists files with only whitespace differences as having changed with 0 differing lines. This is inconsistent with the behavior without -- stat, which doesn't list such files at all. (Same behavior with all the --ignore*space*

[PATCHv3 4/4] unpack-trees: support super-prefix option

In the future we want to support working tree operations within submodules, e.g. "git checkout --recurse-submodules", which will update the submodule to the commit as recorded in its superproject. In the submodule the unpack-tree operation is carried out as usual, but the reporting to the user

[PATCH 4/4] documentation: retire unfinished documentation

When looking for documentation for a specific function, you may be tempted to run git -C Documentation grep index_name_pos only to find the file technical/api-in-core-index.txt, which doesn't help for understanding the given function. It would be better to not find these functions in the

Re: [PATCH] transport submodules: correct error message

On Tue, Jan 17, 2017 at 4:15 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote: >>> Stefan Beller writes: >>> Trying to push with

Re: [PATCH] transport submodules: correct error message

Stefan Beller writes: > On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> Trying to push with --recurse-submodules=on-demand would run into >>> the same problem. To fix this issue >>> 1)

Re: [PATCH v6 4/6] builtin/tag: add --format argument for tag -v

santi...@nyu.edu writes: > @@ -428,9 +443,12 @@ int cmd_tag(int argc, const char **argv, const char > *prefix) > if (filter.merge_commit) > die(_("--merged and --no-merged option are only allowed with > -l")); > if (cmdmode == 'd') > - return

[PATCH v2 0/5] extend git-describe pattern matching

From: Jacob Keller Teach git describe and git name-rev the ability to match multiple patterns inclusively. Additionally, teach these commands to also accept negative patterns to exclude any refs which match. The pattern lists for positive and negative patterns are

[PATCH v3 3/5] name-rev: add support to exclude refs by pattern match

From: Jacob Keller Extend name-rev further to support matching refs by adding `--exclude` patterns. These patterns will limit the scope of refs by excluding any ref that matches at least one exclude pattern. Checking the exclude refs shall happen first, before checking

[PATCH v3 4/5] describe: teach --match to accept multiple patterns

From: Jacob Keller Teach `--match` to be accepted multiple times, accumulating a list of patterns to match into a string list. Each pattern is inclusive, such that a tag need only match one of the provided patterns to be considered for matching. This extension is useful

[PATCH v3 2/5] name-rev: extend --refs to accept multiple patterns

From: Jacob Keller Teach git name-rev to take a string list of patterns from --refs instead of only a single pattern. The list of patterns will be matched inclusively, such that a ref only needs to match one pattern to be included. If a ref will only be excluded if it

[PATCH v3 5/5] describe: teach describe negative pattern matches

From: Jacob Keller Teach git-describe the `--exclude` option which will allow specifying a glob pattern of tags to ignore. This can be combined with the `--match` patterns to enable more flexibility in determining which tags to consider. For example, suppose you wish to

[PATCH v3 0/5] extend git-describe pattern matching

From: Jacob Keller ** v3 fixes a minor typo in one of the test cases, so please ignore v2 I left the interdiff as between v1 and v3 instead of v2 ** Teach git describe and git name-rev the ability to match multiple patterns inclusively. Additionally, teach these

[PATCH v3 1/5] doc: add documentation for OPT_STRING_LIST

From: Jacob Keller Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper", 2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated list of strings. However, this was not documented in the api-parse-options documentation. Add documentation now so

Re: [PATCH] transport submodules: correct error message

On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Trying to push with --recurse-submodules=on-demand would run into >> the same problem. To fix this issue >> 1) specifically mention that we looked for branches on the

[PATCH v2 3/5] name-rev: add support to exclude refs by pattern match

From: Jacob Keller Extend name-rev further to support matching refs by adding `--exclude` patterns. These patterns will limit the scope of refs by excluding any ref that matches at least one exclude pattern. Checking the exclude refs shall happen first, before checking

Re: [PATCH v6 0/6] Add --format to tag verification

santi...@nyu.edu writes: > From: Santiago Torres > > This is the sixth iteration of [1][2][3][4][5], and as a result of the > discussion in [5]. The main goal of this patch series is to bring > --format to git tag verification so that upper-layer tools can inspect > the content

[PATCH v2 2/5] name-rev: extend --refs to accept multiple patterns

From: Jacob Keller Teach git name-rev to take a string list of patterns from --refs instead of only a single pattern. The list of patterns will be matched inclusively, such that a ref only needs to match one pattern to be included. If a ref will only be excluded if it

[PATCH v2 4/5] describe: teach --match to accept multiple patterns

From: Jacob Keller Teach `--match` to be accepted multiple times, accumulating a list of patterns to match into a string list. Each pattern is inclusive, such that a tag need only match one of the provided patterns to be considered for matching. This extension is useful

Re: [PATCH v6 4/6] builtin/tag: add --format argument for tag -v

santi...@nyu.edu writes: > -static int for_each_tag_name(const char **argv, each_tag_name_fn fn) > +static int for_each_tag_name(const char **argv, each_tag_name_fn fn, > + void *cb_data) > { > const char **p; > char ref[PATH_MAX]; > int had_error = 0; >

[PATCH v2 1/5] doc: add documentation for OPT_STRING_LIST

From: Jacob Keller Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper", 2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated list of strings. However, this was not documented in the api-parse-options documentation. Add documentation now so

[PATCH v2 5/5] describe: teach describe negative pattern matches

From: Jacob Keller Teach git-describe the `--exclude` option which will allow specifying a glob pattern of tags to ignore. This can be combined with the `--match` patterns to enable more flexibility in determining which tags to consider. For example, suppose you wish to

Re: [PATCH v6 4/6] builtin/tag: add --format argument for tag -v

santi...@nyu.edu writes: > + if (gpg_verify_tag(sha1, name, flags)) > + return -1; > + > +if (fmt_pretty) > + pretty_print_ref(name, sha1, fmt_pretty); That's a funny indentation. I'll fix it up locally while queuing. > + > + return 0; > }

Re: [PATCH] transport submodules: correct error message

Stefan Beller writes: > Trying to push with --recurse-submodules=on-demand would run into > the same problem. To fix this issue > 1) specifically mention that we looked for branches on the remote. That makes an incorrect statement ("not found on any remote"---we did not

[PATCH v6 2/6] ref-filter: add function to print single ref_array_item

From: Lukas Puehringer ref-filter functions are useful for printing git object information using a format specifier. However, some other modules may not want to use this functionality on a ref-array but only print a single item. Expose a pretty_print_ref function to

[PATCH v6 6/6] t/t7004-tag: Add --format specifier tests

From: Santiago Torres tag -v now supports --format specifiers to inspect the contents of a tag upon verification. Add two tests to ensure this behavior is respected in future changes. Signed-off-by: Santiago Torres --- t/t7004-tag.sh | 16

[PATCH v6 4/6] builtin/tag: add --format argument for tag -v

From: Lukas Puehringer Adding --format to git tag -v mutes the default output of the GPG verification and instead prints the formatted tag object. This allows callers to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG

[PATCH v6 3/6] builtin/verify-tag: add --format to verify-tag

From: Santiago Torres Callers of verify-tag may want to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification. This is to avoid tag refs that point to an incorrect object. Add a --format parameter to git verify-tag to print

[PATCH v6 1/6] gpg-interface,tag: add GPG_VERIFY_OMIT_STATUS flag

From: Lukas Puehringer Functions that print git object information may require that the gpg-interface functions be silent. Add GPG_VERIFY_OMIT_STATUS flag and prevent print_signature_buffer from being called if flag is set. Signed-off-by: Lukas Puehringer

[PATCH v6 5/6] t/t7030-verify-tag: Add --format specifier tests

From: Santiago Torres Verify-tag now provides --format specifiers to inspect and ensure the contents of the tag are proper. We add two tests to ensure this functionality works as expected: the return value should indicate if verification passed, and the format specifiers must

[PATCH v6 0/6] Add --format to tag verification

From: Santiago Torres This is the sixth iteration of [1][2][3][4][5], and as a result of the discussion in [5]. The main goal of this patch series is to bring --format to git tag verification so that upper-layer tools can inspect the content of a tag and make decisions based on

[PATCH 0/4] start documenting core functions

The two single patches[1] are turned into a series here. [1] https://public-inbox.org/git/20170117200147.25425-1-sbel...@google.com/ Thanks, Stefan Stefan Beller (4): document index_name_pos remove_index_entry_at: move documentation to cache.h document add_[file_]to_index documentation:

[PATCH 1/4] document index_name_pos

Signed-off-by: Stefan Beller --- cache.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/cache.h b/cache.h index 1b67f078dd..270a0d0ea7 100644 --- a/cache.h +++ b/cache.h @@ -575,7 +575,22 @@ extern int verify_path(const char *path); extern int

[PATCH 3/4] document add_[file_]to_index

Signed-off-by: Stefan Beller --- cache.h | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/cache.h b/cache.h index 26632065a5..acc639d6e0 100644 --- a/cache.h +++ b/cache.h @@ -605,13 +605,20 @@ extern int remove_index_entry_at(struct

[PATCH 2/4] remove_index_entry_at: move documentation to cache.h

Signed-off-by: Stefan Beller --- cache.h | 3 +++ read-cache.c | 1 - 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index 270a0d0ea7..26632065a5 100644 --- a/cache.h +++ b/cache.h @@ -599,7 +599,10 @@ extern int index_name_pos(const

Re: [PATCH 5/5] describe: teach describe negative pattern matches

On Fri, Jan 13, 2017 at 1:31 PM, Johannes Sixt wrote: > Am 13.01.2017 um 07:57 schrieb Jacob Keller: >> >> On Thu, Jan 12, 2017 at 10:43 PM, Johannes Sixt wrote: >>> >>> When you write >>> >>> git log --branches --exclude=origin/* --remotes >>> >>>

Re: [RFH - Tcl/Tk] use of procedure before declaration?

From: "Johannes Schindelin" Hi Philip, On Mon, 16 Jan 2017, Philip Oakley wrote: In https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242 the procedure `_unset_recentrepo` is called, however the procedure isn't declared until line 248. My

Re: [RFC] Add support for downloading blobs on demand

On Tue, Jan 17, 2017 at 2:05 PM, Martin Fick wrote: > On Tuesday, January 17, 2017 04:50:13 PM Ben Peart wrote: >> While large files can be a real problem, our biggest issue >> today is having a lot (millions!) of source files when >> any individual developer only needs a

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

Jeff King writes: >> Let's fix this by telling Git that a remote is not configured unless any >> fetch/push URL or refspec is configured explicitly. > > I notice here that setting a refspec _does_ define a remote. Is there a > reason you drew the line there, and not at, say,

Re: [RFC] Add support for downloading blobs on demand

On Tuesday, January 17, 2017 04:50:13 PM Ben Peart wrote: > While large files can be a real problem, our biggest issue > today is having a lot (millions!) of source files when > any individual developer only needs a small percentage of > them. Git with 3+ million local files just doesn't >

RE: [RFC] Add support for downloading blobs on demand

Thanks for the encouragement, support, and good ideas to look into. Ben > -Original Message- > From: Shawn Pearce [mailto:spea...@spearce.org] > Sent: Friday, January 13, 2017 4:07 PM > To: Ben Peart > Cc: git ; benpe...@microsoft.com > Subject:

RE: [RFC] Add support for downloading blobs on demand

Thanks for the thoughtful response. No need to appologize for the length, it's a tough problem to solve so I don't expect it to be handled with a single, short email. :) > -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Tuesday, January 17, 2017 1:43 PM > To: Ben

Re: [PATCH] document index_name_pos

On Tue, Jan 17, 2017 at 1:43 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Signed-off-by: Stefan Beller >> --- >> >>> These placeholders are meant to encourage those people who dove into >>> the code to update it, so from that

Re: [PATCH v5 3/3] Retire the scripted difftool

Johannes Schindelin writes: > It served its purpose, but now we have a builtin difftool. Time for the > Perl script to enjoy Florida. > > Signed-off-by: Johannes Schindelin > --- The endgame makes a lot of sense. Both in the cover letter

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

On Tue, Jan 17, 2017 at 10:19:24PM +0100, Johannes Schindelin wrote: > One of the really nice features of the ~/.gitconfig file is that users > can override defaults by their own preferred settings for all of their > repositories. > > One such default that some users like to override is whether

Re: [PATCH 0/2] Fix remote_is_configured()

On Tue, Jan 17, 2017 at 10:18:58PM +0100, Johannes Schindelin wrote: > A surprising behavior triggered the bug report in > https://github.com/git-for-windows/git/issues/888: the mere existence of > the config setting "remote.origin.prune" (in this instance, configured > via ~/.gitconfig so that

Re: [PATCH] document index_name_pos

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > >> These placeholders are meant to encourage those people who dove into >> the code to update it, so from that point of view, I think removing >> it is backwards. > > Yes, I am currently

Re: [PATCH] CodingGuidelines: clarify multi-line brace style

Jeff King writes: > Yeah. I obviously was adapting the original text, and I think I left too > much of the wishy-washy-ness in. As the point of the patch is to avoid > that, let's take your suggestion. A re-rolled patch is below. > > Now the patch is at least self-consistent. The

Re: [PATCH v5 0/3] Turn the difftool into a builtin

Johannes Schindelin writes: > - replaced the cross-validation with the Perl script by a patch that > retires the Perl script instead. Yup. That makes things a lot simpler. While we try to be careful during major rewrite, we usually do not go extra careful to

Re: [PATCH 3/6] fsck: prepare dummy objects for --connectivity-check

On Tue, Jan 17, 2017 at 01:15:57PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > +static void mark_object_for_connectivity(const unsigned char *sha1) > > +{ > > + struct object *obj = lookup_object(sha1); > > + > > + /* > > +* Setting the object type here isn't

Re: [PATCH 3/6] fsck: prepare dummy objects for --connectivity-check

Jeff King writes: > +static void mark_object_for_connectivity(const unsigned char *sha1) > +{ > + struct object *obj = lookup_object(sha1); > + > + /* > + * Setting the object type here isn't strictly necessary here for a > + * connectivity check. Drop one of

[PATCH 0/2] Fix remote_is_configured()

A surprising behavior triggered the bug report in https://github.com/git-for-windows/git/issues/888: the mere existence of the config setting "remote.origin.prune" (in this instance, configured via ~/.gitconfig so that it applies to all repositories) fooled `git remote rename ` into believing

[PATCH 2/2] Be more careful when determining whether a remote was configured

One of the really nice features of the ~/.gitconfig file is that users can override defaults by their own preferred settings for all of their repositories. One such default that some users like to override is whether the "origin" remote gets auto-pruned or not. The user would simply call

[PATCH 1/2] remote rename: demonstrate a bogus "remote exists" bug

Some users like to set `remote.origin.prune = true` in their ~/.gitconfig so that all of their repositories use that default. However, our code is ill-prepared for this, mistaking that single entry to mean that there is already a remote of the name "origin", even if there is not. This patch adds

Re: [PATCH 4/6] fsck: tighten error-checks of "git fsck "

Jeff King writes: > Instead of checking reachability from the refs, you can ask > fsck to check from a particular set of heads. However, the > error checking here is quite lax. In particular: > > 1. It claims lookup_object() will report an error, which > is not true. It

Re: [PATCH 3/6] fsck: prepare dummy objects for --connectivity-check

Jeff King writes: > + # Drop the index now; we want to be sure that we > + # recursively notice that we notice the broken objects > + # because they are reachable from refs, not because > + # they are in the index. Rephrase to

Re: [PATCH 1/6] t1450: clean up sub-objects in duplicate-entry test

On Tue, Jan 17, 2017 at 12:52:43PM -0800, Junio C Hamano wrote: > > Since the setup code happens inside a subshell, we can't > > just set a variable for each object. However, we can stuff > > all of the sha1s into the $T output variable, which is not > > used for anything except cleanup. > > > >

Re: [PATCH 2/6] fsck: report trees as dangling

Jeff King writes: > After checking connectivity, fsck looks through the list of > any objects we've seen mentioned, and reports unreachable > and un-"used" ones as dangling. However, it skips any object > which is not marked as "parsed", as that is an object that > we _don't_ have

Re: [PATCH 1/6] t1450: clean up sub-objects in duplicate-entry test

Jeff King writes: > This test creates a multi-level set of trees, but its > cleanup routine only removes the top-level tree. After the > test finishes, the inner tree and the blob it points to > remain, making the inner tree dangling. > > A later test ("cleaned up") verifies that

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

On Tue, Jan 17, 2017 at 12:32:26PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > That was my general impression, too. But I seem to recall it was you in > > a nearby thread saying that: > > > > if (foo) > > bar(); > > else { > > one(); > > two(); > >

[PATCH] document index_name_pos

Signed-off-by: Stefan Beller --- > These placeholders are meant to encourage those people who dove into > the code to update it, so from that point of view, I think removing > it is backwards. Yes, I am currently understanding and writing up documentation for index_name_pos.

Re: [PATCH] documentation: remove unfinished documentation

Stefan Beller writes: > When looking for documentation for a specific function, you may be tempted > to run > > git -C Documentation grep index_name_pos > > only to find the file technical/api-in-core-index.txt, which doesn't > help for understanding the given function. It

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Jeff King writes: > That was my general impression, too. But I seem to recall it was you in > a nearby thread saying that: > > if (foo) > bar(); > else { > one(); > two(); > } > > was wrong. Maybe I misunderstood. If it were a new code written like the

Re: [RFC] stash --continue

Stephan Beyer writes: > This led to the idea to have something like "git stash --continue"[1] > that would expect the user to "git add" the resolved files (as "git > status" suggests) but then leads to the expected result, i.e. the index > being the same as before the conflict,

Re: [PATCH] CodingGuidelines: clarify multi-line brace style

On Tue, Jan 17, 2017 at 11:39:31AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> I think this is pretty clearly the "gray area" mentioned there. Which > >> yes, does not say "definitely do it this way", but I hope makes it clear > >> that you're supposed to use

[PATCH] documentation: remove unfinished documentation

When looking for documentation for a specific function, you may be tempted to run git -C Documentation grep index_name_pos only to find the file technical/api-in-core-index.txt, which doesn't help for understanding the given function. It would be better to not find these functions in the

Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

Matthieu Moy writes: >> But what if bad-A and bad-B have more than one merge bases? We >> won't know which side the badness came from. >> >> o---o---o---bad-A >> / \ / >> -Good---o---o---o / >>

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Johannes Schindelin writes: > Hi Junio, > > On Sun, 15 Jan 2017, Junio C Hamano wrote: > >> * js/prepare-sequencer-more (2017-01-09) 38 commits > > I think that it adds confusion rather than value to specifically use a > different branch name than I indicated in my

Re: [PATCH v3 00/38] Teach the sequencer to act as rebase -i's backend

Johannes Schindelin writes: >> > The original code is: >> > >> >. "$author_script" >> >> [...] >> >> If the code in the sequencer.c reads things other than the three >> variables we ourselves set, and make them into environment variables >> and propagate to

Re: [PATCH] CodingGuidelines: clarify multi-line brace style

Jeff King writes: >> I think this is pretty clearly the "gray area" mentioned there. Which >> yes, does not say "definitely do it this way", but I hope makes it clear >> that you're supposed to use judgement about readability. > > So here's a patch. > > I know we've usually tried

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

On Tue, Jan 17, 2017 at 11:20:58AM -0800, Junio C Hamano wrote: > > Documentation/CodingGuidelines says: > > > > - We avoid using braces unnecessarily. I.e. > > > > if (bla) { > > x = 1; > > } > > > >is frowned upon. A gray area is when the statement extends

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Jeff King writes: > Documentation/CodingGuidelines says: > > - We avoid using braces unnecessarily. I.e. > > if (bla) { > x = 1; > } > >is frowned upon. A gray area is when the statement extends >over a few lines, and/or you have a

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Jeff King writes: > On Mon, Jan 16, 2017 at 09:33:07PM +0100, Johannes Sixt wrote: > >> However, Jeff's patch is intended to catch exactly these cases (not for the >> cases where this happens accidentally, but when they happen with malicious >> intent). >> >> We are talking about

Re: [BUG/RFC] Git Gui: GIT_DIR leaks to spawned Git Bash

On Tue, Jan 17, 2017 at 11:52:29AM +0100, Johannes Schindelin wrote: > Hi Max, > > On Tue, 17 Jan 2017, Max Kirillov wrote: > >> Apparently various GIT_* environment variables (most >> interesting is GIT_DIR but AFAIR there were more) leak to >> shell session launched from Git Gui's "Git Bash"

Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis wrote: >> >> Technically it is submodule..url instead of >> submodule..url. The name is usually the path initially, and once >> you move the submodule, only the path changes, the name is supposed to >> be constant and stay the

Re: [RFC] Add support for downloading blobs on demand

This is an issue I've thought a lot about. So apologies in advance that this response turned out a bit long. :) On Fri, Jan 13, 2017 at 10:52:53AM -0500, Ben Peart wrote: > Design > ~~ > > Clone and fetch will pass a �--lazy-clone� flag (open to a better name > here) similar to �--depth�

Re: gitk pull request // was: Re: gitk: "lime" color incompatible with older Tk versions

Junio C Hamano writes: > Paul Mackerras writes: > >>> Paul, is it a good time to pull, or do you still have something not >>> published yet that should go together with what you have already >>> queued? >> >> I recently pushed out one more commit to update

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

> VERBOSE|QUIET _does_ have a meaning, which is "show the payload, but do > not print the signature buffer". Perhaps just renaming QUIET to > OMIT_STATUS or something would make it more clear. > Let me give this a go too. OMIT_STATUS does sound less confusing. Thanks, -Santiago. > -Peff

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

Yeah, this actually looks more cleaner. Let me give it a go. Thanks! -Santiago. On Tue, Jan 17, 2017 at 12:30:04PM -0500, Jeff King wrote: > On Tue, Jan 17, 2017 at 12:25:31PM -0500, Jeff King wrote: > > > Actually, looking at the callsites, I think they are fine to just call > >

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

On Tue, Jan 17, 2017 at 12:33:46PM -0500, Santiago Torres wrote: > Yeah, this actually looks more cleaner. > > Let me give it a go. Neat. Note there's a bug: > > diff --git a/builtin/tag.c b/builtin/tag.c > > index 9da11e0c2..068f392b6 100644 > > --- a/builtin/tag.c > > +++ b/builtin/tag.c > >

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

On Tue, Jan 17, 2017 at 12:00:19PM -0500, Santiago Torres wrote: > > > { > > > - return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE); > > > + int flags; > > > + char *fmt_pretty = cb_data; > > > + flags = GPG_VERIFY_VERBOSE; > > > + > > > + if (fmt_pretty) > > > + flags =

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

On Tue, Jan 17, 2017 at 12:25:31PM -0500, Jeff King wrote: > Actually, looking at the callsites, I think they are fine to just call > pretty_print_ref() themselves, and I don't think it actually matters if > it happens before or after the verification. Oh, sorry, I misread it. We do indeed

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

On Tue, Jan 17, 2017 at 11:57:25AM -0500, Santiago Torres wrote: > > Having read through the rest of the series, it looks like you'd > > sometimes have to do: > > IIRC, we did this to make the diff "simpler". It also feeds odd that the > call chain is the following: > >

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

> > { > > - return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE); > > + int flags; > > + char *fmt_pretty = cb_data; > > + flags = GPG_VERIFY_VERBOSE; > > + > > + if (fmt_pretty) > > + flags = GPG_VERIFY_QUIET; > > + > > + return verify_and_format_tag(sha1,

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

> > Hrm. Maybe I am missing something, but what does: > > > > verify_and_format_tag(sha1, name, fmt, flags); > > > > get you over: > > > > gpg_verify_tag(sha1, name, flags); > > pretty_print_ref(name, sha1, fmt); > > > > ? The latter seems much more flexible, and I do not see how the > >

[PATCH v5 1/3] difftool: add a skeleton for the upcoming builtin

This adds a builtin difftool that still falls back to the legacy Perl version, which has been renamed to `legacy-difftool`. The idea is that the new, experimental, builtin difftool immediately hands off to the legacy difftool for now, unless the config variable difftool.useBuiltin is set to true.

[PATCH v5 0/3] Turn the difftool into a builtin

This patch series converts the difftool from a Perl script into a builtin, for three reasons: 1. Perl is really not native on Windows. Not only is there a performance penalty to be paid just for running Perl scripts, we also have to deal with the fact that users may have different Perl

[PATCH v5 2/3] difftool: implement the functionality in the builtin

This patch gives life to the skeleton added in the previous patch. The motivation for converting the difftool is that Perl scripts are not at all native on Windows, and that `git difftool` therefore is pretty slow on that platform, when there is no good reason for it to be slow. In addition,

[PATCH v5 3/3] Retire the scripted difftool

It served its purpose, but now we have a builtin difftool. Time for the Perl script to enjoy Florida. Signed-off-by: Johannes Schindelin --- .gitignore | 1 - Makefile | 1 -

Re: fatal: bad revision 'git rm -r --ignore-unmatch -- folder'

On Tue, Jan 17, 2017 at 04:30:48PM +0100, jean-christophe manciot wrote: > I'm trying to purge a complete folder and its files from the > repository history with: > > git-Games# git filter-branch 'git rm -r --ignore-unmatch -- > Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD > fatal: bad

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

On Tue, Jan 17, 2017 at 10:24:55AM -0500, Jeff King wrote: > On Sun, Jan 15, 2017 at 01:47:01PM -0500, santi...@nyu.edu wrote: > > > From: Lukas Puehringer > > > > Calling functions for gpg_verify_tag() may desire to print relevant > > information about the header for

Re: [PATCH v5 0/7] Add --format to tag verification

On Sun, Jan 15, 2017 at 01:46:58PM -0500, santi...@nyu.edu wrote: > From: Santiago Torres > > This is the fifth iteration of [1][2][3][4], and as a result of the > discussion in [5]. The main goal of this patch series is to bring > --format to git tag verification so that

Re: [PATCH v5 7/7] t/t7004-tag: Add --format specifier tests

On Sun, Jan 15, 2017 at 01:47:05PM -0500, santi...@nyu.edu wrote: > From: Santiago Torres > > tag -v now supports --format specifiers to inspect the contents of a tag > upon verification. Add two tests to ensure this behavior is respected in > future changes. > >

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

On Sun, Jan 15, 2017 at 01:47:03PM -0500, santi...@nyu.edu wrote: > -static int for_each_tag_name(const char **argv, each_tag_name_fn fn) > +static int for_each_tag_name(const char **argv, each_tag_name_fn fn, > + void *cb_data) > { > const char **p; > char ref[PATH_MAX];

fatal: bad revision 'git rm -r --ignore-unmatch -- folder'

Hi there, I'm trying to purge a complete folder and its files from the repository history with: git-Games# git filter-branch 'git rm -r --ignore-unmatch -- Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD fatal: bad revision 'git rm -r --ignore-unmatch -- Ubuntu/16.04/' git does not find the

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

On Sun, Jan 15, 2017 at 01:47:01PM -0500, santi...@nyu.edu wrote: > From: Lukas Puehringer > > Calling functions for gpg_verify_tag() may desire to print relevant > information about the header for further verification. Add an optional > format argument to print any

Re: [RFH - Tcl/Tk] use of procedure before declaration?

Hi Philip, On Mon, 16 Jan 2017, Philip Oakley wrote: > In > https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242 > the procedure `_unset_recentrepo` is called, however the procedure isn't > declared until line 248. My reading of the various Tcl tutorials suggest > (but

  1   2   >