* Re: [PATCH 1/2] Add Git::config_path()
From: Junio C Hamano @ 2011-10-07 22:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Cord Seele, Matthieu Moy, git, Eric Wong, Cord Seele
In-Reply-To: <201110072344.46556.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> char *expand_user_path(const char *path)
> [...]
> if (username_len == 0) {
> const char *home = getenv("HOME");
> if (!home)
> goto return_null;
> strbuf_add(&user_path, home, strlen(home));
> } else {
> [...]
Ahh, Ok. I was afraid getpwnam() codepath might interfere with it.
^ permalink raw reply
* Re: [PATCH v2] Teach merge the '[-e|--edit]' option
From: Junio C Hamano @ 2011-10-07 22:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Todd A. Jacobs
In-Reply-To: <1318023997-54810-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Implemented internally instead of as "git merge --no-commit && git commit"
> so that "merge --edit" is otherwise consistent (hooks, etc) with "merge".
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> On Fri, Oct 7, 2011 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> If we wanted to do this properly, we should update builtin/merge.c to call
>> launch_editor() before it runs commit_tree(), in a way similar to how
>
> I disagree that this is the proper way to do it. --edit is a new option, there's
> no obviously "correct" behavior. You think 'merge --edit' should behave just
> like 'merge', I think 'merge --edit' should behave like 'merge --no-commit &&
> commit'.
>
> The commit performed internally by git-merge is already wildly inconsistent with
> git-commit.
Think and look forward.
You are complaining that the "commit" does not know enough to behave as if
it were a part of the merge command workflow if you split a usual merge
into two steps "merge --no-commit; commit".
How would you make it better? Would you strip all the things usual "merge"
does, so that it would work identically to the split one, losing some hook
support and such, or would you rather make the split case work similar to
the usual merge?
I'd say between "merge" and "merge --no-commit ; commit", the latter is
what needs to be fixed. Viewed that way, why would you even consider
making the new option behave similar to the _wrong_ one?
> I didn't bother with the commit status, it's more code than I wanted
> to deal with duplicating/refactoring from commit.c.
What do you mean by "commit status"? If you mean this patch is incomplete,
it would have been nicer if it were labeled with [PATCH/RFC].
> diff --git a/builtin/merge.c b/builtin/merge.c
> index ee56974371..0dee53b7e4 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -46,6 +46,7 @@ static const char * const builtin_merge_usage[] = {
>
> static int show_diffstat = 1, shortlog_len, squash;
> static int option_commit = 1, allow_fast_forward = 1;
> +static int option_edit = 0;
No need to move this into .data segment when it can be in .bss
segment. Drop the unnecessary " = 0" before ";".
> @@ -842,30 +845,54 @@ static void add_strategies(const char *string, unsigned attr)
>
> }
>
> -static void write_merge_msg(void)
> +static void write_merge_msg(struct strbuf *msg)
> {
> int fd = open(git_path("MERGE_MSG"), O_WRONLY | O_CREAT, 0666);
> if (fd < 0)
> die_errno(_("Could not open '%s' for writing"),
> git_path("MERGE_MSG"));
> - if (write_in_full(fd, merge_msg.buf, merge_msg.len) != merge_msg.len)
> + if (write_in_full(fd, msg->buf, msg->len) != msg->len)
> die_errno(_("Could not write to '%s'"), git_path("MERGE_MSG"));
> close(fd);
> }
>
> -static void read_merge_msg(void)
> +static void read_merge_msg(struct strbuf *msg)
> {
> - strbuf_reset(&merge_msg);
> - if (strbuf_read_file(&merge_msg, git_path("MERGE_MSG"), 0) < 0)
> + strbuf_reset(msg);
> + if (strbuf_read_file(msg, git_path("MERGE_MSG"), 0) < 0)
> die_errno(_("Could not read from '%s'"), git_path("MERGE_MSG"));
> }
>
> -static void run_prepare_commit_msg(void)
> +static void write_merge_state();
s/()/(void)/;
Thanks.
^ permalink raw reply
* Re: [PATCH] po/pl.po: Eliminate fuzzy translations
From: Jakub Narebski @ 2011-10-07 22:11 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Marcin Cieślak
In-Reply-To: <4E8AC294.2060608@in.waw.pl>
On Tue, 4 Oct 2011, Zbigniew Jędrzejewski-Szmek wrote:
> On 10/03/2011 11:37 PM, Jakub Narebski wrote:
>>
>> +# Terminologia dla kluczowych terminów z Subversion:
As I probably should write in the commit message, this terminology
is taken directly from Subversion's po/pl.po file. Subversion has
IMHO quite good Polish translation.
On the other hand no other *.po file in Git has glossary in
comments...
>> +# path - ścieżka
>> +# URL - URL
>> +# file - plik
>> +# directory - katalog
>> +# update - aktualizacja
>> +# commit - zatwierdzenie, zatwierdzenie zmian
>
> This seems kind of awkward. E.g. 'initial commit' would become
> 'początkowe zatwierdzenie zmian' or 'pierwsze zatwierdzenie', which just
> doesn't sound right. What about starting with the mercurial term
> 'changeset'? Git users also use 'commit' to mean 'change', so maybe
> the polish translation of this crucial term should be 'zmiana':
> 'initial commit' -- 'początkowa zmiana' or 'pierwsza zmiana'
> 'commit message' -- 'opis zmiany'
The problem is that "commit" might be a verb ('to commit'), where I think
"zatwierdzenie zmian" is a good translation, and "commit" might also be
used as a noun ('a commit'), where I think it should be probably translated
as "wersja" (eng. version) or "zmiana" (eng. change).
Nb. it is a good idea to take into account existing Mercurial translation
into Polish.
>> +# version control - zarządzanie wersjami
>> +# repository - repozytorium
>> +# branch - odgałęzienie
>
> 'gałąź'? I think that's the translation which is used in informal
> conversations.
"Odgałęzienie" is what Subversion uses, but you are right that "gałąź"
might be better. Though in this case the glossary cannot be marked
as coming from Subversion...
>> +# tag - tag
>
> 'metka', 'etykieta' according to the dictionary. I'm aware of 'metka'
> being used in CS anywhere, but it is short, and pretty cool, IMO.
I think that "etykieta" (eng. label) has already established different
meaning in Polish computer terminology for a "goto label".
"Metka" might be a good solution (it is mainly used in Polish to mean
textile labels), though I wonder if using English term "tag" (which
in Polish is used in computer science to mean metadata tag or markup
language tag) wouldn't be better as it is already computer term.
>> +# merge - łączenie zmian
>
> 'łączenie gałęzi'?
Well, in Subversion it is about merging changes, not branches ;-)))
>> +# conflict - konflikt
>> +# property - atrybut
>> +# revision - wersja
>> +# log message - opis zmian
>> +# entry/item - element
>> +# ancestry - pochodzenie
>> +# ancestor - przodek
>> +# working copy - kopia robocza
>> +# working dir - bieżący katalog
>> +# usage - wykorzystanie
>
> 'użycie', 'wywołanie'?
> E.g. 'standardowe wywołanie tego programu to: prog arg'
I'd have to check how other programs translate this. I think
at least "usage: " in '-h' output is translated as "użycie: ",
though I am not sure if it is really a good translation to recommend.
>> +# source - źródłowy
>> +# destination - docelowy
>> +# hook - skrypt (skrypt repozytorium)
>> +# exclude - wykluczyć
>> +# crop - obciąć
>> +# cache - pamięć podręczna
>> +# child - obiekt podrzędny
>
> Standard CS term is 'ojciec' and 'syn' for 'parent/child'.
Right.
>> +# obliteration - obliteracja
>
> 'wymazanie'?
Well, anyway I don't think this is needed for git translation.
>> +# patch - łata
>> +# notes - adnotacja
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: unexpected behavior with `git log --skip filename`
From: Jay Soffian @ 2011-10-07 21:54 UTC (permalink / raw)
To: Andrew McNabb; +Cc: git
In-Reply-To: <20111007171503.GB16607@mcnabbs.org>
On Fri, Oct 7, 2011 at 1:15 PM, Andrew McNabb <amcnabb@mcnabbs.org> wrote:
> The "--skip" option to "git log" did not behave as I expected, but I'm
> not sure whether this was user error, unclear documentation, or a bug.
> Specifically, I ran the following, intending to find the previous
> revision of a given file:
>
> git log --skip=1 -n 1 --oneline some-filename
>
> My expectation was that this would behave the same as:
>
> git log -n 2 --oneline some-filename |tail -n 1
>
> Instead, the --skip=1 parameter seemed to be ignored. After I tried
> several different values, it appears that the commits are skipped before
> path matching with "some-filename".
Hmm:
$ git log --oneline GIT-VERSION-GEN | head -2
7f41b6bbe3 Post 1.7.7 first wave
703f05ad58 Git 1.7.7
$ git log --oneline --skip=1 -n 1 GIT-VERSION-GEN
703f05ad58 Git 1.7.7
j.
^ permalink raw reply
* [PATCH v2] Teach merge the '[-e|--edit]' option
From: Jay Soffian @ 2011-10-07 21:46 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Todd A. Jacobs
In-Reply-To: <7vk48gwvyd.fsf@alter.siamese.dyndns.org>
Implemented internally instead of as "git merge --no-commit && git commit"
so that "merge --edit" is otherwise consistent (hooks, etc) with "merge".
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
On Fri, Oct 7, 2011 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If we wanted to do this properly, we should update builtin/merge.c to call
> launch_editor() before it runs commit_tree(), in a way similar to how
I disagree that this is the proper way to do it. --edit is a new option, there's
no obviously "correct" behavior. You think 'merge --edit' should behave just
like 'merge', I think 'merge --edit' should behave like 'merge --no-commit &&
commit'.
The commit performed internally by git-merge is already wildly inconsistent with
git-commit. If anything, --edit is a perfect excuse to say "we're trying to make
git-merge perform commits more consistently with git-commit, so we've
implemented 'merge --edit' in terms of git-commit."
I didn't bother with the commit status, it's more code than I wanted
to deal with duplicating/refactoring from commit.c.
Documentation/merge-options.txt | 6 ++
builtin/merge.c | 108 +++++++++++++++++++++++++--------------
t/t7600-merge.sh | 15 +++++
3 files changed, 91 insertions(+), 38 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index b613d4ed08..6bd0b041c3 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -7,6 +7,12 @@ With --no-commit perform the merge but pretend the merge
failed and do not autocommit, to give the user a chance to
inspect and further tweak the merge result before committing.
+--edit::
+-e::
++
+ Invoke editor before committing successful merge to further
+ edit the default merge message.
+
--ff::
--no-ff::
Do not generate a merge commit if the merge resolved as
diff --git a/builtin/merge.c b/builtin/merge.c
index ee56974371..0dee53b7e4 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -46,6 +46,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, shortlog_len, squash;
static int option_commit = 1, allow_fast_forward = 1;
+static int option_edit = 0;
static int fast_forward_only;
static int allow_trivial = 1, have_message;
static struct strbuf merge_msg;
@@ -190,6 +191,8 @@ static struct option builtin_merge_options[] = {
"create a single commit instead of doing a merge"),
OPT_BOOLEAN(0, "commit", &option_commit,
"perform a commit if the merge succeeds (default)"),
+ OPT_BOOLEAN('e', "edit", &option_edit,
+ "edit message before committing"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast-forward (default)"),
OPT_BOOLEAN(0, "ff-only", &fast_forward_only,
@@ -842,30 +845,54 @@ static void add_strategies(const char *string, unsigned attr)
}
-static void write_merge_msg(void)
+static void write_merge_msg(struct strbuf *msg)
{
int fd = open(git_path("MERGE_MSG"), O_WRONLY | O_CREAT, 0666);
if (fd < 0)
die_errno(_("Could not open '%s' for writing"),
git_path("MERGE_MSG"));
- if (write_in_full(fd, merge_msg.buf, merge_msg.len) != merge_msg.len)
+ if (write_in_full(fd, msg->buf, msg->len) != msg->len)
die_errno(_("Could not write to '%s'"), git_path("MERGE_MSG"));
close(fd);
}
-static void read_merge_msg(void)
+static void read_merge_msg(struct strbuf *msg)
{
- strbuf_reset(&merge_msg);
- if (strbuf_read_file(&merge_msg, git_path("MERGE_MSG"), 0) < 0)
+ strbuf_reset(msg);
+ if (strbuf_read_file(msg, git_path("MERGE_MSG"), 0) < 0)
die_errno(_("Could not read from '%s'"), git_path("MERGE_MSG"));
}
-static void run_prepare_commit_msg(void)
+static void write_merge_state();
+static void abort_commit(const char *err_msg)
{
- write_merge_msg();
+ if (err_msg)
+ error("%s", err_msg);
+ fprintf(stderr,
+ _("Not committing merge; use 'git commit' to complete the merge.\n"));
+ write_merge_state();
+ exit(1);
+}
+
+static void prepare_to_commit(void)
+{
+ struct strbuf msg = STRBUF_INIT;
+ strbuf_addbuf(&msg, &merge_msg);
+ strbuf_addch(&msg, '\n');
+ write_merge_msg(&msg);
run_hook(get_index_file(), "prepare-commit-msg",
git_path("MERGE_MSG"), "merge", NULL, NULL);
- read_merge_msg();
+ if (option_edit) {
+ if (launch_editor(git_path("MERGE_MSG"), NULL, NULL))
+ abort_commit(NULL);
+ }
+ read_merge_msg(&msg);
+ stripspace(&msg, option_edit);
+ if (!msg.len)
+ abort_commit(_("Empty commit message."));
+ strbuf_release(&merge_msg);
+ strbuf_addbuf(&merge_msg, &msg);
+ strbuf_release(&msg);
}
static int merge_trivial(void)
@@ -879,7 +906,7 @@ static int merge_trivial(void)
parent->next = xmalloc(sizeof(*parent->next));
parent->next->item = remoteheads->item;
parent->next->next = NULL;
- run_prepare_commit_msg();
+ prepare_to_commit();
commit_tree(merge_msg.buf, result_tree, parent, result_commit, NULL);
finish(result_commit, "In-index merge");
drop_save();
@@ -907,9 +934,9 @@ static int finish_automerge(struct commit_list *common,
for (j = remoteheads; j; j = j->next)
pptr = &commit_list_insert(j->item, pptr)->next;
}
- free_commit_list(remoteheads);
strbuf_addch(&merge_msg, '\n');
- run_prepare_commit_msg();
+ prepare_to_commit();
+ free_commit_list(remoteheads);
commit_tree(merge_msg.buf, result_tree, parents, result_commit, NULL);
strbuf_addf(&buf, "Merge made by the '%s' strategy.", wt_strategy);
finish(result_commit, buf.buf);
@@ -1015,6 +1042,36 @@ static int setup_with_upstream(const char ***argv)
return i;
}
+static void write_merge_state()
+{
+ int fd;
+ struct commit_list *j;
+ struct strbuf buf = STRBUF_INIT;
+
+ for (j = remoteheads; j; j = j->next)
+ strbuf_addf(&buf, "%s\n",
+ sha1_to_hex(j->item->object.sha1));
+ fd = open(git_path("MERGE_HEAD"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die_errno(_("Could not open '%s' for writing"),
+ git_path("MERGE_HEAD"));
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die_errno(_("Could not write to '%s'"), git_path("MERGE_HEAD"));
+ close(fd);
+ strbuf_addch(&merge_msg, '\n');
+ write_merge_msg(&merge_msg);
+ fd = open(git_path("MERGE_MODE"), O_WRONLY | O_CREAT | O_TRUNC, 0666);
+ if (fd < 0)
+ die_errno(_("Could not open '%s' for writing"),
+ git_path("MERGE_MODE"));
+ strbuf_reset(&buf);
+ if (!allow_fast_forward)
+ strbuf_addf(&buf, "no-ff");
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die_errno(_("Could not write to '%s'"), git_path("MERGE_MODE"));
+ close(fd);
+}
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -1418,33 +1475,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (squash)
finish(NULL, NULL);
- else {
- int fd;
- struct commit_list *j;
-
- for (j = remoteheads; j; j = j->next)
- strbuf_addf(&buf, "%s\n",
- sha1_to_hex(j->item->object.sha1));
- fd = open(git_path("MERGE_HEAD"), O_WRONLY | O_CREAT, 0666);
- if (fd < 0)
- die_errno(_("Could not open '%s' for writing"),
- git_path("MERGE_HEAD"));
- if (write_in_full(fd, buf.buf, buf.len) != buf.len)
- die_errno(_("Could not write to '%s'"), git_path("MERGE_HEAD"));
- close(fd);
- strbuf_addch(&merge_msg, '\n');
- write_merge_msg();
- fd = open(git_path("MERGE_MODE"), O_WRONLY | O_CREAT | O_TRUNC, 0666);
- if (fd < 0)
- die_errno(_("Could not open '%s' for writing"),
- git_path("MERGE_MODE"));
- strbuf_reset(&buf);
- if (!allow_fast_forward)
- strbuf_addf(&buf, "no-ff");
- if (write_in_full(fd, buf.buf, buf.len) != buf.len)
- die_errno(_("Could not write to '%s'"), git_path("MERGE_MODE"));
- close(fd);
- }
+ else
+ write_merge_state();
if (merge_was_ok) {
fprintf(stderr, _("Automatic merge went well; "
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 87aac835a1..8c6b811718 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -643,4 +643,19 @@ test_expect_success 'amending no-ff merge commit' '
test_debug 'git log --graph --decorate --oneline --all'
+cat >editor <<\EOF
+#!/bin/sh
+# strip comments and blank lines from end of message
+sed -e '/^#/d' < "$1" | sed -e :a -e '/^\n*$/{$d;N;ba' -e '}' > expected
+EOF
+chmod 755 editor
+
+test_expect_success 'merge --no-ff --edit' '
+ git reset --hard c0 &&
+ EDITOR=./editor git merge --no-ff --edit c1 &&
+ verify_parents $c0 $c1 &&
+ git cat-file commit HEAD | sed "1,/^$/d" > actual &&
+ test_cmp actual expected
+'
+
test_done
--
1.7.7.147.g3a3ce
^ permalink raw reply related
* Re: [PATCH 1/2] Add Git::config_path()
From: Jakub Narebski @ 2011-10-07 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Cord Seele, Matthieu Moy, git, Eric Wong, Cord Seele
In-Reply-To: <7vk48gtrh9.fsf@alter.siamese.dyndns.org>
On Mon, 7 Oct 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
> > index 3787186..7558f0c 100755
> > --- a/t/t9700-perl-git.sh
> > +++ b/t/t9700-perl-git.sh
> > @@ -43,7 +43,9 @@ test_expect_success \
> > git config --add test.booltrue true &&
> > git config --add test.boolfalse no &&
> > git config --add test.boolother other &&
> > - git config --add test.int 2k
> > + git config --add test.int 2k &&
> > + git config --add test.path "~/foo" &&
> > + git config --add test.pathexpanded "$HOME/foo"
>
> Given that test-lib.sh sets up the $HOME away from unknown place to ensure
> repeatability of tests, I am not sure if this test would ever pass.
Well, it passes.
test-lib.sh sets $HOME to "$TRASH_DIRECTORY", but this value of $HOME
is then later seen by "git config --path ..." run by Git::config_path
in t9700/test.pl
char *expand_user_path(const char *path)
[...]
if (username_len == 0) {
const char *home = getenv("HOME");
if (!home)
goto return_null;
strbuf_add(&user_path, home, strlen(home));
} else {
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] Add Git::config_path()
From: Junio C Hamano @ 2011-10-07 21:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Cord Seele, Matthieu Moy, git, Eric Wong, Cord Seele
In-Reply-To: <m3vcs01r32.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
> index 3787186..7558f0c 100755
> --- a/t/t9700-perl-git.sh
> +++ b/t/t9700-perl-git.sh
> @@ -43,7 +43,9 @@ test_expect_success \
> git config --add test.booltrue true &&
> git config --add test.boolfalse no &&
> git config --add test.boolother other &&
> - git config --add test.int 2k
> + git config --add test.int 2k &&
> + git config --add test.path "~/foo" &&
> + git config --add test.pathexpanded "$HOME/foo"
Given that test-lib.sh sets up the $HOME away from unknown place to ensure
repeatability of tests, I am not sure if this test would ever pass.
^ permalink raw reply
* [PATCH/RFC 3/2] Refactor Git::config_*
From: Jakub Narebski @ 2011-10-07 21:17 UTC (permalink / raw)
To: Junio C Hamano, Eric Wong; +Cc: Cord Seele, Matthieu Moy, git, Cord Seele
In-Reply-To: <7voby1oesm.fsf@alter.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
There is, especially with addition of Git::config_path(), much code
repetition in the Git::config_* family of subroutines. Refactor
common parts of Git::config(), Git::config_bool(), Git::config_int()
and Git::config_path() into _config_common() subroutine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is version which has fixed style to be more Perl-ish, and which
actually works (i.e. t9700 passes).
I have also moved _config_common() after commands that use it, just like
it is done with other "private" methods (methods with names starting with
'_'), and excluded this private detail of implementation from docs.
perl/Git.pm | 85 ++++++++++++++---------------------------------------------
1 files changed, 20 insertions(+), 65 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index c279bfb..d6df2e8 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -562,7 +562,6 @@ sub wc_chdir {
$self->{opts}->{WorkingSubdir} = $subdir;
}
-
=item config ( VARIABLE )
Retrieve the configuration C<VARIABLE> in the same manner as C<config>
@@ -570,30 +569,11 @@ does. In scalar context requires the variable to be set only one time
(exception is thrown otherwise), in array context returns allows the
variable to be set multiple times and returns all the values.
-This currently wraps command('config') so it is not so fast.
-
=cut
sub config {
my ($self, $var) = _maybe_self(@_);
-
- try {
- my @cmd = ('config');
- unshift @cmd, $self if $self;
- if (wantarray) {
- return command(@cmd, '--get-all', $var);
- } else {
- return command_oneline(@cmd, '--get', $var);
- }
- } catch Git::Error::Command with {
- my $E = shift;
- if ($E->value() == 1) {
- # Key not found.
- return;
- } else {
- throw $E;
- }
- };
+ return _config_common($self, $var);
}
@@ -603,60 +583,24 @@ Retrieve the bool configuration C<VARIABLE>. The return value
is usable as a boolean in perl (and C<undef> if it's not defined,
of course).
-This currently wraps command('config') so it is not so fast.
-
=cut
sub config_bool {
my ($self, $var) = _maybe_self(@_);
-
- try {
- my @cmd = ('config', '--bool', '--get', $var);
- unshift @cmd, $self if $self;
- my $val = command_oneline(@cmd);
- return undef unless defined $val;
- return $val eq 'true';
- } catch Git::Error::Command with {
- my $E = shift;
- if ($E->value() == 1) {
- # Key not found.
- return undef;
- } else {
- throw $E;
- }
- };
+ my $val = scalar _config_common($self, $var, {'kind' => '--bool'});
+ return (defined $val && $val eq 'true');
}
-
=item config_path ( VARIABLE )
Retrieve the path configuration C<VARIABLE>. The return value
is an expanded path or C<undef> if it's not defined.
-This currently wraps command('config') so it is not so fast.
-
=cut
sub config_path {
my ($self, $var) = _maybe_self(@_);
-
- try {
- my @cmd = ('config', '--path');
- unshift @cmd, $self if $self;
- if (wantarray) {
- return command(@cmd, '--get-all', $var);
- } else {
- return command_oneline(@cmd, '--get', $var);
- }
- } catch Git::Error::Command with {
- my $E = shift;
- if ($E->value() == 1) {
- # Key not found.
- return undef;
- } else {
- throw $E;
- }
- };
+ return _config_common($self, $var, {'kind' => '--path'});
}
=item config_int ( VARIABLE )
@@ -667,28 +611,39 @@ or 'g' in the config file will cause the value to be multiplied
by 1024, 1048576 (1024^2), or 1073741824 (1024^3) prior to output.
It would return C<undef> if configuration variable is not defined,
-This currently wraps command('config') so it is not so fast.
-
=cut
sub config_int {
my ($self, $var) = _maybe_self(@_);
+ return scalar _config_common($self, $var, {'kind' => '--int'});
+}
+
+# Common subroutine to implement bulk of what the config* family of methods
+# do. This wraps command('config') so it is not so fast.
+sub _config_common {
+ my ($self, $var, $opts) = _maybe_self(@_);
try {
- my @cmd = ('config', '--int', '--get', $var);
+ my @cmd = ('config', $opts->{'kind'} ? $opts->{'kind'} : ());
unshift @cmd, $self if $self;
- return command_oneline(@cmd);
+ if (wantarray) {
+ return command(@cmd, '--get-all', $var);
+ } else {
+ return command_oneline(@cmd, '--get', $var);
+ }
} catch Git::Error::Command with {
my $E = shift;
if ($E->value() == 1) {
# Key not found.
- return undef;
+ return;
} else {
throw $E;
}
};
+
}
+
=item get_colorbool ( NAME )
Finds if color should be used for NAMEd operation from the configuration,
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Junio C Hamano @ 2011-10-07 20:59 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jonathan Nieder, git, Jeff King
In-Reply-To: <4E8EED39.1060607@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Alternatively, one could store the description in a blob and refer to
> that directly, of course. I.e., have
>
> refs/description/foo
>
> point to a blob whose content is the description of the ref
>
> ref/foo
>
> That would be unversioned, and one could decide more easily which
> descriptions to share. (A notes tree you either push or don't.)
If refs/descriptions/foo were to point at a commit object and its commit
log message is used to store the description you could make it versioned.
A history that records forest of descriptions where its commit contains a
tree whose leaves are branch names is slightly better than notes based
approach in that it does not have to violate "notes are for objects"
design principle, but it shares the same "branch names are local" issue as
your "lone refs/description/foo describes 'foo' and 'foo' only".
In addition, it shares with the notes based approach that exchanging a
description on a single branch will inevitably pull in descriptions of all
the other branches you happen to have in the forest, which was one of the
reasons that recording "push -s" certificates in notes tree failed whether
the v2 or v3 approach was used.
You should be able to make a few changes to jc/request-pull-show-head-4 to
move the description to such a "refs/desc/$name" from completely local
"branch.$name.description". The machinery to edit the description is
localized to edit_branch_description() introduced in b7200e8 (branch:
teach --edit-description option, 2011-09-20), and the machinery to read
the description is localized to read_branch_desc() in 6f9a332 (branch: add
read_branch_desc() helper function, 2011-09-21); the remainder of the
series could be used unmodified.
But it remains that any of these approaches assume branch names are
universal. Unlike other systems, what we call branches do not have their
own identity, so if you really want to go that route (and we _might_ need
to in the longer term, but I am not convinced at this point yet), you
would first need to define how that local namespace would look like, how
people interact with it, etc. It might be just the matter of declaring a
convention e.g. "Among people who meet at this central repository,
everybody must map the branches identically to their local branch
namespace, and all sharing must go through the central repository", and
calling a tuple <central repository URL, branch name in that repository>
with a name that cannot be confused with "branch" (so "remote branch" is
out), such as "(development) track".
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Michael J Gruber @ 2011-10-07 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Jeff King
In-Reply-To: <7v1uuovahm.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.10.2011 21:59:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I am surprised that you seem to have missed what I meant by "branch
>> names are local"....
>> This matters, a lot, because there is no easy way to partition a
>> namespace of names descriptive for humans without a central authority
>> to negotiate conflicts.
>
> I think we are in total agreement. The branch names are local, but the
> users may want to annotate to describe _the history_ they intend to build
> on it.
>
> Various ways to convey the description when the end product (i.e. the
> history built on it) is shiped were outlined in the series, so that the
> shipper can help the receiver understand the history. The information in
> the annotation (i.e. the _value_ of branch.$name.description) is something
> the shipper wants to share with the receiver, but the mapping between the
> local name of the branch the shipper used to build that history (i.e. the
> key "$name" in branch.$name.description) is immaterial in the end result.
It just seems we judge the "local" aspect completely differently. The
point that I don't get is: How to share a branch without sharing a
branch name? You cannot. Of course you may "change the name" during the
push, or during a fetch, and at that point you know both and can map the
description.
Note that I'm not tied to the notes implementation. But versioned branch
descriptions would be nice for several purposes, for example series
cover letters, or descriptions on long lived feature branches. And I
don't see how else to have versioned descriptions.
Also, for transporting descriptions via config, you have to have an
updated git on the server side, whereas anything object/ref based would
work now, right?
Michael
^ permalink raw reply
* Re: [PATCH 1/2] Add Git::config_path()
From: Jakub Narebski @ 2011-10-07 20:32 UTC (permalink / raw)
To: Cord Seele; +Cc: Matthieu Moy, git, Junio C Hamano, Eric Wong, Cord Seele
In-Reply-To: <1317379945-9355-2-git-send-email-cowose@gmail.com>
Cord Seele <cowose@googlemail.com> writes:
> Use --path option when calling 'git config' thus allow for pathname
> expansion, e.g. a tilde.
>
> Signed-off-by: Cord Seele <cowose@gmail.com>
> ---
> perl/Git.pm | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
I think the following minimal test should be squashed in:
---
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 3787186..7558f0c 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -43,7 +43,9 @@ test_expect_success \
git config --add test.booltrue true &&
git config --add test.boolfalse no &&
git config --add test.boolother other &&
- git config --add test.int 2k
+ git config --add test.int 2k &&
+ git config --add test.path "~/foo" &&
+ git config --add test.pathexpanded "$HOME/foo"
'
# The external test will outputs its own plan
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 13ba96e..ce9340c 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -33,6 +33,8 @@ is($r->config_int("test.int"), 2048, "config_int: integer");
is($r->config_int("test.nonexistent"), undef, "config_int: nonexistent");
ok($r->config_bool("test.booltrue"), "config_bool: true");
ok(!$r->config_bool("test.boolfalse"), "config_bool: false");
+is($r->config_path("test.path"), $r->config("test.pathexpanded"),
+ "config_path: ~/foo expansion");
our $ansi_green = "\x1b[32m";
is($r->get_color("color.test.slot1", "red"), $ansi_green, "get_color");
# Cannot test $r->get_colorbool("color.foo")) because we do not
^ permalink raw reply related
* What's cooking in git.git (Oct 2011, #03; Fri, 7)
From: Junio C Hamano @ 2011-10-07 20:28 UTC (permalink / raw)
To: git
News flash: git://git.kernel.org/pub/scm/git/git.git is back.
---
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
The first wave of topics have been graduated to 'master'. I've rebuilt
'next' while kicking some topics back to 'pu'. Also some topics have been
discarded.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo, html and man:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint, master, html and man:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
--------------------------------------------------
[New Topics]
* jc/signed-commit (2011-10-05) 4 commits
- commit: teach --gpg-sign option
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch is tangled with jc/signed-push and jc/signed-push-3.)
This is to replace the earlier "signed push" experiments.
* js/maint-merge-one-file-osx-expr (2011-10-06) 1 commit
(merged to 'next' on 2011-10-07 at fbb28a2)
+ merge-one-file: fix "expr: non-numeric argument"
Will merge to 'master' in the third wave.
* tm/completion-commit-fixup-squash (2011-10-06) 2 commits
- completion: commit --fixup and --squash
- completion: unite --reuse-message and --reedit-message handling
Looked reasonable but completion is not exactly in my area so I'd like to
see others the test these in the real life and give opinions first.
* tm/completion-push-set-upstream (2011-10-06) 1 commit
- completion: push --set-upstream
Looked reasonable but completion is not exactly in my area so I'd like to
see others the test these in the real life and give opinions first.
* js/no-cherry-pick-head-after-punted (2011-10-06) 1 commit
- Merge branch 'js/maint-no-cherry-pick-head-after-punted' into js/no-cherry-pick-head-after-punted
(this branch uses js/maint-no-cherry-pick-head-after-punted.)
Looked reasonable.
Will merge to 'next'.
* js/maint-no-cherry-pick-head-after-punted (2011-10-06) 2 commits
- cherry-pick: do not give irrelevant advice when cherry-pick punted
- revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
(this branch is used by js/no-cherry-pick-head-after-punted.)
Looked reasonable.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jk/http-auth-keyring (2011-09-28) 22 commits
- credential-cache: don't cache items without context
- check_expirations: don't copy over same element
- t0300: add missing EOF terminator for <<
- credential-store: use a better storage format
- t0300: make alternate username tests more robust
- t0300: make askpass tests a little more robust
- credential-cache: fix expiration calculation corner cases
- docs: minor tweaks to credentials API
- credentials: make credential_fill_gently() static
- credentials: add "getpass" helper
- credentials: add "store" helper
- credentials: add "cache" helper
- docs: end-user documentation for the credential subsystem
- http: use hostname in credential description
- allow the user to configure credential helpers
- look for credentials in config before prompting
- http: use credential API to get passwords
- introduce credentials API
- http: retry authentication failures for all http requests
- remote-curl: don't retry auth failures with dumb protocol
- improve httpd auth tests
- url: decode buffers that are not NUL-terminated
(this branch is used by js/cred-macos-x-keychain-2.)
Kicked back to 'pu' to allow design level discussions to continue.
* js/cred-macos-x-keychain-2 (2011-10-06) 1 commit
- contrib: add a pair of credential helpers for Mac OS X's keychain
(this branch uses jk/http-auth-keyring.)
Kicked back to 'pu' to allow design level discussions to continue.
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
The second from the bottom one needs to be replaced with a properly
written commit log message.
* fg/submodule-auto-push (2011-09-11) 2 commits
- submodule.c: make two functions static
- push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
--------------------------------------------------
[Cooking]
* sp/smart-http-failure (2011-10-04) 1 commit
(merged to 'next' on 2011-10-06 at 02f9982)
+ remote-curl: Fix warning after HTTP failure
Will merge to 'master' in the second wave.
* cb/do-not-pretend-to-hijack-long-help (2011-10-05) 1 commit
(merged to 'next' on 2011-10-06 at 46851fe)
+ use -h for synopsis and --help for manpage consistently
Will merge to 'master' in the second wave.
* cp/git-web-browse-browsers (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at da42ad0)
+ git-web--browse: avoid the use of eval
Will merge to 'master' in the third wave.
* il/archive-err-signal (2011-10-05) 1 commit
(merged to 'next' on 2011-10-06 at 7e3083f)
+ Support ERR in remote archive like in fetch/push
* nd/daemon-log-sock-errors (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at 5f3630f)
+ daemon: log errors if we could not use some sockets
* nd/document-err-packet (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at 0c5f5d0)
+ pack-protocol: document "ERR" line
Will merge to 'master' in the second wave.
* nd/git-daemon-error-msgs (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at 209126d)
+ daemon: return "access denied" if a service is not allowed
* jc/is-url-simplify (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at d6c6741)
+ url.c: simplify is_url()
Will merge to 'master' in the third wave.
* jn/ident-from-etc-mailname (2011-10-06) 2 commits
(merged to 'next' on 2011-10-06 at a68770d)
+ ident: do not retrieve default ident when unnecessary
+ ident: check /etc/mailname if email is unknown
* jn/no-g-plus-s-on-bsd (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at 3d85674)
+ Makefile: do not set setgid bit on directories on GNU/kFreeBSD
Will merge to 'master' in the third wave.
* js/log-show-children (2011-10-04) 1 commit
(merged to 'next' on 2011-10-06 at de8f6f2)
+ log --children
Will merge to 'master' in the third wave.
* rs/name-rev-usage (2011-10-03) 1 commit
(merged to 'next' on 2011-10-06 at e51878e)
+ name-rev: split usage string
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* rs/test-ctype (2011-10-03) 2 commits
(merged to 'next' on 2011-10-06 at b8c26d2)
+ test-ctype: add test for is_pathspec_magic
+ test-ctype: macrofy
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* rs/pending (2011-10-03) 8 commits
(merged to 'next' on 2011-10-06 at 998462b)
+ commit: factor out clear_commit_marks_for_object_array
+ checkout: use leak_pending flag
+ bundle: use leak_pending flag
+ bisect: use leak_pending flag
+ revision: add leak_pending flag
+ checkout: use add_pending_{object,sha1} in orphan check
+ revision: factor out add_pending_sha1
+ checkout: check for "Previous HEAD" notice in t2020
* ph/transport-with-gitfile (2011-10-04) 4 commits
(merged to 'next' on 2011-10-06 at 891b8b6)
+ Add test showing git-fetch groks gitfiles
+ Teach transport about the gitfile mechanism
+ Learn to handle gitfiles in enter_repo
+ enter_repo: do not modify input
* jc/grep-untracked-exclude (2011-10-04) 1 commit
(merged to 'next' on 2011-10-06 at b16cffe)
+ Merge branch 'jc/maint-grep-untracked-exclude' into jc/grep-untracked-exclude
(this branch uses bw/grep-no-index-no-exclude and jc/maint-grep-untracked-exclude.)
* jc/maint-grep-untracked-exclude (2011-10-04) 1 commit
+ grep: teach --untracked and --exclude-standard options
(this branch is used by jc/grep-untracked-exclude; uses bw/grep-no-index-no-exclude.)
* dm/tree-walk (2011-09-28) 2 commits
(merged to 'next' on 2011-10-06 at 76e90c3)
+ tree-walk: micro-optimization in tree_entry_interesting
+ tree-walk: drop unused parameter from match_dir_prefix
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* cs/perl-config-path-send-email (2011-09-30) 2 commits
(merged to 'next' on 2011-10-06 at 93c00f0)
+ use new Git::config_path() for aliasesfile
+ Add Git::config_path()
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* jc/checkout-from-tree-keep-local-changes (2011-09-30) 1 commit
(merged to 'next' on 2011-10-06 at 64061aa)
+ checkout $tree $path: do not clobber local changes in $path not in $tree
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the fourth wave.
* jc/apply-blank-at-eof-fix (2011-09-26) 1 commit
(merged to 'next' on 2011-10-06 at a9dfd8f)
+ apply --whitespace=error: correctly report new blank lines at end
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the third wave.
* nd/sparse-doc (2011-09-26) 1 commit
(merged to 'next' on 2011-10-06 at f6b8355)
+ git-read-tree.txt: update sparse checkout examples
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* jp/get-ref-dir-unsorted (2011-09-30) 2 commits
(merged to 'next' on 2011-10-06 at 69fe65d)
+ refs: Use binary search to lookup refs faster
+ Don't sort ref_list too early
Will merge to 'master' in the third wave.
* jc/parse-options-boolean (2011-09-28) 5 commits
(merged to 'next' on 2011-10-06 at dd4936c)
+ apply: use OPT_NOOP_NOARG
+ revert: use OPT_NOOP_NOARG
+ parseopt: add OPT_NOOP_NOARG
+ archive.c: use OPT_BOOL()
+ parse-options: deprecate OPT_BOOLEAN
Will merge to 'master' in the second wave.
* mh/maint-notes-merge-pathbuf-fix (2011-09-27) 1 commit
(merged to 'next' on 2011-10-06 at 0af69bb)
+ notes_merge_commit(): do not pass temporary buffer to other function
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* ph/push-to-delete-nothing (2011-09-30) 1 commit
(merged to 'next' on 2011-10-06 at 33ac777)
+ receive-pack: don't pass non-existent refs to post-{receive,update} hooks
Will merge to 'master' in the fourth wave.
* ps/gitweb-js-with-lineno (2011-09-27) 1 commit
(merged to 'next' on 2011-10-06 at 9236f5e)
+ gitweb: Fix links to lines in blobs when javascript-actions are enabled
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* zj/send-email-authen-sasl (2011-09-29) 1 commit
(merged to 'next' on 2011-10-06 at 78b31cd)
+ send-email: auth plain/login fix
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the second wave.
* jc/maint-diffstat-numstat-context (2011-09-22) 1 commit
(merged to 'next' on 2011-10-06 at 36c972d)
+ diff: teach --stat/--numstat to honor -U$num
"diff" is allowed to match the common lines differently depending on how
many context lines it is showing, so running --(num)stat with 0 lines of
context internally gives a result that may be surprising to some people.
Originally merged to 'next' on 2011-09-26.
Will merge to 'master' in the second wave.
* nd/maint-sparse-errors (2011-09-22) 2 commits
(merged to 'next' on 2011-10-06 at e3cbb90)
+ Add explanation why we do not allow to sparse checkout to empty working tree
+ sparse checkout: show error messages when worktree shaping fails
Originally merged to 'next' on 2011-09-22.
Will merge to 'master' in the third wave.
* rs/diff-cleanup-records-fix (2011-10-03) 2 commits
(merged to 'next' on 2011-10-06 at 91f035f)
+ diff: resurrect XDF_NEED_MINIMAL with --minimal
+ Revert removal of multi-match discard heuristic in 27af01
Will merge to 'master' in the third wave.
* di/fast-import-empty-tag-note-fix (2011-09-22) 2 commits
(merged to 'next' on 2011-10-06 at 3a01ef1)
+ fast-import: don't allow to note on empty branch
+ fast-import: don't allow to tag empty branch
Originally merged to 'next' on 2011-10-05.
Will merge to 'master' in the fourth wave.
* bw/grep-no-index-no-exclude (2011-09-15) 2 commits
(merged to 'next' on 2011-10-06 at 325270b)
+ grep --no-index: don't use git standard exclusions
+ grep: do not use --index in the short usage output
(this branch is used by jc/grep-untracked-exclude and jc/maint-grep-untracked-exclude.)
Originally merged to 'next' on 2011-09-26.
Will merge to 'master' in the third wave.
* mh/check-ref-format-3 (2011-10-05) 23 commits
(merged to 'next' on 2011-10-06 at c277498)
+ add_ref(): verify that the refname is formatted correctly
+ resolve_ref(): expand documentation
+ resolve_ref(): also treat a too-long SHA1 as invalid
+ resolve_ref(): emit warnings for improperly-formatted references
+ resolve_ref(): verify that the input refname has the right format
+ remote: avoid passing NULL to read_ref()
+ remote: use xstrdup() instead of strdup()
+ resolve_ref(): do not follow incorrectly-formatted symbolic refs
+ resolve_ref(): extract a function get_packed_ref()
+ resolve_ref(): turn buffer into a proper string as soon as possible
+ resolve_ref(): only follow a symlink that contains a valid, normalized refname
+ resolve_ref(): use prefixcmp()
+ resolve_ref(): explicitly fail if a symlink is not readable
+ Change check_refname_format() to reject unnormalized refnames
+ Inline function refname_format_print()
+ Make collapse_slashes() allocate memory for its result
+ Do not allow ".lock" at the end of any refname component
+ Refactor check_refname_format()
+ Change check_ref_format() to take a flags argument
+ Change bad_ref_char() to return a boolean value
+ git check-ref-format: add options --allow-onelevel and --refspec-pattern
+ t1402: add some more tests
+ get_sha1_hex(): do not read past a NUL character
* js/bisect-no-checkout (2011-09-21) 1 commit
(merged to 'next' on 2011-10-06 at 0354e94)
+ bisect: fix exiting when checkout failed in bisect_start()
Originally merged to 'next' on 2011-09-21.
Will merge to 'master' in the third wave.
* jc/request-pull-show-head-4 (2011-10-07) 8 commits
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Will merge to 'master' in the fourth wave.
* jm/mergetool-pathspec (2011-09-26) 2 commits
(merged to 'next' on 2011-10-06 at b8e830f)
+ mergetool: no longer need to save standard input
+ mergetool: Use args as pathspec to unmerged files
Originally merged to 'next' on 2011-09-26.
Will merge to 'master' in the second wave.
* nd/maint-autofix-tag-in-head (2011-09-18) 4 commits
(merged to 'next' on 2011-10-06 at c083e69)
+ Accept tags in HEAD or MERGE_HEAD
+ merge: remove global variable head[]
+ merge: use return value of resolve_ref() to determine if HEAD is invalid
+ merge: keep stash[] a local variable
Originally merged to 'next' on 2011-09-27.
Will merge to 'master' in the third wave.
* bc/attr-ignore-case (2011-10-06) 5 commits
- attr.c: respect core.ignorecase when matching attribute patterns
- attr: read core.attributesfile from git_default_core_config
- builtin/mv.c: plug miniscule memory leak
- cleanup: use internal memory allocation wrapper functions everywhere
- attr.c: avoid inappropriate access to strbuf "buf" member
Re-rolled.
* mz/remote-rename (2011-09-11) 4 commits
(merged to 'next' on 2011-10-06 at 96db20d)
+ remote: only update remote-tracking branch if updating refspec
+ remote rename: warn when refspec was not updated
+ remote: "rename o foo" should not rename ref "origin/bar"
+ remote: write correct fetch spec when renaming remote 'remote'
Originally merged to 'next' on 2011-09-26.
Will merge to 'master' in the second wave.
* cb/common-prefix-unification (2011-09-12) 3 commits
(merged to 'next' on 2011-10-06 at 8349bca)
+ rename pathspec_prefix() to common_prefix() and move to dir.[ch]
+ consolidate pathspec_prefix and common_prefix
+ remove prefix argument from pathspec_prefix
Originally merged to 'next' on 2011-09-14.
Will merge to 'master' in the second wave.
* jn/maint-http-error-message (2011-09-06) 2 commits
(merged to 'next' on 2011-10-06 at 668a706)
+ http: avoid empty error messages for some curl errors
+ http: remove extra newline in error message
Originally merged to 'next' on 2011-09-12.
Will merge to 'master' in the second wave.
* mh/iterate-refs (2011-09-11) 7 commits
(merged to 'next' on 2011-10-06 at c7a33e5)
+ refs.c: make create_cached_refs() static
+ Retain caches of submodule refs
+ Store the submodule name in struct cached_refs
+ Allocate cached_refs objects dynamically
+ Change the signature of read_packed_refs()
+ Access reference caches only through new function get_cached_refs()
+ Extract a function clear_cached_refs()
Originally merged to 'next' on 2011-09-27.
Will merge to 'master' in the second wave.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-10-06 at 4c105df)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Originally merged to 'next' on 2011-08-24.
Will merge to 'master' in the second wave.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-10-06 at 3526bb9)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
Originally merged to 'next' on 2011-08-23.
Will merge to 'master' in the second wave.
--------------------------------------------------
[Discarded]
* jk/default-attr (2011-09-12) 1 commit
. attr: map builtin userdiff drivers to well-known extensions
Discarded, expecting a fresh re-roll.
* jc/make-static (2011-09-14) 4 commits
. exec_cmd.c: prepare_git_cmd() is sometimes used
. environment.c: have_git_dir() has users on Cygwin
. vcs-svn: remove unused functions and make some static
. make-static: master
* jk/add-i-hunk-filter (2011-07-27) 5 commits
. add--interactive: add option to autosplit hunks
. add--interactive: allow negatation of hunk filters
. add--interactive: allow hunk filtering on command line
. add--interactive: factor out regex error handling
. add--interactive: refactor patch mode argument processing
* jc/signed-push (2011-10-05) 7 commits
. push -s: support pre-receive-signature hook
. push -s: receiving end
. push -s: send signed push certificate
. push -s: skeleton
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch is tangled with jc/signed-commit and jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-10-05) 4 commits
. push -s: signed push
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch is tangled with jc/signed-commit and jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
* jh/receive-count-limit (2011-05-23) 10 commits
. receive-pack: Allow server to refuse pushes with too many objects
. pack-objects: Estimate pack size; abort early if pack size limit is exceeded
. send-pack/receive-pack: Allow server to refuse pushing too large packs
. pack-objects: Allow --max-pack-size to be used together with --stdout
. send-pack/receive-pack: Allow server to refuse pushes with too many commits
. pack-objects: Teach new option --max-commit-count, limiting #commits in pack
. receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
. Tighten rules for matching server capabilities in server_supports()
. send-pack: Attempt to retrieve remote status even if pack-objects fails
. Update technical docs to reflect side-band-64k capability in receive-pack
Discarded, expecting another round to separate per-pack and per-session
limits.
* jk/generation-numbers (2011-09-11) 8 commits
. metadata-cache.c: make two functions static
. limit "contains" traversals based on commit generation
. check commit generation cache validity against grafts
. pretty: support %G to show the generation number of a commit
. commit: add commit_generation function
. add metadata-cache infrastructure
. decorate: allow storing values instead of pointers
. Merge branch 'jk/tag-contains-ab' (early part) into HEAD
* po/cygwin-backslash (2011-08-05) 2 commits
. On Cygwin support both UNIX and DOS style path-names
. git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Incomplete with respect to backslash processing in prefix_filename(), and
also loses the ability to escape glob specials.
^ permalink raw reply
* Re: How pretty is pretty? git cat-file -p inconsistency
From: Michael J Gruber @ 2011-10-07 20:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v62k0wudg.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.10.2011 20:04:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> That is, "cat file -p" pretty prints dates for tag objects but not for
>> commit objects. In fact, "-p" on commit objects does not prettify at all
>> compared to the raw content. Is that intentional?
>
> "cat-file -p" is an ill-conceived half-ass afterthought, and I do not
> think anybody sane considers it as part of the "plumbing" ultra stable
> interface for machine consumption. See a0f15fa (Pretty-print tagger
> dates., 2006-03-01).
Uh, I see. "git cat-file -p tagname" is a bit like the the missing "git
tag show tagname" or "git show tagname" without the commit.
>
>> I'd suggest
>> prettifying dates with "-p" for commit objects also.
>
> Please make it so. It is your choice to do a patch to update this single
> thing first, or to discuss the output with "-p" for all the other object
> types at the same time to get the list concensus before proceeding.
I never knew how ugly the output of "git tag-file tree sha1" is. I guess
it's the type of object whose format I don't know... We don't have an
object format description in Doc/technical, do we? tree.c doesn't tell
me much.
Looking at how "cat-file -p" for tags is done makes me not want to do it
for commits ;) We do have pretty "git show" for all types of objects,
though "git cat-file -p treeobject" is more informative than "git show
treeobject". I guess I have to make up my mind about what direction to go.
Michael
^ permalink raw reply
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Jonathan Nieder @ 2011-10-07 20:19 UTC (permalink / raw)
To: Alexey Shumkin
Cc: Johannes Sixt, Fabian Emmes, Alexander Gerasiov, git,
Junio C Hamano
In-Reply-To: <20111007165209.595834f2@ashu.dyn.rarus.ru>
Alexey Shumkin wrote:
> In development process under Windows non-UTF-8
> encoding is used (cp1251 in my case). So, filenames have this encoding,
> and as we know Git stores their names as is - in cp1251 - without a
> conversion. And filenames are also used in diff-stat (with
> core.quotepath= false
Yes, when a person sets [core] quotepath to false, I think it's fair to
assume for now that the filenames are in the same encoding as
everything else (whether that's UTF-8 or something else). Maybe it
would be possible in a separate patch to add a configurable list of
encodings to try out when formatting paths for display.
Jonathan
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Jonathan Nieder @ 2011-10-07 20:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <4E8EED39.1060607@drmicha.warpmail.net>
Hi again,
Michael J Gruber wrote:
> I really haven't seen any convincing argument against yet. The details
> (note attached to refname object, or literal refanmes in the notes tree
> as per Jeff) should be discussed further, of course, but if branch
> descriptions aren't "notesy" then I don't know what is.
As mentioned before, I don't want to debate how Junio should spend his
time (better for each person to provide relevant information and
improvements to help out or to spend time on the alternatives one is
interested in), but as a general question, this statement looked
interesting to me.
"git notes" has a funny name, but deep down, as you know, it's about
attaching additional versioned text to commit objects without changing
their names. Branch descriptions are not per commit object (and as a
mapping, the _keys_ are not shared), and personally I don't think they
should be versioned any more than the branch names are.
I wanted to emphasize this because
"git notes" is not the best tool for all annotations!
This ends this public service announcement.
> Alternatively, one could store the description in a blob and refer to
> that directly, of course. I.e., have
>
> refs/description/foo
>
> point to a blob whose content is the description of the ref
>
> ref/foo
Sure, that would be a sane alternative design. It has the advantage
of having the pumbing for fetching and pulling already set up, as you
mention. The only disadvantages I know of are
- "git branch -m" and "git remote rename" don't know about it yet
- there's not one flat file you can edit to run a search/replace on
all branch descriptions
and those aren't very serious problems.
>> I personally would prefer my branch descriptions to be non-versioned,
>> though I realize that is a matter of taste.
>
> Do you prefer you commit notes to be non-versioned?
No, I like them versioned. If I didn't, why wouldn't I have sent a
patch to change that? Maybe some day there will be a "git notes log"
tool to track the history of a note, taking changes in fanout into
account.
Hope that clarifies a little.
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Junio C Hamano @ 2011-10-07 20:09 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Phil Hord, Sitaram Chamarty, git
In-Reply-To: <20111006181522.GA2936@sita-lt.atc.tcs.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> This is useful if you forgot to restrict the diff to the paths you want
> to see, or selecting precisely the ones you want is too much typing.
>
> Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
> ---
>
> On Thu, Oct 06, 2011 at 10:36:40AM -0700, Junio C Hamano wrote:
>
>> Thanks. It is clear from the subject and the patch text that you are
>> changing "hit return to unconditionally launch" into "launch it if you
>> want to", but can you give justification why a choice not to launch is
>> needed in the log message?
>
> OK; done.
Looks OK from a cursory viewing. Do we want some additional tests?
For that matter, have you run the test suite with this patch applied (I
haven't)?
> git-difftool--helper.sh | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
> index 8452890..0468446 100755
> --- a/git-difftool--helper.sh
> +++ b/git-difftool--helper.sh
> @@ -38,15 +38,16 @@ launch_merge_tool () {
>
> # $LOCAL and $REMOTE are temporary files so prompt
> # the user with the real $MERGED name before launching $merge_tool.
> + ans=y
> if should_prompt
> then
> printf "\nViewing: '$MERGED'\n"
> if use_ext_cmd
> then
> - printf "Hit return to launch '%s': " \
> + printf "Launch '%s' [Y/n]: " \
> "$GIT_DIFFTOOL_EXTCMD"
> else
> - printf "Hit return to launch '%s': " "$merge_tool"
> + printf "Launch '%s' [Y/n]: " "$merge_tool"
> fi
> read ans
> fi
> @@ -54,9 +55,9 @@ launch_merge_tool () {
> if use_ext_cmd
> then
> export BASE
> - eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
> + test "$ans" != "n" && eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
> else
> - run_merge_tool "$merge_tool"
> + test "$ans" != "n" && run_merge_tool "$merge_tool"
> fi
> }
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Junio C Hamano @ 2011-10-07 19:59 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael J Gruber, git, Jeff King
In-Reply-To: <20111007195023.GA29712@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> I am surprised that you seem to have missed what I meant by "branch
> names are local"....
> This matters, a lot, because there is no easy way to partition a
> namespace of names descriptive for humans without a central authority
> to negotiate conflicts.
I think we are in total agreement. The branch names are local, but the
users may want to annotate to describe _the history_ they intend to build
on it.
Various ways to convey the description when the end product (i.e. the
history built on it) is shiped were outlined in the series, so that the
shipper can help the receiver understand the history. The information in
the annotation (i.e. the _value_ of branch.$name.description) is something
the shipper wants to share with the receiver, but the mapping between the
local name of the branch the shipper used to build that history (i.e. the
key "$name" in branch.$name.description) is immaterial in the end result.
I do not think there is much more for me to add to this topic, as I think
you covered all the important bases already.
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Jonathan Nieder @ 2011-10-07 19:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <4E8EED39.1060607@drmicha.warpmail.net>
Michael J Gruber wrote:
> Jonathan Nieder venit, vidit, dixit 07.10.2011 12:06:
>> [1] http://thread.gmane.org/gmane.comp.version-control.git/181953/focus=182000
>
> Funny to point me at a thread I participated in, when I'm saying this
> thread should have continued there ;)
Ah, sorry, I wasn't trying to initiate a debate. I provided the
pointer to save time for others who haven't looked up the thread
you were referring to yet.
I am surprised that you seem to have missed what I meant by "branch
names are local". I meant that what I call "master" is likely to be
very different from what you call "master". Yes, we share commits and
fetch them from each other, and I might even _decide_ that what I call
"master" will be similar to what you call "master". Luckily, in
practice people don't seem to feel constrained to decide so, and there
are many workflows where my "master" is not your "master" and does not
even contain commits that would be acceptable for your "master".
This matters, a lot, because there is no easy way to partition a
namespace of names descriptive for humans without a central authority
to negotiate conflicts.
^ permalink raw reply
* Re: [PATCH] Teach merge the '[-e|--edit]' option
From: Junio C Hamano @ 2011-10-07 19:40 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_DxrQCS8zn5KJ8HnpqShVbMw=zCbqDVa=w08EEibw=tsAA@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> The other inconsistencies I'm aware of between "merge --no-commit &&
> commit" vs "merge" on a clean merge are:
Perhaps you would want to add these to a list of todo items when gitwiki
comes back.
^ permalink raw reply
* Re: [PATCH] Teach merge the '[-e|--edit]' option
From: Jay Soffian @ 2011-10-07 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobxsvd69.fsf@alter.siamese.dyndns.org>
On Fri, Oct 7, 2011 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Think about it. What I suggested does no way make the situation
> worse. Your patch _does_ make it worse by changing the hook behaviour
> between "merge -m 'foo'" vs "merge -m 'foo' -e"
I think it's arguable how -e should behave. With -e opening my editor,
now I really feel like I'm making a commit and would be surprised by
not having the various commit hooks run.
j.
^ permalink raw reply
* Re: [PATCH] Teach merge the '[-e|--edit]' option
From: Jay Soffian @ 2011-10-07 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAG+J_Dz7-tTdgT=cqoKhK+fAhmESLnp93yHyxOF_NOY5Wx01+w@mail.gmail.com>
On Fri, Oct 7, 2011 at 2:01 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> I actually think a better choice would be to remove commit_tree() from
> merge and always have it run commit externally. I'm not seriously
> suggesting that be done, but it would make git more consistent. But
> I'm not going to send in a patch which makes the situation worse.
The other inconsistencies I'm aware of between "merge --no-commit &&
commit" vs "merge" on a clean merge are:
* reflog
- merge uses either "Merge made by the '...' strategy." OR "In-index merge"
- commit uses "commit (merge) <subject>"
* hooks
- merge calls
1) "prepare-commit-msg MERGE_MSG merge"
2) "post-merge [0|1]" where [0|1] indicates a squash or not.
- commit calls
1) "pre-commit"
2) "prepare-commit-msg COMMIT_EDITMSG merge"
3) "commit-msg COMMIT_EDITMSG"
4) "post-commit"
* gc
- merge calls "git gc --auto" after a successful merge unless
--squash was used
- commit does not call "git gc --auto"
* diffstat: merge shows it, commit does not
j.
^ permalink raw reply
* Re: [PATCH] Teach merge the '[-e|--edit]' option
From: Junio C Hamano @ 2011-10-07 19:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_Dz7-tTdgT=cqoKhK+fAhmESLnp93yHyxOF_NOY5Wx01+w@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> I actually think a better choice would be to remove commit_tree() from
> merge and always have it run commit externally. I'm not seriously
> suggesting that be done, but it would make git more consistent. But
> I'm not going to send in a patch which makes the situation worse.
Think about it. What I suggested does no way make the situation
worse. Your patch _does_ make it worse by changing the hook behaviour
between "merge -m 'foo'" vs "merge -m 'foo' -e".
^ permalink raw reply
* Re: Scalable reference handling
From: Martin Fick @ 2011-10-07 18:51 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4E8F2012.90108@alum.mit.edu>
On Friday, October 07, 2011 09:51:46 am Michael Haggerty
wrote:
> I can't write more now, but Martin, if you have time to
> benchmark 9944c7faf903a95d4ed9de284ace32debe21cdc1
> against your repository, I would be very interested to
> learn the results.
The fetch no longer seems to suffer from the large
regression, it is now faster (~7m) than 1.7.7 (which was
+15m).
As a quick note, if I comment out the
invalidate_cached_refs() call in write_ref_sha1() on line
2065 (on top of 9944c7), it is still much faster, only ~2m.
Perhaps growing the array on the fly with many refs is still
be too inefficient?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: git remote doesn't show remotes from .git/remotes
From: Junio C Hamano @ 2011-10-07 18:08 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill Likhodedov, git
In-Reply-To: <20111007150423.GA2076@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Oct 06, 2011 at 07:33:23PM +0400, Kirill Likhodedov wrote:
>
>> It seems that 'git remote' doesn't display remotes registered not in
>> .git/config but in .git/remotes/.
>> Is it a bug?
>
> It seems to have been lost in 211c896 (Make git-remote a builtin,
> 2008-02-29).
Sad.
> I don't think there is a specific plan. They're kept for backwards
> compatibility. But really, there is no reason to be using them at all at
> this point.
I've been thinking about making a list of deprecations/deletions for Git
2.0. The only two requirements needed to be added to the list are that it
gets list concensus and it is backed by a solid patch (or patch series).
^ permalink raw reply
* Re: How pretty is pretty? git cat-file -p inconsistency
From: Junio C Hamano @ 2011-10-07 18:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8EBC00.90909@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> That is, "cat file -p" pretty prints dates for tag objects but not for
> commit objects. In fact, "-p" on commit objects does not prettify at all
> compared to the raw content. Is that intentional?
"cat-file -p" is an ill-conceived half-ass afterthought, and I do not
think anybody sane considers it as part of the "plumbing" ultra stable
interface for machine consumption. See a0f15fa (Pretty-print tagger
dates., 2006-03-01).
> I'd suggest
> prettifying dates with "-p" for commit objects also.
Please make it so. It is your choice to do a patch to update this single
thing first, or to discuss the output with "-p" for all the other object
types at the same time to get the list concensus before proceeding.
Thanks.
^ 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