* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 10:49 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <002e01cdb29a$893593f0$9ba0bbd0$@schmitz-digital.de>
On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
> > > + # for 'make test'
> > > + # some test don't work with /bin/diff, some fail with /bin/tar
> > > + # some need bash, and some need ${prefix}/bin in PATH first
> > > + SHELL_PATH=${prefix}/bin/bash
> > > + SANE_TOOL_PATH=${prefix}/bin
> >
> > This feels a little too specific to go in our Makefile. Do we have any
> > reason to think that where you are installing git is going to be the
> > same place you have bash and other sane tools? Wouldn't this mean that
> > things work when you run "make" but mysteriously break when you run
> > "make prefix=/my/local/install/of/git"?
>
> Well, "make" won't break (I think), but "make test" very well might.
Sure.
> Well, so far all OpenSource packages ported to HP NonStop (at least
> the ones on ituglib.connect-community.org) use prefix=/usr/local and
> there is no intention to change that.
But then I would think using /usr/local would be the sane thing to put
there, if that is the closest to "standard" for your platform.
If there is not a standard, then I think we are better off leaving it
blank and letting people do the right thing for their system (including
packagers who are building for other people).
-Peff
^ permalink raw reply
* Re: [PATCH] Doc repository-layout: Show refs/replace
From: Jeff King @ 2012-10-25 10:34 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1350852757-3924-1-git-send-email-philipoakley@iee.org>
On Sun, Oct 21, 2012 at 09:52:37PM +0100, Philip Oakley wrote:
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
Thanks, this makes sense.
> +refs/replace/`<obj-sha1>`::
> + records the SHA1 of the object that replaces `<obj-sha1>`.
> + This is similar to info/grafts and is internally used and
> + maintained by `git replace`. Such refs can be exchanged between
> + repositories while grafts are not.
This should probably be an actual link to the git-replace manpage. I'll
convert it to a linkgit. No need to resend.
-Peff
^ permalink raw reply
* Re: [PATCH] Doc User-Manual: Patch cover letter, three dashes, and --notes
From: Jeff King @ 2012-10-25 10:26 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-2-git-send-email-philipoakley@iee.org>
On Sun, Oct 21, 2012 at 10:34:08PM +0100, Philip Oakley wrote:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 85651b5..d918c53 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1787,6 +1787,11 @@ $ git format-patch origin
> will produce a numbered series of files in the current directory, one
> for each patch in the current branch but not in origin/HEAD.
>
> +`git format-patch` can include an initial "cover letter". You can insert
> +a commentary on individual patches using a three dash line after the
> +commit message, and before the patch itself. `git format-patch --notes`
> +(v1.8.1) will include the commit's notes in the similar manner.
I'd rather not mention a version number here, as we do not yet know
which version (if any) will contain the feature. Besides, we write our
documentation to match the current version, so as long as this is queued
on top of the new code, I do not see any reason to mention a version at
all.
I'll tweak it while queueing.
-Peff
^ permalink raw reply
* Re: [PATCH] Doc format-patch: clarify --notes use case
From: Jeff King @ 2012-10-25 10:25 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-4-git-send-email-philipoakley@iee.org>
On Sun, Oct 21, 2012 at 10:34:10PM +0100, Philip Oakley wrote:
> The expected use case of this is to write supporting explanation for
> -the commit that does not belong to the commit log message proper
> -when (or after) you create the commit, and include it in your patch
> -submission. But if you can plan ahead and write it down, there may
> -not be a good reason not to write it in your commit message, and if
> -you can't, you can always edit the output of format-patch before
> -sending it out, so the practical value of this option is somewhat
> -dubious, unless your workflow is broken.
> +the commit, that does not belong to the commit log message proper,
> +and include it with the patch submission. The notes can be maintained
> +between versions of the patch series. You can also edit the output of
> +format-patch before sending.
I found the "you can also" slightly awkward here, as it was not clear
why it was mentioned. I think the intent is "this is an alternative that
does not involve the notes workflow", but it is not clear from the text
why you would prefer the notes workflow. Here is what I queued instead,
which tires to clarify that, and also mentions that this workflow needs
additional setup to track rewritten commits:
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 066dc8b..750b3fa 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -196,13 +196,12 @@ The expected use case of this is to write supporting explanation for
after the three-dash line.
+
The expected use case of this is to write supporting explanation for
-the commit that does not belong to the commit log message proper
-when (or after) you create the commit, and include it in your patch
-submission. But if you can plan ahead and write it down, there may
-not be a good reason not to write it in your commit message, and if
-you can't, you can always edit the output of format-patch before
-sending it out, so the practical value of this option is somewhat
-dubious, unless your workflow is broken.
+the commit that does not belong to the commit log message proper,
+and include it with the patch submission. While one can simply write
+these explanations after `format-patch` has run but before sending,
+keeping them as git notes allows them to be maintained between versions
+of the patch series (but see the discussion of the `notes.rewrite.*`
+configuration in linkgit:git-notes[1] to use this workflow).
--[no]-signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
I've queued that and your other patches on top of jc/prettier-pretty-note.
-Peff
^ permalink raw reply related
* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:21 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025095826.GM8390@sigill.intra.peff.net>
> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 11:58 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
>
> On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
>
> > + # for 'make test'
> > + # some test don't work with /bin/diff, some fail with /bin/tar
> > + # some need bash, and some need ${prefix}/bin in PATH first
> > + SHELL_PATH=${prefix}/bin/bash
> > + SANE_TOOL_PATH=${prefix}/bin
>
> This feels a little too specific to go in our Makefile. Do we have any
> reason to think that where you are installing git is going to be the
> same place you have bash and other sane tools? Wouldn't this mean that
> things work when you run "make" but mysteriously break when you run
> "make prefix=/my/local/install/of/git"?
Well, "make" won't break (I think), but "make test" very well might.
Well, so far all OpenSource packages ported to HP NonStop (at least the ones on ituglib.connect-community.org) use prefix=/usr/local and there is no intention to change that.
A few (bash, vim, coreutils, tar, gzip, bzip2) get delivered with the system meanwhile (rather than having to be downloaded and installed by the customer) and live in /usr/corutiles. Still more are needed (e.g. diff , make).
The next lines in my patch cater for that, it is missing though an automatic switch.
Such a switch would be possible, using 'uname -r' and 'uname -v', but pretty convoluted
Pseudo code:
If (`uname -r` = J06 && `uname -v` >= 14) || (`uname -r`= H06 && `uname -v` >= 25)
SHELL_PATH=/usr/coreutils/bin/bash
SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
else
SHELL_PATH=${prefix}/bin/bash
SANE_TOOL_PATH=${prefix}/bin
endif
I didn't deem it worth the effort. As mentioned it'd most likely still need stuff from /usr/local/bin
And someone wanting prefix somewhere else could still do
PATH=/usr/local/bin:$PATH make prefix=/my/local/install/of/git
And so find what's need in either the 1st or 2nd path of PATH
Bye, Jojo
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 10:08 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121025090149.GC8390@sigill.intra.peff.net>
On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:
> > - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > - ($subject =~ /[^[:ascii:]]/)) {
> > - $subject = quote_rfc2047($subject, $auto_8bit_encoding);
> > + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > + $subject = quote_subject($subject, $auto_8bit_encoding);
> > }
>
> Hmm. What is this patch on top of? It looks like it is on top of your
> original patch, but when I tried it on top of that, it does not apply
> either, and the index lines in the patch do not mention a sha1 that I do
> not have.
>
> Do you mind re-rolling a final 2-patch series with:
Ah, never mind. I missed your earlier "use compose-encoding for
Subject". I've queued it and all of the follow-ons onto the
km/send-email-compose-encoding topic.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 9:58 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <001e01cdb061$c25f6380$471e2a80$@schmitz-digital.de>
On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
> + # for 'make test'
> + # some test don't work with /bin/diff, some fail with /bin/tar
> + # some need bash, and some need ${prefix}/bin in PATH first
> + SHELL_PATH=${prefix}/bin/bash
> + SANE_TOOL_PATH=${prefix}/bin
This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run "make" but mysteriously break when you run
"make prefix=/my/local/install/of/git"?
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: remote tracking branch -> remote-tracking branch
From: Jeff King @ 2012-10-25 9:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, angelo.borsotti
In-Reply-To: <1350992045-11141-1-git-send-email-Matthieu.Moy@imag.fr>
On Tue, Oct 23, 2012 at 01:34:05PM +0200, Matthieu Moy wrote:
> This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2
> 2010, Replace "remote tracking" with "remote-tracking"), but new
> instances of remote tracking (without dash) were introduced in the
> meantime.
Thanks. It seems like an obvious step forward.
> I'm not opposed to dropping completely the remote-tracking part in the
> case of merge (i.e. "remote-tracking branches that the current branch
> is configured to use as its upstream" -> "upstream branch") on top of
> that, but if we do this, merge-config.txt should be updated too).
Yeah, I do not care too deeply, but I think it reads just fine without
mentioning remote-tracking at all.
-Peff
^ permalink raw reply
* Re: [PATCH] Document git-svn fetch --log-window-size parameter
From: Jeff King @ 2012-10-25 9:52 UTC (permalink / raw)
To: Gunnlaugur Þór Briem; +Cc: Eric Wong, git
In-Reply-To: <1350988406-97624-1-git-send-email-gunnlaugur@gmail.com>
On Tue, Oct 23, 2012 at 10:33:26AM +0000, Gunnlaugur Þór Briem wrote:
> The --log-window-size parameter to git-svn fetch is undocumented.
>
> Minimally describe what it does and why the user might change it.
Thanks. Your description makes sense to me, but I do not have enough
git-svn knowledge to know if it covers all intended uses of the flag.
Eric?
> +--log-window-size=<n>;;
> + Fetch <n> log entries per request when scanning Subversion history.
> + The default is 100. For very large Subversion repositories, larger
> + values may be needed for 'clone'/'fetch' to complete in reasonable
> + time. But overly large values may lead to request timeouts.
-Peff
^ permalink raw reply
* Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Jeff King @ 2012-10-25 9:45 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1350959091-30030-1-git-send-email-pclouds@gmail.com>
On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:
> These functions are called in sequencer.c, which is part of
> libgit.a. This makes libgit.a potentially require builtin/merge.c for
> external git commands.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I made some unrelated changes in sequencer.c and this problem shown
> up. merge-recursive.c is probably not the best place for these
> functions. I just don't want to create merge.c for them.
I'm fine with this conceptually, but merge-recursive really is the wrong
place. I'd much rather see a new merge.c to collect merge-related helper
functions that are not strategy-specific.
-Peff
^ permalink raw reply
* Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Jeff King @ 2012-10-25 9:42 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, gitster
In-Reply-To: <1531209463.296427.1351015084181.JavaMail.ngmail@webmail16.arcor-online.net>
On Tue, Oct 23, 2012 at 07:58:04PM +0200, Thomas Ackermann wrote:
> - target "html" creates html for all files in Documentation/howto and
> Documentation/technical
Thanks.
> +TECH_DOCS = technical/index-format
> +TECH_DOCS += technical/pack-format
> +TECH_DOCS += technical/pack-heuristics
> +TECH_DOCS += technical/pack-protocol
> +TECH_DOCS += technical/protocol-capabilities
> +TECH_DOCS += technical/protocol-common
> +TECH_DOCS += technical/racy-git
> +TECH_DOCS += technical/send-pack-pipeline
> +TECH_DOCS += technical/shallow
> +TECH_DOCS += technical/trivial-merge
> +SP_ARTICLES += $(TECH_DOCS)
I wonder if these could even be part of the generated api-index.html
(that is, if somebody is reading about the API, they just as well may
want to see these format documents). But I do not overly care much, as I
(and I suspect most other developers) just read the technical
documentation in its original txt format.
If somebody cares, we can easily build it on top.
-Peff
^ permalink raw reply
* Re: [PATCHv2] git-pull: Avoid merge-base on detached head
From: Jeff King @ 2012-10-25 9:34 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Junio C Hamano
In-Reply-To: <1351024796-28174-2-git-send-email-hordp@cisco.com>
On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote:
> git pull --rebase does some clever tricks to find the base
> for $upstream , but it forgets that we may not have any
> branch at all. When this happens, git merge-base reports its
> "usage" help in the middle of an otherwise successful
> rebase operation, because git-merge is called with one too
> few parameters.
>
> Since we do not need the merge-base trick in the case of a
> detached HEAD, detect this condition and bypass the clever
> trick and the usage noise.
Makes sense. I notice there is no test with your patch. It sounds from
the description like the operation still may succeed, but we just get
cruft on stderr?
-Peff
^ permalink raw reply
* Re: [PATCHv2] git-status: show short sequencer state
From: Jeff King @ 2012-10-25 9:29 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <1351022574-27869-2-git-send-email-hordp@cisco.com>
On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:
> Teach git-status to report the sequencer state in short form
> using a new --sequencer (-S) switch. Output zero or more
> simple state token strings indicating the deduced state of the
> git sequencer.
>
> Introduce a common function to determine the current sequencer
> state so the regular status function and this short version can
> share common code.
>
> Add a substate to wt_status_state to track more detailed
> information about a state, such as "conflicted" or "resolved".
> Move the am_empty_patch flage out of wt_status_state and into
This patch ended up quite long. It might be a little easier to review
if it were broken into refactoring steps (I have not looked at it too
closely yet, but it seems like the three paragraphs above could each be
their own commit).
> State token strings which may be emitted and their meanings:
> merge a git-merge is in progress
> am a git-am is in progress
> rebase a git-rebase is in progress
> rebase-interactive a git-rebase--interactive is in progress
A minor nit, but you might want to update this list from the one in the
documentation.
> diff --git a/builtin/commit.c b/builtin/commit.c
> index a17a5df..9706ed9 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
> static enum {
> STATUS_FORMAT_LONG,
> STATUS_FORMAT_SHORT,
> - STATUS_FORMAT_PORCELAIN
> + STATUS_FORMAT_PORCELAIN,
> + STATUS_FORMAT_SEQUENCER
> } status_format = STATUS_FORMAT_LONG;
Hmm. So the new format is its own distinct output format. I could not
say "I would like to see short status, and by the way, show me the
sequencer state", as you can with "-b". Is it possible to do this (or
even desirable; getting the sequencer state should be way cheaper, so
conflating the two may not be what some callers want).
Not complaining, just wondering about the intended use cases.
Also, does there need to be a --porcelain version of this output? It
seems like we can have multiple words (e.g., in a merge, with conflicted
entries). If there is no arbitrary data, we do not have to worry about
delimiters and quoting. But I wonder if we would ever want to expand
the information to include arbitrary strings, at which point we would
want NUL delimiters; should we start with that now?
> + // Determine main sequencer activity
Please avoid C99 comments (there are others in the patch, too).
> +void wt_sequencer_print(struct wt_status *s)
> +{
> + struct wt_status_state state;
> +
> + wt_status_get_state(s, &state);
> +
> + if (state.merge_in_progress)
> + wt_print_token(s, "merge");
> + if (state.am_in_progress)
> + wt_print_token(s, "am");
> + if (state.rebase_in_progress)
> + wt_print_token(s, "rebase");
> + if (state.rebase_interactive_in_progress)
> + wt_print_token(s, "rebase-interactive");
> + if (state.cherry_pick_in_progress)
> + wt_print_token(s, "cherry-pick");
> + if (state.bisect_in_progress)
> + wt_print_token(s, "bisect");
> +
> + switch (state.substate) {
> + case WT_SUBSTATE_NOMINAL:
> + break;
> + case WT_SUBSTATE_CONFLICTED:
> + wt_print_token(s, "conflicted");
> + break;
> + case WT_SUBSTATE_RESOLVED:
> + wt_print_token(s, "resolved");
> + break;
> + case WT_SUBSTATE_EDITED:
> + wt_print_token(s, "edited");
> + break;
> + case WT_SUBSTATE_EDITING:
> + wt_print_token(s, "editing");
> + break;
> + case WT_SUBSTATE_SPLITTING:
> + wt_print_token(s, "splitting");
> + break;
> + case WT_SUBSTATE_AM_EMPTY:
> + wt_print_token(s, "am-empty");
> + break;
> + }
> +}
It is clear from this code that some tokens can happen together, and
some are mutually exclusive. Should the documentation talk about that,
or do we want to literally keep it as a list of tags?
-Peff
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Mat Arge @ 2012-10-25 9:15 UTC (permalink / raw)
To: git
In-Reply-To: <CA+sFfMdSc30xmzFrqbPFYigLkW9v_YSrnTBtumhZiU5TKiBxqQ@mail.gmail.com>
On Thursday 25. October 2012 01:02:33 Brandon Casey wrote:
> On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge <argemat1010@gmail.com> wrote:
> > Hy!
> >
> > I would like to sign each commit with a X.509 certificate and a private
> > key
> > stored on a PKCS#11 token. I assume that that should be possible somehow
> > using a hook which calls openssl. Does somebody know a working
> > implementation of this?
>
> Creating signatures from an rsa key on a pkcs11 token should be
> possible, but gnupg doesn't support pkcs11 for philosophical reasons.
> You need to use gnupg-pkcs11 which is maintained outside of the gnupg
> tree.
>
> Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg
> to sign tags as usual.
>
> I configured this a while back for use with CAC cards using the
> following resources:
>
> http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead)
> http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement
> for above?)
> http://gnupg-pkcs11.sourceforge.net/man.html
>
> Try those docs. If you have questions, I'll try to find my notes.
>
> -Brandon
Thanks for the tip, I will try them (though the appear to be very outdated).
Do you know, if gnupg-pkcs11-scd is able to cooperate with the standard pcscd
from pcsc-lite, or is a one-or-the-other situation?
cheers
Mat
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Mat Arge @ 2012-10-25 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <5087B8E7.8010306@drmicha.warpmail.net>
On Wednesday 24. October 2012 11:46:15 Michael J Gruber wrote:
> Mat Arge venit, vidit, dixit 22.10.2012 15:38:
> > Hy!
> >
> > I would like to sign each commit with a X.509 certificate and a private
> > key
> > stored on a PKCS#11 token. I assume that that should be possible somehow
> > using a hook which calls openssl. Does somebody know a working
> > implementation of this?
> >
> > cheers
> > Mat
>
> In principle, we have an almost pluggable architecture. See for example
> the latter part of the 2nd post in
>
> http://article.gmane.org/gmane.comp.version-control.git/175127
>
> Unless you want to change git itself, you're probably better off storing
> your non-gpg signatures in a note (or a self-created signed tag).
So, there is no possibility to modify the commit itself via a hook, and add a,
say, "opensslsig" instead of a gpgsig tag?
> To
> sign the commit rev, you could sign the output of "git cat-file commit
> rev" (or of "git rev-parse rev") and store that signature in a note that
> commit. To verify, you verify the note against the commit.
>
> Michael
But if I crete/modify a signature file while commiting, that file wouldn't be
commited itself, so the signatur-file would always be one commit behind. Or am
I missing something? I'm quite new to git (or DVCSs in general), so sorry if
this is a dumb question.
cheers
Mat
^ permalink raw reply
* Re: [PATCH] configure: fix some output message
From: Jeff King @ 2012-10-25 9:11 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <b67d9e47dc92c2c316495ac4bd8e7ba93d339781.1351091006.git.stefano.lattarini@gmail.com>
On Wed, Oct 24, 2012 at 05:34:27PM +0200, Stefano Lattarini wrote:
> Before this change, output from ./configure could contain
> botched wording like this:
>
> checking Checking for POSIX Threads with '-pthread'... yes
>
> instead of the intended:
>
> checking for POSIX Threads with '-pthread'... yes
>
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Thanks, looks obviously correct.
-Peff
^ permalink raw reply
* Re: Who is the 'git' vendor?
From: Jeff King @ 2012-10-25 9:10 UTC (permalink / raw)
To: PROHASKA, Thor
Cc: Andreas Ericsson, 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <5088FDDC.20404@op5.se>
On Thu, Oct 25, 2012 at 10:52:44AM +0200, Andreas Ericsson wrote:
> On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> > Hi,
> >
> > The organisation I am currently working for uses 'git'.
> >
> > In order to manage all the software used in the organisation we have
> > been compiling a list of software that includes the software Vendor's
> > name.
> >
> > My colleague has listed the vendor of git as being the 'Software
> > Freedom Conservancy'. Can you please advise me if this is correct? If
> > not, who should the vendor be identified as?
> >
>
> Most likely, you'll want to put "git@vger.kernel.org" as vendor for git,
> as the whole vendor concept doesn't really fly with FOSS. There's noone
> to go to if it breaks your systems, and unless you purchase a support
> contract from somewhere there's noone to turn to except the (excellent)
> git community in case you have issues with it.
Yeah. Depending on the purpose of the list, I would probably _not_ put
the SFC. They help manage the legal and financial aspects of the git
project, but they have nothing at all to do with the code itself. I
would hate for them to get a phone call about support. :)
Probably "The Git Community" or "git@vger.kernel.org" is the best thing
to fill in if you need to write something in a form. If there ends up
being some specific reason for a vendor to be contacted, folks on the
list will be able to point an inquiry in the right direction (which
might even end up being the SFC).
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: add rfc2047 quoting for "=?"
From: Jeff King @ 2012-10-25 9:05 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <1351114109-16310-1-git-send-email-krzysiek@podlesie.net>
On Wed, Oct 24, 2012 at 11:28:29PM +0200, Krzysztof Mazur wrote:
> For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
> but also for any possible rfc2047 in it.
> [...]
> - return ($s =~ /[^[:ascii:]]/);
> + return ($s =~ /[^[:ascii:]]/) || ($s =~ /=\?/);
Very nice and obvious bug-fix made easy by the previous refactoring. :)
> ---
> Oops, this ugly Subject was generated by git format-patch (both 1.8.0
> and km/send-email-compose-encoding).
Yeah, format-patch has the same behavior (to encode when we see "=?").
So we know it is working. It is perhaps overkill in this case, since
there is not technically a valid encoded-word, and a smart parser would
be able to see that it should leave it alone. But it is probably better
to be slightly conservative in what we generate (and the "=?" token is
unlikely to come up in day-to-day usage).
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 9:01 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121024210826.GA23562@shrek.podlesie.net>
On Wed, Oct 24, 2012 at 11:08:26PM +0200, Krzysztof Mazur wrote:
> ok, I'm sending a version that just adds quote_subject() without
> changing any logic, so now we still have in first case:
>
> /[^[:ascii:]]/
>
> and in the latter case:
>
> !is_rfc2047_quoted($subject) && /^[:ascii:]]/
>
>
> In the next patch I will just add matching for "=?" in
> subject_needs_rfc2047_quoting() and we will have:
>
> /=?/ || /[^[:ascii:]]/
>
> and in the latter case:
>
> !is_rfc2047_quoted($subject) && (/=\?/ || /^[:ascii:]]/)
>
> This will also add quoting for any rfc2047 quoted subject or any
> other rfc2047-like subject, as you suggested.
Thanks, the two-patch series you outline makes a lot of sense to me.
> Krzysiek
> --
> From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
> From: Krzysztof Mazur <krzysiek@podlesie.net>
> Date: Wed, 24 Oct 2012 22:46:00 +0200
> Subject: [PATCH] git-send-email: introduce quote_subject()
When sending a patch following some cover letter material, please cut
out any non-essential headers and use the scissors symbol, like this:
-- >8 --
Subject: [PATCH] this subject overrides the whole email's subject
the regular body and diff go here...
That format is understood by "git am" and means I do not have to
manually munge it, which saves a little work.
> +sub quote_subject {
> + local $subject = shift;
> + my $encoding = shift || 'UTF-8';
> +
> + if (subject_needs_rfc2047_quoting($subject)) {
> + return quote_rfc2047($subject, $encoding);
> + }
> + return $subject;
> +}
There is some funny whitespace here (space followed by tab).
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> - ($subject =~ /[^[:ascii:]]/)) {
> - $subject = quote_rfc2047($subject, $auto_8bit_encoding);
> + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> + $subject = quote_subject($subject, $auto_8bit_encoding);
> }
Hmm. What is this patch on top of? It looks like it is on top of your
original patch, but when I tried it on top of that, it does not apply
either, and the index lines in the patch do not mention a sha1 that I do
not have.
Do you mind re-rolling a final 2-patch series with:
1. Your original patch and this one squashed together, with an
appropriate commit message.
2. The second "quote when we see '=?'" patch.
Thanks.
-Peff
^ permalink raw reply
* Re: Who is the 'git' vendor?
From: Andreas Ericsson @ 2012-10-25 8:52 UTC (permalink / raw)
To: PROHASKA, Thor
Cc: 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <8F7A9DADB4F4064EB938B0D3EBB63FDC208A5A34@PBNEMBMSX4120.int.Corp.sun>
On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> Hi,
>
> The organisation I am currently working for uses 'git'.
>
> In order to manage all the software used in the organisation we have
> been compiling a list of software that includes the software Vendor's
> name.
>
> My colleague has listed the vendor of git as being the 'Software
> Freedom Conservancy'. Can you please advise me if this is correct? If
> not, who should the vendor be identified as?
>
Most likely, you'll want to put "git@vger.kernel.org" as vendor for git,
as the whole vendor concept doesn't really fly with FOSS. There's noone
to go to if it breaks your systems, and unless you purchase a support
contract from somewhere there's noone to turn to except the (excellent)
git community in case you have issues with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Jeff King @ 2012-10-25 8:41 UTC (permalink / raw)
To: Geert Bosch; +Cc: Brian Gernhardt, Git List
In-Reply-To: <F721B376-F4E6-4274-9A6E-BD1CFCBDA39F@adacore.com>
On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote:
> On Oct 24, 2012, at 23:54, Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
>
> > It works if I change \s to [[:space:]], but I don't know how portable that is.
>
> As \s is shorthand for the POSIX character class [:space:], I'd say the latter
> should be more portable: anything accepting the shorthand should also accept
> the full character class. If not, you probably only care about horizontal tab
> and space, for which you could just use a simple regular expression. Just a
> literal space and tab character between square brackets is probably going to be
> most portable, though not most readable.
I agree that the POSIX character class would be more portable than "\s",
but we do not have any existing uses of them, and I would worry a little
about older systems like Solaris. If we can simply use a literal space
and tab, that seems like the safest.
Brian, can you work up a patch?
-Peff
^ permalink raw reply
* Re: [PATCH] Fixes handling of --reference argument.
From: Jeff King @ 2012-10-25 8:36 UTC (permalink / raw)
To: szager; +Cc: git
In-Reply-To: <5088c5a4.L25tOcUVCSwBRpYF%szager@google.com>
On Wed, Oct 24, 2012 at 09:52:52PM -0700, szager@google.com wrote:
> Signed-off-by: Stefan Zager <szager@google.com>
> ---
> git-submodule.sh | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..dcceb43 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -270,7 +270,6 @@ cmd_add()
> ;;
> --reference=*)
> reference="$1"
> - shift
> ;;
Is that right? We'll unconditionally do a "shift" at the end of the
loop. If it were a two-part argument like "--reference foo", the extra
shift would make sense, but for "--reference=*", no extra shift should
be neccessary. Am I missing something?
-Peff
^ permalink raw reply
* Re: Is git mktag supposed to accept git cat-file input?
From: Michael J Gruber @ 2012-10-25 8:34 UTC (permalink / raw)
To: Anand Kumria; +Cc: Brandon Casey, git
In-Reply-To: <CAM1C4Gn6tr_bxG1De+kZecpJ7kLg7_hOO7q-aa7HwFkr9od6_Q@mail.gmail.com>
Anand Kumria venit, vidit, dixit 25.10.2012 02:58:
> Ahh, unix time. Of course.
That's the only difference *at the time being*, but this is not
guaranteed. Really, as Brandon says: "cat-file -p" is pretty printing
for human readability (which could be improved), and "cat-file <type>"
is the raw format which is the content being hashed to the sha1.
>
> Thanks Brandon.
>
> On 25 October 2012 01:18, Brandon Casey <drafnel@gmail.com> wrote:
>> On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria <akumria@acm.org> wrote:
>>> Hi,
>>>
>>> I am doing some experimenting with git-mktag, and was looking into the
>>> format it expects on input.
>>>
>>> Should this sequence of commands work?
>>
>> Yes, with a slight tweak...
>>
>>> kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test
>>> kalki:[/tmp/gittest]% git cat-file -p e619
>>
>> '-p' means pretty-print, i.e. produce a human-readable format. mktag
>> supports the raw format. So you should invoke it like this:
>>
>> $ git cat-file tag e619
>>
>> which should produce something like:
>>
>> object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
>> type commit
>> tag tag-test
>> tagger Anand Kumria <akumria@acm.org> 1351121552 +0100
>>
>> tag-test
>>
>> and is the format expected by mktag.
>>
>> -Brandon
>>
>
>
>
^ permalink raw reply
* Re: Where should git-prompt.sh be installed?
From: Anders Kaseorg @ 2012-10-25 8:10 UTC (permalink / raw)
To: Danny Yates
Cc: Jonathan Nieder, git@vger.kernel.org, Felipe Contreras,
Ted Pavlic, SZEDER Gábor, Dan McGee
In-Reply-To: <3B606942-D194-4148-AF6E-1F3283C983ED@googlemail.com>
On 10/25/2012 02:02 AM, Danny Yates wrote:
> Would that not give the impression of "git sh-prompt" being a core
> command?
No more than git-sh-setup, which already works like that. Unless
perhaps by “core” you mean “not contrib”.
(Now that I think of it, I saw a request from an Ubuntu PPA user last
week to install git-subtree in a more accessible location, and there’s a
similar request about gitview at https://bugs.launchpad.net/bugs/152212
. These are less critical since the Debian package puts them in
/usr/share/doc/git/contrib. Is it a good idea to package those
somewhere like /usr/lib/git-core or /usr/bin, or is that a dangerous
slippery slope? I dunno.)
Anders
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Brandon Casey @ 2012-10-25 8:02 UTC (permalink / raw)
To: Mat Arge; +Cc: git
In-Reply-To: <1392235.RizYqAYdkC@off17>
On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge <argemat1010@gmail.com> wrote:
> Hy!
>
> I would like to sign each commit with a X.509 certificate and a private key
> stored on a PKCS#11 token. I assume that that should be possible somehow using
> a hook which calls openssl. Does somebody know a working implementation of
> this?
Creating signatures from an rsa key on a pkcs11 token should be
possible, but gnupg doesn't support pkcs11 for philosophical reasons.
You need to use gnupg-pkcs11 which is maintained outside of the gnupg
tree.
Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg
to sign tags as usual.
I configured this a while back for use with CAC cards using the
following resources:
http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead)
http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement
for above?)
http://gnupg-pkcs11.sourceforge.net/man.html
Try those docs. If you have questions, I'll try to find my notes.
-Brandon
^ 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