Re: email as a bona fide git transport

On Fri, Oct 18, 2019 at 12:03:43PM -0400, Konstantin Ryabitsev wrote: > On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote: > > > Seeing how large this signature is, I have to admit that I am partial to > > > Konstantin's suggestion of using minisign.

Re: email as a bona fide git transport

> Seeing how large this signature is, I have to admit that I am partial to > Konstantin's suggestion of using minisign. This seems like something > that could be added to git as an alternative to gpg without too much > trouble, I think. > > I wonder how big the pgp payload would be with ed25519

Re: email as a bona fide git transport

cover the new content > and to have a > way to verify every step. > Moreover you won't be able to reparent the commit as a maintainer (wich > I think is > also a deal-breaker) For reference, we did something similar here[1]. I'll acknowledge it's somewhat of a niche us

Re: email as a bona fide git transport

ly that you have a stable way to refer to > > a patch or commit (despite it appearing on a mailing list), and there > > is no need for "changeset IDs" or whatever, since you can just use the > > git SHA1 which is unique, unambiguous, and stable. I wonder if it'd be also possible to then embed gpg signatures over send-mail payloads so as they can be transparently transferred to the commit. -Santiago signature.asc Description: PGP signature

Re: git diff autocomplete

compare revisions *and* paths. I see that if I do git diff -- [TAB] I get all the paths as an autocomplete option, which I think is desired behavior. Thanks, -Santiago. signature.asc Description: PGP signature

Re: [git for translators] How to always generate conflicts for merges?

Hi, I'm not completely sure if this is the best way to achieve this, but I you could instruct a merge driver to mark all new files as unset. Cheers! -Santiago. On Thu, Jul 25, 2019 at 04:42:48PM +0300, Ilya Kantor wrote: > Hi, > > We're using Git to manage translations of

Re: [PATCH 2/2] builtin/verify-tag: do not omit gpg on --format

verify_tag_options); > > - } > > This leaves us with a weird doubled conditional (with no braces > either!). Maybe: > > if (format.format && verify_ref_format(&format)) > usage_with_options(...); > > ? Yes, I think chaining this if here is cleaner/less error prone. > > Other than that, the patch looks good. I think it could use a test in > t7030, though. Let me make a re-roll with these changes included and a test suite for both t7030 or t7004. Thanks! -Santiago. signature.asc Description: PGP signature

Re: [PATCH 1/2] builtin/tag: do not omit -v gpg out for --format

I'll add a patch to the series with a test for this. Thanks for the review! -Santiago. signature.asc Description: PGP signature

[PATCH 2/2] builtin/verify-tag: do not omit gpg on --format

From: Santiago Torres The current implementation of git-verify-tag omits the gpg output when the --format flag is passed. This may not be useful to users that want to see the gpg output *and* --format the output of git verify-tag. Instead, respect the --raw flag or the default gpg output

[PATCH 1/2] builtin/tag: do not omit -v gpg out for --format

From: Santiago Torres The current implementation of git tag -v omits the gpg output when the --format flag is passed. This may not be useful to users that want to see the gpg output *and* --format the output of the git tag -v. Instead, pass the default gpg interface output if --format is

[PATCH 0/2] tag verification: do not mute gpg output

From: Santiago Torres The default behavior of the tag verification functions used to quiet down the gpg output if --format was passed. The rationale for this was to avoid --format to be litterred by the gpg output. However, this may be unnecessary because the gpg output is already streamed to

Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty

On Mon, Apr 22, 2019 at 11:07:01PM +, brian m. carlson wrote: > On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote: > > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote: > > > > > I think that would be great, as we could make it simpler for

Re: What's cooking in git.git (Apr 2019, #04; Mon, 22)

On Mon, Apr 22, 2019 at 11:28:42AM -0400, Jeff King wrote: > On Mon, Apr 22, 2019 at 10:52:38AM -0400, Santiago Torres Arias wrote: > > Hi, > > > > This is the second what's cooking that's gone by without mention of the > > RFC patch regarding verify_tag[1].

Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty

t specifier, similar to the way "log > --format=%G?" works. I think that would be great, as we could make it simpler for verifiers to parse gpg output. > So I think ultimately that's the direction we want to go, but I think > in the meantime restoring the gpg output to stderr especially for the > porcelain "git tag -v" makes sense for human eyes. Great! let me re-roll and make a more formal take on this. Thanks! -Santiago signature.asc Description: PGP signature

Re: What's cooking in git.git (Apr 2019, #04; Mon, 22)

the RFC patch regarding verify_tag[1]. Is this due to lack of interest or is this an error on my side (f.e., did I forget to send something?). Thanks! -Santiago [1] https://public-inbox.org/git/20190412201609.hivppg2l37b6pzze@LykOS.localdomain/ signature.asc Description: PGP signature

Re: [RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty

On Fri, Apr 12, 2019 at 04:14:32PM -0400, santi...@nyu.edu wrote: > From: Santiago Torres > > On the git tag -v code, there is a guard to suppress gpg output if a > pretty format is provided. The rationale for this is that the gpg output > *and* the pretty formats together may con

[RFC PATCH] builtin:tag:verify_tag: allow gpg output + pretty

From: Santiago Torres On the git tag -v code, there is a guard to suppress gpg output if a pretty format is provided. The rationale for this is that the gpg output *and* the pretty formats together may conflict with each other. However, both outputs are directed to different output streams and

Re: git tag -v should verify that the tag signer intended the same tag name as the user is verifying

], and there's some stalled work into implementing this using push certificates... Thanks, -Santiago. [1] https://public-inbox.org/git/xmqqk2hzldx8@gitster.mtv.corp.google.com/ [2] https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html [3] https://www.usenix.org/confe

Re: Can't build first git commit

s about it somewhere? :)) Cheers! -Santiago. On Wed, Mar 06, 2019 at 09:19:58PM +0100, Fabio Aiuto wrote: > Yes that's great. > Why somebody told me about a outdate toolchain when I started this > little thread about first git compiling? Sorry for my stupid question > but the you j

Re: Can't build first git commit

is sometimes distracting. Good luck! -Santiago. On Mon, Mar 04, 2019 at 09:19:52PM +0100, Fabio Aiuto wrote: > What a pity, It would have been very useful for me, to debug around > that simple version, to understand how everithing works. > Thank you Santiago. > Fabio. > Il giorno

Re: Can't build first git commit

e openssl 1.0.0 series anymore. Thanks, -Santiago. On Mon, Mar 04, 2019 at 08:58:37PM +0100, Fabio Aiuto wrote: > Hi to all, > > I'm trying to build first commit of git made by Linus. I mean the one > named e83c5163316f89bfbde7d9ab23... (I think this is enough). > But at buildi

Re: Am a newby and I cannot compile git

Awesome, Do consider reading the files under Documentation (as other people suggested) to make it easier to contribute. There's CodingGuidelines and SubmittingPatches that are super useful :) Good luck! -Santiago. On Tue, Feb 12, 2019 at 10:43:13PM +0100, Fabio Aiuto wrote: > Ok I ty

Re: Am a newby and I cannot compile git

It'd be difficult to debug without more context: Do you mind sharing your build log and more informationa about your setup? (e.g., what OS are you running, what packages are installed, how did you get the git sources, etc.) Thanks, -Santiago. On Sun, Feb 10, 2019 at 10:56:54PM +0100,

Re: Improved Error Message

Hi, Ralph. This feels like an issue of how homebrew relays information rather than with git: santiago at ~ ✔ git clone nonexistent fatal: repository 'nonexistent' does not exist santiago at ~ ✗ git clone https://nonexistent.git Cloning into 'nonexistent'...

Re: [PATCH 1/1] verify-tag/verify-commit should exit unsuccessfully when signature is not trusted

