[PATCHv2 1/8] t1300: style updates
On Wed, Oct 24, 2012 at 02:37:12AM -0400, Jeff King wrote: > > Here's a case you forgot to update to test_cmp. > [...] > > And while you are here, you might want to remove this extra space. ;) > > > > Otherwise, looks fine. > > Thanks, I'll fix up both. Here's an updated version of patch 1 that I'm planning on queuing. It's rather tedious to read, but if anybody feels like giving it one more run-through, let me know if you see any problems. I won't bother re-posting the other patches, as they are unchanged on top. -- >8 -- Subject: [PATCH] t1300: style updates The t1300 test script is quite old, and does not use our modern techniques or styles. This patch updates it in the following ways: 1. Use test_cmp instead of cmp (to make failures easier to debug). 2. Use test_cmp instead of 'test $(command) = expected'. This makes failures much easier to debug, and also makes sure that $(command) exits appropriately. 3. Use test_must_fail (easier to read, and checks more rigorously for signal death). 4. Write tests with the usual style of: test_expect_success 'test name' ' test commands && ... ' rather than one-liners, or using backslash-continuation. This is purely a style fixup. There are still a few command happening outside of test_expect invocations, but they are all innoccuous system commands like "cat" and "cp". In an ideal world, each test would be self sufficient and all commands would happen inside test_expect, but it is not immediately obvious how the grouping should work (some of the commands impact the subsequent tests, and some of them are setting up and modifying state that many tests depend on). This patch just picks the low-hanging style fruit, and we can do more fixes on top later. Signed-off-by: Jeff King --- t/t1300-repo-config.sh | 301 + 1 file changed, 178 insertions(+), 123 deletions(-) diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh index e127f35..feb7430 100755 --- a/t/t1300-repo-config.sh +++ b/t/t1300-repo-config.sh @@ -55,11 +55,13 @@ test_expect_success 'replace with non-match' \ test_cmp expect .git/config ' -test_expect_success 'replace with non-match' \ - 'git config core.penguin kingpin !blue' +test_expect_success 'replace with non-match' ' + git config core.penguin kingpin !blue +' -test_expect_success 'replace with non-match (actually matching)' \ - 'git config core.penguin "very blue" !kingpin' +test_expect_success 'replace with non-match (actually matching)' ' + git config core.penguin "very blue" !kingpin +' cat > expect << EOF [core] @@ -108,8 +110,9 @@ EOF lines EOF -test_expect_success 'unset with cont. lines' \ - 'git config --unset beta.baz' +test_expect_success 'unset with cont. lines' ' + git config --unset beta.baz +' cat > expect <<\EOF [alpha] @@ -133,8 +136,9 @@ cp .git/config .git/config2 cp .git/config .git/config2 -test_expect_success 'multiple unset' \ - 'git config --unset-all beta.haha' +test_expect_success 'multiple unset' ' + git config --unset-all beta.haha +' cat > expect << EOF [beta] ; silly comment # another comment @@ -145,7 +149,9 @@ EOF [nextSection] noNewline = ouch EOF -test_expect_success 'multiple unset is correct' 'test_cmp expect .git/config' +test_expect_success 'multiple unset is correct' ' + test_cmp expect .git/config +' cp .git/config2 .git/config @@ -156,8 +162,9 @@ rm .git/config2 rm .git/config2 -test_expect_success '--replace-all' \ - 'git config --replace-all beta.haha gamma' +test_expect_success '--replace-all' ' + git config --replace-all beta.haha gamma +' cat > expect << EOF [beta] ; silly comment # another comment @@ -169,7 +176,9 @@ EOF [nextSection] noNewline = ouch EOF -test_expect_success 'all replaced' 'test_cmp expect .git/config' +test_expect_success 'all replaced' ' + test_cmp expect .git/config +' cat > expect << EOF [beta] ; silly comment # another comment @@ -200,7 +209,11 @@ test_expect_success 'really really mean test' ' test_cmp expect .git/config ' -test_expect_success 'get value' 'test alpha = $(git config beta.haha)' +test_expect_success 'get value' ' + echo alpha >expect && + git config beta.haha >actual && + test_cmp expect actual +' cat > expect << EOF [beta] ; silly comment # another comment @@ -231,18 +244,23 @@ test_expect_success 'ambiguous get' ' test_cmp expect .git/config ' -test_expect_success 'non-match' \ - 'git config --get nextsection.nonewline !for' +test_expect_success 'non-match' ' + git config --get nextsection.nonewline !for +' -test_expect_success 'non-match value' \ - 'test wow = $(git config --get nextsection.nonewline !for)' +test_expect_success 'non-match value' ' + echo wow >expect && + git config --get nextsection.nonewline !
Re: Large number of object files
On Wed, Oct 24, 2012 at 01:59:16PM +0700, Nguyen Thai Ngoc Duy wrote: > On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz wrote: > > Continuing to work on improving clone times, using "git gc > > --aggressive" has resulted in a large number of tags combining into a > > single file but now I have a large number of files in the objects > > directory - 131k for a ~2.7GB repository. > > Can you paste "git count-objects -v"? I'm curious why gc keeps so many > loose objects around. Presumably ejected from the pack because they are now unreachable. That's a rather large number, but if there was recent ref maintenance (e.g., deleting branches or tags), it is not impossible. > > Any way to reduce the number of these files to speed up clones? > > An easy way to get rid of them is to clone the non-local way. > Everything will be sent over a pack, the result would be a single pack > in new repo. Try "git clone file:///path/to/source/repo new-repo". If you have git v1.7.12 or greater, you can also use the "--no-local" option to clone. But as you mentioned, pruning is probably the most sensible thing (and for a non-local clone, those objects should not impact performance at all, as we will never even look at unreferenced objects). -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] git-submodule: wrap branch option with "<>" in usage strings.
On Tue, Oct 23, 2012 at 05:00:21PM -0400, W. Trevor King wrote: > From: "W. Trevor King" > > Use "-b " instead of "-b branch". This brings the usage > strings in line with other options, e.g. "--reference ". > > Signed-off-by: W. Trevor King Thanks. Looks obviously correct to me. -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: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
I'll see if I can come up with a patch that cater for both use-cases. I see that I forgot to Cc you; please see the patch series starting with the Subject "[RFC PATCH 0/2] Localize log output", which I posted here yesterday. -- \\// Peter - http://www.softwolves.pp.se/ -- 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] git-send-email: skip RFC2047 quoting for ASCII subjects
The git-send-email always use RFC2047 subject quoting for files
with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
skipped.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 3 ++-
t/t9001-send-email.sh | 17 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index adcb4e3..efeae4c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1327,7 +1327,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
+ if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
+ ($subject =~ /[^[:ascii:]]/)) {
$subject = quote_rfc2047($subject, $auto_8bit_encoding);
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 89fceda..6c6af7d 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1143,6 +1143,23 @@ EOF
'
test_expect_success $PREREQ 'setup expect' '
+cat >expected actual &&
+ test_cmp expected actual
+'
+
+test_expect_success $PREREQ 'setup expect' '
cat >content-type-decl
Re: [PATCH] git-status: show short sequencer state
Phil Hord writes:
>>> + if (state->substate==WT_SUBSTATE_NOMINAL)
>>> status_printf_ln(s, color,
>>> _("The current patch is empty."));
>> This looks weird. First, spaces around == (here and below). Then, the
>> logic is unintuitive. The "if" suggests everything is allright, and the
>> message below is very specific. This at least deserves a comment.
>
> Yes, I agree. It was less clear but more reasonable before I tried to
> clear it up some. It's driven by the short-token printer. The state is
> "you're in a 'git am' but I do not see any conflicted files. Therefore,
> your patch must be empty."
This was my guess, but I wouldn't have needed to guess if there was a
comment in the code ;-).
> I'll try to make this more explicit. Currently the short-status
> version will say either "am" or "am \n conflicted" when a 'git am' is in
> progress. The logical path to follow if I re-add 'git-am-empty' state
> tracker is for this to now show either "am \n am-is-empty" or "am \n
> conflicted". But I think I should suppress the "am-is-empty" report in
> that case. What do you think
I don't think you should remove it from the output (no strong opinion).
My point was just that the code looked weird.
>>> +static void wt_print_token(struct wt_status *s, const char *color, const
>>> char *token)
>>> +{
>>> + color_fprintf(s->fp, color, "%s", token);
>>> + fputc(s->null_termination ? '\0' : '\n', s->fp);
>>> +}
>> The output format seems to be meant only for machine-consumption. Is
>> there any case when we'd want color? [...]
> > [...]I thought I might be going back there, or that I might combine this
> > with full 'git status' again somehow, and colors seemed appropriate
> > still.
> > [...]
> > So I can remove this color decorator until someone finds a need for
> > it.
I'm fine with both options, with a slight preference for removing them.
> My own use-case involves $PS1.
That makes sense (indeed, the implementation of status hints was
slightly inspired from what the bash prompt in
contrib/completion/git-prompt.sh does). The next step could be to use
your porcelain there instead of checking manually file existance.
You may want to add a short note about this motivation in the commit
message.
--
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
Re: [PATCH 7/9] pretty: support padding placeholders, %< %> and %>
On Sun, Sep 23, 2012 at 04:10:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> + else {
> + int sb_len = sb->len, offset;
> + switch (c->flush_type) {
> + case flush_left:
> + offset = padding - len;
> + break;
> + case flush_right:
> + offset = 0;
> + break;
> + case flush_both:
> + offset = (padding - len) / 2;
> + break;
> + case no_flush: /* to make gcc happy */
> + break;
> + }
> + /*
> + * we calculate padding in columns, now
> + * convert it back to chars
> + */
> + padding = padding - len + local_sb.len;
> + strbuf_grow(sb, padding);
> + strbuf_setlen(sb, sb_len + padding);
> + memset(sb->buf + sb_len, ' ', sb->len - sb_len);
> + memcpy(sb->buf + sb_len + offset, local_sb.buf,
> +local_sb.len);
> + }
gcc complains (rightly, I think) that offset can be used uninitialized
in the final line (looks like it is from the no_flush case). If it is a
"can never happen" case that is there to appease gcc in the switch
statement, should we drop a die("BUG: XXX") there? If so, what would the
XXX be?
-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] git-send-email: skip RFC2047 quoting for ASCII subjects
On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
> The git-send-email always use RFC2047 subject quoting for files
> with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
> even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
> skipped.
> [...]
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> + ($subject =~ /[^[:ascii:]]/)) {
Is that test sufficient? We would also need to encode if it has rfc2047
specials, no?
It looks like we use the same regex elsewhere. Maybe this would be a
good chance to abstract out a needs_rfc2047_quoting while we are in the
area?
Other than that, I did not see anything wrong with the patch.
-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
A note from the (interim) maintainer
Since Junio is gone for a few weeks, I'll be doing my best to fill in. My plan is to pick up topics from the list and keep development moving on "master" and "next". I'm not planning on cutting any releases, which should be fine unless some emergency comes up which would require a quick v1.8.0.1. I'll publish my branches at: git://github.com/peff/git.git There's nothing new there yet. Now that the 1.8.0 dust has settled, I'm going to start graduating existing topics to master, according to the comments from the latest "What's Cooking" messages. I'll also rewind "next" soon-ish. I've picked up a few topics from the list already, but there's some backlog. My goal for Wednesday is to process the rest of that, push out an integration cycle, and then send out a What's Cooking with the current state. If you have a topic in flight with no response, I probably just haven't looked at it yet. If you don't see it in the next WC, though, I probably missed it and you should resend. -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: signing commits with openssl/PKCS#11
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). 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 -- 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
confused by git diff --exit-code
With merge conflicts in the work-tree, diff's exit-code seems inconsistent. I thought --quiet implied --exit-code /others/foo$ git diff --quiet /others/foo$ echo $? 1 /others/foo$ git diff --exit-code diff --cc foo.txt index f3dc283,bea67fd..000 --- a/foo.txt +++ b/foo.txt /others/foo$ echo $? 0 /others/foo$ git diff --cc --quiet /others/foo$ echo $? 0 /others/foo$ git diff --cc --exit-code diff --cc foo.txt index f3dc283,bea67fd..000 --- a/foo.txt +++ b/foo.txt /others/foo$ echo $? 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote: > On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: > > > It is spelled: > > > > > > git notes add -m SHA1 > > > > > > The resulting notes are stored in a separate revision-controlled branch > > > and can be pushed and pulled like regular refs. Note, though, that the > > > default refspecs do not yet include refs/notes, so you'd have to add > > > them manually. The workflows around notes are not very mature yet, so if > > > you start using them, feedback would be appreciated. > > > > What would be nice is that notes are pushed/pulled automatically with > > standard git push/fetch/pull commands. Usually git walks the DAG > > starting with the pulled commit or tag and following the parents. With > > notes, the reference is reversed, the note pointing to the commit and > > not the other way around. So handling this automatically in Git would > > be really useful. > > Right, that's what I meant about the refspecs. You can configure git to > push or pull them automatically, but it is not the default. Something > like: > > git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*' Yes, but that's a bit more complicated than a simple pull. Anyway, Linus seems to not be in favour of annotating commits later for adding acks, so no need for such feature. > > The other feature I'd like is that notes are automatically folded in > > the log during git rebase (maybe similar to the squash option). If you > > rebase, you lose all the notes (though this depends on the workflow, > > it may not be needed with published branches). > > Git-rebase can automatically copy notes from one commit to another > during a rebase, but you need to set notes.rewriteRef to do so (see "git > help config" for details). The reason for this conservative default is > that some notes may not be appropriate for automatic copying (e.g., a > notes tree containing QA approval should probably be invalidated during > a rebase, whereas one with commentary probably should). Thanks, I wasn't aware of this. > Squashing the notes into the commit message during rebase would be a > useful feature (at least for some type of notes), but that feature does > not currently exist (and as far as I recall, this is the first it has > been proposed). For some workflow - I post patches to the list, people reply with their acks, I could just add those to notes and later fold them into the existing commits before pushing the branch upstream. I guess it may be just a matter of changing git format-patch to include the notes. I can later reword he commits and drop the "Notes:" line. -- Catalin -- 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 commit-tree man page
Angelo Borsotti writes: > Hello, > > the man page of git commit-tree SYNOPSIS is: > > git commit-tree [(-p )...] < changelog > git commit-tree [(-p )...] [(-m )...] [(-F > )...] > > The second form is incorrect: the must be specified before the options. > E.g. > > $ git commit-tree -m B 88f7dbd47 > fatal: Not a valid object name -m This has been fixed in 1.7.11.4: * "git commit-tree" learned a more natural "-p " order of arguments long time ago, but recently forgot it by mistake. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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: [DOCBUG] git subtree synopsis needs updating
On Sat, 20 Oct 2012 21:40:03 +0200 Herman van Rink wrote: > On 10/19/2012 03:21 PM, Yann Dirson wrote: > > As the examples in git-subtree.txt show, the synopsis in the same file > > should > > surely get a patch along the lines of: > > > > -'git subtree' add -P > > +'git subtree' add -P > > > > Failure to specify the repository (by just specifying a local commit) fails > > with > > the cryptic: > > > > warning: read-tree: emptying the index with no arguments is deprecated; > > use --empty > > fatal: just how do you expect me to merge 0 trees? > > > > > > Furthermore, the doc paragraph for add, aside from mentionning > > , also > > mentions a which the synopsis does not show either. > > > > > > As a sidenote it someone wants to do some maintainance, using "." as > > repository when > > the branch to subtree-add is already locally available does not work well > > either > > (fails with "could not find ref myremote/myhead"). > > > > The version of subtree in contrib is rather out-dated unfortunately. > > I've collected a bunch of patches in > https://github.com/helmo/git/tree/subtree-updates Ah, it's nice to see subtree updates. Any plans to get them merged anytime soon ? I guess you may want to rebase the patches from https://github.com/helmo/git-subtree, the subtree-updates patch looks like a "subtree merge --squash" result, and is not really suitable for reviewing on the list. > The documentation issue is also fixed in there. > -- Yann Dirson - Bertin Technologies -- 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Jeff King wrote: > On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > > The resulting notes are stored in a separate > > > revision-controlled branch > > > > Which branch(es) is/are that ? What are the semantics of that? [...] Nice feature. Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? -Marc -- 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 v3 5/6] tests: add remote-hg tests
On Sun, Oct 21, 2012 at 11:02 PM, Sverre Rabbelier wrote: > On Sun, Oct 21, 2012 at 10:49 AM, Felipe Contreras > wrote: >> From the original remote-hg. >> >> You need git-remote-hg already in your path to run them. >> >> I'm not proposing to include this patch like this, but should make it easier >> to >> test. > > You should also have a look at the tests that were marked as "expected > to fail", since they point out a bug with fast-export. What tests? All the tests I see in msysgit are expected to succeed: https://github.com/msysgit/git/blob/devel/t/t5801-remote-hg.sh > I'd sent a > series to fix that, but didn't follow-up to get it merged: > > http://thread.gmane.org/gmane.comp.version-control.git/184874 I have read that thread multiple times now, and I still don't see the problem. Everything works fine in my remote-hg. I still don't understand what changes are required in upstream that your remote-hg needs, and the fact that there is no up-to-date remote-hg branch doesn't help. Cheers. -- Felipe Contreras -- 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-send-email: skip RFC2047 quoting for ASCII subjects
On Wed, Oct 24, 2012 at 04:46:36AM -0400, Jeff King wrote:
> On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
>
> > The git-send-email always use RFC2047 subject quoting for files
> > with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
> > even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
> > skipped.
> > [...]
> > - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > + ($subject =~ /[^[:ascii:]]/)) {
>
> Is that test sufficient? We would also need to encode if it has rfc2047
> specials, no?
For Subject this should be sufficient. According to RFC822 after
"Subject:" we have "text" token,
--- from RFC822 ---
/ "Subject" ":" *text
--- from RFC822 ---
and text is defined as:
--- from RFC822 ---
text= atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
--- from RFC822 ---
so only CRLF is not allowed in Subject.
So the problem only exists for broken RFC2047-like texts, but I think
it's ok to just pass such subjects, in most cases the Subject comes
from already formatted patch file. I think that we just want to fix Subjects
without specified encoding here.
In most cases, when git-send-email is used for patches generated
by "git format-patch" we just don't want to corrupt Subject. The
"git format-patch" generates "broken" patches when commit message
uses only ASCII characters and patch contains some non-ASCII characters.
In this case original git-send-email, without this patch, adds RFC2047
quotation for pure ASCII Subject.
>
> It looks like we use the same regex elsewhere. Maybe this would be a
> good chance to abstract out a needs_rfc2047_quoting while we are in the
> area?
It's a good idea, however rules are different for Subject and addresses
(sanitize_address).
I think we can go even further, we can just add quote_subject(),
which performs this test and calls quote_rfc2047() if necessary.
I'm sending bellow patch that does that.
Krzysiek
--
>From a1e6eef831275485ec1555d94ff0d9aac852dd12 Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur
Date: Wed, 24 Oct 2012 19:08:57 +0200
Subject: [PATCH] git-send-email: introduce quote_subject()
The quote_rfc2047() always adds RFC2047 quoting and to avoid quoting ASCII
subjects, before calling quote_rfc2047() subject must be tested for non-ASCII
characters. To avoid this new quote_subject() function is introduced.
The quote_subject() performs this test and calls quote_rfc2047() only if
necessary.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index efeae4c..e9aec8d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -657,9 +657,7 @@ EOT
$initial_subject = $1;
my $subject = $initial_subject;
$_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
-quote_rfc2047($subject, $compose_encoding) :
-$subject) .
+ quote_subject($subject, $compose_encoding) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
@@ -907,6 +905,22 @@ sub is_rfc2047_quoted {
$s =~ m/^(?:"[[:ascii:]]*"|=\?$token\?$token\?$encoded_text\?=)$/o;
}
+sub subject_needs_rfc2047_quoting {
+ my $s = shift;
+
+ return !is_rfc2047_quoted($s) && ($s =~ /[^[:ascii:]]/);
+}
+
+sub quote_subject {
+ local $subject = shift;
+ my $encoding = shift || 'UTF-8';
+
+ if (subject_needs_rfc2047_quoting($subject)) {
+ return quote_rfc2047($subject, $encoding);
+ }
+ return $subject;
+}
+
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
@@ -1327,9 +1341,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
- ($subject =~ /[^[:ascii:]]/)) {
- $subject = quote_rfc2047($subject, $auto_8bit_encoding);
+ if ($broken_encoding{$t}) {
+ $subject = quote_subject($subject, $auto_8bit_encoding);
}
if (defined $author and $author ne $sender) {
--
1.8.0.3.gf4c35fc
--
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: Long clone time after "done."
It all goes to pack_refs() in write_remote_refs called from update_remote_refs(). On Tue, Oct 23, 2012 at 11:29 PM, Nguyen Thai Ngoc Duy wrote: > On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz wrote: >> I have a large repository which I ran "git gc --aggressive" on that >> I'm trying to clone on a local file system. I would expect it to >> complete very quickly with hard links but it's taking about 6min to >> complete with no checkout (git clone -n). I see the message "Clining >> into 'repos'... done." appear after a few seconds but then Git just >> hangs there for another 6min. Any idea what it's doing at this point >> and how I can speed it up? > > "done." is printed by clone_local(), which is called in cmd_clone(). > After that there are just a few more calls. Maybe you could add a few > printf in between these calls, see which one takes most time? > -- > Duy -- 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 1/3] t9350: point out that refs are not updated correctly
Hi,
Joined late to the party :)
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier wrote:
> This happens only when the corresponding commits are not exported in
> the current fast-export run. This can happen either when the relevant
> commit is already marked, or when the commit is explicitly marked
> as UNINTERESTING with a negative ref by another argument.
>
> This breaks fast-export based remote helpers, as they use marks
> files to store which commits have already been seen. The call graph
> is something as follows:
>
> $ # push master to remote repo
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # make a commit on master and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile master
> $ # run `git branch foo` and push it to remote
> $ git fast-export --{im,ex}port-marks=marksfile foo
That is correctly, but try this:
$ git fast-export --{im,ex}port-marks=marksfile foo foo
Now foo is updated.
> When fast-export imports the marksfile and sees that all commits in
> foo are marked as UNINTERESTING (they have already been exported
> while pushing master), it exits without doing anything. However,
> what we want is for it to reset 'foo' to the already-exported commit.
>
> Either way demonstrates the problem, and since this is the most
> succint way to demonstrate the problem it is implemented by passing
> master..master on the commandline.
>
> Signed-off-by: Sverre Rabbelier
> ---
> t/t9350-fast-export.sh | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
> index 950d0ff..74914dc 100755
> --- a/t/t9350-fast-export.sh
> +++ b/t/t9350-fast-export.sh
> @@ -440,4 +440,15 @@ test_expect_success 'fast-export quotes pathnames' '
> )
> '
>
> +cat > expected << EOF
> +reset refs/heads/master
> +from $(git rev-parse master)
> +
> +EOF
> +
> +test_expect_failure 'refs are updated even if no commits need to be
> exported' '
> + git fast-export master..master > actual &&
> + test_cmp expected actual
> +'
> +
> test_done
This test is completely wrong.
1) Where are the marks file?
2) master..master shouldn't export anything
3) Why do you expect a SHA-1? It could be a mark.
I decided to write my own this way:
---
cat > expected << EOF
reset refs/heads/master
from ##mark##
EOF
test_expect_failure 'refs are updated even if no commits need to be exported' '
cp tmp-marks /tmp
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master | true &&
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master > actual &&
mark=$(grep $(git rev-parse master) tmp-marks | cut -f 1 -d " ")
sed -i -e "s/##mark##/$mark/" expected &&
test_cmp expected actual
'
---
Yes, it's true this fails, but change to 'master master', and then it works.
This can be easily fixed by this patch:
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..3b4c2d6 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,10 +523,13 @@ static void get_tags_and_duplicates(struct
object_array *pending,
typename(e->item->type));
continue;
}
- if (commit->util)
- /* more than one name for the same object */
+ /*
+* This ref will not be updated through a commit, lets make
+* sure it gets properly updated eventually.
+*/
+ if (commit->util || commit->object.flags & SHOWN)
string_list_append(extra_refs,
full_name)->util = commit;
- else
+ if (!commit->util)
commit->util = full_name;
}
}
Now if you specify a ref it will get updated regardless. However, this
points to another bug:
% git fast-export --{im,ex}port-marks=/tmp/marks master ^foo foo.foo
The foo ref will be reset _twice_ because all pending refs after the
first one get reset no matter how they were specified.
That is already the case, my patch will cause this to generate the same output:
% git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
Which is still not got, but not catastrophic by any means.
Cheers.
--
Felipe Contreras
--
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/3] fast-export: output reset command for commandline revs
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier wrote:
> When a revision is specified on the commandline we explicitly output
> a 'reset' command for it if it was not handled already. This allows
> for example the remote-helper protocol to use fast-export to create
> branches that point to a commit that has already been exported.
This simpler patch does the same, doesn't it?
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..3b4c2d6 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,10 +523,13 @@ static void get_tags_and_duplicates(struct
object_array *pending,
typename(e->item->type));
continue;
}
- if (commit->util)
- /* more than one name for the same object */
+ /*
+* This ref will not be updated through a commit, lets make
+* sure it gets properly updated eventually.
+*/
+ if (commit->util || commit->object.flags & SHOWN)
string_list_append(extra_refs,
full_name)->util = commit;
- else
+ if (!commit->util)
commit->util = full_name;
}
}
> Initial-patch-by: Johannes Schindelin
> Signed-off-by: Sverre Rabbelier
> ---
>
> Most of the hard work for this patch was done by Dscho. The rest of
> it was basically me applying the technique used by jch in c3502fa
> (25-08-2011 do not include sibling history in --ancestry-path).
>
> The if statement dealing with tag_of_filtered_mode is not as
> elegant as either me or Dscho would have liked, but we couldn't
> find a better way to determine if a ref is a tag at this point
> in the code.
Which is needed why?
Right now if I do:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 tag-to-foo1
Where tag-to-foo1 is a tag that that points to foo1, I get a reset for that.
> Additionally, the elem->whence != REV_CMD_RIGHT case should really
> check if REV_CMD_RIGHT_REF, but as this is not provided by the
> ref_info structure this is left as is. A result of this is that
> incorrect input will result in incorrect output, rather than an
> error message. That is: `git fast-export a..` will
> incorrectly generate a `reset ` statement in the fast-export
> stream.
I don't see the point of this.
Besides, you can check the return value of dwim_ref, if it's not 1,
then you shouldn't generate a reset.
> The dwim_ref bit is a double work (it has already been done by the
> caller of this function), but I decided it would be more work to
> pass this information along than to recompute it for the few
> commandline refs that were relevant.
It's already stored in commit->util, you don't need to do that.
As I said, I think the patch above does the trick, and it even has the
advantage of not having the above a.. issues.
Cheers.
--
Felipe Contreras
--
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 1/3] t9350: point out that refs are not updated correctly
Hi Felipe, Felipe Contreras wrote: > This test is completely wrong. > > 1) Where are the marks file? > 2) master..master shouldn't export anything Why shouldn't master..master export anything? It means "update the master ref; we already have all commits up to and including master^0". The underlying problem is that fast-export takes rev-list arguments as parameters, which is unfortunately only an approximation to what is really intended. Ideally it would separately take a list of refs to import and rev-list arguments representing the commits we already have. Hoping that clarifies, Jonathan -- 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-submodule add: Record branch name in .gitmodules
On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King wrote:
> On a tangentially related note, it would be nice to set environment
> variables for each of the settings in submodule.$name during a foreach
> call. Then you could use
>
> git submodule foreach 'git checkout $branch && git pull'
>
> Perhaps you'd want to blacklist/whitelist or downcase settings names
> to avoid things like
>
> [submodule "foo"]
> PATH = /my/rootkit/
>
> but the update line is much cleaner.
This is ugly as can be, but it works in my meagre testing. It defines
"submodule_path=/my/rootkit/" for the above bit of .gitmodules. That
is, it adds definitions for 'submodule_' for each
in .gitmodules in submodule.$name., but is
lowercased and defanged (everything that's not already [a-z0-9] is
replaced with underscore). For example,
git submodule foreach 'echo $submodule_url'
--- >8 ---
diff --git c/git-submodule.sh i/git-submodule.sh
index 6dd2338..79b3467 100755
--- c/git-submodule.sh
+++ i/git-submodule.sh
@@ -416,7 +416,15 @@ cmd_foreach()
prefix="$prefix$sm_path/"
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+ # make all submodule variables
available to scripts
+ eval $(git config -f .gitmodules
--get-regexp "^submodule\.${name}\..*" |
+ sed -e "s|^submodule\.${name}\.||" |
+ while read VAR_NAME VAR_VALUE ; do
+ VAR_NAME=$(printf '%s'
"$VAR_NAME" | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g')
+ printf 'submodule_%s=%s;\n'
"$VAR_NAME" "'$VAR_VALUE'"
+ done)
cd "$sm_path" &&
eval "$@" &&
if test -n "$recursive"
--
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-gui: textconv not used on unstaged files
Hi, i am using a textconv filter to display .doc files as plain text. It seems git gui does not use this textconv filter for displaying new unstaged files (other files? = _O) It seems diff.tcl start_show_diff calls show_other_diff because of this. This manually loads the file and does not care about textconv filters. Is this manual loading really necessary or can't we just ask git? If it is can it be modified to use the textconv filter? Thanks, Greetings Peter .gitattributes: *.docdiff=astextplain gitconfig: [diff "astextplain"] textconv = astextplain -- 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 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 8:08 PM, Jonathan Nieder wrote:
> Hi Felipe,
>
> Felipe Contreras wrote:
>
>> This test is completely wrong.
>>
>> 1) Where are the marks file?
>> 2) master..master shouldn't export anything
>
> Why shouldn't master..master export anything? It means "update the
> master ref; we already have all commits up to and including master^0".
Does it mean that? I don't think so, but let's assume that's the case.
We don't have all those commits; without the marks we have nothing. Or
what exactly do you mean by 'we'?
Go to your git.git repository, and run this:
% git git init /tmp/git
% git fast-export master^..master | git --git-dir=/tmp/git/.git fast-import
What do you expect? I expect a single commit, and that's what we get,
now do the same with 'master..master', what do you expect?
How about 'git fast-export ^master'? Do you expect to get anything
there? Or what about '^master master'?
Without marks these idioms don't make any sense. Now lets assume that
marks were meant to be there.
If 'master..master' is supposed to update master, then what is
'master' supposed to do?
% git fast-export --{im,ex}port-marks=/tmp/marks master..master
vs.
% git fast-export --{im,ex}port-marks=/tmp/marks master
Either way, my patch will make 'master..master' throw a reset (if the
marks are present, I haven't tried without them), I don't think it
should, but that's a different story, and a different patch fix.
> The underlying problem is that fast-export takes rev-list arguments as
> parameters, which is unfortunately only an approximation to what is
> really intended. Ideally it would separately take a list of refs to
> import and rev-list arguments representing the commits we already
> have.
The commits we already have (exported before) are stored in the marks.
Maybe we can store the refs there as well, but that would not change
the semantics of refspecs, nor the fact that we need the marks.
Cheers.
--
Felipe Contreras
--
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-submodule add: Record branch name in .gitmodules
Am 24.10.2012 00:02, schrieb Nahor: > On 2012-10-23 13:36, Jens Lehmann wrote: >> Am 23.10.2012 21:16, schrieb Nahor: >>> Last issue, the branch that exists in your local repository may not >>> exist in someone else's repository, either because the branch is >>> purely local, or because it has a different name on the remote repo. >> >> You'll always face this kind of problems with commits too when using >> submodules, so I don't see that as a problem here. > > Commits can't change or disappear during "normal" git operation (i.e. without > using "git push -f" or "git branch -D"). > A commit also has the same id in all the clones repository so there is no > issue of a different name between the local and the remote repositories. But if you forget to push a submodule commit it won't exist in someone else's repository and so he won't be able to update the submodule after checking out a commit in the superproject that records that unpushed submodule commit. -- 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 1/3] t9350: point out that refs are not updated correctly
Felipe Contreras wrote: > Does it mean that? I don't think so, but let's assume that's the case. > > We don't have all those commits; without the marks we have nothing. Or > what exactly do you mean by 'we'? Not everyone uses marks. Ciao, Jonathan -- 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 8/8] git-config: use git_config_with_options
Yeah same here. Thanks for tackling this bug. Looking forward to using the include mechanism for overriding user.email in future versions. -- 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] git-submodule add: Add -r/--record option.
I still fail to see what adding that functionality to the submodule
command buys us (unless we also add code which really uses the branch
setting). What's wrong with doing a simple:
git config -f .gitmodules submodule..branch
on the command line when you want to use the branch setting for your
own purposes? You could easily wrap that into a helper script, no?
Am 23.10.2012 23:57, schrieb W. Trevor King:
> From: "W. Trevor King"
>
> This option allows you to record a submodule..branch option in
> .gitmodules. Git does not currently use this configuration option for
> anything, but users have used it for several things, so it makes sense
> to add some syntactic sugar for initializing the value.
>
> Current consumers:
>
> Ævar uses this setting to designate the upstream branch for pulling
> submodule updates:
>
> $ git submodule foreach 'git checkout $(git config --file
> $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> as he describes in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason
> Date: Fri May 21 16:10:10 2010 +
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses this setting to
>
> “indicate the branch of a submodule project that when updated will
> trigger automatic update of its registered gitlink.” [1]
>
> I'm not clear on what that means, but they accept special values like
> '.', so their usage is not compatible with Ævar's proposal.
>
> By remaining agnostic on the variable usage, this patch makes
> submodule setup more convenient for all parties.
>
> [1]
> https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
>
> Signed-off-by: W. Trevor King
> ---
> Documentation/git-submodule.txt | 11 ++-
> git-submodule.sh| 19 ++-
> t/t7400-submodule-basic.sh | 25 +
> 3 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b4683bb..f9c74d6 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
> SYNOPSIS
>
> [verse]
> -'git submodule' [--quiet] add [-b branch] [-f|--force]
> +'git submodule' [--quiet] add [-b branch] [--record[=]] [-f|--force]
> [--reference ] [--] []
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
> 'git submodule' [--quiet] init [--] [...]
> @@ -209,6 +209,15 @@ OPTIONS
> --branch::
> Branch of repository to add as submodule.
>
> +-r::
> +--record::
> + Record a branch name used as `submodule..branch` in
> + `.gitmodules` for future reference. If you do not list an explicit
> + name here, the name given with `--branch` will be recorded. If that
> + is not set either, `HEAD` will be recorded. Because the branch name
> + is optional, you must use the equal-sign form (`-r=`), not
> + `-r `.
> +
> -f::
> --force::
> This option is only valid for add and update commands.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..bc33112 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -5,7 +5,7 @@
> # Copyright (c) 2007 Lars Hjemli
>
> dashless=$(basename "$0" | sed -e 's/-/ /')
> -USAGE="[--quiet] add [-b branch] [-f|--force] [--reference ]
> [--] []
> +USAGE="[--quiet] add [-b branch] [--record[=]] [-f|--force]
> [--reference ] [--] []
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
> or: $dashless [--quiet] init [--] [...]
> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
> [--rebase] [--reference ] [--merge] [--recursive] [--] [...]
> @@ -20,6 +20,8 @@ require_work_tree
>
> command=
> branch=
> +record_branch=
> +record_branch_empty=
> force=
> reference=
> cached=
> @@ -257,6 +259,12 @@ cmd_add()
> branch=$2
> shift
> ;;
> + -r | --record)
> + record_branch_empty=true
> + ;;
> + -r=* | --record=*)
> + record_branch="${1#*=}"
> + ;;
> -f | --force)
> force=$1
> ;;
> @@ -328,6 +336,11 @@ cmd_add()
> git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
> die "$(eval_gettext "'\$sm_path' already exists in the index")"
>
> + if test -z "$record_branch" && test "$record_branch_empty" = "true"
> + then
> + record_branch="${branch:=HEAD}"
> + fi
> +
> if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path"
> > /dev/null 2>&1
> then
> eval_gettextln "The following path is ignored by one of your
> .gitignore files:
> @@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
>
> git config -f .gitmodules submodu
Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
On Wed, Oct 24, 2012 at 07:10:36PM +0200, Krzysztof Mazur wrote:
> > > - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > > + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > > + ($subject =~ /[^[:ascii:]]/)) {
> >
> > Is that test sufficient? We would also need to encode if it has rfc2047
> > specials, no?
>
> For Subject this should be sufficient. According to RFC822 after
> "Subject:" we have "text" token,
> [...]
> So the problem only exists for broken RFC2047-like texts, but I think
> it's ok to just pass such subjects, in most cases the Subject comes
> from already formatted patch file. I think that we just want to fix Subjects
> without specified encoding here.
Right, but I was specifically worried about raw "=?", which is only an
issue due to rfc2047 itself.
However, reading the patch again, we are already checking for that with
is_rfc2047_quoted. It might miss the case where we have =? but not the
rest of a valid encoded word, but any compliant parser should recognize
that and leave it be.
So I think your original patch is actually correct.
> I think we can go even further, we can just add quote_subject(),
> which performs this test and calls quote_rfc2047() if necessary.
> I'm sending bellow patch that does that.
Yeah, it would still be nice to keep the logic in one place.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index efeae4c..e9aec8d 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -657,9 +657,7 @@ EOT
> $initial_subject = $1;
> my $subject = $initial_subject;
> $_ = "Subject: " .
> - ($subject =~ /[^[:ascii:]]/ ?
> - quote_rfc2047($subject, $compose_encoding) :
> - $subject) .
> + quote_subject($subject, $compose_encoding) .
Hrm. Isn't this one technically a regression if the $subject contains
encoded words? IOW, in this case we feed quote_subject a known-raw
header; any rfc2047 in it would want to be encoded to be preserved.
But in this case:
> @@ -1327,9 +1341,8 @@ foreach my $t (@files) {
> $body_encoding = $auto_8bit_encoding;
> }
>
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> - ($subject =~ /[^[:ascii:]]/)) {
> - $subject = quote_rfc2047($subject, $auto_8bit_encoding);
> + if ($broken_encoding{$t}) {
> + $subject = quote_subject($subject, $auto_8bit_encoding);
> }
We have a possibly already-encoded header, and we would want to avoid
double-encoding it.
In the first case, the "wants quoting" logic should be:
is_rfc2047_quoted($subject) || /[^[:ascii:]]/
and in the latter case it would be:
!is_rfc2047_quoted($subject) && /^[:ascii:]]/
-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
strange problems applying --no-prefix patch with -p0 and added files
Hello.
I am trying to apply a patch made via {git diff somehash^ somehash >
} before (same version of Git, same machine). I have no-prefix
enabled by default.
If I try to apply the patch with -p0, it fails.
If I go to a directory where all the changed files are ("src/" below)
to "simulate" the prefix for -p1, it silently does nothing.
Only if I make it a -p1 patch, it actually tries to do apply (and
applies the new files that cause problems in -p0 alright too, if used
with --reject).
I am relatively new to git, so while researching I realized I might be
using wrong ways to do things (e.g. not using cherry-pick), but this
seems like a bug regardless.
Here's the log of my interactions with git:
reznor-mbp:git-hbase-089 sergey$ git version
git version 1.7.10.2 (Apple Git-33)
reznor-mbp:git-hbase-089 sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
#HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:git-hbase-089 sergey$ git apply -p0 HBASE-6371.patch
fatal: git apply: bad git-diff - inconsistent new filename on line 128
reznor-mbp:git-hbase-089 sergey$ sed -n 125,129p HBASE-6371.patch
diff --git src/main/java/org/apache/
hadoop/hbase/regionserver/CompactSelection.java
src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
new file mode 100644
index 000..a9ee0d4
--- /dev/null
+++ src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
reznor-mbp:git-hbase-089 sergey$ cd src
reznor-mbp:src sergey$ git apply -p1 -v --whitespace=nowarn ../HBASE-6371.patch
[ there's nothing here, e.g. no output ]
reznor-mbp:src sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
#../HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:src sergey$ cd ..
reznor-mbp:git-hbase-089 sergey$ sed -E "s/(--git|---) src/\1 a\/src/"
HBASE-6371.patch | sed -E "s/ src\// b\/src\//" >
HBASE-6371-prefix.patch
reznor-mbp:git-hbase-089 sergey$ git apply HBASE-6371-prefix.patch
HBASE-6371-prefix.patch:169: trailing whitespace.
...
error: patch failed:
src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:64
error: src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:
patch does not apply
--
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-send-email: skip RFC2047 quoting for ASCII subjects
On Wed, Oct 24, 2012 at 03:25:30PM -0400, Jeff King wrote:
> Right, but I was specifically worried about raw "=?", which is only an
> issue due to rfc2047 itself.
>
> However, reading the patch again, we are already checking for that with
> is_rfc2047_quoted. It might miss the case where we have =? but not the
> rest of a valid encoded word, but any compliant parser should recognize
> that and leave it be.
>
> So I think your original patch is actually correct.
>
> [...]
> We have a possibly already-encoded header, and we would want to avoid
> double-encoding it.
>
> In the first case, the "wants quoting" logic should be:
>
> is_rfc2047_quoted($subject) || /[^[:ascii:]]/
>
> and in the latter case it would be:
>
> !is_rfc2047_quoted($subject) && /^[:ascii:]]/
>
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.
Krzysiek
--
>From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur
Date: Wed, 24 Oct 2012 22:46:00 +0200
Subject: [PATCH] git-send-email: introduce quote_subject()
The quote_rfc2047() always adds RFC2047 quoting and to avoid quoting ASCII
subjects, before calling quote_rfc2047() subject must be tested for non-ASCII
characters. To avoid this new quote_subject() function is introduced.
The quote_subject() performs this test and calls quote_rfc2047() only if
necessary.
Signed-off-by: Krzysztof Mazur
---
git-send-email.perl | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index efeae4c..eb1b876 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -657,9 +657,7 @@ EOT
$initial_subject = $1;
my $subject = $initial_subject;
$_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
-quote_rfc2047($subject, $compose_encoding) :
-$subject) .
+ quote_subject($subject, $compose_encoding) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
@@ -907,6 +905,22 @@ sub is_rfc2047_quoted {
$s =~ m/^(?:"[[:ascii:]]*"|=\?$token\?$token\?$encoded_text\?=)$/o;
}
+sub subject_needs_rfc2047_quoting {
+ my $s = shift;
+
+ return ($s =~ /[^[:ascii:]]/);
+}
+
+sub quote_subject {
+ local $subject = shift;
+ my $encoding = shift || 'UTF-8';
+
+ if (subject_needs_rfc2047_quoting($subject)) {
+ return quote_rfc2047($subject, $encoding);
+ }
+ return $subject;
+}
+
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
@@ -1327,9 +1341,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- 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);
}
if (defined $author and $author ne $sender) {
--
1.8.0.4.ge8ddce6
--
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] git-send-email: add rfc2047 quoting for "=?"
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
but also for any possible rfc2047 in it.
Signed-off-by: Krzysztof Mazur
---
Oops, this ugly Subject was generated by git format-patch (both 1.8.0
and km/send-email-compose-encoding).
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index eb1b876..cfd20fa 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -908,7 +908,7 @@ sub is_rfc2047_quoted {
sub subject_needs_rfc2047_quoting {
my $s = shift;
- return ($s =~ /[^[:ascii:]]/);
+ return ($s =~ /[^[:ascii:]]/) || ($s =~ /=\?/);
}
sub quote_subject {
--
1.8.0.rc0.30.g72615bf
--
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 1/3] t9350: point out that refs are not updated correctly
Hi, On Wed, 24 Oct 2012, Felipe Contreras wrote: > 2) master..master shouldn't export anything The underlying issue -- as explained in the thread -- is when you want to update master to a commit that another ref already points to. In that case no commits need to exported, but the ref needs to be updated nevertheless. We just wrote the test in the most convenient way, no need to complicate things more than necessary. Hth, Johannes -- 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
Is git mktag supposed to accept git cat-file input?
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? kalki:[~]% mkdir /tmp/gittest; cd /tmp/gittest kalki:[/tmp/gittest]% git init Initialized empty Git repository in /tmp/gittest/.git/ kalki:[/tmp/gittest]% echo "test" > test kalki:[/tmp/gittest]% git add test kalki:[/tmp/gittest]% git commit -m "commit-test" [master (root-commit) c0ae36f] commit-test 1 file changed, 1 insertion(+) create mode 100644 test kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test kalki:[/tmp/gittest]% git cat-file -p e619 object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5 type commit tag tag-test tagger Anand Kumria Thu Oct 25 00:32:32 2012 +0100 tag-test kalki:[/tmp/gittest]% git cat-file -p e619 | sed -e's/tag-test/tag-test2/' > tag-test2 kalki:[/tmp/gittest]% cat tag-test2 object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5 type commit tag tag-test2 tagger Anand Kumria Thu Oct 25 00:32:32 2012 +0100 tag-test2 kalki:[/tmp/gittest]% git mktag < tag-test2 error: char112: missing tag timestamp fatal: invalid tag signature file kalki:[/tmp/gittest]% git --version git version 1.7.9.5 The error message related to the timezone / timestamp being incorrect but I can't see what the problem is. Any advice appreciated. Please CC me as I may miss your reply. Thanks, Anand -- “Don’t be sad because it’s over. Smile because it happened.” – Dr. Seuss -- 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: Is git mktag supposed to accept git cat-file input?
On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria 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 1351121552 +0100 tag-test and is the format expected by mktag. -Brandon -- 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
Where should git-prompt.sh be installed?
Hi, In olden days the admin would copy contrib/completion/git-completion.sh to /etc/bash_completion.d/git and mortals could source /etc/bash_completion or /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among multiple machines) so that the bash completion and __git_ps1 helpers could work. With Git 1.7.12 __git_ps1 has been split into a separate file, to help users who only want __git_ps1 to avoid the overhead of loading the entire completion script (and allow the completion script to be loaded by bash-completion magic on the fly!). Now the sysadmin should copy contrib/completion/git-completion.sh to /usr/share/bash-completion/completions/git and contrib/completion/git-prompt.sh to /usr/share/git-core/contrib/?? (somewhere?) Mortals source /etc/bash_completion in their ~/.bashrc (possibly shared among multiple machines) and expect bash completion to work. For __git_ps1, users should source that ?? path. Questions: 1) what path is appropriate for ?? above? 2) is this documented anywhere? Possible answers: 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses /usr/share/bash-completion/git-prompt. Maybe others use some other path. 2) The scripts themselves suggest copying to ~/.git-completion.sh and ~/.git-prompt.sh. Proposal: 1) /usr/lib/git-core/git-sh-prompt 2) git-sh-prompt(1) Sensible? Thanks, Jonathan -- 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] git-submodule add: Add -r/--record option.
On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote: > I still fail to see what adding that functionality to the submodule > command buys us (unless we also add code which really uses the branch > setting). What's wrong with doing a simple: > >git config -f .gitmodules submodule..branch > > on the command line when you want to use the branch setting for your > own purposes? You could easily wrap that into a helper script, no? Sure. But why maintain my own helper script if I can edit git-submodules.sh? It seems like a number of people are using this config option, and they generally store the same name in it that they use to create the submodule. This way I can save them time too. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Is git mktag supposed to accept git cat-file input?
Ahh, unix time. Of course. Thanks Brandon. On 25 October 2012 01:18, Brandon Casey wrote: > On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria 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 1351121552 +0100 > >tag-test > > and is the format expected by mktag. > > -Brandon > -- “Don’t be sad because it’s over. Smile because it happened.” – Dr. Seuss -- 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-submodule add: Record branch name in .gitmodules
On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
> Some projects now use the 'branch' config value to record the tracking
> branch for the submodule. Some ascribe different meaning to the
> configuration if the value is given vs. undefined. For example, see
> the Gerrit submodule-subscription mechanism. This change will cause
> those workflows to behave differently than they do now.
For those to lazy to hunt down a reference, Gerrit uses
submodule.$name.branch to
“indicate the branch of a submodule project that when updated will
trigger automatic update of its registered gitlink.” [1]
They also have some extra sauce:
“The branch value could be '.' if the submodule project branch has
the same name as the destination branch of the commit having
gitlinks/.gitmodules file.
…
Any git submodules which are added and not have the branch field
available in the .gitmodules file will not be subscribed by Gerrit
to automatically update the superproject.”
> I do like the idea, but I wish it had a different name for the
> recording. Maybe --record-branch=${BRANCH} as an extra switch so the
> action is explicitly requested.
>
> git submodule add --branch=master --record-branch=master foo bar
Ugh, I don't want to retype the branch name whenever I do this.
How about -r/--record, with the recorded name being optional?
--record-branch[=]
This would satisfy Gerrit users that wanted to use '.', but also
satisfy me with:
git submodule add -rb=master foo bar
However, there is a change that people would see that, and then use
git submodule add -r -b=master foo bar
which would checkout the HEAD from foo and store `-b=master` in
submodule.$name.branch.
A more verbose, but less dangerous, option would be a boolean
-r/--record that enables the recording of whatever was passed to
-b/--branch. This looses the flexibility of running something like
git submodule add --branch=master --record-branch=. foo bar
but the Gerrit folks have gotten along OK without any branch recording
so far ;). They can keep setting '.' the same way they always have.
On a tangentially related note, it would be nice to set environment
variables for each of the settings in submodule.$name during a foreach
call. Then you could use
git submodule foreach 'git checkout $branch && git pull'
Perhaps you'd want to blacklist/whitelist or downcase settings names
to avoid things like
[submodule "foo"]
PATH = /my/rootkit/
but the update line is much cleaner.
Cheers,
Trevor
[1]:
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] git-submodule add: Record branch name in .gitmodules
On Wed, Oct 24, 2012 at 02:12:18PM -0400, Phil Hord wrote: > + VAR_NAME=$(printf '%s' > "$VAR_NAME" | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g') Is there a reason why you use printf instead of echo? Also, this sort of name cleaning should probably live in a new function: clean_environment_variable() or some such. Is there a git-utility-functions.sh library hiding somewhere in the source? ;) -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Where should git-prompt.sh be installed?
On Wed, Oct 24, 2012 at 8:51 PM, Jonathan Nieder wrote: > Now the sysadmin should copy > contrib/completion/git-completion.sh to > > /usr/share/bash-completion/completions/git > > and contrib/completion/git-prompt.sh to > > /usr/share/git-core/contrib/?? (somewhere?) > > Mortals source /etc/bash_completion in their ~/.bashrc (possibly > shared among multiple machines) and expect bash completion to work. > For __git_ps1, users should source that ?? path. > > Questions: > > 1) what path is appropriate for ?? above? > 2) is this documented anywhere? > > Possible answers: > > 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses > /usr/share/bash-completion/git-prompt. Maybe others use > some other path. > > 2) The scripts themselves suggest copying to ~/.git-completion.sh > and ~/.git-prompt.sh. > > Proposal: > > 1) /usr/lib/git-core/git-sh-prompt > 2) git-sh-prompt(1) > > Sensible? Does the LSB provide any guidance? If not, or if such guidance isn't helpful, I say that looks reasonable. What I'd like to know is why we are saying "copy" when symlinking is likely to be more easily maintainable? (Less chance to screw up.) -- -Drew Northup -- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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] Fix git p4 sync errors
On Oct 21, 2012, at 12:06 , Junio C Hamano wrote: > >> >> This solves errors in some cases when syncing renamed files. > > Can you be a bit more descriptive? What are "errors in some case"? > It might just be when files are renamed. I ran into this after months of using it, and I'm skeptical that in that time no files were ever renamed. I'm not sure what was special about the file that was renamed. (There also might have been deleted files in the same commit, not sure if that matters) > In short, what I am getting at are: > > - What breaks by not passing "-s"? What are the user visible > symptoms? There's a key error on the line line 2198:epoch = details["time"] The details object is an error different fields set (I don't remember what it is exactly, I'm not at work right now) > > - Why is it a bug not to pass "-s"? How does the bug happen? I encountered this one time after using it for months. One day I couldn't git p4 rebase with the key error. I searched for the error and found some version of git-p4 that fixed a similar error by adding the -s to describe. Adding the -s fixed the error and everything seemed to be working correctly. -- 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
t9401 fails with OS X sed
I seem to write these kinds of e-mails fairly regularly...
When running t9401-git-cvsserver-crlf:
expecting success:
check_status_options cvswork2 textfile.c "" &&
check_status_options cvswork2 binfile.bin -kb &&
check_status_options cvswork2 .gitattributes "" &&
check_status_options cvswork2 mixedUp.c -kb &&
check_status_options cvswork2 multiline.c -kb &&
check_status_options cvswork2 multilineTxt.c "" &&
check_status_options cvswork2/subdir withCr.bin -kb &&
check_status_options cvswork2 subdir/withCr.bin -kb &&
check_status_options cvswork2/subdir file.h "" &&
check_status_options cvswork2 subdir/file.h "" &&
check_status_options cvswork2/subdir unspecified.other "" &&
check_status_options cvswork2/subdir newfile.bin "" &&
check_status_options cvswork2/subdir newfile.c ""
not ok - 12 cvs status - sticky options
I have tracked it down to a sed expression that is parsing the output of cvs
status:
49:got="$(sed -n -e 's/^\s*Sticky Options:\s*//p' "${WORKDIR}/status.out")"
The problem is that cvs outputs "Sticky Options:\t\t(none)\n", but OS X's sed
doesn't recognize the \s shortcut. (According to re_format(5), \s is part of
the "enhanced" regex format, which sed doesn't use.)
It works if I change \s to [[:space:]], but I don't know how portable that is.
~~ Brian Gernhardt
--
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 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 9:11 PM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> Does it mean that? I don't think so, but let's assume that's the case. >> >> We don't have all those commits; without the marks we have nothing. Or >> what exactly do you mean by 'we'? > > Not everyone uses marks. When you don't have marks you have to export *everything* that you are interested. If you want all the history from the root to master, then that's what you will get (and you specify 'master'), if you want only the commit pointed to master and nothing else that's what you will get (with 'master^..master'), but when you do 'master..master', you get nothing, because that's what you asked for. Again, if you don't have marks, I don't see what you expect to be exported with 'master..master', even with marks, I don't see what you expect. -- Felipe Contreras -- 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 1/3] t9350: point out that refs are not updated correctly
Felipe Contreras wrote: > Again, if you don't have marks, I don't see what you expect to be > exported with 'master..master', even with marks, I don't see what you > expect. And that's fine. Unless you were trying to do some work and this lack of understanding got in the way. In that case, with a calmer and more humble approach you might find people willing to help you. Maybe they will learn something from you, too. Ciao, Jonathan -- 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] Fixes handling of --reference argument.
Signed-off-by: Stefan Zager --- 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 ;; --) shift -- 1.7.7.3 -- 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 push slowly under 1000M/s network
Yes, I believe it's gerrit problem and will discuss there. During first minutes of restarting gerrit, the pushing becomes quite faster 13s instead. 2012/10/24 Shawn Pearce : > On Mon, Oct 22, 2012 at 11:27 PM, Joey Jiao wrote: >> It looks like the client is waiting the pushing result status from >> server although by checking server side, the real object has already >> been upload succeed. >> >> Below is the log after adding time info. >> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git >> HEAD:refs/changes/33599 2>&1|tee -a log.txt > ... >> remote: Resolving deltas: 0% (0/2) >> remote: (W) afafdad: no files changed, message updated > ... >> real9m56.928s >> user0m0.364s >> sys 0m0.160s > > What version of Gerrit are you using? > How many changes already exist in this project? > > I am fairly certain this is an issue with Gerrit. Which may be better > discussed at http://groups.google.com/group/repo-discuss -- -Joey Jiao -- 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: t9401 fails with OS X sed
On Oct 24, 2012, at 23:54, Brian Gernhardt 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. -Geert-- 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 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin wrote: > Hi, > > On Wed, 24 Oct 2012, Felipe Contreras wrote: > >> 2) master..master shouldn't export anything > > The underlying issue -- as explained in the thread -- is when you want to > update master to a commit that another ref already points to. In that case > no commits need to exported, but the ref needs to be updated nevertheless. > > We just wrote the test in the most convenient way, no need to complicate > things more than necessary. That test cannot work, and it shouldn't work. You say you want to 'update master to a commit that another ref already points to'. What other ref? If you want to update master, this is what you do: % git fast-export master What do you expect 'git fast-export master..master' to export? This? --- reset refs/heads/master from $(git rev-parse master) --- What is a remote helper supposed to do with a SHA-1? Nothing, a git SHA-1 is useless to say, a mercurial remote helper. To make sense of it you would need to access the git repository and get the commit object, and that's defeating the purpose of a fast exporter. No, that's not what you want. But at this point there's only one ref in the picture, you said 'update master to a commit that another ref already points to', but there's only one ref, where is the other ref? Maybe your test should do this: % git fast-export foo master But wait, that actually works, except that the output will be nothing close what you expected before, we would get all the commits and files that constitute 'foo', which is actually useful, and what we expect from fast-export, and in addition, master will be updated to the right ref. No, the problem is not only 'update master to a commit that another ref already points to', but that this happens in two different commands, and that can only be done with marks, just like the test I proposed. The original test doesn't expose the problem we are trying to solve, and it shouldn't work anyway. Moreover, what we eventually want to do is support the transport helpers, so how about you run this: --- #!/bin/sh cat > git-remote-foo <<-\EOF #!/bin/sh read l echo $l 1>&2 echo export echo refspec refs/heads/*:refs/foo/origin/* test -e /tmp/marks-git && echo *import-marks /tmp/marks-git echo *export-marks /tmp/marks-git echo read l echo $l 1>&2 echo ? refs/heads/master echo read l echo $l 1>&2 while read l; do echo $l 1>&2 test "$l" == 'done' && exit done EOF chmod +x git-remote-foo export PATH=$PWD:$PATH rm -f /tmp/marks-git ( git init test cd test echo Test >> Test git add --all git commit -m 'Initial commit' git branch foo echo "== master ==" git push foo::test master echo "== foo ==" git push foo::test foo ) --- I get this output with my patch: --- [master (root-commit) b159eff] Initial commit 1 file changed, 1 insertion(+) create mode 100644 Test == master == capabilities list export feature done blob mark :1 data 5 Test reset refs/heads/master commit refs/heads/master mark :2 author Felipe Contreras 1351140987 +0200 committer Felipe Contreras 1351140987 +0200 data 15 Initial commit M 100644 :1 Test done == foo == capabilities list export feature done reset refs/heads/foo from :2 done --- Hey, did you see that? 'foo' is updated, both 'master' and 'foo' point to the same object. What is the problem? -- Felipe Contreras -- 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 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 6:27 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> Again, if you don't have marks, I don't see what you expect to be >> exported with 'master..master', even with marks, I don't see what you >> expect. > > And that's fine. Unless you were trying to do some work and this lack > of understanding got in the way. What is fine? What lack of understanding? You still haven't said what you expect the output to be. Consider this repo: --- git init test cd test echo one >> file git add --all git commit -m 'one' echo two >> file git commit -m 'one' --- What *exactly* should the output of 'git fast-export master..master' be? I say nothing, what do you say? > In that case, with a calmer and more humble approach you might find > people willing to help you. Maybe they will learn something from you, > too. I don't need help, I am helping you, I was asked to take a look at this patch series. If you don't want my help, then by all means, keep this series rotting, it has being doing so for the past year without anybody complaining. Cheers. -- Felipe Contreras -- 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 1/3] t9350: point out that refs are not updated correctly
Felipe Contreras wrote: > I don't need help, I am helping you, I was asked to take a look at > this patch series. If you don't want my help, then by all means, keep > this series rotting, it has being doing so for the past year without > anybody complaining. Ah, so _that_ (namely getting Sverre's remote helper to work) is the work you were trying to do. Thanks for explaining. If I understand correctly, it is possible to get Sverre's remote helper to work without affecting this particular testcase. From that point of view I think you were on the right track. The testcase is imho correct and does not need changing. So yes, I don't want your help changing it. I don't suspect you will be using "git fast-export $(git rev-parse master)..master". It is safe and good to add additional testcases documenting the syntax that you do use, as an independent topic. Thanks, Jonathan -- 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 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder wrote: > The testcase is imho correct and does not need changing. So yes, I > don't want your help changing it. I don't suspect you will be using > "git fast-export $(git rev-parse master)..master". It is safe and > good to add additional testcases documenting the syntax that you do > use, as an independent topic. To re-iterate Dscho's point, the reason for this testcase is that if you do this: $ git checkout master $ git branch next $ git push hg://example.com master $ git push hg://example.com next With the current design, next will not be present on the remote. This is caused by the fact that git looks at "fast-export ^master next", sees that it's empty, and decides not to export anything. This patch series solves that, by having "fast-export ^master next" emit a "from :42\nreset next" (or something like that, assuming :42 is where master is currently at). -- Cheers, Sverre Rabbelier -- 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 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 7:28 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> I don't need help, I am helping you, I was asked to take a look at >> this patch series. If you don't want my help, then by all means, keep >> this series rotting, it has being doing so for the past year without >> anybody complaining. > > Ah, so _that_ (namely getting Sverre's remote helper to work) is the > work you were trying to do. Thanks for explaining. No, that's not what I'm doing. I haven't even seen a remote-hg branch from either Sverre, or Johannes. IIRC the msysgit wiki mentions that there were some patches not quite accepted in upstream that prevented the remote-hg from getting upstream. But I don't know which patches are those, I don't know why they are needed, and I haven't even been able to run this stuff. I was told this might be an issue for all remote helpers, and it seems to be the case (albeit a small issue IMO). > If I understand correctly, it is possible to get Sverre's remote > helper to work without affecting this particular testcase. From that > point of view I think you were on the right track. That makes sense. So are there any other patches? > The testcase is imho correct and does not need changing. So yes, I > don't want your help changing it. I don't suspect you will be using > "git fast-export $(git rev-parse master)..master". It is safe and > good to add additional testcases documenting the syntax that you do > use, as an independent topic. All right, so I run this and get this: % git fast-export master..master reset refs/heads/master from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 As an user of fast-export, what do I do with that now? -- Felipe Contreras -- 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 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 7:39 AM, Sverre Rabbelier wrote: > On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder wrote: >> The testcase is imho correct and does not need changing. So yes, I >> don't want your help changing it. I don't suspect you will be using >> "git fast-export $(git rev-parse master)..master". It is safe and >> good to add additional testcases documenting the syntax that you do >> use, as an independent topic. > > To re-iterate Dscho's point, the reason for this testcase is that if > you do this: > $ git checkout master > $ git branch next > $ git push hg://example.com master > $ git push hg://example.com next > > With the current design, next will not be present on the remote. This > is caused by the fact that git looks at "fast-export ^master next", > sees that it's empty, and decides not to export anything. This patch > series solves that, by having "fast-export ^master next" emit a "from > :42\nreset next" (or something like that, assuming :42 is where master > is currently at). Only if the remote helper is using marks, and this particular patch is adding a test-case without any use of marks at all. IOW; this test is testing something completely different, which happens to fix the original issue, but this is not the only way to fix, and in IMO certainly not the best. As I showed in my script above: $ git checkout master $ git branch next $ git push hg://example.com master $ git push hg://example.com next This works just fine. Go ahead, apply my patch, and run it, the second branch gets updated. It will fail this test, but that's because the test is not testing what it should: that *when using marks* the second branch exported is ignored. This test does that: --- cat > expected << EOF reset refs/heads/master from ##mark## EOF test_expect_failure 'refs are updated even if no commits need to be exported' ' cp tmp-marks /tmp git fast-export --import-marks=tmp-marks \ --export-marks=tmp-marks master | true && git fast-export --import-marks=tmp-marks \ --export-marks=tmp-marks master > actual && mark=$(grep $(git rev-parse master) tmp-marks | cut -f 1 -d " ") sed -i -e "s/##mark##/$mark/" expected && test_cmp expected actual ' --- -- Felipe Contreras -- 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 1/3] t9350: point out that refs are not updated correctly
Felipe Contreras wrote: > All right, so I run this and get this: > > % git fast-export master..master > reset refs/heads/master > from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 > > As an user of fast-export, what do I do with that now? You passed "master.." on the command line, indicating that your repository already has commit 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0. Now you can update the "master" branch to point to that commit, as the fast-export output indicates. Jonathan -- 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: Where should git-prompt.sh be installed?
Would that not give the impression of "git sh-prompt" being a core command? If so, that would be poor, IMHO. When I was investigating this last night, I expected to find it (git-prompt.sh) in contrib, although that doesn't make an enormous amount of sense. Ideally, the full path to wherever it's installed should be mentioned in the bash completion file (which is where I went to look when __git_ps1 stopped working), but that would mean modifying a file from upstream and I'm not sure if that's easy/"the done thing". Danny. On 25 Oct 2012, at 01:51, Jonathan Nieder wrote: > Hi, > > In olden days the admin would copy contrib/completion/git-completion.sh > to > >/etc/bash_completion.d/git > > and mortals could source /etc/bash_completion or > /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among > multiple machines) so that the bash completion and __git_ps1 helpers > could work. > > With Git 1.7.12 __git_ps1 has been split into a separate file, to help > users who only want __git_ps1 to avoid the overhead of loading the > entire completion script (and allow the completion script to be loaded > by bash-completion magic on the fly!). Now the sysadmin should copy > contrib/completion/git-completion.sh to > >/usr/share/bash-completion/completions/git > > and contrib/completion/git-prompt.sh to > >/usr/share/git-core/contrib/?? (somewhere?) > > Mortals source /etc/bash_completion in their ~/.bashrc (possibly > shared among multiple machines) and expect bash completion to work. > For __git_ps1, users should source that ?? path. > > Questions: > > 1) what path is appropriate for ?? above? > 2) is this documented anywhere? > > Possible answers: > > 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses >/usr/share/bash-completion/git-prompt. Maybe others use >some other path. > > 2) The scripts themselves suggest copying to ~/.git-completion.sh >and ~/.git-prompt.sh. > > Proposal: > > 1) /usr/lib/git-core/git-sh-prompt > 2) git-sh-prompt(1) > > Sensible? > > Thanks, > Jonathan -- 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 1/3] t9350: point out that refs are not updated correctly
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
wrote:
> This works just fine. Go ahead, apply my patch, and run it, the second
> branch gets updated.
Yes, but as you said:
> That is already the case, my patch will cause this to generate the same
> output:
> % git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
> Which is still not got, but not catastrophic by any means.
Which is exactly the reason we (Dscho and I during our little
hackathon) went with the approach we did. We considered the approach
you took (if I still had the repository I might even find something
very like your patch in my reflog), but dismissed it for that reason.
By teaching fast-export to properly re-export interesting refs, this
exporting of negated refs does not happen. Additionally, you say it is
not catastrophic, but it _is_, if you run: 'git fast-export ^master
foo', you do not expect master to suddenly show up on the remote side.
I agree that your test more accurately describes what we're testing
(and in fact, it should probably go in the tests for remote helpers).
However, this test points out a shortcoming of fast-export that
prevents us from implementing a cleaner solution to the 'fast-export
push an existing ref' problem.
--
Cheers,
Sverre Rabbelier
--
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 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 8:07 AM, Sverre Rabbelier wrote:
> On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
> wrote:
>> This works just fine. Go ahead, apply my patch, and run it, the second
>> branch gets updated.
>
> Yes, but as you said:
>
>> That is already the case, my patch will cause this to generate the same
>> output:
>> % git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
>> Which is still not got, but not catastrophic by any means.
>
> Which is exactly the reason we (Dscho and I during our little
> hackathon) went with the approach we did. We considered the approach
> you took (if I still had the repository I might even find something
> very like your patch in my reflog), but dismissed it for that reason.
> By teaching fast-export to properly re-export interesting refs, this
> exporting of negated refs does not happen.
Oh really? This is with your patches:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo1
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
This is with mine:
% ./git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
reset refs/heads/foo1
from :21
Now tell me again. What is the benefit of your approach?
> Additionally, you say it is
> not catastrophic, but it _is_, if you run: 'git fast-export ^master
> foo', you do not expect master to suddenly show up on the remote side.
If 'git fast-export ^master foo' is catastrophic, so is 'git
fast-export foo ^master', and that already exports master *today*.
> I agree that your test more accurately describes what we're testing
> (and in fact, it should probably go in the tests for remote helpers).
> However, this test points out a shortcoming of fast-export that
> prevents us from implementing a cleaner solution to the 'fast-export
> push an existing ref' problem.
Which is something few users will notice. What they surely notice is
that there's no remote-hg they can readily use. Nobody expects all
software to be perfect or have all the features from day 1. Something
that just fetches a hg repo is already better than the current
situation: *nothing*.
And BTW, in mercurial a commit can be only on one branch anyway, so
you can't have 'foo' and 'master' both pointing to the same
commit/revision. Sure bookmarks is another story, but again, I don't
think people would prefer remote-hg to stay out because bookmarks
don't work _perfectly_.
Cheers.
--
Felipe Contreras
--
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 1/3] t9350: point out that refs are not updated correctly
On Thu, Oct 25, 2012 at 7:53 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: > >> All right, so I run this and get this: >> >> % git fast-export master..master >> reset refs/heads/master >> from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 >> >> As an user of fast-export, what do I do with that now? > > You passed "master.." on the command line, indicating that your > repository already has commit 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0. No I didn't. Maybe I'm not interested in all the old history and I just want to create a repository from that point forward. For example 'git fast-export v1.5.0..master. I don't want no references to objects I don't have, there's no way I can do anything sensible with that SHA-1. % git fast-export master..master | git --git-dir=/tmp/git/.git fast-import fatal: Not a valid commit: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0 fast-import: dumping crash report to /tmp/git/.git/fast_import_crash_32498 Does it make sense to you that the output of fast-export doesn't work with fast-import? > Now you can update the "master" branch to point to that commit, > as the fast-export output indicates. I don't have that commit, I don't even know what 8c7a786 means. Show me a single remote helper that manually stores SHA-1's and I might believe you, but I doubt that, marks are too convenient. Or show me a script. I doubt there will be any, because otherwise somebody would have pushed for this patch, and there doesn't seem to be too many people. But fine, lets assume it's a valid use-case and people need this... it still has absolutely nothing to do with the original intent of the patch series. The series is in fact doing two things: 1) Use SHA-1's when a mark can't be found 2) Update refs that have been already visited (through marks) These two things are orthogonal to each other, we should have two tests, and in fact, two separate patch series. One will be useful for remote helpers, the other one will be useful to nobody IMO, but that's something that can be discussed there, and I particularly don't care. My test and my patch are good for 2), and so far I haven't seen anybody saying otherwise. Cheers. -- Felipe Contreras -- 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
Who is the 'git' vendor?
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? Regards, Thor Thor Prohaska Test Coordinator - Desktop Anywhere Enterprise Engineering BT, 3/300 Queen St, Brisbane Desk Phone: 07 3362 1809 Mobile: 0419 344 806 This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. -- 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
