* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-24 18:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <CAMP44s1hdZb_7Lv8SEe+MsfC_q-nXsnjJobABFq6eFR_er4TaA@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Felipe Contreras @ 2012-10-24 18:02 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier <srabbelier@gmail.com> 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 <Johannes.Schindelin@gmx.de>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> ---
>
> 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..<sha1>` will
> incorrectly generate a `reset <sha1>` 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..<SHA-1> issues.
Cheers.
--
Felipe Contreras
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-24 17:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-2-git-send-email-srabbelier@gmail.com>
Hi,
Joined late to the party :)
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier <srabbelier@gmail.com> 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 <srabbelier@gmail.com>
> ---
> 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
^ permalink raw reply related
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-10-24 17:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DvNSVSUT_9ym52pVaDSNMk10WfaVGhfgQeC8+SOWSpEw@mail.gmail.com>
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
<pclouds@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz <uri@4refs.com> 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
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-24 17:10 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121024084636.GA23500@sigill.intra.peff.net>
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 = <any CHAR, including bare ; => 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 <krzysiek@podlesie.net>
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 <krzysiek@podlesie.net>
---
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
^ permalink raw reply related
* Re: [PATCH v3 5/6] tests: add remote-hg tests
From: Felipe Contreras @ 2012-10-24 15:47 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Junio C Hamano, Johannes Schindelin, Ilari Liusvaara,
Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <CAGdFq_hhjvysViU+rceOcX7L48BkxUbDzKiyT7LakFqz1ikT8A@mail.gmail.com>
On Sun, Oct 21, 2012 at 11:02 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sun, Oct 21, 2012 at 10:49 AM, Felipe Contreras
> <felipe.contreras@gmail.com> 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
^ permalink raw reply
* [PATCH] configure: fix some output message
From: Stefano Lattarini @ 2012-10-24 15:34 UTC (permalink / raw)
To: git; +Cc: Stefano Lattarini
Before this change, output from ./configure could contain
botched wording like this:
checking Checking for POSIX Threads with '-pthread'... yes
instead of the intended:
checking for POSIX Threads with '-pthread'... yes
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c85888c..ad215cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1024,7 +1024,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
for opt in -mt -pthread -lpthread; do
old_CFLAGS="$CFLAGS"
CFLAGS="$opt $CFLAGS"
- AC_MSG_CHECKING([Checking for POSIX Threads with '$opt'])
+ AC_MSG_CHECKING([for POSIX Threads with '$opt'])
AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
@@ -1044,7 +1044,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
else
old_CFLAGS="$CFLAGS"
CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
- AC_MSG_CHECKING([Checking for POSIX Threads with '$PTHREAD_CFLAGS'])
+ AC_MSG_CHECKING([for POSIX Threads with '$PTHREAD_CFLAGS'])
AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
NO_PTHREADS=
--
1.8.0.rc2.11.gd25c58c
^ permalink raw reply related
* Re: [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2012-10-24 14:29 UTC (permalink / raw)
To: Herman van Rink; +Cc: git list
In-Reply-To: <5082FE13.2000003@initfour.nl>
On Sat, 20 Oct 2012 21:40:03 +0200
Herman van Rink <rink@initfour.nl> 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 <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > 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 <repository>, also
> > mentions a <refspec> 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
^ permalink raw reply
* Re: git commit-tree man page
From: Andreas Schwab @ 2012-10-24 13:59 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9BMndLj_nHW=EQbSS96Gp5+5NA3Vyb0r-EfVd+OPyQhnA@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hello,
>
> the man page of git commit-tree SYNOPSIS is:
>
> git commit-tree <tree> [(-p <parent>)...] < changelog
> git commit-tree [(-p <parent>)...] [(-m <message>)...] [(-F
> <file>)...] <tree>
>
> The second form is incorrect: the <tree> 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 <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git commit-tree man page
From: Angelo Borsotti @ 2012-10-24 12:45 UTC (permalink / raw)
To: git
Hello,
the man page of git commit-tree SYNOPSIS is:
git commit-tree <tree> [(-p <parent>)...] < changelog
git commit-tree [(-p <parent>)...] [(-m <message>)...] [(-F
<file>)...] <tree>
The second form is incorrect: the <tree> must be specified before the options.
E.g.
$ git commit-tree -m B 88f7dbd47
fatal: Not a valid object name -m
$ git commit-tree 88f7dbd47 -m B
2f7619ed932787a128a84c4809d7b72ef38257a5
-Angelo Borsotti
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Catalin Marinas @ 2012-10-24 11:18 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Gleixner, Al Viro, Chris Metcalf, LKML,
linux-arch@vger.kernel.org, Linus Torvalds, git@vger.kernel.org,
Junio C Hamano
In-Reply-To: <20121023212245.GA28828@sigill.intra.peff.net>
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 <comment> 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
^ permalink raw reply
* confused by git diff --exit-code
From: Bogolisk @ 2012-10-24 10:33 UTC (permalink / raw)
To: git
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..0000000
--- 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..0000000
--- a/foo.txt
+++ b/foo.txt
/others/foo$ echo $?
0
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Michael J Gruber @ 2012-10-24 9:46 UTC (permalink / raw)
To: Mat Arge; +Cc: git
In-Reply-To: <1392235.RizYqAYdkC@off17>
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
^ permalink raw reply
* A note from the (interim) maintainer
From: Jeff King @ 2012-10-24 9:01 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-24 8:46 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <1351065815-22416-1-git-send-email-krzysiek@podlesie.net>
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
^ permalink raw reply
* Re: [PATCH 7/9] pretty: support padding placeholders, %< %> and %><
From: Jeff King @ 2012-10-24 8:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1348391433-11300-8-git-send-email-pclouds@gmail.com>
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
^ permalink raw reply
* Re: [PATCH] git-status: show short sequencer state
From: Matthieu Moy @ 2012-10-24 8:15 UTC (permalink / raw)
To: Phil Hord
Cc: phil.hord@gmail.com, Junio C Hamano, konglu@minatec.inpg.fr,
Kong Lucien, git@vger.kernel.org, Duperray Valentin, Jonas Franck,
Nguy Thomas, Nguyen Huynh Khoi Nguyen
In-Reply-To: <5086DBDB.9070606@cisco.com>
Phil Hord <hordp@cisco.com> 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/
^ permalink raw reply
* [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-24 8:03 UTC (permalink / raw)
To: gitster, git; +Cc: Krzysztof Mazur
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 <krzysiek@podlesie.net>
---
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 <<EOF
+Subject: subject goes here
+EOF
+'
+
+test_expect_success $PREREQ 'ASCII subject is not RFC2047 quoted' '
+ clean_fake_sendmail &&
+ echo bogus |
+ git send-email --from=author@example.com --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --8bit-encoding=UTF-8 \
+ email-using-8bit >stdout &&
+ grep "Subject" msgtxt1 >actual &&
+ test_cmp expected actual
+'
+
+test_expect_success $PREREQ 'setup expect' '
cat >content-type-decl <<EOF
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
--
1.8.0.3.gf4c35fc
^ permalink raw reply related
* Re: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
From: Peter Krefting @ 2012-10-24 7:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Jiang Xin
In-Reply-To: <alpine.DEB.2.00.1210200035220.15821@ds9.cixit.se>
> 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/
^ permalink raw reply
* Re: [PATCH] git-submodule: wrap branch option with "<>" in usage strings.
From: Jeff King @ 2012-10-24 7:34 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <6332cbbfccd24f9d1ed37de424372ca354e9a4da.1351026021.git.wking@tremily.us>
On Tue, Oct 23, 2012 at 05:00:21PM -0400, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> Use "-b <branch>" instead of "-b branch". This brings the usage
> strings in line with other options, e.g. "--reference <repository>".
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
Thanks. Looks obviously correct to me.
-Peff
^ permalink raw reply
* Re: Large number of object files
From: Jeff King @ 2012-10-24 7:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Uri Moszkowicz, git
In-Reply-To: <CACsJy8CcMBJLV=urVoWOQABQzQkC6y35spPF+_3fW6dtJjHtvg@mail.gmail.com>
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 <uri@4refs.com> 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
^ permalink raw reply
* [PATCHv2 1/8] t1300: style updates
From: Jeff King @ 2012-10-24 7:07 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <20121024063712.GA17789@sigill.intra.peff.net>
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 <peff@peff.net>
---
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 !for >actual &&
+ test_cmp expect actual
+'
test_expect_success 'ambiguous get' '
test_must_fail git config --get nextsection.nonewline
'
-test_expect_success 'get multivar' \
- 'git config --get-all nextsection.nonewline'
+test_expect_success 'get multivar' '
+ git config --get-all nextsection.nonewline
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -290,8 +308,9 @@ test_expect_success 'correct key' 'git config 123456.a123 987'
test_expect_success 'correct key' 'git config 123456.a123 987'
-test_expect_success 'hierarchical section' \
- 'git config Version.1.2.3eX.Alpha beta'
+test_expect_success 'hierarchical section' '
+ git config Version.1.2.3eX.Alpha beta
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -307,7 +326,9 @@ EOF
Alpha = beta
EOF
-test_expect_success 'hierarchical section value' 'test_cmp expect .git/config'
+test_expect_success 'hierarchical section value' '
+ test_cmp expect .git/config
+'
cat > expect << EOF
beta.noindent=sillyValue
@@ -316,9 +337,10 @@ EOF
version.1.2.3eX.alpha=beta
EOF
-test_expect_success 'working --list' \
- 'git config --list > output && cmp output expect'
-
+test_expect_success 'working --list' '
+ git config --list > output &&
+ test_cmp expect output
+'
cat > expect << EOF
EOF
@@ -332,8 +354,10 @@ EOF
nextsection.nonewline wow2 for me
EOF
-test_expect_success '--get-regexp' \
- 'git config --get-regexp in > output && cmp output expect'
+test_expect_success '--get-regexp' '
+ git config --get-regexp in >output &&
+ test_cmp expect output
+'
cat > expect << EOF
wow2 for me
@@ -353,41 +377,48 @@ echo false > expect
variable =
EOF
-test_expect_success 'get variable with no value' \
- 'git config --get novalue.variable ^$'
+test_expect_success 'get variable with no value' '
+ git config --get novalue.variable ^$
+'
-test_expect_success 'get variable with empty value' \
- 'git config --get emptyvalue.variable ^$'
+test_expect_success 'get variable with empty value' '
+ git config --get emptyvalue.variable ^$
+'
echo novalue.variable > expect
-test_expect_success 'get-regexp variable with no value' \
- 'git config --get-regexp novalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp variable with no value' '
+ git config --get-regexp novalue > output &&
+ test_cmp expect output
+'
echo 'novalue.variable true' > expect
-test_expect_success 'get-regexp --bool variable with no value' \
- 'git config --bool --get-regexp novalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp --bool variable with no value' '
+ git config --bool --get-regexp novalue > output &&
+ test_cmp expect output
+'
echo 'emptyvalue.variable ' > expect
-test_expect_success 'get-regexp variable with empty value' \
- 'git config --get-regexp emptyvalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp variable with empty value' '
+ git config --get-regexp emptyvalue > output &&
+ test_cmp expect output
+'
echo true > expect
-test_expect_success 'get bool variable with no value' \
- 'git config --bool novalue.variable > output &&
- cmp output expect'
+test_expect_success 'get bool variable with no value' '
+ git config --bool novalue.variable > output &&
+ test_cmp expect output
+'
echo false > expect
-test_expect_success 'get bool variable with empty value' \
- 'git config --bool emptyvalue.variable > output &&
- cmp output expect'
+test_expect_success 'get bool variable with empty value' '
+ git config --bool emptyvalue.variable > output &&
+ test_cmp expect output
+'
test_expect_success 'no arguments, but no crash' '
test_must_fail git config >output 2>&1 &&
@@ -427,8 +458,9 @@ test_expect_success 'new variable inserts into proper section' '
test_cmp expect .git/config
'
-test_expect_success 'alternative GIT_CONFIG (non-existing file should fail)' \
- 'test_must_fail git config --file non-existing-config -l'
+test_expect_success 'alternative GIT_CONFIG (non-existing file should fail)' '
+ test_must_fail git config --file non-existing-config -l
+'
cat > other-config << EOF
[ein]
@@ -444,8 +476,10 @@ test_expect_success 'alternative GIT_CONFIG' '
test_cmp expect output
'
-test_expect_success 'alternative GIT_CONFIG (--file)' \
- 'git config --file other-config -l > output && cmp output expect'
+test_expect_success 'alternative GIT_CONFIG (--file)' '
+ git config --file other-config -l > output &&
+ test_cmp expect output
+'
test_expect_success 'refer config from subdirectory' '
mkdir x &&
@@ -489,8 +523,9 @@ EOF
weird
EOF
-test_expect_success "rename section" \
- "git config --rename-section branch.eins branch.zwei"
+test_expect_success 'rename section' '
+ git config --rename-section branch.eins branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -503,17 +538,22 @@ test_expect_success "rename succeeded" "test_cmp expect .git/config"
weird
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
-test_expect_success "rename non-existing section" '
+test_expect_success 'rename non-existing section' '
test_must_fail git config --rename-section \
branch."world domination" branch.drei
'
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
-test_expect_success "rename another section" \
- 'git config --rename-section branch."1 234 blabl/a" branch.drei'
+test_expect_success 'rename another section' '
+ git config --rename-section branch."1 234 blabl/a" branch.drei
+'
cat > expect << EOF
# Hallo
@@ -526,14 +566,17 @@ EOF
weird
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
cat >> .git/config << EOF
[branch "vier"] z = 1
EOF
-test_expect_success "rename a section with a var on the same line" \
- 'git config --rename-section branch.vier branch.zwei'
+test_expect_success 'rename a section with a var on the same line' '
+ git config --rename-section branch.vier branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -548,7 +591,9 @@ EOF
z = 1
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
test_expect_success 'renaming empty section name is rejected' '
test_must_fail git config --rename-section branch.zwei ""
@@ -562,7 +607,9 @@ EOF
[branch "zwei"] a = 1 [branch "vier"]
EOF
-test_expect_success "remove section" "git config --remove-section branch.zwei"
+test_expect_success 'remove section' '
+ git config --remove-section branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -571,8 +618,9 @@ EOF
weird
EOF
-test_expect_success "section was removed properly" \
- "test_cmp expect .git/config"
+test_expect_success 'section was removed properly' '
+ test_cmp expect .git/config
+'
cat > expect << EOF
[gitcvs]
@@ -583,7 +631,6 @@ test_expect_success 'section ending' '
EOF
test_expect_success 'section ending' '
-
rm -f .git/config &&
git config gitcvs.enabled true &&
git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
@@ -593,30 +640,25 @@ test_expect_success 'invalid unit' '
'
test_expect_success numbers '
-
git config kilo.gram 1k &&
git config mega.ton 1m &&
- k=$(git config --int --get kilo.gram) &&
- test z1024 = "z$k" &&
- m=$(git config --int --get mega.ton) &&
- test z1048576 = "z$m"
+ echo 1024 >expect &&
+ echo 1048576 >>expect &&
+ git config --int --get kilo.gram >actual &&
+ git config --int --get mega.ton >>actual &&
+ test_cmp expect actual
'
-cat > expect <<EOF
-fatal: bad config value for 'aninvalid.unit' in .git/config
-EOF
-
test_expect_success 'invalid unit' '
-
git config aninvalid.unit "1auto" &&
- s=$(git config aninvalid.unit) &&
- test "z1auto" = "z$s" &&
- if git config --int --get aninvalid.unit 2>actual
- then
- echo config should have failed
- false
- fi &&
- cmp actual expect
+ echo 1auto >expect &&
+ git config aninvalid.unit >actual &&
+ test_cmp expect actual &&
+ cat > expect <<-\EOF
+ fatal: bad config value for '\''aninvalid.unit'\'' in .git/config
+ EOF
+ test_must_fail git config --int --get aninvalid.unit 2>actual &&
+ test_cmp actual expect
'
cat > expect << EOF
@@ -646,7 +688,7 @@ test_expect_success bool '
git config --bool --get bool.true$i >>result
git config --bool --get bool.false$i >>result
done &&
- cmp expect result'
+ test_cmp expect result'
test_expect_success 'invalid bool (--get)' '
@@ -680,7 +722,7 @@ test_expect_success 'set --bool' '
git config --bool bool.false2 "" &&
git config --bool bool.false3 nO &&
git config --bool bool.false4 FALSE &&
- cmp expect .git/config'
+ test_cmp expect .git/config'
cat > expect <<\EOF
[int]
@@ -695,39 +737,37 @@ cat >expect <<\EOF
git config --int int.val1 01 &&
git config --int int.val2 -1 &&
git config --int int.val3 5m &&
- cmp expect .git/config'
+ test_cmp expect .git/config
+'
-cat >expect <<\EOF
-[bool]
- true1 = true
+test_expect_success 'get --bool-or-int' '
+ cat >.git/config <<-\EOF &&
+ [bool]
+ true1
true2 = true
- false1 = false
- false2 = false
-[int]
+ false = false
+ [int]
int1 = 0
int2 = 1
int3 = -1
-EOF
-
-test_expect_success 'get --bool-or-int' '
- rm -f .git/config &&
- (
- echo "[bool]"
- echo true1
- echo true2 = true
- echo false = false
- echo "[int]"
- echo int1 = 0
- echo int2 = 1
- echo int3 = -1
- ) >>.git/config &&
- test $(git config --bool-or-int bool.true1) = true &&
- test $(git config --bool-or-int bool.true2) = true &&
- test $(git config --bool-or-int bool.false) = false &&
- test $(git config --bool-or-int int.int1) = 0 &&
- test $(git config --bool-or-int int.int2) = 1 &&
- test $(git config --bool-or-int int.int3) = -1
-
+ EOF
+ cat >expect <<-\EOF &&
+ true
+ true
+ false
+ 0
+ 1
+ -1
+ EOF
+ {
+ git config --bool-or-int bool.true1 &&
+ git config --bool-or-int bool.true2 &&
+ git config --bool-or-int bool.false &&
+ git config --bool-or-int int.int1 &&
+ git config --bool-or-int int.int2 &&
+ git config --bool-or-int int.int3
+ } >actual &&
+ test_cmp expect actual
'
cat >expect <<\EOF
@@ -844,7 +884,7 @@ test_expect_success 'value continued on next line' '
test_expect_success 'value continued on next line' '
git config --list > result &&
- cmp result expect
+ test_cmp result expect
'
cat > .git/config <<\EOF
@@ -880,11 +920,12 @@ test_expect_success SYMLINKS 'symlinked configuration' '
test_expect_success 'inner whitespace kept verbatim' '
git config section.val "foo bar" &&
- test "z$(git config section.val)" = "zfoo bar"
+ echo "foo bar" >expect &&
+ git config section.val >actual &&
+ test_cmp expect actual
'
test_expect_success SYMLINKS 'symlinked configuration' '
-
ln -s notyet myconfig &&
GIT_CONFIG=myconfig git config test.frotz nitfol &&
test -h myconfig &&
@@ -893,9 +934,15 @@ test_expect_success SYMLINKS 'symlinked configuration' '
GIT_CONFIG=myconfig git config test.xyzzy rezrov &&
test -h myconfig &&
test -f notyet &&
- test "z$(GIT_CONFIG=notyet git config test.frotz)" = znitfol &&
- test "z$(GIT_CONFIG=notyet git config test.xyzzy)" = zrezrov
-
+ cat >expect <<-\EOF &&
+ nitfol
+ rezrov
+ EOF
+ {
+ GIT_CONFIG=notyet git config test.frotz &&
+ GIT_CONFIG=notyet git config test.xyzzy
+ } >actual &&
+ test_cmp expect actual
'
test_expect_success 'nonexistent configuration' '
@@ -927,12 +974,20 @@ test_expect_success 'git -c "key=value" support' '
git commit -m 'initial commit' &&
git config branch.master.mergeoptions 'echo \"' &&
test_must_fail git merge master
- "
+"
test_expect_success 'git -c "key=value" support' '
- test "z$(git -c core.name=value config core.name)" = zvalue &&
- test "z$(git -c foo.CamelCase=value config foo.camelcase)" = zvalue &&
- test "z$(git -c foo.flag config --bool foo.flag)" = ztrue &&
+ cat >expect <<-\EOF &&
+ value
+ value
+ true
+ EOF
+ {
+ git -c core.name=value config core.name &&
+ git -c foo.CamelCase=value config foo.camelcase &&
+ git -c foo.flag config --bool foo.flag
+ } >actual &&
+ test_cmp expect actual &&
test_must_fail git -c name=value config core.name
'
--
1.8.0.3.g3456896
^ permalink raw reply related
* Re: Large number of object files
From: Nguyen Thai Ngoc Duy @ 2012-10-24 6:59 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5AS1=Cf--0=1Xynxf1J-22fxBq05XjNGMcUep+ndAOO7ig@mail.gmail.com>
On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz <uri@4refs.com> 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.
> 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". You
can also try "git prune" on the existing repo (read its man page
before use).
--
Duy
^ permalink raw reply
* Re: [PATCH 1/8] t1300: style updates
From: Jeff King @ 2012-10-24 6:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <50878BAB.60809@viscovery.net>
On Wed, Oct 24, 2012 at 08:33:15AM +0200, Johannes Sixt wrote:
> Am 10/24/2012 0:35, schrieb Jeff King:
> > -test_expect_success 'non-match value' \
> > - 'test wow = $(git config --get nextsection.nonewline !for)'
> > +test_expect_success 'non-match value' '
> > + test wow = $(git config --get nextsection.nonewline !for)
> > +'
>
> Here's a case you forgot to update to test_cmp.
Thanks. I noticed I left quite a few of those in (the other changes I
did mechanically, but I only fixed up the "test" ones in nearby spots).
> > +test_expect_success 'get-regexp variable with no value' '
> > + git config --get-regexp novalue > output &&
> > + test_cmp expect output'
>
> And while you are here, you might want to remove this extra space. ;)
>
> Otherwise, looks fine.
Thanks, I'll fix up both.
-Peff
^ permalink raw reply
* Re: [PATCH 8/8] git-config: use git_config_with_options
From: Johannes Sixt @ 2012-10-24 6:33 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <20121023224119.GH17392@sigill.intra.peff.net>
All looked sane. Thanks for a pleasant read!
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox