Re: [PATCH] git-quiltimport.sh: disallow fuzz
Junio C Hamano writes:
> Let's have it the other way around, keep the same behaviour for
> those who run the command without the new option, while allowing
> people who know better and are aligned with the spirit of git to
> pass the parameter, at least for now, with a note in the
> documentation to warn that the default may change in the future to
> allow no fuzz, or something.
Perhaps like this, with some documentation added (do we have/need
any test???).
-- >8 --
To: Jörn Engel
Date: Thu, 25 Sep 2014 18:08:31 -0400
Subject: [PATCH] git-quiltimport.sh: allow declining fuzz with --exact option
git-quiltimport unconditionally passes "-C1" to "git apply",
supposedly to roughly match the quilt default of --fuzz 2. Allow
users to pass --exact option to disable it, requiring the patch to
apply without any fuzz.
Also note that -C1 and fuzz=2 is not identical. Most patches have
three lines of context, so fuzz=2 leaves one relevant line of
context. But for any patches with more or less context this is not
true. git-apply has no option for fuzz, so any emulation will
always be best-effort.
Signed-off-by: Joern Engel
Signed-off-by: Junio C Hamano
---
Documentation/git-quiltimport.txt | 12
git-quiltimport.sh| 17 -
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-quiltimport.txt
b/Documentation/git-quiltimport.txt
index a356196..109918d 100644
--- a/Documentation/git-quiltimport.txt
+++ b/Documentation/git-quiltimport.txt
@@ -49,6 +49,18 @@ The default for the patch directory is patches
or the value of the $QUILT_PATCHES environment
variable.
+-C ::
+ Pass `-C` to underlying `git apply` when applying
+ the patch, to reduce number of context lines to be matched.
+ By default, `-C1` is passed to `git apply` to emulate the
+ `--fuzz=2` behaviour of quilt (assuming the standard 3
+ context lines).
+
+--exact::
+ Do not pass any `-C` option to `git apply` when
+ applying the patch, to require context lines to fully match.
+
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 167d79f..2d2c377 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -6,6 +6,8 @@ git quiltimport [options]
--
n,dry-run dry run
author= author name and email address for patches without any
+C=minimum context (see git apply)
+exact allow no-fuzz
patches= path to the quilt series and patches
"
SUBDIRECTORY_ON=Yes
@@ -13,6 +15,7 @@ SUBDIRECTORY_ON=Yes
dry_run=""
quilt_author=""
+cflag=-C1
while test $# != 0
do
case "$1" in
@@ -20,6 +23,18 @@ do
shift
quilt_author="$1"
;;
+ -C)
+ shift
+ # ensure numerical parameter
+ case "$1" in
+ ''|*[!0-9]*) usage;;
+ *) ;;
+ esac
+ cflag="-C$1"
+ ;;
+ --exact)
+ cflag=
+ ;;
-n|--dry-run)
dry_run=1
;;
@@ -130,7 +145,7 @@ do
fi
if [ -z "$dry_run" ] ; then
- git apply --index -C1 ${level:+"$level"} "$tmp_patch" &&
+ git apply --index $cflag ${level:+"$level"} "$tmp_patch" &&
tree=$(git write-tree) &&
commit=$( (echo "$SUBJECT"; echo; cat "$tmp_msg") | git
commit-tree $tree -p $commit) &&
git update-ref -m "quiltimport: $patch_name" HEAD $commit ||
exit 4
--
2.1.1-394-g5293c25
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-quiltimport.sh: disallow fuzz
Jörn Engel writes:
> When I am working on a problem I never think about beauty. I think
> only how to solve the problem. But when I have finished, if the
> solution is not beautiful, I know it is wrong.
> -- R. Buckminster Fuller
Nice quote, but does not belong to above --- lines, unless you have
a -- >8 -- line below or something.
Now is the patch beautiful? ;-)
> Subject: [PATCH] git-quiltimport.sh: disallow fuzz by default
>
> git-quiltimport passed "-C1" to git-apply, supposedly to roughly match
> the quilt default of --fuzz 2. This is against the spirit of git.
> Quoting Linus:
> Except unlike the standard "patch" program, "git apply" doesn't accept
> fuzz by default (which to me is a huge deal - I hate how "patch" tries
> to apply stuff that clearly isn't valid any more)
> Users that want to want to emulate quilt defaults can pass "-C 1" to
> git-quiltimport now.
Things might have been different if this were mid 2006 or early
2007, but I am afraid that "the spirit of git" with a quote from
Linus no longer carries much weight on this particular issue. A
backward incompatible change is backward incompatible change that
breaks existing users no matter how loudly you (and I) shout that it
is the right thing to do in the long run.
Let's have it the other way around, keep the same behaviour for
those who run the command without the new option, while allowing
people who know better and are aligned with the spirit of git to
pass the parameter, at least for now, with a note in the
documentation to warn that the default may change in the future to
allow no fuzz, or something.
> Also note that -C1 and fuzz=2 is not identical. Most patches have three
> lines of context, so fuzz=2 leaves one relevant line of context. But
> for any patches with more or less context this is not true. git-apply
> has no option for fuzz, so any emulation will always be best-effort.
>
> Signed-off-by: Joern Engel
> ---
> git-quiltimport.sh | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/git-quiltimport.sh b/git-quiltimport.sh
> index 167d79fea809..f45ee5ff6599 100755
> --- a/git-quiltimport.sh
> +++ b/git-quiltimport.sh
> @@ -4,8 +4,9 @@ OPTIONS_STUCKLONG=
> OPTIONS_SPEC="\
> git quiltimport [options]
> --
> -n,dry-run dry run
> author= author name and email address for patches without any
> +C=minimum context (see git apply)
> +n,dry-run dry run
> patches= path to the quilt series and patches
> "
> SUBDIRECTORY_ON=Yes
> @@ -13,6 +14,7 @@ SUBDIRECTORY_ON=Yes
>
> dry_run=""
> quilt_author=""
> +cflag=""
> while test $# != 0
> do
> case "$1" in
> @@ -20,6 +22,15 @@ do
> shift
> quilt_author="$1"
> ;;
> + -C)
> + shift
> + # ensure numerical parameter
> + case $1 in
> + ''|*[!0-9]*) usage;;
> + *) ;;
> + esac
> + cflag="-C$1"
> + ;;
> -n|--dry-run)
> dry_run=1
> ;;
> @@ -130,7 +141,7 @@ do
> fi
>
> if [ -z "$dry_run" ] ; then
> - git apply --index -C1 ${level:+"$level"} "$tmp_patch" &&
> + git apply --index $cflag ${level:+"$level"} "$tmp_patch" &&
> tree=$(git write-tree) &&
> commit=$( (echo "$SUBJECT"; echo; cat "$tmp_msg") | git
> commit-tree $tree -p $commit) &&
> git update-ref -m "quiltimport: $patch_name" HEAD $commit ||
> exit 4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-quiltimport.sh: disallow fuzz
On Wed, 24 September 2014 22:09:33 -0700, Junio C Hamano wrote:
>
> This is fine for those who use quilt with --fuzz=0, but how are you
> helping those who use quilt without --fuzz=0?
>
> I agree that unconditionally passing -C1 is a bad thing, but
> unconditionally passing -C2 is not that better. Shouldn't this be
> done by introducing a new --fuzz= option to quiltimport?
Maybe the patch below then? Defaulting to no fuzz is both me
enforcing my (and Linus') preference and that alternatives are hard
and messy. How would one specify fuzz=0? -C3 would work for standard
patches, but be wrong for patches with more context. -C0 would
arguably also be wrong. There really is no good choice. And I won't
add a fuzz parameter until git-apply has one, as it can only be
transformed to -C by either making assumptions about the context or
parsing the patches - ick!
Jörn
--
When I am working on a problem I never think about beauty. I think
only how to solve the problem. But when I have finished, if the
solution is not beautiful, I know it is wrong.
-- R. Buckminster Fuller
Subject: [PATCH] git-quiltimport.sh: disallow fuzz by default
git-quiltimport passed "-C1" to git-apply, supposedly to roughly match
the quilt default of --fuzz 2. This is against the spirit of git.
Quoting Linus:
Except unlike the standard "patch" program, "git apply" doesn't accept
fuzz by default (which to me is a huge deal - I hate how "patch" tries
to apply stuff that clearly isn't valid any more)
Users that want to want to emulate quilt defaults can pass "-C 1" to
git-quiltimport now.
Also note that -C1 and fuzz=2 is not identical. Most patches have three
lines of context, so fuzz=2 leaves one relevant line of context. But
for any patches with more or less context this is not true. git-apply
has no option for fuzz, so any emulation will always be best-effort.
Signed-off-by: Joern Engel
---
git-quiltimport.sh | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 167d79fea809..f45ee5ff6599 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -4,8 +4,9 @@ OPTIONS_STUCKLONG=
OPTIONS_SPEC="\
git quiltimport [options]
--
-n,dry-run dry run
author= author name and email address for patches without any
+C=minimum context (see git apply)
+n,dry-run dry run
patches= path to the quilt series and patches
"
SUBDIRECTORY_ON=Yes
@@ -13,6 +14,7 @@ SUBDIRECTORY_ON=Yes
dry_run=""
quilt_author=""
+cflag=""
while test $# != 0
do
case "$1" in
@@ -20,6 +22,15 @@ do
shift
quilt_author="$1"
;;
+ -C)
+ shift
+ # ensure numerical parameter
+ case $1 in
+ ''|*[!0-9]*) usage;;
+ *) ;;
+ esac
+ cflag="-C$1"
+ ;;
-n|--dry-run)
dry_run=1
;;
@@ -130,7 +141,7 @@ do
fi
if [ -z "$dry_run" ] ; then
- git apply --index -C1 ${level:+"$level"} "$tmp_patch" &&
+ git apply --index $cflag ${level:+"$level"} "$tmp_patch" &&
tree=$(git write-tree) &&
commit=$( (echo "$SUBJECT"; echo; cat "$tmp_msg") | git
commit-tree $tree -p $commit) &&
git update-ref -m "quiltimport: $patch_name" HEAD $commit ||
exit 4
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)
Jonathan Nieder writes: > The patch "fix handling of badly named refs"[1] is still undergoing > heavy churn. > > I think it's worth getting that one right. Oh, no question about it. I was only making sure that I didn't miss availability of updates for larger series we saw during this cycle. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)
Junio C Hamano wrote: > I know that a review-update cycle is still going in the dark at > > https://code-review.googlesource.com/#/q/topic:ref-transaction > > for this series. Eh, it's at least public and doesn't flood the list with rebased versions of the series. Would you prefer if there were some list archived on gmane with the automated mails from gerrit, to make it easier to look back at later? > Are we almost there for v22 which hopefully be the > final before we merge it to 'next' and go incremental? The patch "fix handling of badly named refs"[1] is still undergoing heavy churn. I think it's worth getting that one right. Thanks, Jonathan [1] https://code-review.googlesource.com/1070 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)
I know that a review-update cycle is still going in the dark at https://code-review.googlesource.com/#/q/topic:ref-transaction for this series. Are we almost there for v22 which hopefully be the final before we merge it to 'next' and go incremental? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/32] nd/multiple-work-trees
It has been a while since the last review exchanges were seen. Will it be time for v3 soon? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] de.po: Fixup one translation
Stefan Beller wrote: > English grammar with German words doesn't make it a German translation. ;) > > Signed-off-by: Stefan Beller > --- > Here we go again without sentence fragments. > > Thanks, > Stefan > > po/de.po | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/po/de.po b/po/de.po > index e5d2b25..bae3723 100644 > --- a/po/de.po > +++ b/po/de.po > @@ -3463,13 +3463,13 @@ msgid_plural "" > "\n" > "%s\n" > msgstr[0] "" > -"Warnung: Sie sind um %d Commit hinterher, nicht verbunden zu\n" > -"einem Ihrer Branches:\n" > +"Warnung: Sie sind um %d Commit hinterher, folgende Commits sind in\n" > +"keinem Ihrer Branches enthalten: \n" > "\n" > "%s\n" > msgstr[1] "" > -"Warnung: Sie sind um %d Commits hinterher, nicht verbunden zu\n" > -"einem Ihrer Branches:\n" > +"Warnung: Sie sind um %d Commits hinterher, folgende Commits sind in\n" > +"keinem Ihrer Branches enthalten: \n" > "\n" > "%s\n" > That are two sentences. I'll queue this: -- >8 -- From: Stefan Beller Date: Tue, 23 Sep 2014 14:54:46 +0200 Subject: [PATCH] de.po: Fixup one translation English grammar with German words doesn't make it a German translation. ;) Signed-off-by: Stefan Beller Signed-off-by: Ralf Thielow --- po/de.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/de.po b/po/de.po index e5d2b25..fe940d1 100644 --- a/po/de.po +++ b/po/de.po @@ -3463,13 +3463,13 @@ msgid_plural "" "\n" "%s\n" msgstr[0] "" -"Warnung: Sie sind um %d Commit hinterher, nicht verbunden zu\n" -"einem Ihrer Branches:\n" +"Warnung: Sie sind um %d Commit hinterher. Folgende Commits sind in\n" +"keinem Ihrer Branches enthalten:\n" "\n" "%s\n" msgstr[1] "" -"Warnung: Sie sind um %d Commits hinterher, nicht verbunden zu\n" -"einem Ihrer Branches:\n" +"Warnung: Sie sind um %d Commits hinterher. Folgende Commits sind in\n" +"keinem Ihrer Branches enthalten:\n" "\n" "%s\n" -- 2.1.1.446.g43bbf76 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] part3: l10n: de.po: use imperative form for command options
Hi, >You send a patch for the comma before "um" (thanks for that). I'll >rebase >these patches on top of that before applying, so the comma will be >added >then. > Okey, thanks. >> >> Maybe its better to use »Stream» instead of »Strom« in general? >> > >What about "Datenstrom"? Yeah, that would work. Phillip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: project wide: git config entry for [diff] renames=true
Junio C Hamano writes: > or even > > [config] > safe = !* > ... Gaah, I meant [include] in all places I spelled [config] in the previous message. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: project wide: git config entry for [diff] renames=true
Jeff King writes: > There is no such mechanism within git. We've resisted adding one because > of the danger of something like: > > [diff] > external = rm -rf / > > diff.renames is probably safe, but any config-sharing mechanism would > have to deal with either whitelisting, or providing some mechanism for > the puller to review changes before blindly following them. It might be useful to add a "safe include" feature, perhaps? We ship a small set of hardcoded default whitelist (diff.renames may be included in there), and allow the user who do not want to be affected to override it with [include] safe = !diff.renames or even [config] safe = !* at the same time allow them to add what we do not hardcode to it using the same mechanism, e.g. [config] safe = merge.* Then [include] safe path = ../project.gitconfig [include] path = $HOME/.gitconfig-variant1 would only allow the variables include.safe deems safe to affect us from the in-tree file, and use everything from my personal set in my home directory. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: project wide: git config entry for [diff] renames=true
Joe Perches writes: > On Thu, 2014-09-25 at 14:00 -0400, Jeff King wrote: > ... >> diff.renames is probably safe, but any config-sharing mechanism would >> have to deal with either whitelisting, or providing some mechanism for >> the puller to review changes before blindly following them. > > Another mechanism might be to add a repository > top level .gitconfig and add whatever to that. That could be smaller half of an implementation detail of one of the two possibilities Jeff mentioned i.e. "mechanism for the puller to review changes before blindly following". It gives the transfer part. You still need a new mechanism to make that file that is tracked in the repository to be used as part of your configuration variable set after letting the puller to review and approve. A puller who blindly trust the project could use the "include" mechanism from your .git/config to include a file with a well-known name that is tracked by the project _without_ review or approval. I doubt we would recommend that in an open source setting, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] log-tree: let format-patch not indent notes
Hello Junio, On Thu, Sep 25, 2014 at 10:24:53AM -0700, Junio C Hamano wrote: > Uwe Kleine-König writes: > > Commit logs as shown by git-log are usually indented by four spaces so > > here it makes sense to do the same for commit notes. > > > > However when using format-patch to create a patch for submission via > > e-mail the commit log isn't indented and also the "Notes:" header isn't > > really useful. So consequently don't indent and skip the header in this > > case. This also removes the empty line between the end-of-commit marker > > and the start of the notes. > > > > Signed-off-by: Uwe Kleine-König > > --- > > This commit changes the output of format-patch (applied on this commit) > > from: > > > > ... > > case. > > > > Signed-off-by: Uwe Kleine-König > > --- > > > > Notes: > > This commit changes the output of format-patch (applied on this > > commit) from: > > > > to > > > > ... > > case. > > > > Signed-off-by: Uwe Kleine-König > > --- > > This commit changes the output of format-patch (applied on this commit) > > from: > > > > which I consider to be more useful. > > I suspect that is fairly subjective, as the current one is in that > form because those who wrote this feature first, reviewed, applied > would have considered it more useful, isn't it? Well, I thought when the feature to dump the notes into a patch was created there was exactly one way these notes were written. This was was designed for git-log and so intended and with "Notes:". For git-format-patch it was good enough. > Because I never send out a format-patch output without looking it > over in an editor, I know I can easily remove it if I find the > "Notes:" out of place in the output, but if the "Notes:" thing > weren't there in the first place I may scratch my head trying to > figure out where to update it if the information there were stale, > so for that reason I'd find it more useful to have Notes: to remind > me where that information comes from. As you must explicitly request notes to be included in patches (--notes) I think it's unusual to not know where the info comes from, doesn't it? I don't know how many people use git-notes to track their comments, but the first thing I do when editing patches is to remove the Notes: header and s/^// on the remaining lines. And most of the time this is the only thing I do and I need to touch every patch only because of that. > But that is just my personal preference and I am willing to be > persuaded either way with a better argument than "to me it looks > nicer". > > As to indenting, because the material after three-dashes is meant to > be fed to "git apply" or "patch", I'd prefer to keep it to avoid > having to worry about a payload that may look like part of a patch. > This preference is a bit stronger than the presence/absence of > "Notes:". Ok, that's a valid concern. If we want to assert that this doesn't look like a patch we need to at least parse the notes and quote it somehow. Hmm. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: project wide: git config entry for [diff] renames=true
On Thu, 2014-09-25 at 14:00 -0400, Jeff King wrote: > On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: > > > On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: > > > > > In the future, please generate a git "move" diff, which makes it easier > > > to review, and prove that nothing really changed. It also helps if the > > > file is a bit different from what you diffed against, which in my case, > > > was true. > > > > Maybe it'd be possible to add > > > > [diff] > > renames = true > > > > to the .git/config file. > > > > but I don't find a mechanism to add anything to the > > .git/config and have it be pulled. > > There is no such mechanism within git. We've resisted adding one because > of the danger of something like: > > [diff] > external = rm -rf / > > diff.renames is probably safe, but any config-sharing mechanism would > have to deal with either whitelisting, or providing some mechanism for > the puller to review changes before blindly following them. Another mechanism might be to add a repository top level .gitconfig and add whatever to that. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] part3: l10n: de.po: use imperative form for command options
Hi, 2014-09-23 12:24 GMT+02:00 Phillip Sz : > Hi, > >> #: builtin/describe.c:395 >> msgid "find the tag that comes after the commit" >> -msgstr "findet das Tag, das nach Commit kommt" >> +msgstr "das Tag finden, das nach Commit kommt" >> > > "das Tag finden, das nach dem Commit kommt" > >> #: builtin/fast-export.c:718 >> msgid "Use the done feature to terminate the stream" >> -msgstr "Benutzt die \"done\"-Funktion um den Strom abzuschließen" >> +msgstr "die \"done\"-Funktion benutzen um den Strom abzuschließen" >> > > "die \"done\"-Funktion benutzen, um den Strom abzuschließen" You send a patch for the comma before "um" (thanks for that). I'll rebase these patches on top of that before applying, so the comma will be added then. > > Maybe its better to use »Stream» instead of »Strom« in general? > What about "Datenstrom"? > Phillip > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Receive-pack: include entire SHA1 in nonce
On Sep 25, 2014, at 1:54 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I am not happy with this version, either, though, because now we >> have an uninitialized piece of memory at the end of sha1[20] of the >> caller, which is given to sha1_to_hex() to produce garbage. It is >> discarded by %.*s format so there is no negative net effect, but I >> suspect that the compiler would not see that through. > > ... and if we want to fix that, we would end up with a set of > changes, somewhat ugly like this. > > Which might be an improvement, but let's start with your "sizeof(arg) > is the size of a pointer, even when the definition of arg[] is > spelled with bra-ket, a dummy maintainer!" fix. > > I'd like to have your sign-off. I'd also prefer to retitle it as > something like "hmac_sha1: copy the entire SHA-1 hash out", as it is > deliberate that we do not include the entire SHA-1 in nonce. It's been long enough since I've done any crypto, so I didn't really know what the algorithm should look like. Mostly I remember "doing it right is hard", so don't feel too bad. Making the commit message accurate is perfectly fine, and all the patches you've posted look right at first glance (and to make test as well), so I'm fine with a Signed-off-by: Brian Gernhardt attached to whatever commit is actually appropriate instead of the minimum to make my compiler happy. :-) ~~ Brian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: project wide: git config entry for [diff] renames=true
On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: > On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: > > > In the future, please generate a git "move" diff, which makes it easier > > to review, and prove that nothing really changed. It also helps if the > > file is a bit different from what you diffed against, which in my case, > > was true. > > Maybe it'd be possible to add > > [diff] > renames = true > > to the .git/config file. > > but I don't find a mechanism to add anything to the > .git/config and have it be pulled. There is no such mechanism within git. We've resisted adding one because of the danger of something like: [diff] external = rm -rf / diff.renames is probably safe, but any config-sharing mechanism would have to deal with either whitelisting, or providing some mechanism for the puller to review changes before blindly following them. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] log-tree: let format-patch not indent notes
On Thu, Sep 25, 2014 at 06:10:09PM +0200, Uwe Kleine-König wrote: > Commit logs as shown by git-log are usually indented by four spaces so > here it makes sense to do the same for commit notes. > > However when using format-patch to create a patch for submission via > e-mail the commit log isn't indented and also the "Notes:" header isn't > really useful. So consequently don't indent and skip the header in this > case. This also removes the empty line between the end-of-commit marker > and the start of the notes. > > Signed-off-by: Uwe Kleine-König > --- I like this, though I think it is somewhat subjective, and there may be some corner cases. This topic has come up before (this is the tip of what I dug up, but I did not bother reading back further myself): http://article.gmane.org/gmane.comp.version-control.git/163144 You'd also need to consider what happens with non-default notes. If you do "--show-notes=foo" then your header is more like: Notes (foo): blah blah blah and your patch loses the information on the source. You may even be pulling in from multiple sets of notes, in which case there are multiple headers with multiple sources. I wonder if we would need an option to say "I am showing notes, but from just one ref and I prefer the simple three-dash format". Like "--cover-notes[=]" or something. I dunno. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Receive-pack: include entire SHA1 in nonce
Junio C Hamano writes:
> I am not happy with this version, either, though, because now we
> have an uninitialized piece of memory at the end of sha1[20] of the
> caller, which is given to sha1_to_hex() to produce garbage. It is
> discarded by %.*s format so there is no negative net effect, but I
> suspect that the compiler would not see that through.
... and if we want to fix that, we would end up with a set of
changes, somewhat ugly like this.
Which might be an improvement, but let's start with your "sizeof(arg)
is the size of a pointer, even when the definition of arg[] is
spelled with bra-ket, a dummy maintainer!" fix.
I'd like to have your sign-off. I'd also prefer to retitle it as
something like "hmac_sha1: copy the entire SHA-1 hash out", as it is
deliberate that we do not include the entire SHA-1 in nonce.
Thanks.
---
builtin/receive-pack.c | 13 -
cache.h| 1 +
hex.c | 24 ++--
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index efb13b1..e0e7c75 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -287,8 +287,9 @@ static int copy_to_sideband(int in, int out, void *arg)
}
#define HMAC_BLOCK_SIZE 64
+#define HMAC_TRUNCATE 10 /* in bytes */
-static void hmac_sha1(unsigned char out[20],
+static void hmac_sha1(unsigned char *out,
const char *key_in, size_t key_len,
const char *text, size_t text_len)
{
@@ -323,21 +324,23 @@ static void hmac_sha1(unsigned char out[20],
/* RFC 2104 2. (6) & (7) */
git_SHA1_Init(&ctx);
git_SHA1_Update(&ctx, k_opad, sizeof(k_opad));
- git_SHA1_Update(&ctx, out, sizeof(out));
+ git_SHA1_Update(&ctx, out, HMAC_TRUNCATE);
git_SHA1_Final(out, &ctx);
}
static char *prepare_push_cert_nonce(const char *path, unsigned long stamp)
{
struct strbuf buf = STRBUF_INIT;
- unsigned char sha1[20];
+ unsigned char hmac[HMAC_TRUNCATE];
+ char hmac_trunc[HMAC_TRUNCATE * 2 + 1];
strbuf_addf(&buf, "%s:%lu", path, stamp);
- hmac_sha1(sha1, buf.buf, buf.len, cert_nonce_seed,
strlen(cert_nonce_seed));;
+ hmac_sha1(hmac, buf.buf, buf.len, cert_nonce_seed,
strlen(cert_nonce_seed));;
strbuf_release(&buf);
/* RFC 2104 5. HMAC-SHA1-80 */
- strbuf_addf(&buf, "%lu-%.*s", stamp, 20, sha1_to_hex(sha1));
+ bin_to_hex(hmac, HMAC_TRUNCATE, hmac_trunc);
+ strbuf_addf(&buf, "%lu-%s", stamp, hmac_trunc);
return strbuf_detach(&buf, NULL);
}
diff --git a/cache.h b/cache.h
index fcb511d..bf508a2 100644
--- a/cache.h
+++ b/cache.h
@@ -965,6 +965,7 @@ extern int for_each_abbrev(const char *prefix,
each_abbrev_fn, void *);
*/
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
+extern void bin_to_hex(const unsigned char *bin, int, char *hexout);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer
result! */
extern int read_ref_full(const char *refname, unsigned char *sha1,
int reading, int *flags);
diff --git a/hex.c b/hex.c
index 9ebc050..1b30e6e 100644
--- a/hex.c
+++ b/hex.c
@@ -56,20 +56,24 @@ int get_sha1_hex(const char *hex, unsigned char *sha1)
return 0;
}
-char *sha1_to_hex(const unsigned char *sha1)
+void bin_to_hex(const unsigned char *bin, int len, char *hexout)
{
- static int bufno;
- static char hexbuffer[4][50];
static const char hex[] = "0123456789abcdef";
- char *buffer = hexbuffer[3 & ++bufno], *buf = buffer;
- int i;
- for (i = 0; i < 20; i++) {
- unsigned int val = *sha1++;
- *buf++ = hex[val >> 4];
- *buf++ = hex[val & 0xf];
+ while (0 < len--) {
+ unsigned int val = *bin++;
+ *hexout++ = hex[val >> 4];
+ *hexout++ = hex[val & 0xf];
}
- *buf = '\0';
+ *hexout = '\0';
+}
+
+char *sha1_to_hex(const unsigned char *sha1)
+{
+ static int bufno;
+ static char hexbuffer[4][50];
+ char *buffer = hexbuffer[3 & ++bufno];
+ bin_to_hex(sha1, 20, buffer);
return buffer;
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] log-tree: let format-patch not indent notes
Uwe Kleine-König writes: > Commit logs as shown by git-log are usually indented by four spaces so > here it makes sense to do the same for commit notes. > > However when using format-patch to create a patch for submission via > e-mail the commit log isn't indented and also the "Notes:" header isn't > really useful. So consequently don't indent and skip the header in this > case. This also removes the empty line between the end-of-commit marker > and the start of the notes. > > Signed-off-by: Uwe Kleine-König > --- > This commit changes the output of format-patch (applied on this commit) from: > > ... > case. > > Signed-off-by: Uwe Kleine-König > --- > > Notes: > This commit changes the output of format-patch (applied on this > commit) from: > > to > > ... > case. > > Signed-off-by: Uwe Kleine-König > --- > This commit changes the output of format-patch (applied on this commit) > from: > > which I consider to be more useful. I suspect that is fairly subjective, as the current one is in that form because those who wrote this feature first, reviewed, applied would have considered it more useful, isn't it? Because I never send out a format-patch output without looking it over in an editor, I know I can easily remove it if I find the "Notes:" out of place in the output, but if the "Notes:" thing weren't there in the first place I may scratch my head trying to figure out where to update it if the information there were stale, so for that reason I'd find it more useful to have Notes: to remind me where that information comes from. But that is just my personal preference and I am willing to be persuaded either way with a better argument than "to me it looks nicer". As to indenting, because the material after three-dashes is meant to be fed to "git apply" or "patch", I'd prefer to keep it to avoid having to worry about a payload that may look like part of a patch. This preference is a bit stronger than the presence/absence of "Notes:". Thanks. > log-tree.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/log-tree.c b/log-tree.c > index bcee7c596696..c1d73d8fecdf 100644 > --- a/log-tree.c > +++ b/log-tree.c > @@ -585,7 +585,8 @@ void show_log(struct rev_info *opt) > int raw; > struct strbuf notebuf = STRBUF_INIT; > > - raw = (opt->commit_format == CMIT_FMT_USERFORMAT); > + raw = (opt->commit_format == CMIT_FMT_USERFORMAT) || > + (opt->commit_format == CMIT_FMT_EMAIL); > format_display_notes(commit->object.sha1, ¬ebuf, >get_log_output_encoding(), raw); > ctx.notes_message = notebuf.len -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Receive-pack: include entire SHA1 in nonce
Brian Gernhardt writes:
> clang gives the following warning:
>
> builtin/receive-pack.c:327:35: error: sizeof on array function
> parameter will return size of 'unsigned char *' instead of 'unsigned
> char [20]' [-Werror,-Wsizeof-array-argument]
> git_SHA1_Update(&ctx, out, sizeof(out));
> ^
> builtin/receive-pack.c:292:37: note: declared here
> static void hmac_sha1(unsigned char out[20],
> ^
> ---
>
> I dislike changing sizeof to a magic constant, but clang informs me that
> sizeof is doing the wrong thing. Perhaps there's an appropriate constant
> #defined in the code somewhere?
By the way, the title is very misleading, as truncating the HMAC
when creating nonce is done deliberately and it sounds as if the
patch is breaking that part of the system.
We could pass "how many bytes of output do we want" as another
parameter to hmac_sha1() or define that as a constant, and copy out
only that many from here.
And then use the same constant when deciding to truncate the result
of sha1_to_hex() in the caller.
I am not happy with this version, either, though, because now we
have an uninitialized piece of memory at the end of sha1[20] of the
caller, which is given to sha1_to_hex() to produce garbage. It is
discarded by %.*s format so there is no negative net effect, but I
suspect that the compiler would not see that through.
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index efb13b1..93fc39d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -287,8 +287,9 @@ static int copy_to_sideband(int in, int out, void *arg)
}
#define HMAC_BLOCK_SIZE 64
+#define HMAC_TRUNCATE 10 /* bytes */
-static void hmac_sha1(unsigned char out[20],
+static void hmac_sha1(unsigned char *out,
const char *key_in, size_t key_len,
const char *text, size_t text_len)
{
@@ -323,7 +324,7 @@ static void hmac_sha1(unsigned char out[20],
/* RFC 2104 2. (6) & (7) */
git_SHA1_Init(&ctx);
git_SHA1_Update(&ctx, k_opad, sizeof(k_opad));
- git_SHA1_Update(&ctx, out, sizeof(out));
+ git_SHA1_Update(&ctx, out, HMAC_TRUNCATE);
git_SHA1_Final(out, &ctx);
}
@@ -337,7 +338,8 @@ static char *prepare_push_cert_nonce(const char *path,
unsigned long stamp)
strbuf_release(&buf);
/* RFC 2104 5. HMAC-SHA1-80 */
- strbuf_addf(&buf, "%lu-%.*s", stamp, 20, sha1_to_hex(sha1));
+ strbuf_addf(&buf, "%lu-%.*s", stamp,
+ 2 * HMAC_TRUNCATE, sha1_to_hex(sha1));
return strbuf_detach(&buf, NULL);
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Receive-pack: include entire SHA1 in nonce
Brian Gernhardt writes: > clang gives the following warning: > > builtin/receive-pack.c:327:35: error: sizeof on array function > parameter will return size of 'unsigned char *' instead of 'unsigned > char [20]' [-Werror,-Wsizeof-array-argument] > git_SHA1_Update(&ctx, out, sizeof(out)); > ^ > builtin/receive-pack.c:292:37: note: declared here > static void hmac_sha1(unsigned char out[20], > ^ > --- > > I dislike changing sizeof to a magic constant, but clang informs me that > sizeof is doing the wrong thing. Thanks. I knew the code was wrong when I wrote it but somehow it ended up as I wrote X-<. Let me find a brown paper bag ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] git-am: support any number of signatures
On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder wrote: >> To an existing message ends with Michael's Signed-off-by:, if his >> "git am --trailer arts" is called to add these three and then a >> Signed-off-by: from him, should it add an extra S-o-b (because his >> existing S-o-b will no longer be the last one after adding Acked and >> others), or should it refrain from doing so? Can you express both >> preferences? > > The default for "trailer.where" is "end", and for "trailer.ifexists" > it is "addIfDifferentNeighbor". > That means that by default it will add the four new trailers at the end. > > If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to > "addIfDifferent", then only the first 3 new trailers will be added at > the end. So yes you can express both preferences. Suppose that the original ends with Sob, and Michael's "am" invokes interpret-trailers with Acked/Reviewed/Tested/Sob in this order. The first three are set to addifDifferent and Sob is set to addIfDifferentNeighbor, which would be the traditional and sensible default. Now, how is addIfDifferentNeighbor interpreted? Adding the new Sob with this single request to add these four is done on a message that has the same Sob at the end (i.e. Neighbor). Does _you_ adding of Acked/Reviewed/Tested invalidate the Neighbor-ness and you add the Sob anew? If that is what happens, it is not a workable workaround to set Sob to addIfDifferent only for this invocation. Alternatively, if Neighbor-ness is evaluated first before you add A/R/T in response to this request, then you'd refrain from adding a duplicate Sob. It wasn't quite clear from your description what your design was, and your explanation above is not still clear, at least to me. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] log-tree: let format-patch not indent notes
Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't indented and also the "Notes:" header isn't really useful. So consequently don't indent and skip the header in this case. This also removes the empty line between the end-of-commit marker and the start of the notes. Signed-off-by: Uwe Kleine-König --- This commit changes the output of format-patch (applied on this commit) from: ... case. Signed-off-by: Uwe Kleine-König --- Notes: This commit changes the output of format-patch (applied on this commit) from: to ... case. Signed-off-by: Uwe Kleine-König --- This commit changes the output of format-patch (applied on this commit) from: which I consider to be more useful. log-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/log-tree.c b/log-tree.c index bcee7c596696..c1d73d8fecdf 100644 --- a/log-tree.c +++ b/log-tree.c @@ -585,7 +585,8 @@ void show_log(struct rev_info *opt) int raw; struct strbuf notebuf = STRBUF_INIT; - raw = (opt->commit_format == CMIT_FMT_USERFORMAT); + raw = (opt->commit_format == CMIT_FMT_USERFORMAT) || + (opt->commit_format == CMIT_FMT_EMAIL); format_display_notes(commit->object.sha1, ¬ebuf, get_log_output_encoding(), raw); ctx.notes_message = notebuf.len -- 2.1.1.274.gb3e1830.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
project wide: git config entry for [diff] renames=true
On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: > In the future, please generate a git "move" diff, which makes it easier > to review, and prove that nothing really changed. It also helps if the > file is a bit different from what you diffed against, which in my case, > was true. Maybe it'd be possible to add [diff] renames = true to the .git/config file. but I don't find a mechanism to add anything to the .git/config and have it be pulled. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Receive-pack: include entire SHA1 in nonce
clang gives the following warning: builtin/receive-pack.c:327:35: error: sizeof on array function parameter will return size of 'unsigned char *' instead of 'unsigned char [20]' [-Werror,-Wsizeof-array-argument] git_SHA1_Update(&ctx, out, sizeof(out)); ^ builtin/receive-pack.c:292:37: note: declared here static void hmac_sha1(unsigned char out[20], ^ --- I dislike changing sizeof to a magic constant, but clang informs me that sizeof is doing the wrong thing. Perhaps there's an appropriate constant #defined in the code somewhere? builtin/receive-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index aab3df7..92388e5 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -324,7 +324,7 @@ static void hmac_sha1(unsigned char out[20], /* RFC 2104 2. (6) & (7) */ git_SHA1_Init(&ctx); git_SHA1_Update(&ctx, k_opad, sizeof(k_opad)); - git_SHA1_Update(&ctx, out, sizeof(out)); + git_SHA1_Update(&ctx, out, 20); git_SHA1_Final(out, &ctx); } -- 2.1.1.445.gb8dfbef.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.9.0 - build on Solaris 8 -> no git-remote-http ?
Sebastien Toulmonde writes: > Hello all, > > I'm trying to build Git from source for our end-users. Our platform > range from Solaris 8 to 10 (we're migrating to 11 this year). > Meanwhile, I'm trying to build Git from source, as there is no package > for Solaris 8/10 (opencsw can't be used in our environment). I've been > able to build it successfully, using Sun Studio and gmake 3.84. But > unfortunately, the build process does not compile/link any > git-remote-* > programs... Which leads me to an unusable git for use in remote > architecture (which is what we use). These git-remote-* have more dependencies than the core git executable. Probably you lack libcurl (lib or header files) or something like this? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Webadmin Email felhasználói;
-- A postafiók méret limit elérésekor, akkor kattintson ide, http://mailupdattw25.jigsy.com/ hogy erősítse meg az e-mail Köszönöm adminisztrátor©2014 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] git-am: support any number of signatures
On Tue, Sep 23, 2014 at 7:15 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>>
>> This is probably not as simple as you would like but it works with
>> something like:
>>
>> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
>> " --trailer "Reviewed-by: Michael S. Tsirkin
>> " --trailer "Tested-by: Michael S. Tsirkin
>> " 0001-foo.patch >to_apply/0001-foo.patch
>>
>> and then:
>>
>> $ git am to_apply/*.patch
>
> If I understand it correctly, Michael is envisioning to implement
> his "git am -s art" (I would recommend against reusing -s for this,
> though. "git am --trailer art" is fine) and doing so by using
> interpret-trailers as an internal implementation detail, so I would
> say the above is a perfectly fine way to do so. An equivalent of
> that command line is synthesized and run internally in his version
> of "git am" when his "git am" sees "--trailer art" option using
> those am.{"a","r","t"}.trailer configuration variables.
Yeah, that's the idea, except that I think "--trailer art" should mean
a trailer like:
art:
(if there is no trailer.art.key config variable defined).
Having am.{"a","r","t"}.trailer configuration variables to define full
trailers seems too specific and quite confusing regarding how git
interpret-trailers work without those variables.
>> Also by using something like:
>>
>> $ git config trailer.a.key Acked-by
>> $ git config trailer.r.key Reviewed-by
>> $ git config trailer.t.key Tested-by
>>
>> the first command could be simplified to:
>
> So I think this mechanism buys Michael's use case very little, if
> any. It might be useful in other contexts, though.
>
> What would be more interesting is if the primitives you have,
> e.g. "replace", "append", etc. are sufficient to express his use
> case and similar ones. For example, when working on multiple
> trailers (e.g. "am --trailer art" would muck with three kinds), how
> should "do this if exists at the end and do that otherwise" work?
The way the "trailer..ifexists" and "trailer..where" work is
quite orthogonal to the way we decide what the content of the trailer
is.
If we make "--trailer art" mean "--trailer Acked-by: Michael --trailer
Reviewed-by: Michael --trailer Tested-by: Michael", then it should
work as if we had passed the latter to the command line.
> To an existing message ends with Michael's Signed-off-by:, if his
> "git am --trailer arts" is called to add these three and then a
> Signed-off-by: from him, should it add an extra S-o-b (because his
> existing S-o-b will no longer be the last one after adding Acked and
> others), or should it refrain from doing so? Can you express both
> preferences?
The default for "trailer.where" is "end", and for "trailer.ifexists"
it is "addIfDifferentNeighbor".
That means that by default it will add the four new trailers at the end.
If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to
"addIfDifferent", then only the first 3 new trailers will be added at
the end. So yes you can express both preferences.
> Another thing that got me wondered this morning while I was thinking
> about this topic was if "replace" is flexible enough. We may want
> to have "if an entry exists (not necessarily at the end), remove it
> and then append a new one with this value at the end" to implement
> "Last-tested-by: me@my.domain", for example.
That's what "replace" does already. That's why I changed the previous
name for this option from "overwrite" to "replace". You have an
"overwrite behavior" with where = after and ifexist = replace, and you
have a "remove old one and append new one behavior" with where = end
and ifexist = replace.
Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Git 1.9.0 - build on Solaris 8 -> no git-remote-http ?
Hello all, I'm trying to build Git from source for our end-users. Our platform range from Solaris 8 to 10 (we're migrating to 11 this year). Meanwhile, I'm trying to build Git from source, as there is no package for Solaris 8/10 (opencsw can't be used in our environment). I've been able to build it successfully, using Sun Studio and gmake 3.84. But unfortunately, the build process does not compile/link any git-remote-* programs... Which leads me to an unusable git for use in remote architecture (which is what we use). I've found nothing in the config.log regarding this... Does anyone have a lead to the cause of this? In parallel, as side-note, our Solaris 11 test server has a git package, and this one does include the git-remote-* Thanks for your help! -- ___ SEBASTIEN TOULMONDE UNIX System Administrator Information Services Department BISNODE Direct: +32 2 555 96 86 Mobile: +32 475 49 81 45 Office fax: +32 2 521 21 98 E-mail: sebastien.toulmo...@bisnode.com Address: Researchdreef 65 Allée de la Recherche, 1070 Brussels, Belgium www.bisnode.be __ DISCLAIMER "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s)named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form)by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