> > disable fetching keys from hkp servers. This way signature verification > > should fail. > > > > Thanks, > > -Santiago. > > This is not a deviation. GPG correctly recognizes difference between trusted, > untrusted and unknown levels. git on the other ha

Re: [PATCH 1/1] verify-tag/verify-commit should exit unsuccessfully when signature is not trusted

Tooling around gpg is generally difficult for this reason, but using the raw output should be enough to discard signatures with untrusted keys. Another alternative is to use a keyring with trusted keys *only* and disable fetching keys from hkp servers. This way signature verification should fail.

Re: does a new repo actually *need* default template content?

part of every repository (e.g., hold them under /usr/share/git/samples/hooks/ or something along those lines). > I also wish hooks were just shell snippets in the config files that > could follow the usual config-precedence rules. I like this idea, but I'd probably keep the snippets in a separate file to keep things clean. Thanks, -Santiago. signature.asc Description: PGP signature

Re: GIT 2.3.1 - Code Execution Vulnerability

or your solaris version are the ones (possibly) packaging 2.3.1. I'd email or open a ticket with Oracle after making sure they 1) haven't backported patches to fix these, or 2) don't have a newer version in their repositories. Cheers! -Santiago. [1] https://security.archlinux.

Re: upstreaming https://github.com/cgwalters/git-evtag ?

o be very very > welcome. I agree. I personally think that at least the sample hook work on here would be a good candidate for this[1], although I don't know what's the status of it. The way they are right now, they should at least warn when push certificates are not enabled on the se

Re: upstreaming https://github.com/cgwalters/git-evtag ?

my very opinionated take on it. Full disclosure, I published a "competing" solution a couple of years ago[1] but, in my personal opinion, I think push certificates can achieve the same security guarantees as my system with very little changes. Cheers! -Santiago. [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias signature.asc Description: PGP signature

Re: upstreaming https://github.com/cgwalters/git-evtag ?

it evtags already. Thanks, -Santiago. signature.asc Description: PGP signature

Re: upstreaming https://github.com/cgwalters/git-evtag ?

h a signed data structure with relevant git reference information as a git object to avoid a server/mitm from moving references around. Cheers! -Santiago. [1] https://public-inbox.org/git/1408485987-3590-1-git-send-email-gits...@pobox.com/ [2] https://public-inbox.org/git/20171202091248.6037-1-r...@shikhe

Re: upstreaming https://github.com/cgwalters/git-evtag ?

embedded in it. I wonder if, with the current tooling in git, this could be done as a custom command... Cheers! -Santiago. On Mon, Jan 08, 2018 at 03:12:00PM -0500, Colin Walters wrote: > Hi, so quite a while ago I wrote this: > https://github.com/cgwalters/git-evtag > > Since I last poste

Re: git status always modifies index?

Ah, my bad. I missed this patch... Good luck! -Santiago. signature.asc Description: PGP signature

Re: git status always modifies index?

eem like status should be one of those > cases. I think it's because of the reasons above. That being said, I don't know what the rest of the community would think of something akin to a --no-update-index type flag. Cheers! -Santiago. signature.asc Description: PGP signature

Re: git status always modifies index?

hanks, -Santiago signature.asc Description: PGP signature

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

d definitely not litter the stdout with ENOENT-like error messages though... Thanks again for catching this! -Santiago. signature.asc Description: PGP signature

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Quick followup. The version that triggers this is at least 2.1.21[1]. I recall there was some wiggle room on minor versions before it. Thanks! -Santiago. [1] https://dev.gnupg.org/T3218 On Mon, Nov 13, 2017 at 06:02:02PM -0500, Santiago Torres wrote: > > > Were the ENOENT e

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

l to gpgconf. If that worked > across the various gnupg 2.x releases, it would be a simple enough change to > make as a follow-up. Let me dig up the exact versions. IIRC it was somewhere between 2.1.0 and 2.2.x or so. I think somewhere within the patch re-rolls I had the exact versions.

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

for scdaemon only). Thanks again! -Santiago. signature.asc Description: PGP signature

