* Re: [PATCH 2/2] pickaxe: use textconv for -S counting
From: Jeff King @ 2012-11-15 1:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Oberndorfer, git
In-Reply-To: <7vk3tpcd0w.fsf@alter.siamese.dyndns.org>
On Tue, Nov 13, 2012 at 03:13:19PM -0800, Junio C Hamano wrote:
> > static int has_changes(struct diff_filepair *p, struct diff_options *o,
> > regex_t *regexp, kwset_t kws)
> > {
> > + struct userdiff_driver *textconv_one = get_textconv(p->one);
> > + struct userdiff_driver *textconv_two = get_textconv(p->two);
> > + mmfile_t mf1, mf2;
> > + int ret;
> > +
> > if (!o->pickaxe[0])
> > return 0;
> >
> > - if (!DIFF_FILE_VALID(p->one)) {
> > - if (!DIFF_FILE_VALID(p->two))
> > - return 0; /* ignore unmerged */
>
> What happened to this part that avoids showing nonsense for unmerged
> paths?
It's moved down. fill_one will return an empty mmfile if
!DIFF_FILE_VALID, so we end up here:
fill_one(p->one, &mf1, &textconv_one);
fill_one(p->two, &mf2, &textconv_two);
if (!mf1.ptr) {
if (!mf2.ptr)
ret = 0; /* ignore unmerged */
Prior to this change, we didn't use fill_one, so we had to check manually.
> > + /*
> > + * If we have an unmodified pair, we know that the count will be the
> > + * same and don't even have to load the blobs. Unless textconv is in
> > + * play, _and_ we are using two different textconv filters (e.g.,
> > + * because a pair is an exact rename with different textconv attributes
> > + * for each side, which might generate different content).
> > + */
> > + if (textconv_one == textconv_two && diff_unmodified_pair(p))
> > + return 0;
>
> I am not sure about this part that cares about the textconv.
>
> Wouldn't the normal "git diff A B" skip the filepair that are
> unmodified in the first place at the object name level without even
> looking at the contents (see e.g. diff_flush_patch())?
Hmph. The point was to find the case when the paths are different (e.g.,
in a rename), and therefore the textconvs might be different. But I
think I missed the fact that diff_unmodified_pair will note the
difference in paths. So just calling diff_unmodified_pair would be
sufficient, as the code prior to my patch does.
I thought the point was an optimization to avoid comparing contains() on
the same data (which we can know will match without looking at it).
Exact renames are the obvious one, but they are not handled here. So I
am not sure of the point (to catch "git diff $blob1 $blob2" when the two
are identical? I am not sure at what layer we cull that from the diff
queue).
So there is room for optimization here on exact renames, but
diff_unmodified_pair is too forgiving of what is interesting (a rename
is interesting to diff_flush_patch, because it wants to mention the
rename, but it is not interesting to pickaxe, because we did not change
the content, and it could be culled here).
I don't know that it is that big a deal in general. Pure renames are
going to be the minority of blobs we look at, so it is probably not even
measurable. You could construct a pathological case (e.g., an otherwise
small repo with a 2G file, rename the 2G file without modification, then
running "git log -Sfoo" will unnecessarily load the giant blob while
examining the rename commit).
> Shouldn't this part of the code emulating that behaviour no matter
> what textconv filter(s) are configured for these paths?
Yeah, I just missed that it is checking the path already. It may still
make sense to tighten the optimization, but that is a separate issue. It
should just check diff_unmodified_pair as before; textconv only matters
if you are trying to optimize out exact renames.
-Peff
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Javier Domingo @ 2012-11-15 1:15 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451m4saVa7-NLbVbXp7q8ca5_0N4FLk3wYaqxLT=AE5frbw@mail.gmail.com>
Hi Andrew,
Doing this would require I got tracked which one comes from which. So
it would imply some logic (and db) over it. With the hardlinking way,
it wouldn't require anything. The idea is that you don't have to do
anything else in the server.
I understand that it would be imposible to do it for windows users
(but using cygwin), but for *nix ones yes...
Javier Domingo
2012/11/15 Andrew Ardill <andrew.ardill@gmail.com>:
> On 15 November 2012 11:40, Javier Domingo <javierdo1@gmail.com> wrote:
>> Hi Andrew,
>>
>> The problem about that, is that if I want to delete the first repo, I
>> will loose objects... Or does that repack also hard-link the objects
>> in other repos? I don't want to accidentally loose data, so it would
>> be nice that althought avoided to repack things, it would also
>> hardlink them.
>
> Hi Javier, check out the section below the one I linked earlier:
>
>> How to stop sharing objects between repositories?
>>
>> To copy the shared objects into the local repository, repack without the -l flag
>>
>> git repack -a
>>
>> Then remove the pointer to the alternate object store
>>
>> rm .git/objects/info/alternates
>>
>> (If the repository is edited between the two steps, it could become corrupted
>> when the alternates file is removed. If you're unsure, you can use git fsck to
>> check for corruption. If things go wrong, you can always recover by replacing
>> the alternates file and starting over).
>
> Regards,
>
> Andrew Ardill
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Andrew Ardill @ 2012-11-15 0:53 UTC (permalink / raw)
To: Javier Domingo; +Cc: git@vger.kernel.org
In-Reply-To: <CALZVap=kOwOpxeu8+_+5uQYZz3GNC8Ep_JeK7WCQHtu+Hn3rUw@mail.gmail.com>
On 15 November 2012 11:40, Javier Domingo <javierdo1@gmail.com> wrote:
> Hi Andrew,
>
> The problem about that, is that if I want to delete the first repo, I
> will loose objects... Or does that repack also hard-link the objects
> in other repos? I don't want to accidentally loose data, so it would
> be nice that althought avoided to repack things, it would also
> hardlink them.
Hi Javier, check out the section below the one I linked earlier:
> How to stop sharing objects between repositories?
>
> To copy the shared objects into the local repository, repack without the -l flag
>
> git repack -a
>
> Then remove the pointer to the alternate object store
>
> rm .git/objects/info/alternates
>
> (If the repository is edited between the two steps, it could become corrupted
> when the alternates file is removed. If you're unsure, you can use git fsck to
> check for corruption. If things go wrong, you can always recover by replacing
> the alternates file and starting over).
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Javier Domingo @ 2012-11-15 0:40 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451nW2esQR8XaAttT3tYJZEw1Nj3OEMgkHsMZrZDxhcRXHw@mail.gmail.com>
Hi Andrew,
The problem about that, is that if I want to delete the first repo, I
will loose objects... Or does that repack also hard-link the objects
in other repos? I don't want to accidentally loose data, so it would
be nice that althought avoided to repack things, it would also
hardlink them.
Javier Domingo
2012/11/15 Andrew Ardill <andrew.ardill@gmail.com>:
> On 15 November 2012 10:42, Javier Domingo <javierdo1@gmail.com> wrote:
>> Hi,
>>
>> I have come up with this while doing some local forks for work.
>> Currently, when you clone a repo using a path (not file:/// protocol)
>> you get all the common objects linked.
>>
>> But as you work, each one will continue growing on its way, although
>> they may have common objects.
>>
>> Is there any way to avoid this? I mean, can something be done in git,
>> that it checks for (when pulling) the same objects in the other forks?
>
> Have you seen alternates? From [1]:
>
>> How to share objects between existing repositories?
>> ---------------------------------------------------------------------------
>>
>> Do
>>
>> echo "/source/git/project/.git/objects/" > .git/objects/info/alternates
>>
>> and then follow it up with
>>
>> git repack -a -d -l
>>
>> where the '-l' means that it will only put local objects in the pack-file
>> (strictly speaking, it will put any loose objects from the alternate tree
>> too, so you'll have a fully packed archive, but it won't duplicate objects
>> that are already packed in the alternate tree).
>
> [1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F
>
>
> Regards,
>
> Andrew Ardill
^ permalink raw reply
* [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Jeff King @ 2012-11-15 0:36 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
If git-send-email is configured with sendemail.from, we will
not prompt the user for the "From" address of the emails.
If it is not configured, we prompt the user, but provide the
repo author or committer as a default. Even though we
probably have a sensible value for the default, the prompt
is a safety check in case git generated an incorrect
implicit ident string.
Now that Git.pm will tell us whether the ident is implicit or
explicit, we can stop prompting in the explicit case, saving
most users from having to see the prompt at all.
Signed-off-by: Jeff King <peff@peff.net>
---
git-send-email.perl | 22 +++++++++++++---------
t/t9001-send-email.sh | 36 ++++++++++++++++++++++++++++++++++--
2 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..0c49b32 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -436,9 +436,8 @@ if (0) {
}
}
-my ($repoauthor, $repocommitter);
-($repoauthor) = Git::ident_person(@repo, 'author');
-($repocommitter) = Git::ident_person(@repo, 'committer');
+my ($repoauthor, $author_explicit) = Git::ident_person(@repo, 'author');
+my ($repocommitter, $committer_explicit) = Git::ident_person(@repo, 'committer');
# Verify the user input
@@ -755,12 +754,17 @@ if (!$force) {
my $prompting = 0;
if (!defined $sender) {
- $sender = $repoauthor || $repocommitter || '';
- $sender = ask("Who should the emails appear to be from? [$sender] ",
- default => $sender,
- valid_re => qr/\@.*\./, confirm_only => 1);
- print "Emails will be sent from: ", $sender, "\n";
- $prompting++;
+ ($sender, my $explicit) =
+ defined $repoauthor ? ($repoauthor, $author_explicit) :
+ defined $repocommitter ? ($repocommitter, $committer_explicit) :
+ ('', 0);
+ if (!$explicit) {
+ $sender = ask("Who should the emails appear to be from? [$sender] ",
+ default => $sender,
+ valid_re => qr/\@.*\./, confirm_only => 1);
+ print "Emails will be sent from: ", $sender, "\n";
+ $prompting++;
+ }
}
if (!@initial_to && !defined $to_cmd) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 6c6af7d..0fe0b8e 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -191,15 +191,47 @@ test_expect_success $PREREQ 'Show all headers' '
test_expect_success $PREREQ 'Prompting works' '
clean_fake_sendmail &&
- (echo "Example <from@example.com>"
- echo "to@example.com"
+ (echo "to@example.com"
echo ""
) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
2>errors &&
+ grep "^From: A U Thor <author@example.com>\$" msgtxt1 &&
+ grep "^To: to@example.com\$" msgtxt1
+'
+
+test_expect_success $PREREQ,AUTOIDENT 'implicit ident prompts for sender' '
+ clean_fake_sendmail &&
+ (echo "Example <from@example.com>" &&
+ echo "to@example.com" &&
+ echo ""
+ ) |
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches \
+ 2>errors &&
grep "^From: Example <from@example.com>\$" msgtxt1 &&
grep "^To: to@example.com\$" msgtxt1
+ )
+'
+
+test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
+ clean_fake_sendmail &&
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
+ test_must_fail git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches </dev/null 2>errors.out &&
+ test_i18ngrep "tell me who you are" errors.out
+ )
'
test_expect_success $PREREQ 'tocmd works' '
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 7/8] Git.pm: teach "ident" to query explicitness
From: Jeff King @ 2012-11-15 0:36 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
"git var" recently learned to report on whether an ident we
fetch from it was configured explicitly or implicitly. Let's
make that information available to callers of the ident
function.
Because evaluating "ident" in an array versus scalar context
already has a meaning, we cannot return our extra value in a
backwards compatible way. Instead, we require the caller to
add an extra "explicit" flag to request the information.
The ident_person function, on the other hand, always returns
a scalar, so we are free to overload it in an array context.
Signed-off-by: Jeff King <peff@peff.net>
---
perl/Git.pm | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 497f420..28075a9 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -737,7 +737,7 @@ sub remote_refs {
}
-=item ident ( TYPE | IDENTSTR )
+=item ident ( TYPE | IDENTSTR [, options] )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
@@ -750,8 +750,16 @@ and either returns it as a scalar string or as an array with the fields parsed.
Alternatively, it can take a prepared ident string (e.g. from the commit
object) and just parse it.
+If the C<explicit> option is set to 1, we are in an array context, and we are
+using C<git var> to lookup the ident, the returned array will contain an
+additional boolean element specifying whether the ident was configured
+explicitly by the user. See the description of GIT_*_EXPLICIT in git-var(1) for
+details.
+
C<ident_person> returns the person part of the ident - name and email;
it can take the same arguments as C<ident> or the array returned by C<ident>.
+In an array context, C<ident_person> returns both the person string and the
+C<explicit> boolean.
The synopsis is like:
@@ -763,17 +771,22 @@ The synopsis is like:
=cut
sub ident {
- my ($self, $type) = _maybe_self(@_);
- my $identstr;
+ my ($self, $type, %options) = _maybe_self(@_);
+ my ($identstr, $explicit);
if (lc $type eq lc 'committer' or lc $type eq lc 'author') {
- my @cmd = ('var', 'GIT_'.uc($type).'_IDENT');
+ my $uc = uc($type);
+ my @cmd = ('var', "GIT_${uc}_IDENT", "GIT_${uc}_EXPLICIT");
unshift @cmd, $self if $self;
- $identstr = command_oneline(@cmd);
+ ($identstr, $explicit) = command(@cmd);
} else {
$identstr = $type;
}
if (wantarray) {
- return $identstr =~ /^(.*) <(.*)> (\d+ [+-]\d{4})$/;
+ my @ret = $identstr =~ /^(.*) <(.*)> (\d+ [+-]\d{4})$/;
+ if ($options{explicit} && defined $explicit) {
+ push @ret, $explicit;
+ }
+ return @ret;
} else {
return $identstr;
}
@@ -781,8 +794,11 @@ sub ident {
sub ident_person {
my ($self, @ident) = _maybe_self(@_);
- $#ident == 0 and @ident = $self ? $self->ident($ident[0]) : ident($ident[0]);
- return "$ident[0] <$ident[1]>";
+ $#ident == 0 and @ident = $self ?
+ $self->ident($ident[0], explicit => 1) :
+ ident($ident[0], explicit => 1);
+ my $ret = "$ident[0] <$ident[1]>";
+ return wantarray ? ($ret, @ident[3]) : $ret;
}
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 6/8] var: provide explicit/implicit ident information
From: Jeff King @ 2012-11-15 0:35 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
Internally, we keep track of whether the author or committer
ident information was provided by the user, or whether it
was implicitly determined by the system. However, there is
currently no way for external programs or scripts to get
this information without re-implementing the ident logic
themselves. Let's provide a way for them to do so.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-var.txt | 12 ++++++++++++
builtin/var.c | 27 +++++++++++++++++++++++++++
t/t0007-git-var.sh | 36 ++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 53abba5..bb2997d 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -39,9 +39,21 @@ VARIABLES
GIT_AUTHOR_IDENT::
The author of a piece of code.
+GIT_AUTHOR_EXPLICIT::
+ Outputs "1" if the author identity was provided explicitly by the
+ user, or "0" if it was determined implicitly from the system.
+ Identity is considered explicit if it comes from one of git's config
+ file (i.e., via the `user.*` variables), from the `$GIT_AUTHOR_*`
+ environment variables, or from the `$EMAIL` environment variable. It
+ is considered implicit if it was generated from system variables
+ like the username and hostname.
+
GIT_COMMITTER_IDENT::
The person who put a piece of code into git.
+GIT_COMMITTER_EXPLICIT::
+ Like GIT_AUTHOR_EXPLICIT, but for the committer ident.
+
GIT_EDITOR::
Text editor for use by git commands. The value is meant to be
interpreted by the shell when it is used. Examples: `~/bin/vi`,
diff --git a/builtin/var.c b/builtin/var.c
index 49ab300..9503df9 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -26,13 +26,40 @@ static const char *pager(int flag)
return pgm;
}
+static const char *explicit_ident(const char * (*get_ident)(int),
+ int (*check_ident)(void))
+{
+ /*
+ * Prime the "explicit" flag by getting the identity.
+ * We do not want to be strict here, because we would not want
+ * to die on bogus implicit values, but instead just report that they
+ * are not explicit.
+ */
+ get_ident(0);
+ return check_ident() ? "1" : "0";
+}
+
+static const char *committer_explicit(int flag)
+{
+ return explicit_ident(git_committer_info,
+ committer_ident_sufficiently_given);
+}
+
+static const char *author_explicit(int flag)
+{
+ return explicit_ident(git_author_info,
+ author_ident_sufficiently_given);
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
};
static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
+ { "GIT_COMMITTER_EXPLICIT", committer_explicit },
{ "GIT_AUTHOR_IDENT", git_author_info },
+ { "GIT_AUTHOR_EXPLICIT", author_explicit },
{ "GIT_EDITOR", editor },
{ "GIT_PAGER", pager },
{ "", NULL },
diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
index ec5d946..47907de 100755
--- a/t/t0007-git-var.sh
+++ b/t/t0007-git-var.sh
@@ -47,4 +47,40 @@ test_expect_success 'git var can show multiple values' '
test_cmp expect actual
'
+for type in AUTHOR COMMITTER; do
+ test_expect_success "$type ident can detect implicit values" "
+ echo 0 >expect &&
+ (
+ sane_unset GIT_${type}_NAME &&
+ sane_unset GIT_${type}_EMAIL &&
+ sane_unset EMAIL &&
+ git var GIT_${type}_EXPLICIT >actual
+ ) &&
+ test_cmp expect actual
+ "
+
+ test_expect_success "$type ident is explicit via environment" "
+ echo 1 >expect &&
+ (
+ GIT_${type}_NAME='A Name' &&
+ export GIT_${type}_NAME &&
+ GIT_${type}_EMAIL='name@example.com' &&
+ export GIT_${type}_EMAIL &&
+ git var GIT_${type}_EXPLICIT >actual
+ ) &&
+ test_cmp expect actual
+ "
+
+ test_expect_success "$type ident is explicit via config" "
+ echo 1 >expect &&
+ test_config user.name 'A Name' &&
+ test_config user.email 'name@example.com' &&
+ (
+ sane_unset GIT_${type}_NAME &&
+ sane_unset GIT_${type}_EMAIL &&
+ git var GIT_${type}_EXPLICIT >actual
+ )
+ "
+done
+
test_done
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 5/8] var: accept multiple variables on the command line
From: Jeff King @ 2012-11-15 0:35 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
Git-var currently only accepts a single value to print. This
is inefficient if the caller is interested in finding
multiple values, as they must invoke git-var multiple times.
This patch lets callers specify multiple variables, and
prints one per line.
While we're in the area, let's add some basic tests for "git
var", which until now was largely untested (and of course a
test for multiple values on top).
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-var.txt | 9 +++++++--
builtin/var.c | 17 +++++++++-------
t/t0007-git-var.sh | 50 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 67 insertions(+), 9 deletions(-)
create mode 100755 t/t0007-git-var.sh
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 67edf58..53abba5 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -9,11 +9,16 @@ git-var - Show a git logical variable
SYNOPSIS
--------
[verse]
-'git var' ( -l | <variable> )
+'git var' ( -l | <variable>... )
DESCRIPTION
-----------
-Prints a git logical variable.
+Prints one or more git logical variables, separated by newlines.
+
+Note that some variables may contain newlines themselves (e.g.,
+`GIT_EDITOR`), and it is therefore possible to receive ambiguous output
+when requesting multiple variables. This can be mitigated by putting any
+such variables at the end of the list.
OPTIONS
-------
diff --git a/builtin/var.c b/builtin/var.c
index aedbb53..49ab300 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -5,7 +5,7 @@
*/
#include "builtin.h"
-static const char var_usage[] = "git var (-l | <variable>)";
+static const char var_usage[] = "git var (-l | <variable>...)";
static const char *editor(int flag)
{
@@ -73,21 +73,24 @@ static int show_config(const char *var, const char *value, void *cb)
int cmd_var(int argc, const char **argv, const char *prefix)
{
- const char *val = NULL;
- if (argc != 2)
+ if (argc < 2)
usage(var_usage);
if (strcmp(argv[1], "-l") == 0) {
+ if (argc > 2)
+ usage(var_usage);
git_config(show_config, NULL);
list_vars();
return 0;
}
git_config(git_default_config, NULL);
- val = read_var(argv[1]);
- if (!val)
- usage(var_usage);
- printf("%s\n", val);
+ while (*++argv) {
+ const char *val = read_var(*argv);
+ if (!val)
+ usage(var_usage);
+ printf("%s\n", val);
+ }
return 0;
}
diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
new file mode 100755
index 0000000..ec5d946
--- /dev/null
+++ b/t/t0007-git-var.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+test_description='basic sanity checks for git var'
+. ./test-lib.sh
+
+test_expect_success 'get GIT_AUTHOR_IDENT' '
+ test_tick &&
+ echo "$GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ git var GIT_AUTHOR_IDENT >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'get GIT_COMMITTER_IDENT' '
+ test_tick &&
+ echo "$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE" >expect &&
+ git var GIT_COMMITTER_IDENT >actual &&
+ test_cmp expect actual
+'
+
+# For git var -l, we check only a representative variable;
+# testing the whole output would make our test too brittle with
+# respect to unrelated changes in the test suite's environment.
+test_expect_success 'git var -l lists variables' '
+ git var -l >actual &&
+ echo "$GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ sed -n s/GIT_AUTHOR_IDENT=//p <actual >actual.author &&
+ test_cmp expect actual.author
+'
+
+test_expect_success 'git var -l lists config' '
+ git var -l >actual &&
+ echo false >expect &&
+ sed -n s/core\\.bare=//p <actual >actual.bare &&
+ test_cmp expect actual.bare
+'
+
+test_expect_success 'listing and asking for variables are exclusive' '
+ test_must_fail git var -l GIT_COMMITTER_IDENT
+'
+
+test_expect_success 'git var can show multiple values' '
+ cat >expect <<-EOF &&
+ $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE
+ $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ EOF
+ git var GIT_AUTHOR_IDENT GIT_COMMITTER_IDENT >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 4/8] ident: keep separate "explicit" flags for author and committer
From: Jeff King @ 2012-11-15 0:34 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
We keep track of whether the user ident was given to us
explicitly, or if we guessed at it from system parameters
like username and hostname. However, we kept only a single
variable. This covers the common cases (because the author
and committer will usually come from the same explicit
source), but can miss two cases:
1. GIT_COMMITTER_* is set explicitly, but we fallback for
GIT_AUTHOR. We claim the ident is explicit, even though
the author is not.
2. GIT_AUTHOR_* is set and we ask for author ident, but
not committer ident. We will claim the ident is
implicit, even though it is explicit.
This patch uses two variables instead of one, updates both
when we set the "fallback" values, and updates them
individually when we read from the environment.
Rather than keep user_ident_sufficiently_given as a
compatibility wrapper, we update the only two callers to
check the committer_ident, which matches their intent and
what was happening already.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/commit.c | 4 ++--
cache.h | 3 ++-
ident.c | 32 +++++++++++++++++++++++++-------
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..d6dd3df 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -755,7 +755,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
ident_shown++ ? "" : "\n",
author_ident->buf);
- if (!user_ident_sufficiently_given())
+ if (!committer_ident_sufficiently_given())
status_printf_ln(s, GIT_COLOR_NORMAL,
_("%s"
"Committer: %s"),
@@ -1265,7 +1265,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1,
strbuf_addstr(&format, "\n Author: ");
strbuf_addbuf_percentquote(&format, &author_ident);
}
- if (!user_ident_sufficiently_given()) {
+ if (!committer_ident_sufficiently_given()) {
strbuf_addstr(&format, "\n Committer: ");
strbuf_addbuf_percentquote(&format, &committer_ident);
if (advice_implicit_identity) {
diff --git a/cache.h b/cache.h
index 50d9eea..18fdd18 100644
--- a/cache.h
+++ b/cache.h
@@ -1149,7 +1149,8 @@ struct config_include_data {
#define CONFIG_INCLUDE_INIT { 0 }
extern int git_config_include(const char *name, const char *value, void *data);
-extern int user_ident_sufficiently_given(void);
+extern int committer_ident_sufficiently_given(void);
+extern int author_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
diff --git a/ident.c b/ident.c
index 733d69d..ac9672f 100644
--- a/ident.c
+++ b/ident.c
@@ -14,7 +14,8 @@ static char git_default_date[50];
#define IDENT_NAME_GIVEN 01
#define IDENT_MAIL_GIVEN 02
#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
-static int user_ident_explicitly_given;
+static int committer_ident_explicitly_given;
+static int author_ident_explicitly_given;
#ifdef NO_GECOS_IN_PWENT
#define get_gecos(ignored) "&"
@@ -113,7 +114,8 @@ const char *ident_default_email(void)
if (email && email[0]) {
strbuf_addstr(&git_default_email, email);
- user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ committer_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ author_ident_explicitly_given |= IDENT_MAIL_GIVEN;
} else
copy_email(xgetpwuid_self(), &git_default_email);
strbuf_trim(&git_default_email);
@@ -331,6 +333,10 @@ const char *fmt_name(const char *name, const char *email)
const char *git_author_info(int flag)
{
+ if (getenv("GIT_AUTHOR_NAME"))
+ author_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ if (getenv("GIT_AUTHOR_EMAIL"))
+ author_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return fmt_ident(getenv("GIT_AUTHOR_NAME"),
getenv("GIT_AUTHOR_EMAIL"),
getenv("GIT_AUTHOR_DATE"),
@@ -340,16 +346,16 @@ const char *git_author_info(int flag)
const char *git_committer_info(int flag)
{
if (getenv("GIT_COMMITTER_NAME"))
- user_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ committer_ident_explicitly_given |= IDENT_NAME_GIVEN;
if (getenv("GIT_COMMITTER_EMAIL"))
- user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ committer_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
flag);
}
-int user_ident_sufficiently_given(void)
+static int ident_is_sufficient(int user_ident_explicitly_given)
{
#ifndef WINDOWS
return (user_ident_explicitly_given & IDENT_MAIL_GIVEN);
@@ -358,6 +364,16 @@ int user_ident_sufficiently_given(void)
#endif
}
+int committer_ident_sufficiently_given(void)
+{
+ return ident_is_sufficient(committer_ident_explicitly_given);
+}
+
+int author_ident_sufficiently_given(void)
+{
+ return ident_is_sufficient(author_ident_explicitly_given);
+}
+
int git_ident_config(const char *var, const char *value, void *data)
{
if (!strcmp(var, "user.name")) {
@@ -365,7 +381,8 @@ int git_ident_config(const char *var, const char *value, void *data)
return config_error_nonbool(var);
strbuf_reset(&git_default_name);
strbuf_addstr(&git_default_name, value);
- user_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ committer_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ author_ident_explicitly_given |= IDENT_NAME_GIVEN;
return 0;
}
@@ -374,7 +391,8 @@ int git_ident_config(const char *var, const char *value, void *data)
return config_error_nonbool(var);
strbuf_reset(&git_default_email);
strbuf_addstr(&git_default_email, value);
- user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ committer_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ author_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return 0;
}
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 3/8] ident: make user_ident_explicitly_given static
From: Jeff King @ 2012-11-15 0:34 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given"
was introduced as a global for communication between config,
ident, and builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07)
readers switched to using the common wrapper
user_ident_sufficiently_given(). After v1.7.11-rc1~15^2~18
(2012-05-21), the var is only written in ident.c.
Now we can make it static, which will enable further
refactoring without worrying about upsetting other code.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
---
cache.h | 4 ----
ident.c | 6 +++++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index dbd8018..50d9eea 100644
--- a/cache.h
+++ b/cache.h
@@ -1149,10 +1149,6 @@ struct config_include_data {
#define CONFIG_INCLUDE_INIT { 0 }
extern int git_config_include(const char *name, const char *value, void *data);
-#define IDENT_NAME_GIVEN 01
-#define IDENT_MAIL_GIVEN 02
-#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
-extern int user_ident_explicitly_given;
extern int user_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
diff --git a/ident.c b/ident.c
index a4bf206..733d69d 100644
--- a/ident.c
+++ b/ident.c
@@ -10,7 +10,11 @@
static struct strbuf git_default_name = STRBUF_INIT;
static struct strbuf git_default_email = STRBUF_INIT;
static char git_default_date[50];
-int user_ident_explicitly_given;
+
+#define IDENT_NAME_GIVEN 01
+#define IDENT_MAIL_GIVEN 02
+#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
+static int user_ident_explicitly_given;
#ifdef NO_GECOS_IN_PWENT
#define get_gecos(ignored) "&"
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 2/8] t7502: factor out autoident prerequisite
From: Jeff King @ 2012-11-15 0:33 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
t7502 checks the behavior of commit when we can and cannot
determine a valid committer ident. Let's move that into
test-lib as a lazy prerequisite so other scripts can use it.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7502-commit.sh | 12 +-----------
t/test-lib.sh | 6 ++++++
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index deb187e..1a5cb69 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -243,16 +243,6 @@ test_expect_success 'message shows author when it is not equal to committer' '
.git/COMMIT_EDITMSG
'
-test_expect_success 'setup auto-ident prerequisite' '
- if (sane_unset GIT_COMMITTER_EMAIL &&
- sane_unset GIT_COMMITTER_NAME &&
- git var GIT_COMMITTER_IDENT); then
- test_set_prereq AUTOIDENT
- else
- test_set_prereq NOAUTOIDENT
- fi
-'
-
test_expect_success AUTOIDENT 'message shows committer when it is automatic' '
echo >>negative &&
@@ -271,7 +261,7 @@ echo editor started > "$(pwd)/.git/result"
exit 0
EOF
-test_expect_success NOAUTOIDENT 'do not fire editor when committer is bogus' '
+test_expect_success !AUTOIDENT 'do not fire editor when committer is bogus' '
>.git/result
>expect &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 489bc80..0334a9e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -738,6 +738,12 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
esac
'
+test_lazy_prereq AUTOIDENT '
+ sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ git var GIT_AUTHOR_IDENT
+'
+
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
test -w / || test_set_prereq SANITY
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 1/8] test-lib: allow negation of prerequisites
From: Jeff King @ 2012-11-15 0:33 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121115003029.GA17550@sigill.intra.peff.net>
You can set and test a prerequisite like this:
test_set_prereq FOO
test_have_prereq FOO && echo yes
You can negate the test in the shell like this:
! test_have_prereq && echo no
However, when you are using the automatic prerequisite
checking in test_expect_*, there is no opportunity to use
the shell negation. This patch introduces the syntax "!FOO"
to indicate that the test should only run if a prerequisite
is not meant.
One alternative is to set an explicit negative prerequisite,
like:
if system_has_foo; then
test_set_prereq FOO
else
test_set_prereq NO_FOO
fi
However, this doesn't work for lazy prerequisites, which
associate a single test with a single name. We could teach
the lazy prereq evaluator to set both forms, but the code
change ends up quite similar to this one (because we still
need to convert NO_FOO into FOO to find the correct lazy
script).
Signed-off-by: Jeff King <peff@peff.net>
---
I chose "!" as the negation prefix because it will never conflict with
another prerequisite. But we could also use "NO_" if that's more
aesthetically pleasing. I don't have a strong preference.
t/t0000-basic.sh | 32 ++++++++++++++++++++++++++++++++
t/test-lib-functions.sh | 21 ++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 08677df..562cf41 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -115,6 +115,38 @@ then
exit 1
fi
+test_lazy_prereq LAZY_TRUE true
+havetrue=no
+test_expect_success LAZY_TRUE 'test runs if lazy prereq is satisfied' '
+ havetrue=yes
+'
+donthavetrue=yes
+test_expect_success !LAZY_TRUE 'missing lazy prereqs skip tests' '
+ donthavetrue=no
+'
+
+if test "$havetrue$donthavetrue" != yesyes
+then
+ say 'bug in test framework: lazy prerequisites do not work'
+ exit 1
+fi
+
+test_lazy_prereq LAZY_FALSE false
+nothavefalse=no
+test_expect_success !LAZY_FALSE 'negative lazy prereqs checked' '
+ nothavefalse=yes
+'
+havefalse=yes
+test_expect_success LAZY_FALSE 'missing negative lazy prereqs will skip' '
+ havefalse=no
+'
+
+if test "$nothavefalse$havefalse" != yesyes
+then
+ say 'bug in test framework: negative lazy prerequisites do not work'
+ exit 1
+fi
+
clean=no
test_expect_success 'tests clean up after themselves' '
test_when_finished clean=yes
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 8889ba5..22a4f8f 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -275,6 +275,15 @@ test_have_prereq () {
for prerequisite
do
+ case "$prerequisite" in
+ !*)
+ negative_prereq=t
+ prerequisite=${prerequisite#!}
+ ;;
+ *)
+ negative_prereq=
+ esac
+
case " $lazily_tested_prereq " in
*" $prerequisite "*)
;;
@@ -294,10 +303,20 @@ test_have_prereq () {
total_prereq=$(($total_prereq + 1))
case "$satisfied_prereq" in
*" $prerequisite "*)
+ satisfied_this_prereq=t
+ ;;
+ *)
+ satisfied_this_prereq=
+ esac
+
+ case "$satisfied_this_prereq,$negative_prereq" in
+ t,|,t)
ok_prereq=$(($ok_prereq + 1))
;;
*)
- # Keep a list of missing prerequisites
+ # Keep a list of missing prerequisites; restore
+ # the negative marker if necessary.
+ prerequisite=${negative_prereq:+!}$prerequisite
if test -z "$missing_prereq"
then
missing_prereq=$prerequisite
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* [PATCHv2 0/8] loosening "sender" prompt in send-email
From: Jeff King @ 2012-11-15 0:30 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <20121113164845.GD20361@sigill.intra.peff.net>
On Tue, Nov 13, 2012 at 11:48:45AM -0500, Jeff King wrote:
> [1/6]: ident: make user_ident_explicitly_given private
> [2/6]: ident: keep separate "explicit" flags for author and committer
> [3/6]: var: accept multiple variables on the command line
> [4/6]: var: provide explicit/implicit ident information
> [5/6]: Git.pm: teach "ident" to query explicitness
> [6/6]: send-email: do not prompt for explicit repo ident
Here is a re-roll of the series based on comments from Jonathan (changes
from the first version noted below):
[1/8]: test-lib: allow negation of prerequisites
[2/8]: t7502: factor out autoident prerequisite
These two are new, and allow us to use the same prereq from t7502 in
t9001.
[3/8]: ident: make user_ident_explicitly_given static
Expanded the commit message to explain history of the variable.
[4/8]: ident: keep separate "explicit" flags for author and committer
Same as before.
[5/8]: var: accept multiple variables on the command line
- Expanded tests to include "git var -l"
- Use $GIT_* variables to create test "expect" files, which should make
them less brittle.
- Fixed "git var -l foo" to print usage instead of ignoring foo (i.e.,
keeping the behavior the same).
- Update usage message to match new feature.
[6/8]: var: provide explicit/implicit ident information
Updated documentation to describe what "explicit" means. No functional
changes.
[7/8]: Git.pm: teach "ident" to query explicitness
Improved Git.pm documentation. No functional changes.
[8/8]: send-email: do not prompt for explicit repo ident
Test the implicit ident case, both when we have implicit ident and when
we don't. No changes to send-email.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Junio C Hamano @ 2012-11-15 0:19 UTC (permalink / raw)
To: Jeff King; +Cc: Torsten Bögershausen, Mark Levedahl, git
In-Reply-To: <20121115001635.GA17370@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:
>
>> >>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
>> >>>> - Update cygwin.c for new mingw-64 win32 api headers
>> >>>>
>> >>>> Make git work on newer cygwin.
>> >>>>
>> >>>> Will merge to 'next'.
>
> I'm cc-ing Junio in case he missed the discussion; my original plan had
> been to move this topic right to 'next' to get exposure from other
> cygwin people. But it seems we have already got that, and it might need
> re-rolling, so it probably makes sense to hold back until the discussion
> reaches a conclusion.
Thanks for a reminder; that is what I did.
^ permalink raw reply
* Re: Local clones aka forks disk size optimization
From: Andrew Ardill @ 2012-11-15 0:18 UTC (permalink / raw)
To: Javier Domingo; +Cc: git@vger.kernel.org
In-Reply-To: <CALZVapmO61d8yXfXXGx6Qc444ka+8n7HabuNRt0rJdE5qy_7aQ@mail.gmail.com>
On 15 November 2012 10:42, Javier Domingo <javierdo1@gmail.com> wrote:
> Hi,
>
> I have come up with this while doing some local forks for work.
> Currently, when you clone a repo using a path (not file:/// protocol)
> you get all the common objects linked.
>
> But as you work, each one will continue growing on its way, although
> they may have common objects.
>
> Is there any way to avoid this? I mean, can something be done in git,
> that it checks for (when pulling) the same objects in the other forks?
Have you seen alternates? From [1]:
> How to share objects between existing repositories?
> ---------------------------------------------------------------------------
>
> Do
>
> echo "/source/git/project/.git/objects/" > .git/objects/info/alternates
>
> and then follow it up with
>
> git repack -a -d -l
>
> where the '-l' means that it will only put local objects in the pack-file
> (strictly speaking, it will put any loose objects from the alternate tree
> too, so you'll have a fully packed archive, but it won't duplicate objects
> that are already packed in the alternate tree).
[1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F
Regards,
Andrew Ardill
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Jeff King @ 2012-11-15 0:16 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, Mark Levedahl, git
In-Reply-To: <50A40978.2060504@web.de>
On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:
> >>>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
> >>>> - Update cygwin.c for new mingw-64 win32 api headers
> >>>>
> >>>> Make git work on newer cygwin.
> >>>>
> >>>> Will merge to 'next'.
I'm cc-ing Junio in case he missed the discussion; my original plan had
been to move this topic right to 'next' to get exposure from other
cygwin people. But it seems we have already got that, and it might need
re-rolling, so it probably makes sense to hold back until the discussion
reaches a conclusion.
> There are a couple of things which we may want consider:
> a) the name V15_MINGW_HEADERS:
> It indicates that this is true for Version 1.5 (of what?)
> If I assume Cygwin version 1.5 , then this name is confusing.
> Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5
> A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic.
Regardless of flipping the logic, I agree that having CYGWIN in the name
makes a lot of sense.
> b) Autodetection:
> (Just loud thinking), running
> $grep mingw /usr/include/w32api/winsock2.h
> * This file is part of the mingw-w64 runtime package.
> #include <_mingw_unicode.h>
>
> on cygwin 1.7.17 indicates that we can use grep in the Makefile to
> autodetect the "mingw headers"
Hmm. Can we rely on the /usr/include bit, though?
I assume a test-compile would be sufficient, but currently we do not do
anything more magic than "uname" in the Makefile itself to determine
defaults. Maybe it would be better to do the detection in the configure
script? And then eventually flip the default in the Makefile once
sufficient time has passed for most people to want the new format (which
would not be necessary for people using autoconf, but would help people
who do not).
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-15 0:09 UTC (permalink / raw)
To: Angelo Borsotti
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <7vmwykay4n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Addendum.
> In any case, I thought this series was about users who run "push"
> voluntarily stopping themselves from pushing updates to tags that
> may happen to fast-forward, so if we were to go with the
> configuration route, the suggestion would be more like
>
> [push]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> or perhaps
>
> [remote "origin"]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> if we want to configure it per-remote, to specify that you would
> need to say "--force" to update the refs in the listed hierarchies.
>
> Then your patch series could become just the matter of declaring
> that the value of push.updateNeedsForce, when unspecified, defaults
> to "refs/tags/".
The above is not a "you should do it this way" suggestion, by the
way.
I was just explaining what I meant by "it may be a good feature, but
may not necessarily be limited to refs/tags" in my earlier message
in a different way "... and a possible design that lifts the
limitation may go like this".
I am *not* convinced that the "refs/tags/ is the only special
hierarchy whose contents should not move" is a bad limitation we
should avoid, but if it indeed is a bad limitation, the above is one
possible way to think about avoiding it.
Thanks.
^ permalink raw reply
* Re: [PATCH] send-email: add proper default sender
From: Jeff King @ 2012-11-15 0:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Thomas Rast, Junio C Hamano, Jonathan Nieder
In-Reply-To: <CAMP44s3sBj0iYsCLUpiouUB8PXRwLORDEyD_+dWKrSsMP+TOaw@mail.gmail.com>
On Tue, Nov 13, 2012 at 09:35:18PM +0100, Felipe Contreras wrote:
> > Yes, dying would be a regression, in that you would have to configure
> > your name via the environment and re-run rather than type it at the
> > prompt. You raise a good point that for people who _could_ take the
> > implicit default, hitting "enter" is working fine now, and we would lose
> > that. I'd be fine with also just continuing to prompt in the implicit
> > case.
> >
> > But that is a much smaller issue to me than having send-email fail to
> > respect environment variables and silently use user.*, which is what
> > started this whole discussion. And I agree it is worth considering as a
> > regression we should avoid.
>
> It might be smaller, I don't think so. A hypothetical user that was
> relying on GIT_AUTHOR for whatever reason can switch to 'git
> send-email --from' (which is much easier) when they notice the
> failure, the same way somebody relying on fqdn would. The difference
> is that people with fqdn do exist, and they might be relying on this.
>
> Both are small issues, that I agree with.
>
> But the point is that you seem to be very adamant about _my_
> regressions, and not pay much attention about yours.
Really? I mentioned initially the possibility of dying instead of
prompting. You raised the point that it would regress a certain use
case. And then what happened? I said above "you raise a good point[...].
I'd be fine with also just continuing to prompt[...]. I agree it is
worth considering as a regression we should avoid". And then I sent out
a patch series which does not have the regression.
In other words, my suggestion was a bad one, and once it was pointed
out, I did not pursue it. If you want to call that "not paying much
attention", feel free. But I'd much rather you point out problems in my
actual patch series.
> Why do you hold on to my first patch?
Because clearly I am confused by your behavior. You continued to argue
that the initial regression was not worth worrying about. Which I
thought meant you were still interested in pursuing that patch. But if
you are not, then there is not even any point in discussing it. Which
is just fine with me, as that discussion seemed to be going nowhere.
> The second patch doesn't have this issue. It does change the behavior
> of 'git commit', yeah, but I think that's a benefit.
Changing "git commit" is even something I would entertain. It would be a
regression for some people, but at least it buys us something (increased
safety against people making bogus commits and failing to notice the
warning). I'm undecided on whether that is worth it or not.
But when you presented it, as far as I could tell the change in behavior
to "git commit" was accidental (which is why I pointed it out in
response). And as it was in the middle of a discussion about whether
regressions matter, it was not clear to me that your argument was "I
have thought this through and the inconvenience is outweighted by the
benefit" and not "I did not bother to consider the implications for
users who are currently using this feature".
If you want to seriously propose changing the behavior of "git commit",
I think the best thing would be to make a real patch, laying out the
pros and cons in the commit message, and post it. I would not be
surprised if the other list participants have stopped reading our thread
at this point, and the idea is going otherwise unnoticed.
> > So you can either:
> >
> > 1. Reimplement the environment variable lookup that ident.c does,
> > leaving implicit ident logic out completely.
> >
> > 2. Modify ident.c and "git var" to let send-email reuse the logic in
> > ident.c, but avoid dropping the prompt when an implicit ident is
> > used.
> >
> > Doing (2) sounds a lot more maintainable to me in the long run.
>
> Or:
>
> 3. Change the meaning of the STRICT flag so that the values are
> explicit, which has benefits outside 'git send-email'. Yes, this would
> change the behavior in 'git commit' and other tools, but it's worth to
> investigate these changes, and most likely they would be desirable.
Yes, I think that is fine _if_ we want to change git-commit. Which is
not clear to me. If we don't, then it is not an option.
> Or:
>
> 4. Just stop prompting
>
> I already sent a patch for 4. with all the details of why nobody (or
> very few, if any) would be affected negatively.
If doing (2) were really hard, that might be worth considering. But it's
not. I already did it. So I don't see how this is an attractive option,
unless my series is so unpalatable that we would rather accept a
regression.
> > [1/6]: ident: make user_ident_explicitly_given private
> > [2/6]: ident: keep separate "explicit" flags for author and committer
> > [3/6]: var: accept multiple variables on the command line
> > [4/6]: var: provide explicit/implicit ident information
> > [5/6]: Git.pm: teach "ident" to query explicitness
> > [6/6]: send-email: do not prompt for explicit repo ident
>
> I think this adds a lot of code that nobody would use.
A lot of code? It is mostly refactoring, which IMHO makes the resulting
code cleaner, and it increases the utility of "git var", and our test
coverage. If you have review comments, then by all means, respond to the
series.
> > I do not necessarily agree on "git commit". Moreover, I feel like it is
> > a separate issue. My series above _just_ implements the "do not prompt
> > when explicit" behavior. It does not deal with git-commit at all, nor
> > does it address the author/committer fallback questions. Those can
> > easily go on top.
>
> Yes, at the cost of adding a lot of code. If we end up agreeing that
> the changes to 'git commit' are desirable (which I hope at some point
> we will), then this code would be all for nothing.
If we are going to change "git commit" immediately, then I agree there
is not much point merging my series. But even if we do change it, will
we do so immediately? Will there be a deprecation period? If so, then my
series helps send-email in the meantime. And it's already written, so
you do not even have to do anything.
> I want clarify that this is merely a disagreement to at which level
> should we worry about regressions. On one side of the spectrum you
> have projects like GNOME, who don't have any problem breaking the
> user-experience from one release to the next, I'm not proposing
> anything like that. On the other side I think it's you, because I
> don't recall encountering anybody with such an extreme position of
> never introducing a regression ever if there's absolutely no evidence
> that anybody is using certain feature.
I don't think that's a fair characterization of my position. I am fine
with introducing a regression if there is a large benefit to it, and
especially if the regression is mutually exclusive with the benefit. For
example, look at IDENT_STRICT. We used to allow broken email addresses
in commits, and it was _me_ who pushed forward the change to disallow
it. That potentially regressed people who would rather have junk in the
commit objects than configure their identity (e.g., because they are
creating commits on the backend of some automated process). But we
discussed it, and the breakage was worth the increased safety for normal
users. We could not have it both ways, since the safety came at the
expense of switching the default.
But with this topic, we had a too-safe default (a safety prompt that was
sometimes overkill). We can have our cake and eat it, too: drop the
prompt for the overkill cases, but leave the other cases untouched. And
that is what I tried to do in my series. Note that this _still_
regresses certain use cases. What if I have configured my user.email,
but I am expecting send-email to prompt me so I can put in some other
random value. But we can't improve the prompting and leave that case
there; they are mutually exclusive. But IMHO, the benefit outweighs the
possibility of breakage.
-Peff
^ permalink raw reply
* Re: creation of empty branches
From: Andrew Ardill @ 2012-11-15 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Angelo Borsotti, git
In-Reply-To: <7vmwyjan96.fsf@alter.siamese.dyndns.org>
On 15 November 2012 08:27, Junio C Hamano <gitster@pobox.com> wrote:
> ... "git branch foo master" (or its
> moral equivalent "git checkout -b foo" while on master) is a wish to
> have a history that ends in 'foo' *forked* from history of 'master',
> but because you do not even have anything on 'master' yet, you
> cannot fork the history, as you explained earlier (snipped). In
> that sense, 'empty branch' is a slight misnomer---as far as "git
> branch foo master" is concerned, the 'master' branch does not yet
> exist (and that is why we often call it an "unborn branch", not
> "empty").
>
> fatal: cannot fork master's history that does not exist yet.
>
> would be more accurate description of the situation.
So in the situation where a start-point is an unborn branch (ie it is
referenced in HEAD) we should modify the error to show that the unborn
branch is in fact unborn. This is a good improvement I think, as it
catches this edge case and improves understanding of what an unborn
branch is. The term 'fork' is not used at all in branch's man page, so
perhaps a more consistent error message is something like
fatal: 'master' has no history, so we cannot create a new branch from it
Also, currently 'git checkout -b' *will* rename an unborn branch which
is different from the 'git branch' behaviour. Not sure how this
behaviour can be corrected without causing a regression or introducing
potentially confusing error messages for the git branch case.
>> So explicitly, I am proposing the following behaviour changes:
>>
>> When trying to create a new branch without specifying a start point,
>> if HEAD points to an empty branch, error with a more useful message
>> that assumes the user might want to rename the empty branch.
>
> I do not think that is the right assumption in the first place. It
> is very likely that the user does not yet know how Git works when
> she attempts to fork from a history that does not exist. It is also
> very likely that she is expecting, after "git branch foo master"
> succeeds when 'master' is yet to be born, have two branches 'foo'
> and 'master', so that "git checkout foo" and "git checkout master"
> can be done subsequently.
>
> But that expectation is wrong, and it would help the user in the
> longer run to correct that expectation. "We assume you wanted to
> rename 'master' to 'foo'" is a logical consequence that changing
> HEAD that points at an unborn 'master' to point at an unborn 'foo'
> is the best (or closest) thing the user can do, *if* the user
> understands that the current branch being unborn is a special state
> and there can only be one such unborn branch (that is, the current
> one). The user who gets this error message, however, clearly does
> not understand that, so it is not a logical consequence to her at
> all. The advice does not help her, but instead invites "No, I did
> not want to rename it, I wanted to have 'foo' without losing
> 'master'", leading to even more confusion.
I can't speak for others, but I think it is more likely that a new
user who doesn't understand git and tries to use the branch command on
a brand new repository is not trying to fork master's history, but is
rather trying to switch to a different branch. A subversion user might
want to switch from 'master' to 'trunk' as a (somewhat?) common use
case. That is the reasoning behind my recommendation to show how to
rename the branch. Furthermore, we can educate the user about unborn
branches and suggest a possible solution at the same time.
With the new error message from above, something like the following
might be nice.
fatal: 'master' has no history, so we cannot create a new branch from it
hint: A repository can only contain one unborn branch at a time.
hint: To rename a branch use 'git branch -m [<old-branch>] <new-branch>'
I'm not sure about the intended syntax of hint messages but this seems
consistent.
>
>> When trying to create a new branch whilst specifying an empty branch
>> as the start point,
>> if HEAD points to the same empty branch that is listed as the start
>> point, error with a more useful message that assumes the user might
>> want to rename the empty branch.
>> otherwise error due to invalid ref
>
> See above (for all the other cases, too).
>
You didn't address the branch rename command 'git branch -m
[<old-branch>] <new-branch>' (or you included it with the others). I
think it is a significantly different action to creating a new branch,
and should handle unborn branches in the expected way, which is to
rename them. What are your thoughts on that?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Angelo Borsotti @ 2012-11-14 23:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <7vmwykay4n.fsf@alter.siamese.dyndns.org>
Hi Junio,
> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no?
Yes, it is. Actually I thought some means to let the owner do decide
what to accept were already present (the pushNonFastForward config
key), and going along this avenue I thought it could be appropriate to
extent this a bit.
-Angelo
On 14 November 2012 18:32, Junio C Hamano <gitster@pobox.com> wrote:
> Angelo Borsotti <angelo.borsotti@gmail.com> writes:
>
>> actually, I proposed to add a key in config files, e.g.
>> pushTagsNoChange to be set in the remote repo do disallow changes to
>> tags, similar to pushNonFastForward that disallows non-fastforward
>> changes to branches. I still have the impression that this is simple
>> and clear, and allows the owner of the remote repository to enforce
>> the policy s/he wants on her/his repository.
>
> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no? You can implement any such
> policy in the pre-receive hook on the receiving end with a simple
> and clear manner, instead of adding specific logic to enforce a
> single hardcoded policy to the code that is flipped on with a
> configuration variable.
>
> In any case, I thought this series was about users who run "push"
> voluntarily stopping themselves from pushing updates to tags that
> may happen to fast-forward, so if we were to go with the
> configuration route, the suggestion would be more like
>
> [push]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> or perhaps
>
> [remote "origin"]
> updateNeedsForce = refs/tags/:refs/frotz/
>
> if we want to configure it per-remote, to specify that you would
> need to say "--force" to update the refs in the listed hierarchies.
>
> Then your patch series could become just the matter of declaring
> that the value of push.updateNeedsForce, when unspecified, defaults
> to "refs/tags/".
>
^ permalink raw reply
* Fwd: Local clones aka forks disk size optimization
From: Javier Domingo @ 2012-11-14 23:42 UTC (permalink / raw)
To: git
In-Reply-To: <CALZVapmG+HL0SQx8zx=Cfz5pWv84hJq90x-7VdjA0m2Z4dC34A@mail.gmail.com>
Hi,
I have come up with this while doing some local forks for work.
Currently, when you clone a repo using a path (not file:/// protocol)
you get all the common objects linked.
But as you work, each one will continue growing on its way, although
they may have common objects.
Is there any way to avoid this? I mean, can something be done in git,
that it checks for (when pulling) the same objects in the other forks?
Thought this doesn't make much sense in clients, when you have to
maintain 20 forks of very big projects in server side, it eats
precious disk space.
I don't know how if this should have [RFC] in the subject or what. But
here is my idea.
As hardlinking is already done by git, if it checked for how many
links there are for its files, it would be able to find other dirs
where to search. The easier way is checking for the most ancient pack.
Hope you like this idea,
Javier Domingo
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Andreas Schwab @ 2012-11-14 23:15 UTC (permalink / raw)
To: Douglas Mencken; +Cc: Torsten Bögershausen, Ramsay Jones, git
In-Reply-To: <CACYvZ7g7nCgQmcnwJYxvx5hJ+Y8rCQOBQyWYLZOt8NT5BTwTrw@mail.gmail.com>
Douglas Mencken <dougmencken@gmail.com> writes:
>>>> I cannot reproduce the problem (on openSUSE 12.2).
>>>
>>> You do need multiple CPU/multi-core machine, as I got it.
>>
>> Which is what I have.
>
> Then try to build *vanilla* git 1.8.0,
Which is what I did.
> not OpenSuSE's one (with a lot of patches inside srcrpm).
Which lot of patches?
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
* Re: "git am" crash (builtin/apply.c:2108) + small repro
From: Junio C Hamano @ 2012-11-14 22:50 UTC (permalink / raw)
To: Alexey Spiridonov; +Cc: git, Björn Gustavsson, Nguyen Thai Ngoc Duy
In-Reply-To: <CAOKKMFE=gwF4d+R2SD+3eRWqvZwkAt2hX8aPT8fvcwEZXiZbuQ@mail.gmail.com>
Alexey Spiridonov <snarkmaster@gmail.com> writes:
> Thanks for looking into this, guys!
>
> I seem to run into this with some regularity, but my setting is
> apply.whitespace=strip rather than 'fix'.
'strip' is an old synonym for 'fix'.
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #04; Wed, 14)
From: Junio C Hamano @ 2012-11-14 22:42 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Big thanks go to Jeff who curated topics in flight while I was on
vacation. I merged a couple of topics to 'next', and will start
merging what he marked for 'master' after giving them a final look
by the end of the week.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jl/submodule-rm (2012-11-14) 1 commit
- docs: move submodule section
* sg/complete-help-undup (2012-11-14) 1 commit
- completion: remove 'help' duplicate from porcelain commands
--------------------------------------------------
[Stalled]
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
--------------------------------------------------
[Cooking]
* jk/maint-gitweb-xss (2012-11-12) 1 commit
(merged to 'next' on 2012-11-14 at 7a667bc)
+ gitweb: escape html in rss title
Fixes an XSS vulnerability in gitweb.
* jk/send-email-sender-prompt (2012-11-13) 6 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given private
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Needs review.
* mg/replace-resolve-delete (2012-11-13) 1 commit
(merged to 'next' on 2012-11-14 at fa785ae)
+ replace: parse revision argument for -d
Be more user friendly to people using "git replace -d".
* ml/cygwin-mingw-headers (2012-11-12) 1 commit
- Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
Will merge to 'next'.
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
(merged to 'next' on 2012-11-13 at e11fafd)
+ Documentation: build html for all files in technical and howto
+ Documentation/howto: convert plain text files to asciidoc
+ Documentation/technical: convert plain text files to asciidoc
+ Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
+ Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
+ Split over-long synopsis in git-fetch-pack.txt into several lines
Will merge to 'master' in the sixth batch.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
Needs some test updates.
* jc/prettier-pretty-note (2012-11-13) 12 commits
(merged to 'next' on 2012-11-14 at 7230f26)
+ format-patch: add a blank line between notes and diffstat
(merged to 'next' on 2012-11-04 at 40e3e48)
+ Doc User-Manual: Patch cover letter, three dashes, and --notes
+ Doc format-patch: clarify --notes use case
+ Doc notes: Include the format-patch --notes option
+ Doc SubmittingPatches: Mention --notes option after "cover letter"
+ Documentation: decribe format-patch --notes
+ format-patch --notes: show notes after three-dashes
+ format-patch: append --signature after notes
+ pretty_print_commit(): do not append notes message
+ pretty: prepare notes message at a centralized place
+ format_note(): simplify API
+ pretty: remove reencode_commit_message()
Emit the notes attached to the commit in "format-patch --notes"
output after three-dashes.
Will merge to 'master' in the fifth batch.
* jc/same-encoding (2012-11-04) 1 commit
(merged to 'next' on 2012-11-04 at 54991f2)
+ reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
Will merge to 'master' in the fifth batch.
* cr/cvsimport-local-zone (2012-11-04) 2 commits
(merged to 'next' on 2012-11-04 at 292f0b4)
+ cvsimport: work around perl tzset issue
+ git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
Will merge to 'master' in the fifth batch.
* fc/zsh-completion (2012-10-29) 3 commits
- completion: add new zsh completion
- completion: add new __gitcompadd helper
- completion: get rid of empty COMPREPLY assignments
There were some comments on this, but I wasn't clear on the outcome.
Need to take a closer look.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will cook in 'next'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
(merged to 'next' on 2012-11-04 at eda85ef)
+ get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
Will merge to 'master' in the fifth batch.
* jh/symbolic-ref-d (2012-10-21) 1 commit
(merged to 'next' on 2012-11-04 at b0762f5)
+ git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
Will merge to 'master' in the fifth batch.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
Need to check reviews, but is probably ready for 'next'.
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.
Will merge to 'master' in the sixth batch.
* ph/submodule-sync-recursive (2012-10-29) 2 commits
(merged to 'next' on 2012-11-04 at a000f78)
+ Add tests for submodule sync --recursive
+ Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
Will merge to 'master' in the fifth batch.
* fc/completion-test-simplification (2012-10-29) 2 commits
- completion: simplify __gitcomp test helper
- completion: refactor __gitcomp related tests
Clean up completion tests.
There were some comments on the list.
Expecting a re-roll.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review.
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
(merged to 'next' on 2012-11-04 at 790337b)
+ diff_grep: use textconv buffers for add/deleted files
(this branch is used by jk/pickaxe-textconv.)
Fixes inconsistent use of textconv with "git log -G".
Will merge to 'master' in the fifth batch.
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
(this branch uses jk/maint-diff-grep-textconv.)
Use textconv filters when searching with "log -S".
Waiting for a sanity check and review from Junio.
* as/maint-doc-fix-no-post-rewrite (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 117a91e)
+ commit: fixup misplacement of --no-post-rewrite description
Will merge to 'master' in the fifth batch.
* fc/remote-bzr (2012-11-08) 5 commits
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- remote-bzr: add simple tests
- Add new remote-bzr transport helper
New remote helper for bzr.
Will merge to 'next'.
* fc/remote-hg (2012-11-12) 20 commits
- remote-hg: avoid bad refs
- remote-hg: try the 'tip' if no checkout present
- remote-hg: fix compatibility with older versions of hg
- remote-hg: add missing config for basic tests
- remote-hg: the author email can be null
- remote-hg: add option to not track branches
- remote-hg: add extra author test
- remote-hg: add tests to compare with hg-git
- remote-hg: add bidirectional tests
- test-lib: avoid full path to store test results
- remote-hg: add basic tests
- remote-hg: fake bookmark when there's none
- remote-hg: add compat for hg-git author fixes
- remote-hg: add support for hg-git compat mode
- remote-hg: match hg merge behavior
- remote-hg: make sure the encoding is correct
- remote-hg: add support to push URLs
- remote-hg: add support for remote pushing
- remote-hg: add support for pushing
- Add new remote-hg transport helper
New remote helper for hg.
Will merge to 'next'.
* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits
(merged to 'next' on 2012-11-09 at af69926)
+ remote-curl: retry failed requests for auth even with gzip
+ remote-curl: hoist gzip buffer size to top of post_rpc
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
Will merge to 'master' in the sixth batch.
* js/hp-nonstop (2012-10-30) 1 commit
(merged to 'next' on 2012-11-09 at fe58205)
+ fix 'make test' for HP NonStop
Will merge to 'master' in the fifth batch.
* kb/preload-index-more (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at a750ebd)
+ update-index/diff-index: use core.preloadindex to improve performance
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
Will merge to 'master' in the sixth batch.
* mh/notes-string-list (2012-11-08) 5 commits
(merged to 'next' on 2012-11-09 at 7a4c58c)
+ string_list_add_refs_from_colon_sep(): use string_list_split()
+ notes: fix handling of colon-separated values
+ combine_notes_cat_sort_uniq(): sort and dedup lines all at once
+ Initialize sort_uniq_list using named constant
+ string_list: add a function string_list_remove_empty_items()
Improve the asymptotic performance of the cat_sort_uniq notes merge
strategy.
Will merge to 'master' in the fifth batch.
* mh/strbuf-split (2012-11-04) 4 commits
(merged to 'next' on 2012-11-09 at fa984b1)
+ strbuf_split*(): document functions
+ strbuf_split*(): rename "delim" parameter to "terminator"
+ strbuf_split_buf(): simplify iteration
+ strbuf_split_buf(): use ALLOC_GROW()
Cleanups and documentation for strbuf_split.
Will merge to 'master' in the fifth batch.
* mm/maint-doc-commit-edit (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at 8dab7f5)
+ Document 'git commit --no-edit' explicitly
Will merge to 'master' in the fifth batch.
* cr/push-force-tag-update (2012-11-12) 5 commits
- push: update remote tags only with force
- push: flag updates that require force
- push: flag updates
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
Needs review.
I'm undecided yet on whether the goal is the right thing to do, but it
does prevent some potential mistakes. I haven't looked closely at the
implementation itself; review from interested parties would be helpful.
* fc/fast-export-fixes (2012-11-08) 14 commits
- fast-export: don't handle uninteresting refs
- fast-export: make sure updated refs get updated
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: make clear the 'done' feature
- remote-testgit: report success after an import
- remote-testgit: exercise more features
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: get rid of non-local functionality
- Add new simplified git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-testgit: fix direction of marks
- fast-export: avoid importing blob marks
Improvements to fix fast-export bugs, including how refs pointing to
already-seen commits are handled. An earlier 4-commit version of this
series looked good to me, but this much-expanded version has not seen
any comments.
Looks like it has been re-rolled, but I haven't checked it out yet.
Needs review.
* mg/maint-pull-suggest-upstream-to (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at bd74252)
+ push/pull: adjust missing upstream help text to changed interface
Follow-on to the new "--set-upstream-to" topic from v1.8.0 to avoid
suggesting the deprecated "--set-upstream".
Will merge to 'master' in the fifth batch.
* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits
(merged to 'next' on 2012-11-13 at 2bf41d9)
+ link_alt_odb_entries(): take (char *, len) rather than two pointers
+ link_alt_odb_entries(): use string_list_split_in_place()
Cleanups in the alternates code. Fixes a potential bug and makes the
code much cleaner.
Will merge to 'master' in the sixth batch.
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* pp/gitweb-config-underscore (2012-11-08) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
Junio raised a good point about the implementation for three-level
variables.
Expecting a re-roll.
* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at e90cc7c)
+ git p4: RCS expansion should not span newlines
I do not have p4 to play with, but looks obviously correct to me.
Will merge to 'master' in the sixth batch.
* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at c57d856)
+ gitweb.perl: fix %highlight_ext mappings
Fixes a clever misuse of perl's list interpretation.
Will merge to 'master' in the sixth batch.
* rr/submodule-diff-config (2012-11-08) 3 commits
- submodule: display summary header in bold
- diff: introduce diff.submodule configuration variable
- Documentation: move diff.wordRegex from config.txt to diff-config.txt
Lets "git diff --submodule=log" become the default via configuration.
Almost there. Looks like a new version has been posted, but I haven't
picked it up yet.
Needs review.
^ permalink raw reply
* Re: creation of empty branches
From: Junio C Hamano @ 2012-11-14 21:27 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Angelo Borsotti, git
In-Reply-To: <CAH5451mkcszgJxziKn3q3OwSDM-qQ71PtT5+UWb=PG7VYAcFyQ@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> Since git branch has the default behaviour to create a branch 'in the
> background' it makes sense to fail when trying to create a new branch
> this way from an empty branch. The error message should be improved to
> handle this edge case in a nicer way. If we allow for renaming empty
> branches (described below) then the message can be even more helpful.
> Instead of
> fatal: Not a valid object name: 'master'.
> perhaps
> fatal: Cannot create branch 'foo' from empty branch 'master'. To
> rename 'master' use 'git branch -m master foo'.
The first new sentence is a definite improvement, but I do not think
the advice in the second sentence is necessarily a good idea,
because it is dubious that the user is likely to have wanted to
rename 'master' to something else. "git branch foo master" (or its
moral equivalent "git checkout -b foo" while on master) is a wish to
have a history that ends in 'foo' *forked* from history of 'master',
but because you do not even have anything on 'master' yet, you
cannot fork the history, as you explained earlier (snipped). In
that sense, 'empty branch' is a slight misnomer---as far as "git
branch foo master" is concerned, the 'master' branch does not yet
exist (and that is why we often call it an "unborn branch", not
"empty").
fatal: cannot fork master's history that does not exist yet.
would be more accurate description of the situation.
> So explicitly, I am proposing the following behaviour changes:
>
> When trying to create a new branch without specifying a start point,
> if HEAD points to an empty branch, error with a more useful message
> that assumes the user might want to rename the empty branch.
I do not think that is the right assumption in the first place. It
is very likely that the user does not yet know how Git works when
she attempts to fork from a history that does not exist. It is also
very likely that she is expecting, after "git branch foo master"
succeeds when 'master' is yet to be born, have two branches 'foo'
and 'master', so that "git checkout foo" and "git checkout master"
can be done subsequently.
But that expectation is wrong, and it would help the user in the
longer run to correct that expectation. "We assume you wanted to
rename 'master' to 'foo'" is a logical consequence that changing
HEAD that points at an unborn 'master' to point at an unborn 'foo'
is the best (or closest) thing the user can do, *if* the user
understands that the current branch being unborn is a special state
and there can only be one such unborn branch (that is, the current
one). The user who gets this error message, however, clearly does
not understand that, so it is not a logical consequence to her at
all. The advice does not help her, but instead invites "No, I did
not want to rename it, I wanted to have 'foo' without losing
'master'", leading to even more confusion.
> When trying to create a new branch whilst specifying an empty branch
> as the start point,
> if HEAD points to the same empty branch that is listed as the start
> point, error with a more useful message that assumes the user might
> want to rename the empty branch.
> otherwise error due to invalid ref
See above (for all the other cases, too).
^ 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