Re: Unable to use --patch with git add

It'd be helpful to know: - What did you do? - What did you expect to happen? - What happened instead? I suspect you are using --patch with a new file, so you probably need to first add it with -N or so. This is just a shot in the dark though... Thanks, -Santiago. On Wed, Oct 11, 2017 at

Re: git ls-tree -d doesn't work if the specified path is the repository root?

e these four behaviors: [santiago@LykOS bg_daemon]$ git ls-tree -d HEAD -- src 04 tree 238a62ca62527423fd3190d00917ddfef0d254a3src [santiago@LykOS bg_daemon]$ git ls-tree -d HEAD -- src/ 04 tree 767beaaf0927f89e630c52830b6fbac138ec039asrc/bg_daemon [santiago@LykOS bg_daemon]$

Re: [RFC PATCH 0/2] Add named reference to latest push cert

to the latest push certificate would make it easier to handle/tool/sync around the push certificate solution? Thanks, -Santiago. [1] https://public-inbox.org/git/CAJo=hJvWbjEM9E5AjPHgmQ=eY8xf=Q=xtukeu2ur7auuqea...@mail.gmail.com/ signature.asc Description: PGP signature

Re: signing commits using gpg2

ed: secret key not available This feels like an issue with the interface to the key itself. Can you start a non-detached agent with --verbose to see exactly where it blows up? We probably want to continue this offlist as this seems more of a gpg issue rather than git. We can always come back if we figure out this is something git related :) Cheers! -Santiago. signature.asc Description: PGP signature

Re: t5551 hangs ?

ps or things I can do are welcome. > t5551 seems to be flaky - from time to time. > It seems that I have it reproducable unstable, so if someone has more > ideas, please. I'm still unable to reproduce. Do you think you can enable GIT_TRACE, GIT_TRACE_PACK and GIT_TRACE_CURL and pastebin/paste what you see? Cheers! -Santiago. signature.asc Description: PGP signature

Re: t5551 hangs ?

ens if you kill the apache processes? I can't reproduce on my side, but let me see if I can dig a little into it. Cheers! -Santiago. signature.asc Description: PGP signature

[PATCH v2] t: lib-gpg: flush gpg agent on startup

From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when attempting to

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

> With that "run it but ignore the outcome even if we failed to.", we > do not have to worry about any of that ;-) Oh right! thanks for the suggestion! Let me re-roll... Thanks, -Santiago. signature.asc Description: PGP signature

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

opefully gpgconf goes nowhere by then). I was able to test this on debian oldstable/stable and arch. Cheers! -Santiago. [1] https://public-inbox.org/git/xmqqvampmnmv@gitster.mtv.corp.google.com/ On Thu, Jul 20, 2017 at 12:58:14PM -0400, santi...@nyu.edu wrote: > From: Santiago Torres

[PATCH] t: lib-gpg: flush gpg agent on startup

From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when attempting to

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

tch/Arch, who do ship gpg2 with gpgconf. It seems Debian oldstable and other variants still ship gpg1, which doesn't have it. Would it make sense to have a fallthrough branch on the switch statement for gpg2.1 instead? something like the attached patch. Thanks, -Santiago. From 07ab87c1ddb3119

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

is clearly understood and > documented. I double checked the patch/solutions/causes just to be sure I'm not doing anything crazy. Here's a v2 of the patch that kills the agent upon cleanup rather than startup. Thanks! -Santiago. From 20491890b804d13f9edb0205c1cc21d080beffe2 Mon Sep

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

and would leave an agent instance per test running, possibly forever. E.g., make test would result in the following: santiago at ~ ✔ pgrep -a gpg-agent 632 gpg-agent --homedir /git/t/trash directory.t6050-replace/gpghome --use-standard-socket --daemon 1192 /usr/bin/gpg-agent --supe

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

GPG_AGENT_INFO SSH_AUTH_SOCK etc. into the list of > envirionment variables to nuke there? > > Combined with the unknown-ness of the root cause of the issue, I can > only say that the patch may be raising an issue worth addressing, > but it is too sketchy to tell if it is a right solution or what the > exact problem being solved is. I'll dig into this. This sounds a way more reasonable approach. Thanks for the feedback! -Santiago. signature.asc Description: PGP signature

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

elopment lately. I checked the latest iterations of "what's cooking" to see if it was going to be discarded or so, but I see no mention of it. Thanks! -Santiago [1] https://public-inbox.org/git/20170707220729.a3xrsju3rf4guyzs@LykOS.localdomain/T/#t signature.asc Description: PGP signature

Re: [RFC PATCH] t: lib-gpg: flush agent sockets on startup

Hello all, I don't know if this is a desired feature, but I noticed that, one some versions of gpg, gpg tests are skipped when I run a test suite multiple times. Cheers! -Santiago. On Fri, Jul 07, 2017 at 06:01:59PM -0400, santi...@nyu.edu wrote: > From: Santiago Torres > > Wh

[RFC PATCH] t: lib-gpg: flush agent sockets on startup

From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is ran for a trash_directory-specific GNUPGHOME. This daemon creates a unix socket on the target host, and it will be used on subsequent runs of the same test script. Add a call to kill the agent and flush the sockets of the

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote: > Santiago Torres writes: > OK, so has everybody agreed what the next step would be? I believe it is, although I imagine getting a confirmation from Peff would be adequate. > Is the patch below a good first step (I stil

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

uot;ignored unless %(gpg) formatters > are used". Which would be backwards-compatible and safe for old formats, > and work correctly for new ones. This sounds like a helpful addition to implement. We could update/add tests for compliance on this once the feature is addded and fix the ambiguo

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

e current > behavior, the bogus ones are quietly omitted. Which can also be > confusing, but I'd think would generally err on the side of caution. In that case, something like this would be closer to the desired behavior? I'm also unsure on what would be the right thing to put on the co

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

gt;> t/t7004-tag.sh| 8 > >> t/t7030-verify-tag.sh | 8 > >> 2 files changed, 8 insertions(+), 8 deletions(-) > > > > Like 2/3, this one also produces test failures for me. It looks like > > "verify-tag" does not show a tag

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

ilures for me. It looks like > "verify-tag" does not show a tag which has been forged. I'm not sure if > that's intentional (and the test is wrong) or a bug. I see that offending code would be [1]. Changing this behavior should be trivial (dropping the continue), although I

Re: SHA1 collisions found

together. I think Arstechnica may be a little bit sensationalistic here. Cheers! -Santiago. [1] https://bugs.webkit.org/show_bug.cgi?id=168774#c27 signature.asc Description: PGP signature

SHAttered (the first practical SHA1 attack)

Hello all, I ran into this website presenting the "first practical attack on sha1"[1]. I don't recall seeing this on the ML, so I'm sharing this just in case. I know there are proposals to move out of sha1 already. I wonder if this affects the timeline for their adoption? Th

Re: idea: light-weight pull requests

could be implemented by tools like this rather easily (e.g., using symlinks + inotify or something less hacky). I'm wondering if standardizing this would be more interesting to those communities? I would like to see what becomes of this. Cheers! -Santiago. On Tue, Feb 07, 2017 at 08:32

Re: git clone problem

git clone --recursive https://github.com/... $ ls Thanks, -Santiago On Wed, Jan 25, 2017 at 05:58:58PM +0100, Jordi Durban wrote: > Hi all! Not sure if that will reach the goal, but let's it a try. > > I have a problem with the git clone command: when I try to clone a remote >

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

On Wed, Jan 18, 2017 at 10:44:03AM -0800, Junio C Hamano wrote: > Santiago Torres writes: > Was: Thanks! Would you want me to re-roll really quick? or would you rather apply this on your side? Thanks, -Santiago. > > Eric, I've noticed that this message > > > h

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

e updated. > > Squashing the following into this commit solves this issue with the > former approach. The lines it touches are all from 4/6 and I view > all of it as general improvement, including type correctness and > code formatting. Thanks! Should I re-roll this really quick? Or would you rather apply this on your tree directly? -Santiago. signature.asc Description: PGP signature

[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 create, pretty print and free

[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 1 file changed, 16 insertions

[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 be respected

[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 verification. The callback functio

[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 the formatted tag

[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 --- gpg-interface.h | 5 +++-- tag.c

[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 it. In this re

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. Thank

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

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

(GPG_VERIFY_VERBOSE will be unset when GPG_VERIFY_QUIET). I would have to re-read the patch to make sure this is the case then. GPG_VERIFY_QUIET was added to suppress any VERBOSE|RAW flags, we could defeault to QUIET if flags are not set. What do you think? Thanks! -Santiago signature.asc Description: PGP signature

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

) run_gpg_verification() I'm afraid that adding yet another wrapper would further convolute the call chain. If you think this is not an issue, I could easily do it. Do you have any suggested name for the wrapper? Thanks! -Santiago signature.asc Description: PGP signature

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

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 desired information after GPG verification. Signed-off-by: Lukas Puehringer --- builtin/tag.c|

[PATCH v5 4/7] 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 the formatted tag

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

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 upper-layer tools can inspect the content of a tag and make decisions based on it. In this re-woll

[PATCH v5 1/7] gpg-interface, tag: add GPG_VERIFY_QUIET flag

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

[PATCH v5 6/7] 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 be respected

[PATCH v5 7/7] 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 1 file changed, 16 insertions

[PATCH v5 2/7] 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 create, pretty print and free

[PATCH v5 5/7] 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 verification. The callback functio

Re: [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format

On Wed, Oct 19, 2016 at 04:39:44PM -0400, Jeff King wrote: > The ref-filter code generally expects to see fully qualified > refs, so that things like "%(refname)" and "%(refname:short)" > work as expected. We can do so easily from git-tag, which > always works with refnames in the refs/tags namespa

Re: [PATCH v4 2/7] ref-filter: add function to print single ref_array_item

and you can use > "%(refname:short)" if you want the shorter part). Hmm, I hadn't actually noticed that. Do you have any suggestions in how to address this? In general this feels like a consequence of disambiguating .git/tags/* within builtin/tag.c rather than letting ref-filter figure it out. Thanks, -Santiago. signature.asc Description: PGP signature

Re: What's cooking in git.git (Oct 2016, #03; Tue, 11)

t; Is this ready for 'next'? Hi, I saw this on the previous "what's cooking." Is there anything I need to do on my side to make sure this is ready for next? Thanks! -Santiago. signature.asc Description: PGP signature

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

Hi, I noticed there were no replies for this thread. I was curious if it got buried because I sent it on the Friday evening before a long weekend. I don't mean to pressure or anything. Thanks! -Santiago. On Fri, Oct 07, 2016 at 05:07:14PM -0400, santi...@nyu.edu wrote: > From: Santiag

[PATCH v4 6/7] 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 be respected

[PATCH v4 5/7] 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 verification. The callback functio

[PATCH v4 7/7] 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 1 file changed, 16 insertions

[PATCH v4 0/7] Add --format to tag verification

From: Santiago Torres This is the fourth iteration of the series in [1][2][3], which comes as a result of the discussion in [4]. 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 v4 1/7] gpg-interface, tag: add GPG_VERIFY_QUIET flag

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

[PATCH v4 2/7] 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 create, pretty print and free

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

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 desired information after GPG verification. Signed-off-by: Lukas Puehringer --- builtin/tag.c|

[PATCH v4 4/7] 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 the formatted tag

Re: [PATCH v3 0/5] Add --format to tag verification

cial attention to? (I'm looking at t7004 mostly right now). Thanks! -Santiago. signature.asc Description: PGP signature

  1   2   3   >