* Re: [PATCH 2/3] fetch: honor the user-provided refspecs when pruning refs
From: Jeff King @ 2011-10-07 16:26 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, Junio C Hamano, mathstuf
In-Reply-To: <1317936107-1230-3-git-send-email-cmn@elego.de>
On Thu, Oct 06, 2011 at 11:21:46PM +0200, Carlos Martín Nieto wrote:
> If the user gave us refspecs on the command line, we should use those
> when deciding whether to prune a ref instead of relying on the
> refspecs in the config.
>
> Previously, running
>
> git fetch --prune origin refs/heads/master:refs/remotes/origin/master
>
> would delete every other tag under the origin namespace because we
I assume you mean s/tag/branch/ in the last line?
> ---
> builtin/fetch.c | 6 ++--
> builtin/remote.c | 2 +-
> remote.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++-----
> remote.h | 3 +-
> 4 files changed, 77 insertions(+), 12 deletions(-)
Tests?
> static int get_stale_heads_cb(const char *refname,
> const unsigned char *sha1, int flags, void *cb_data)
> {
> struct stale_heads_info *info = cb_data;
> struct refspec refspec;
> + int ret;
> memset(&refspec, 0, sizeof(refspec));
> refspec.dst = (char *)refname;
> - if (!remote_find_tracking(info->remote, &refspec)) {
> - if (!((flags & REF_ISSYMREF) ||
> - string_list_has_string(info->ref_names, refspec.src))) {
> - struct ref *ref = make_linked_ref(refname, &info->stale_refs_tail);
> - hashcpy(ref->new_sha1, sha1);
> - }
> +
> + /*
> + * If the user speicified refspecs on the command line, we
> + * should only use those to check. Otherwise, look in the
> + * remote's configuration for the branch.
> + */
> + if (info->ref_count)
> + ret = find_in_refs(info->refs, info->ref_count, &refspec);
> + else
> + ret = remote_find_tracking(info->remote, &refspec);
Minor typo in the comment. But more importantly, this feels like a very
low-level place to be thinking about things like what the user gave us
on the command line.
Shouldn't get_stale_heads not get a remote at all, and just get a set of
refspecs? Those should be the minimal information it needs to get its
answer, right?
-Peff
^ permalink raw reply
* Re: [PATCH] show git tag output in pager
From: Jeff King @ 2011-10-07 16:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michal Vyskocil, git
In-Reply-To: <vpqsjn4dfi4.fsf@bauges.imag.fr>
On Fri, Oct 07, 2011 at 04:48:35PM +0200, Matthieu Moy wrote:
> > On Mon, Oct 03, 2011 at 02:57:09PM +0200, Matthieu Moy wrote:
> >
> >> I like the try_subcommand_pager idea. Ideally, there would also be a
> >> nice mechanism to set defaults for subcommands, so that "git tag
> >> <whatever>" does the right thing without configuration.
> >
> > That's easy enough. Something like the patch below?
>
> It may have been better with a big centralized array of configurations
> like
>
> static struct cmd_struct commands[] = {
> { "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
> ...
>
> in git.c, but if we have only a few instances of this, your system is
> probably fine. I like it.
I don't think you can centralize it in the same way, because some of it
will have to be implemented in shell script (unlike the full-command
ones, which we can always trigger at the git.c wrapper layer).
So you could have:
static struct pager_default subcommands[] = {
{ "tag.list", 1 },
{ "branch.list", 1 },
};
but you'll never be able to put "stash.list" into that structure (and as
you probably guessed, my patch isn't enough to implement stash.list,
either; it would need a shell implementation of try_subcommand_pager).
-Peff
^ permalink raw reply
* Scalable reference handling
From: Michael Haggerty @ 2011-10-07 15:51 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <4E8E6E8E.5070909@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
On 10/07/2011 05:14 AM, Michael Haggerty wrote:
> On 10/07/2011 12:16 AM, Martin Fick wrote:
>> I downloaded your patch series and tested it on my repos.
>
> Very cool (though a bit premature, as you discovered). The patch series
> still has a known performance regression in the area of
> do_for_each_ref(), which I hope to figure out soon. I will definitely
> tell you when I think that the patch series is ready for more serious
> testing (hopefully today) in the hopes that you can benchmark it against
> your repo.
I just pushed versions to github that I think are ready for some
preliminary testing. There were some silly inefficiencies in the
version that you tested earlier, so this version is considerably faster
in a few key tests.
I don't have complete benchmarking results, but I have attached what I
have. I wouldn't put much weight on small differences in the numbers
because the computer was not 100% quiescent while I ran the tests. But
I think the results are impressive: the new code (columns 5-8) is a bit
slower in only a few cases but faster (sometimes by a large factor) in
many other cases.
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.
BTW I am not asking anybody to review the patch series yet; I would like
to do some more tests and cleanup first. But of course I wouldn't
object to feedback. A good starting point would be the comments at the
top of refs.c, where the basic data structures are explained.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
[-- Attachment #2: refperf-summary-3.out --]
[-- Type: text/plain, Size: 4983 bytes --]
=================================== ======= ======= ======= ======= ======= ======= ======= ======= =======
Test name [0] [1] [2] [3] [4] [5] [6] [7] [8]
=================================== ======= ======= ======= ======= ======= ======= ======= ======= =======
branch-loose-cold 5.14 5.80 4.98 4.55 5.03 0.41 0.45 0.45 0.51
branch-loose-warm 0.10 0.12 0.12 0.19 0.11 0.02 0.02 0.03 0.02
for-each-ref-loose-cold 6.02 6.36 7.48 5.62 6.27 5.32 5.02 5.24 5.01
for-each-ref-loose-warm 0.25 0.25 0.27 0.25 0.25 0.26 0.26 0.25 0.26
checkout-loose-cold 5.47 5.03 5.66 5.39 5.72 0.65 0.77 0.95 0.59
checkout-loose-warm 0.11 0.11 0.11 0.11 0.11 0.02 0.03 0.03 0.03
checkout-orphan-loose 0.09 0.09 0.10 0.10 0.10 0.03 0.01 0.01 0.02
checkout-from-detached-loose-cold N/A N/A N/A N/A N/A N/A N/A N/A N/A
checkout-from-detached-loose-warm N/A N/A N/A N/A N/A N/A N/A N/A N/A
branch-contains-loose-cold 14.69 13.95 13.76 13.84 14.07 14.08 14.12 14.01 14.77
branch-contains-loose-warm 8.99 8.89 8.74 8.82 8.80 8.81 8.84 8.76 8.91
pack-refs-loose 1.23 1.02 1.02 1.02 1.01 1.02 1.00 0.99 1.03
branch-packed-cold 0.66 0.65 0.84 0.67 0.52 0.76 0.58 0.55 0.59
branch-packed-warm 0.01 0.01 0.03 0.03 0.02 0.02 0.05 0.02 0.05
for-each-ref-packed-cold 1.38 1.29 1.07 1.13 1.05 1.08 1.26 1.05 1.27
for-each-ref-packed-warm 0.17 0.16 0.17 0.17 0.17 0.16 0.17 0.16 0.16
checkout-packed-cold 8.74 7.75 7.75 1.59 1.61 1.79 1.54 1.55 1.53
checkout-packed-warm 0.03 0.05 0.04 0.04 0.05 0.05 0.03 0.05 0.06
checkout-orphan-packed 0.04 0.01 0.01 0.03 0.02 0.02 0.05 0.05 0.02
checkout-from-detached-packed-cold 8.88 8.22 8.12 1.98 1.81 1.94 1.99 1.88 1.97
checkout-from-detached-packed-warm 6.55 6.43 6.44 0.44 0.46 0.45 0.46 0.46 0.49
branch-contains-packed-cold 11.59 10.73 10.37 9.42 9.24 9.40 9.37 9.56 9.34
branch-contains-packed-warm 10.20 9.79 9.83 8.68 8.61 8.68 8.61 8.82 9.33
clone-loose-cold 105.58 86.98 89.42 88.96 88.19 87.01 87.20 87.11 88.20
clone-loose-warm 3.26 3.11 3.18 3.10 3.17 3.14 3.14 3.21 3.16
fetch-nothing-loose 0.85 0.84 0.86 0.85 0.84 0.88 0.84 0.84 0.84
pack-refs 0.12 0.14 0.16 0.13 0.15 0.14 0.14 0.15 0.14
fetch-nothing-packed 0.84 0.84 0.86 0.85 0.89 0.85 0.84 0.84 0.83
clone-packed-cold 2.72 2.33 2.11 2.19 2.23 2.14 2.24 2.01 2.16
clone-packed-warm 0.40 0.40 0.33 0.40 0.28 0.29 0.33 0.31 0.31
fetch-everything-cold 106.28 92.92 94.12 88.76 91.62 88.75 89.49 89.78 91.43
fetch-everything-warm 5.56 5.63 5.70 5.62 5.63 5.66 5.69 5.71 5.78
=================================== ======= ======= ======= ======= ======= ======= ======= ======= =======
[0] v1.7.6 (refperf.times.d78c84e8698e750139667bc724b08eb34e795b65)
[1] v1.7.7 (refperf.times.a258e475eb74e183e9e68ca30e32c5253081356d)
[2] origin/master (refperf.times.27897d25f1b36d400b82b655701b87fd205dbc2f)
[3] 16583974c20b856bb60b5a733020425c16a19670^ (refperf.times.558b49c8489c95cf966b959c3444c95d177dc4dc)
[4] 16583974c20b856bb60b5a733020425c16a19670 (refperf.times.16583974c20b856bb60b5a733020425c16a19670)
[5] origin/hierarchical-refs^^^^ (refperf.times.5f5a126553eef88455f7deb2745c5f93073bfe69)
[6] origin/hierarchical-refs^^^ (refperf.times.a306af145856f8296bf2ff4a3ace5e86ac3b1fc8)
[7] origin/hierarchical-refs^ (refperf.times.fd53cf7a7fcc360f30ea0ec5b964cefeec70c11b)
[8] origin/hierarchical-refs (refperf.times.9944c7faf903a95d4ed9de284ace32debe21cdc1)
^ permalink raw reply
* Re: git remote doesn't show remotes from .git/remotes
From: Kirill Likhodedov @ 2011-10-07 15:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111007150423.GA2076@sigill.intra.peff.net>
07.10.2011, в 19:04, Jeff King wrote
> I'm not sure how much we
> care, though. We haven't generated .git/remotes files in a long time,
> and this is the first notice of the bug after 3.5 years. Is this an old
> repo that has remotes, or are you wondering if you should use them in a
> new repo?
>
No, I never came across any usages of .git/remotes.
I am writing a Git integration plugin for an IDE, and was studying documentation for git-remote where I saw this method to define remotes.
So I've just decided to report the lack of the 'git remote' output and make sure that I didn't miss anything. And also decide if I have to support them in the product - probably, not.
I agree that the bug is not worth fixing since nobody uses .git/remotes anyway.
Thanks for the clarification.
^ permalink raw reply
* [PATCH] Teach merge the '[-e|--edit]' option
From: Jay Soffian @ 2011-10-07 15:29 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Todd A. Jacobs
Implement "git merge [-e|--edit]" as "git merge --no-commit && git commit"
as a convenience for the user.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Documentation/merge-options.txt | 6 ++++++
builtin/merge.c | 14 ++++++++++++++
t/t7600-merge.sh | 15 +++++++++++++++
3 files changed, 35 insertions(+), 0 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..815e151487 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,
@@ -1092,6 +1095,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
option_commit = 0;
}
+ /* if not committing, edit is nonsensical */
+ if (!option_commit)
+ option_edit = 0;
+ /* if editing, invoke 'git commit -e' after successful merge */
+ if (option_edit)
+ option_commit = 0;
+
if (!allow_fast_forward && fast_forward_only)
die(_("You cannot combine --no-ff with --ff-only."));
@@ -1447,6 +1457,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
if (merge_was_ok) {
+ if (option_edit) {
+ const char *args[] = {"commit", "-e", NULL};
+ return run_command_v_opt(args, RUN_GIT_CMD);
+ }
fprintf(stderr, _("Automatic merge went well; "
"stopped before committing as requested\n"));
return 0;
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.g00fdf
^ permalink raw reply related
* Re: git remote doesn't show remotes from .git/remotes
From: Jeff King @ 2011-10-07 15:04 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: git
In-Reply-To: <26866FC7-4D4D-46D0-89DE-85AF459AC48C@jetbrains.com>
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).
It wouldn't be that hard to add it back in. I'm not sure how much we
care, though. We haven't generated .git/remotes files in a long time,
and this is the first notice of the bug after 3.5 years. Is this an old
repo that has remotes, or are you wondering if you should use them in a
new repo?
> Btw, are there advantages in using .git/remotes/ instead of .git/config ?
No. They were an older format, and were replaced by having the remote
defined in the configuration (and there are many things you can specify
in the config that you can't do via .git/remotes).
> If not, are there plans to remove .git/remotes/ support in future versions?
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.
-Peff
^ permalink raw reply
* Re: [PATCH] show git tag output in pager
From: Matthieu Moy @ 2011-10-07 14:48 UTC (permalink / raw)
To: Jeff King; +Cc: Michal Vyskocil, git
In-Reply-To: <20111007144438.GA30318@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 03, 2011 at 02:57:09PM +0200, Matthieu Moy wrote:
>
>> I like the try_subcommand_pager idea. Ideally, there would also be a
>> nice mechanism to set defaults for subcommands, so that "git tag
>> <whatever>" does the right thing without configuration.
>
> That's easy enough. Something like the patch below?
It may have been better with a big centralized array of configurations
like
static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
...
in git.c, but if we have only a few instances of this, your system is
probably fine. I like it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] show git tag output in pager
From: Jeff King @ 2011-10-07 14:44 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michal Vyskocil, git
In-Reply-To: <vpqwrcmw7ve.fsf@bauges.imag.fr>
On Mon, Oct 03, 2011 at 02:57:09PM +0200, Matthieu Moy wrote:
> I like the try_subcommand_pager idea. Ideally, there would also be a
> nice mechanism to set defaults for subcommands, so that "git tag
> <whatever>" does the right thing without configuration.
That's easy enough. Something like the patch below?
Still thoroughly untested, but it looks Obviously Correct to me. :)
---
builtin.h | 1 +
builtin/tag.c | 1 +
git.c | 13 +++++++++++++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin.h b/builtin.h
index 0e9da90..b2badf8 100644
--- a/builtin.h
+++ b/builtin.h
@@ -35,6 +35,7 @@ int copy_note_for_rewrite(struct notes_rewrite_cfg *c,
void finish_copy_notes_for_rewrite(struct notes_rewrite_cfg *c);
extern int check_pager_config(const char *cmd);
+extern void try_subcommand_pager(const char *subcommand, int fallback);
extern int textconv_object(const char *path, unsigned mode, const unsigned char *sha1, char **buf, unsigned long *buf_size);
diff --git a/builtin/tag.c b/builtin/tag.c
index 9d89616..c77adc4 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -152,6 +152,7 @@ static int list_tags(const char **patterns, int lines,
filter.lines = lines;
filter.with_commit = with_commit;
+ try_subcommand_pager("tag.list", 1);
for_each_tag_ref(show_reference, (void *) &filter);
return 0;
diff --git a/git.c b/git.c
index 8e34903..11ee1a8 100644
--- a/git.c
+++ b/git.c
@@ -64,6 +64,19 @@ static void commit_pager_choice(void) {
}
}
+void try_subcommand_pager(const char *subcommand, int fallback)
+{
+ /* it's too late to turn off a running pager */
+ if (pager_in_use())
+ return;
+
+ if (use_pager == -1)
+ use_pager = check_pager_config(subcommand);
+ if (use_pager == -1)
+ use_pager = fallback;
+ commit_pager_choice();
+}
+
static int handle_options(const char ***argv, int *argc, int *envchanged)
{
const char **orig_argv = *argv;
--
1.7.7.rc2.7.gdfc92
^ permalink raw reply related
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Alexey Shumkin @ 2011-10-07 12:52 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Johannes Sixt, Fabian Emmes, Alexander Gerasiov, git,
Junio C Hamano
In-Reply-To: <20111007090601.GA22541@elie.hsd1.il.comcast.net>
> Johannes Sixt wrote:
> > Am 9/20/2011 12:42, schrieb Shumkin Alexey:
>
> >> 1. post-send-mail uses description file of a repo
> >> 2. gitweb also uses this file and AFAIK it assumes one to be in
> >> UTF-8 (I do not know whether it can be changed there but I tested
> >> gitweb once long time ago)
> >> 3. So if i18n.logoutputencoding is not UTF-8 we get a message
> >> composed with mixed encodings. This fact oblidge us to encode
> >> headers (as quoted printable at least) and synchronize body
> >> message that contain repo description (in UTF-8) and diffstat (in
> >> i18n.logoutputencoding).
> [...]
> > In this case, it may make sense to have a separate setting, but you
> > should call git like this:
> >
> > git -c "i18n.logoutputencoding=$emailcharset" show ...
> > git -c "i18n.logoutputencoding=$emailcharset" rev-list
> > --pretty ...
>
> Something like this, I suppose?
>
> This teaches post-receive-email to use plumbing where possible and to
> explicitly declare what encoding it expects output to use. Completely
> untested --- basic sanity checking, testing, and tweaks to allow
> overriding the choice of encoding left as an exercise to the reader.
>
> Based on patches by Gerrit Pape and Jeff King and advice from Johannes
> Sixt.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> More background:
> http://thread.gmane.org/gmane.comp.version-control.git/124350/focus=124355
>
> contrib/hooks/post-receive-email | 15 +++++++++------
> 1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email
> b/contrib/hooks/post-receive-email index ba077c13..bc603b02 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -234,6 +234,9 @@ generate_email_header()
> cat <<-EOF
> To: $recipients
> Subject: ${emailprefix}$projectdesc $refname_type
> $short_refname ${change_type}d. $describe
> + MIME-Version: 1.0
> + Content-Type: text/plain; charset=utf-8
> + Content-Transfer-Encoding: 8bit
> X-Git-Refname: $refname
> X-Git-Reftype: $refname_type
> X-Git-Oldrev: $oldrev
> @@ -462,7 +465,7 @@ generate_delete_branch_email()
> echo " was $oldrev"
> echo ""
> echo $LOGEND
> - git show -s --pretty=oneline $oldrev
> + git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
> echo $LOGEND
> }
>
> @@ -538,11 +541,11 @@ generate_atag_email()
> # performed on them
> if [ -n "$prevtag" ]; then
> # Show changes since the previous release
> - git rev-list --pretty=short
> "$prevtag..$newrev" | git shortlog
> + git shortlog --encoding=UTF-8
> "$prevtag..$newrev" else
> # No previous tag, show all the changes
> since time # began
> - git rev-list --pretty=short $newrev | git
> shortlog
> + git shortlog --encoding=UTF-8 "$newrev"
> fi
> ;;
> *)
> @@ -562,7 +565,7 @@ generate_delete_atag_email()
> echo " was $oldrev"
> echo ""
> echo $LOGEND
> - git show -s --pretty=oneline $oldrev
> + git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
> echo $LOGEND
> }
>
> @@ -608,7 +611,7 @@ generate_general_email()
> echo ""
> if [ "$newrev_type" = "commit" ]; then
> echo $LOGBEGIN
> - git show --no-color --root -s --pretty=medium $newrev
> + git diff-tree --encoding=UTF-8 --root -s
> --pretty=oneline $newrev echo $LOGEND
> else
> # What can we do here? The tag marks an object that
> is not @@ -627,7 +630,7 @@ generate_delete_general_email()
> echo " was $oldrev"
> echo ""
> echo $LOGEND
> - git show -s --pretty=oneline $oldrev
> + git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
> echo $LOGEND
> }
>
As I understand, this patches make email message with explicitly set
Content-Type header (it's ok) and UTF-8 encoding (that is a subject
to discuss).
My proposition was in to send email message in explicitly defined
custom encoding. Why? 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, BTW, I did not take into account this config)
without any conversion. So if we'll make all text in UTF-8 but
filenames are still non-UTF-8, email would look corrupted.
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Michael J Gruber @ 2011-10-07 12:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20111007100646.GA23193@elie.hsd1.il.comcast.net>
Jonathan Nieder venit, vidit, dixit 07.10.2011 12:06:
> Michael J Gruber wrote:
>
>> But my main point here is that we should discuss the pros and cons of
>> each approach in context (the context of the original thread), and I
>> haven't heard many pros and cons for either.
>
> Ok, here are some thoughts (you can file them under the "pro" or "con"
> column according to your taste):
>
> Branch names are local.
You can pull a branch only if you know its name, or using a wildcard
refspec. In both cases you know the translation from what is local on
the other side to your side. In the vast majority it will be the simple
refs/heads/foo -> refs/remotes/bar/foo mapping.
> The same tip commit can belong to multiple branches, which would make
> using the tip commit as a key for the branch description problematic.
Sure, tip commit is a no-go.
That's why I propose notes tacked onto refnames.
> I don't think git notes are a good fit for this purpose.
Why not?
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.
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.)
But it still has the advantage of being easily pushable and shareable.
Heck, config is config and not metadata ;)
> 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? Probably, but still
they are, and you don't need to care. Just don't run log on your notes ref.
> Some other information about a branch (such as which upstream branch
> it pulls from) is stored in the [branch "<branchname>"] section of the
> git configuration, so it makes a certain kind of sense to put the
> branch description there, too. On the other hand, the possibility of
> a [branch "<branchname>"] section in ~/.gitconfig has always been
> strange, and this is no exception.
Note that most use cases for branch descriptions that have been
described so far (format-patch cover-letter, merge-msg, pull-request
message) are about distributing that information. Not very local.
>> I'd be surprised if we changed the protocol just to be able to share
>> some descriptions, when we have everything we need for sharing refs.
>
> The impact of such a protocol change would not have to be as dramatic
> as you seem to be suggesting. Virtual hosts and peeled ref values
> were added as backward-compatible extensions to the reference
> discovery protocol (see Documentation/technical/pack-protocol.txt)
> which can be taken as examples for inspiration.
I don't see how a protocol change could solve the perceived issue with
localality of name, and indeed what it could solve that can't be solved
with existing methods.
> Here's some discussion of the implementation based on branchname-keyed
> notes that you mentioned [1]. It is nice to have multiple designs
> available for trying out, and I hope experience using each reveals
> potential improvements in the other.
>
> [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 ;)
Michael
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Nguyen Thai Ngoc Duy @ 2011-10-07 11:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Robin H. Johnson, Junio C Hamano
In-Reply-To: <4E8EBAFE.8020805@drmicha.warpmail.net>
On Fri, Oct 7, 2011 at 7:40 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>> 3. If I have prepared a series on a local branch, and I want to sign all
>> of them, is this a variant of rebase or?
>
> If you really want to sign all you can rebase-i and use "exec" to do
> that automatically, but there's no point: signing the top-most commit
> serves the same purpose.
I think Gentoo wants identity, who (typically a Gentoo dev) signs this
particular commit and takes responsibility for making sure the commit
follows all kinds of Gentoo requirements. Commits can be passed
around, author and committer are not a reliable source.
--
Duy
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Jonathan Nieder @ 2011-10-07 10:06 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <4E8ECA25.205@drmicha.warpmail.net>
Michael J Gruber wrote:
> But my main point here is that we should discuss the pros and cons of
> each approach in context (the context of the original thread), and I
> haven't heard many pros and cons for either.
Ok, here are some thoughts (you can file them under the "pro" or "con"
column according to your taste):
Branch names are local.
The same tip commit can belong to multiple branches, which would make
using the tip commit as a key for the branch description problematic.
I don't think git notes are a good fit for this purpose.
I personally would prefer my branch descriptions to be non-versioned,
though I realize that is a matter of taste.
Some other information about a branch (such as which upstream branch
it pulls from) is stored in the [branch "<branchname>"] section of the
git configuration, so it makes a certain kind of sense to put the
branch description there, too. On the other hand, the possibility of
a [branch "<branchname>"] section in ~/.gitconfig has always been
strange, and this is no exception.
> I'd be surprised if we changed the protocol just to be able to share
> some descriptions, when we have everything we need for sharing refs.
The impact of such a protocol change would not have to be as dramatic
as you seem to be suggesting. Virtual hosts and peeled ref values
were added as backward-compatible extensions to the reference
discovery protocol (see Documentation/technical/pack-protocol.txt)
which can be taken as examples for inspiration.
Here's some discussion of the implementation based on branchname-keyed
notes that you mentioned [1]. It is nice to have multiple designs
available for trying out, and I hope experience using each reveals
potential improvements in the other.
[1] http://thread.gmane.org/gmane.comp.version-control.git/181953/focus=182000
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Michael J Gruber @ 2011-10-07 9:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20111007091636.GA22822@elie.hsd1.il.comcast.net>
Jonathan Nieder venit, vidit, dixit 07.10.2011 11:16:
> Michael J Gruber wrote:
>
>> config based is so non-distributed, local in nature.
>
> I don't follow. Wouldn't a protocol change be enough to fix that, by
> sharing branch descriptions analagously to how refs themselves are
> shared?
I'd be surprised if we changed the protocol just to be able to share
some descriptions, when we have everything we need for sharing refs.
Also note that config is non-versioned etc.
But my main point here is that we should discuss the pros and cons of
each approach in context (the context of the original thread), and I
haven't heard many pros and cons for either.
Michael
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Jonathan Nieder @ 2011-10-07 9:16 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4E8EBDA7.2040007@drmicha.warpmail.net>
Michael J Gruber wrote:
> config based is so non-distributed, local in nature.
I don't follow. Wouldn't a protocol change be enough to fix that, by
sharing branch descriptions analagously to how refs themselves are
shared?
^ permalink raw reply
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Jonathan Nieder @ 2011-10-07 9:06 UTC (permalink / raw)
To: Johannes Sixt
Cc: zapped, Fabian Emmes, Alexander Gerasiov, git, Junio C Hamano
In-Reply-To: <4E7874B9.2060909@viscovery.net>
Johannes Sixt wrote:
> Am 9/20/2011 12:42, schrieb Shumkin Alexey:
>> 1. post-send-mail uses description file of a repo
>> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
>> (I do not know whether it can be changed there but I tested gitweb once long
>> time ago)
>> 3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
>> with mixed encodings. This fact oblidge us to encode headers
>> (as quoted printable at least) and synchronize body message that contain
>> repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
[...]
> In this case, it may make sense to have a separate setting, but you should
> call git like this:
>
> git -c "i18n.logoutputencoding=$emailcharset" show ...
> git -c "i18n.logoutputencoding=$emailcharset" rev-list --pretty ...
Something like this, I suppose?
This teaches post-receive-email to use plumbing where possible and to
explicitly declare what encoding it expects output to use. Completely
untested --- basic sanity checking, testing, and tweaks to allow
overriding the choice of encoding left as an exercise to the reader.
Based on patches by Gerrit Pape and Jeff King and advice from Johannes
Sixt.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
More background:
http://thread.gmane.org/gmane.comp.version-control.git/124350/focus=124355
contrib/hooks/post-receive-email | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba077c13..bc603b02 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -234,6 +234,9 @@ generate_email_header()
cat <<-EOF
To: $recipients
Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+ MIME-Version: 1.0
+ Content-Type: text/plain; charset=utf-8
+ Content-Transfer-Encoding: 8bit
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
@@ -462,7 +465,7 @@ generate_delete_branch_email()
echo " was $oldrev"
echo ""
echo $LOGEND
- git show -s --pretty=oneline $oldrev
+ git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
echo $LOGEND
}
@@ -538,11 +541,11 @@ generate_atag_email()
# performed on them
if [ -n "$prevtag" ]; then
# Show changes since the previous release
- git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
+ git shortlog --encoding=UTF-8 "$prevtag..$newrev"
else
# No previous tag, show all the changes since time
# began
- git rev-list --pretty=short $newrev | git shortlog
+ git shortlog --encoding=UTF-8 "$newrev"
fi
;;
*)
@@ -562,7 +565,7 @@ generate_delete_atag_email()
echo " was $oldrev"
echo ""
echo $LOGEND
- git show -s --pretty=oneline $oldrev
+ git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
echo $LOGEND
}
@@ -608,7 +611,7 @@ generate_general_email()
echo ""
if [ "$newrev_type" = "commit" ]; then
echo $LOGBEGIN
- git show --no-color --root -s --pretty=medium $newrev
+ git diff-tree --encoding=UTF-8 --root -s --pretty=oneline $newrev
echo $LOGEND
else
# What can we do here? The tag marks an object that is not
@@ -627,7 +630,7 @@ generate_delete_general_email()
echo " was $oldrev"
echo ""
echo $LOGEND
- git show -s --pretty=oneline $oldrev
+ git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
echo $LOGEND
}
--
1.7.7.rc1
^ permalink raw reply related
* [PATCH 2/2] submodule::module_clone(): silence die() message from module_name()
From: Tay Ray Chuan @ 2011-10-07 9:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1317978295-4796-1-git-send-email-rctay89@gmail.com>
The die() message that may occur in module_name() is not really relevant
to the user when called from module_clone(); the latter handles the
"failure" (no submodule mapping) anyway.
Leave other callers of module_name() unchanged, as the die() message
shown is either relevant for user consumption (such as those that exit()
when the call fails), or will not occur at all (when called with paths
returned by module_list()).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ebea35b..3adab93 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -130,7 +130,7 @@ module_clone()
gitdir=
gitdir_base=
- name=$(module_name "$path")
+ name=$(module_name "$path" 2>/dev/null)
base_path=$(dirname "$path")
gitdir=$(git rev-parse --git-dir)
--
1.7.7.584.g16d0ea
^ permalink raw reply related
* [PATCH 1/2] submodule: whitespace fix
From: Tay Ray Chuan @ 2011-10-07 9:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Replace SPs with TAB.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
git-submodule.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 928a62f..ebea35b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -104,9 +104,9 @@ module_name()
re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
- test -z "$name" &&
- die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
- echo "$name"
+ test -z "$name" &&
+ die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
+ echo "$name"
}
#
--
1.7.7.584.g16d0ea
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: use branch.$name.description
From: Michael J Gruber @ 2011-10-07 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobxtwaog.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.10.2011 08:57:
> This teaches "merge --log" and fmt-merge-msg to use branch description
> information when merging a local topic branch into the mainline. The
> description goes between the branch name label and the list of commit
> titles.
>
> The refactoring to share the common configuration parsing between
> merge and fmt-merge-msg needs to be made into a separate patch.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * This is a follow-up to the branch.$name.description series that has
> been queued in 'pu' (jc/request-pull-show-head-4). The two commands
> join the family of commands that are aware of the branch description,
> i.e. format-patch (cover letter), request-pull.
Uhm, I tried to start a discussion there about whether we really want
config based branch descriptions, together with suggestions and actual
series for notes based descriptions, notes based format-patch
cover-letter, notes based branch output. Making fmt-merge-msg use that
is a no-brainer.
Do we want an implementation race, or could we please reach some
consensus about the direction first? (Not many have spoken up yet.)
config based is so non-distributed, local in nature.
> Makefile | 1 +
> builtin/fmt-merge-msg.c | 63 ++++++++++++++++++++++++++++++++++++++--------
> builtin/merge.c | 16 +++++------
> fmt-merge-msg.h | 6 ++++
> 4 files changed, 66 insertions(+), 20 deletions(-)
> create mode 100644 fmt-merge-msg.h
>
> diff --git a/Makefile b/Makefile
> index 8d6d451..b499049 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -527,6 +527,7 @@ LIB_H += diffcore.h
> LIB_H += diff.h
> LIB_H += dir.h
> LIB_H += exec_cmd.h
> +LIB_H += fmt-merge-msg.h
> LIB_H += fsck.h
> LIB_H += gettext.h
> LIB_H += git-compat-util.h
> diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
> index 7581632..21efd25 100644
> --- a/builtin/fmt-merge-msg.c
> +++ b/builtin/fmt-merge-msg.c
> @@ -5,6 +5,8 @@
> #include "revision.h"
> #include "tag.h"
> #include "string-list.h"
> +#include "branch.h"
> +#include "fmt-merge-msg.h"
>
> static const char * const fmt_merge_msg_usage[] = {
> "git fmt-merge-msg [-m <message>] [--log[=<n>]|--no-log] [--file <file>]",
> @@ -12,8 +14,9 @@ static const char * const fmt_merge_msg_usage[] = {
> };
>
> static int shortlog_len;
> +static int use_branch_desc;
>
> -static int fmt_merge_msg_config(const char *key, const char *value, void *cb)
> +int fmt_merge_msg_config(const char *key, const char *value, void *cb)
> {
> if (!strcmp(key, "merge.log") || !strcmp(key, "merge.summary")) {
> int is_bool;
> @@ -22,6 +25,8 @@ static int fmt_merge_msg_config(const char *key, const char *value, void *cb)
> return error("%s: negative length %s", key, value);
> if (is_bool && shortlog_len)
> shortlog_len = DEFAULT_MERGE_LOG_LEN;
> + } else if (!strcmp(key, "merge.branchdesc")) {
> + use_branch_desc = git_config_bool(key, value);
> }
> return 0;
> }
> @@ -31,6 +36,11 @@ struct src_data {
> int head_status;
> };
>
> +struct origin_data {
> + unsigned char sha1[20];
> + int is_local_branch:1;
> +};
> +
> static void init_src_data(struct src_data *data)
> {
> data->branch.strdup_strings = 1;
> @@ -45,7 +55,7 @@ static struct string_list origins = STRING_LIST_INIT_DUP;
> static int handle_line(char *line)
> {
> int i, len = strlen(line);
> - unsigned char *sha1;
> + struct origin_data *origin_data;
> char *src, *origin;
> struct src_data *src_data;
> struct string_list_item *item;
> @@ -61,11 +71,13 @@ static int handle_line(char *line)
> return 2;
>
> line[40] = 0;
> - sha1 = xmalloc(20);
> - i = get_sha1(line, sha1);
> + origin_data = xcalloc(1, sizeof(struct origin_data));
> + i = get_sha1(line, origin_data->sha1);
> line[40] = '\t';
> - if (i)
> + if (i) {
> + free(origin_data);
> return 3;
> + }
>
> if (line[len - 1] == '\n')
> line[len - 1] = 0;
> @@ -93,6 +105,7 @@ static int handle_line(char *line)
> origin = src;
> src_data->head_status |= 1;
> } else if (!prefixcmp(line, "branch ")) {
> + origin_data->is_local_branch = 1;
> origin = line + 7;
> string_list_append(&src_data->branch, origin);
> src_data->head_status |= 2;
> @@ -119,7 +132,9 @@ static int handle_line(char *line)
> sprintf(new_origin, "%s of %s", origin, src);
> origin = new_origin;
> }
> - string_list_append(&origins, origin)->util = sha1;
> + if (strcmp(".", src))
> + origin_data->is_local_branch = 0;
> + string_list_append(&origins, origin)->util = origin_data;
> return 0;
> }
>
> @@ -140,9 +155,30 @@ static void print_joined(const char *singular, const char *plural,
> }
> }
>
> -static void shortlog(const char *name, unsigned char *sha1,
> - struct commit *head, struct rev_info *rev, int limit,
> - struct strbuf *out)
> +static void add_branch_desc(struct strbuf *out, const char *name)
> +{
> + struct strbuf desc = STRBUF_INIT;
> +
> + if (!read_branch_desc(&desc, name)) {
> + const char *bp = desc.buf;
> + while (*bp) {
> + const char *ep = strchrnul(bp, '\n');
> + if (*ep)
> + ep++;
> + strbuf_addf(out, " : %.*s", (int)(ep - bp), bp);
> + bp = ep;
> + }
> + if (out->buf[out->len - 1] != '\n')
> + strbuf_addch(out, '\n');
> + }
> + strbuf_release(&desc);
> +}
> +
> +static void shortlog(const char *name,
> + struct origin_data *origin_data,
> + struct commit *head,
> + struct rev_info *rev, int limit,
> + struct strbuf *out)
> {
> int i, count = 0;
> struct commit *commit;
> @@ -150,6 +186,7 @@ static void shortlog(const char *name, unsigned char *sha1,
> struct string_list subjects = STRING_LIST_INIT_DUP;
> int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
> struct strbuf sb = STRBUF_INIT;
> + const unsigned char *sha1 = origin_data->sha1;
>
> branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
> if (!branch || branch->type != OBJ_COMMIT)
> @@ -188,6 +225,9 @@ static void shortlog(const char *name, unsigned char *sha1,
> else
> strbuf_addf(out, "\n* %s:\n", name);
>
> + if (origin_data->is_local_branch && use_branch_desc)
> + add_branch_desc(out, name);
> +
> for (i = 0; i < subjects.nr; i++)
> if (i >= limit)
> strbuf_addf(out, " ...\n");
> @@ -303,8 +343,9 @@ static int do_fmt_merge_msg(int merge_title, struct strbuf *in,
> strbuf_addch(out, '\n');
>
> for (i = 0; i < origins.nr; i++)
> - shortlog(origins.items[i].string, origins.items[i].util,
> - head, &rev, shortlog_len, out);
> + shortlog(origins.items[i].string,
> + origins.items[i].util,
> + head, &rev, shortlog_len, out);
> }
> return 0;
> }
> diff --git a/builtin/merge.c b/builtin/merge.c
> index ab4077f..fe56aad 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -26,6 +26,7 @@
> #include "merge-recursive.h"
> #include "resolve-undo.h"
> #include "remote.h"
> +#include "fmt-merge-msg.h"
>
> #define DEFAULT_TWOHEAD (1<<0)
> #define DEFAULT_OCTOPUS (1<<1)
> @@ -525,6 +526,8 @@ static void parse_branch_merge_options(char *bmo)
>
> static int git_merge_config(const char *k, const char *v, void *cb)
> {
> + int status;
> +
> if (branch && !prefixcmp(k, "branch.") &&
> !prefixcmp(k + 7, branch) &&
> !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
> @@ -541,15 +544,7 @@ static int git_merge_config(const char *k, const char *v, void *cb)
> return git_config_string(&pull_octopus, k, v);
> else if (!strcmp(k, "merge.renormalize"))
> option_renormalize = git_config_bool(k, v);
> - else if (!strcmp(k, "merge.log") || !strcmp(k, "merge.summary")) {
> - int is_bool;
> - shortlog_len = git_config_bool_or_int(k, v, &is_bool);
> - if (!is_bool && shortlog_len < 0)
> - return error(_("%s: negative length %s"), k, v);
> - if (is_bool && shortlog_len)
> - shortlog_len = DEFAULT_MERGE_LOG_LEN;
> - return 0;
> - } else if (!strcmp(k, "merge.ff")) {
> + else if (!strcmp(k, "merge.ff")) {
> int boolval = git_config_maybe_bool(k, v);
> if (0 <= boolval) {
> allow_fast_forward = boolval;
> @@ -562,6 +557,9 @@ static int git_merge_config(const char *k, const char *v, void *cb)
> default_to_upstream = git_config_bool(k, v);
> return 0;
> }
> + status = fmt_merge_msg_config(k, v, cb);
> + if (status)
> + return status;
> return git_diff_ui_config(k, v, cb);
> }
>
> diff --git a/fmt-merge-msg.h b/fmt-merge-msg.h
> new file mode 100644
> index 0000000..9217fdb
> --- /dev/null
> +++ b/fmt-merge-msg.h
> @@ -0,0 +1,6 @@
> +#ifndef FMT_MERGE_MSG_H
> +#define FMT_MERGE_MSG_H
> +
> +extern int fmt_merge_msg_config(const char *key, const char *value, void *cb);
> +
> +#endif /* FMT_MERGE_MSG_H */
^ permalink raw reply
* How pretty is pretty? git cat-file -p inconsistency
From: Michael J Gruber @ 2011-10-07 8:44 UTC (permalink / raw)
To: Git Mailing List
diff <(git cat-file -p tags/v1.7.7) <(git cat-file tag tags/v1.7.7)
4c4
< tagger Junio C Hamano <gitster@pobox.com> Fri Sep 30 14:21:06 2011 -0700
---
> tagger Junio C Hamano <gitster@pobox.com> 1317417666 -0700
vs.
diff <(git cat-file -p tags/v1.7.7^{}) <(git cat-file commit tags/v1.7.7^{})
(no diff)
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? I'd suggest
prettifying dates with "-p" for commit objects also. But just how
plumbing is the "-p" mode of "cat-file"?
Michael
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Michael J Gruber @ 2011-10-07 8:40 UTC (permalink / raw)
To: Git Mailing List; +Cc: Robin H. Johnson, Junio C Hamano
In-Reply-To: <robbat2-20111006T221637-481195848Z@orbis-terrarum.net>
[readding JCH to cc whom you dropped]
Robin H. Johnson venit, vidit, dixit 07.10.2011 00:24:
> On Wed, Oct 05, 2011 at 05:56:55PM -0700, Junio C Hamano wrote:
>> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
>>
>> $ git commit --gpg-sign -m foo
>> You need a passphrase to unlock the secret key for
>> user: "Junio C Hamano <gitster@pobox.com>"
>> 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
>>
>> [master 8457d13] foo
>> 1 files changed, 1 insertions(+), 0 deletions(-)
> I like it, but I have a couple of questions:
> 1. Are the sig lines used in computed SHA1/commitid of a given commit (I
> see examples w/ --amend and that would usually change the SHA1)?
Yes, just like with tag objects.
> 2. Can we allow more than one person sign a commit?
I don't think we support it now (tags) but we could allow concatenating
signatures since they are detached.
There's a somewhat delicate issue here: The signature (tag/commit) is a
signature on the contents of the object, and is itself not part of the
contents (or else we would have a chicken-egg-problem).
The sha1 of the object is determined by the content+header, i.e.
including the signature.
So, by adding a signature, you change the sha1, but any existing
signature remains valid.
This is also how you can try to achieve a specific sha1 for a given
object content...
> 3. If I have prepared a series on a local branch, and I want to sign all
> of them, is this a variant of rebase or?
If you really want to sign all you can rebase-i and use "exec" to do
that automatically, but there's no point: signing the top-most commit
serves the same purpose.
> I think this isn't a replacement for push certificates, but has value in
> itself. It's certainly provides better integration than the
> signature-in-note variants.
>
I do think it's meant as an implementation of push certificates. I don't
see any other value in it which could not be achieved by signed tags.
Can you describe any?
Michael
^ permalink raw reply
* [PATCH v2] fetch: plug two leaks on error exit in store_updated_refs
From: Tay Ray Chuan @ 2011-10-07 7:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Chris Wilson, René Scharfe
In-Reply-To: <4E8EA33E.5020009@lsrfire.ath.cx>
Close FETCH_HEAD and release the string url even if we have to leave the
function store_updated_refs() early.
Reported-by: Chris Wilson <cwilson@vigilantsw.com>
Helped-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
builtin/fetch.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index fc254b6..9b7ce10 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -423,8 +423,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
else
url = xstrdup("foreign");
- if (check_everything_connected(ref_map, 0))
- return error(_("%s did not send all necessary objects\n"), url);
+ if (check_everything_connected(ref_map, 0)) {
+ rc = error(_("%s did not send all necessary objects\n"), url);
+ goto abort;
+ }
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -506,12 +508,15 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
fprintf(stderr, " %s\n", note);
}
}
- free(url);
- fclose(fp);
+
if (rc & STORE_REF_ERROR_DF_CONFLICT)
error(_("some local refs could not be updated; try running\n"
" 'git remote prune %s' to remove any old, conflicting "
"branches"), remote_name);
+
+ abort:
+ free(url);
+ fclose(fp);
return rc;
}
--
1.7.7.584.g16d0ea
^ permalink raw reply related
* Re: [PATCH WIP 0/3] git log --exclude
From: Nguyen Thai Ngoc Duy @ 2011-10-07 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <7vhb3n8ie9.fsf@alter.siamese.dyndns.org>
2011/10/6 Junio C Hamano <gitster@pobox.com>:
> For the purpose of "log --exclude" [*2*], I do not mind too much if the UI
> expressed negative pathspecs using such a new command line option, but I
> think it would be more natural to say (notations aside):
>
> $ git log -- ':(no):po' .
>
> and define the behaviour of user-supplied pathspec limiter this way:
>
> * Paths are matched from left to right;
>
> * First match determines the fate of the path;
>
> * A match with negative pathspec means "the path in question does _not_
> match".
Things have changed a bit since last time I touched negative pathspec.
Because of depth limit support [1], pathspecs have to be sorted, which
means we cannot keep pathspec in original order to match from left to
right.
There may be a solution to mix depth limit and negative pathspec. I
haven't thought carefully about that because I lean towards a simpler
behaviour that only allows one negation level: a file is in if it
matches any positive pathspecs and none of negative ones.
This is enough if narrow clones consist of positive pathspec only. I
really doubt if users would want to make a narrow clone that "contains
A but not A/B, storage-wise".
[1] 86e4ca6 (tree_entry_interesting(): fix depth limit with
overlapping pathspecs)
--
Duy
^ permalink raw reply
* Re: [PATCH] fetch: plug two leaks on error exit in store_updated_refs
From: René Scharfe @ 2011-10-07 6:59 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Chris Wilson, git, Junio C Hamano
In-Reply-To: <CALUzUxp4Eo7j=kM7YPJbj70-rwuyFK5V1mZZMY7vBwwPYWS6gQ@mail.gmail.com>
Am 07.10.2011 08:49, schrieb Tay Ray Chuan:
> How about reusing the function's cleanup calls, like this?
Yes, that's better.
> -- >8 --
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index fc254b6..56267c4 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -423,8 +423,10 @@ static int store_updated_refs(const char
> *raw_url, const char *remote_name,
> else
> url = xstrdup("foreign");
>
> - if (check_everything_connected(ref_map, 0))
> - return error(_("%s did not send all necessary objects\n"), url);
> + if (check_everything_connected(ref_map, 0)) {
> + rc = error(_("%s did not send all necessary objects\n"), url);
> + goto abort;
> + }
>
> for (rm = ref_map; rm; rm = rm->next) {
> struct ref *ref = NULL;
> @@ -506,12 +508,15 @@ static int store_updated_refs(const char
> *raw_url, const char *remote_name,
> fprintf(stderr, " %s\n", note);
> }
> }
> - free(url);
> - fclose(fp);
> +
> if (rc & STORE_REF_ERROR_DF_CONFLICT)
> error(_("some local refs could not be updated; try running\n"
> " 'git remote prune %s' to remove any old, conflicting "
> "branches"), remote_name);
> +
> +abort:
> + free(url);
> + fclose(fp);
> return rc;
> }
>
Micro-nit: If you start the label with a space ("+ abort:") then the
code continues to play nice with git grep -W.
René
^ permalink raw reply
* [PATCH] fmt-merge-msg: use branch.$name.description
From: Junio C Hamano @ 2011-10-07 6:57 UTC (permalink / raw)
To: git
This teaches "merge --log" and fmt-merge-msg to use branch description
information when merging a local topic branch into the mainline. The
description goes between the branch name label and the list of commit
titles.
The refactoring to share the common configuration parsing between
merge and fmt-merge-msg needs to be made into a separate patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is a follow-up to the branch.$name.description series that has
been queued in 'pu' (jc/request-pull-show-head-4). The two commands
join the family of commands that are aware of the branch description,
i.e. format-patch (cover letter), request-pull.
Makefile | 1 +
builtin/fmt-merge-msg.c | 63 ++++++++++++++++++++++++++++++++++++++--------
builtin/merge.c | 16 +++++------
fmt-merge-msg.h | 6 ++++
4 files changed, 66 insertions(+), 20 deletions(-)
create mode 100644 fmt-merge-msg.h
diff --git a/Makefile b/Makefile
index 8d6d451..b499049 100644
--- a/Makefile
+++ b/Makefile
@@ -527,6 +527,7 @@ LIB_H += diffcore.h
LIB_H += diff.h
LIB_H += dir.h
LIB_H += exec_cmd.h
+LIB_H += fmt-merge-msg.h
LIB_H += fsck.h
LIB_H += gettext.h
LIB_H += git-compat-util.h
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 7581632..21efd25 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -5,6 +5,8 @@
#include "revision.h"
#include "tag.h"
#include "string-list.h"
+#include "branch.h"
+#include "fmt-merge-msg.h"
static const char * const fmt_merge_msg_usage[] = {
"git fmt-merge-msg [-m <message>] [--log[=<n>]|--no-log] [--file <file>]",
@@ -12,8 +14,9 @@ static const char * const fmt_merge_msg_usage[] = {
};
static int shortlog_len;
+static int use_branch_desc;
-static int fmt_merge_msg_config(const char *key, const char *value, void *cb)
+int fmt_merge_msg_config(const char *key, const char *value, void *cb)
{
if (!strcmp(key, "merge.log") || !strcmp(key, "merge.summary")) {
int is_bool;
@@ -22,6 +25,8 @@ static int fmt_merge_msg_config(const char *key, const char *value, void *cb)
return error("%s: negative length %s", key, value);
if (is_bool && shortlog_len)
shortlog_len = DEFAULT_MERGE_LOG_LEN;
+ } else if (!strcmp(key, "merge.branchdesc")) {
+ use_branch_desc = git_config_bool(key, value);
}
return 0;
}
@@ -31,6 +36,11 @@ struct src_data {
int head_status;
};
+struct origin_data {
+ unsigned char sha1[20];
+ int is_local_branch:1;
+};
+
static void init_src_data(struct src_data *data)
{
data->branch.strdup_strings = 1;
@@ -45,7 +55,7 @@ static struct string_list origins = STRING_LIST_INIT_DUP;
static int handle_line(char *line)
{
int i, len = strlen(line);
- unsigned char *sha1;
+ struct origin_data *origin_data;
char *src, *origin;
struct src_data *src_data;
struct string_list_item *item;
@@ -61,11 +71,13 @@ static int handle_line(char *line)
return 2;
line[40] = 0;
- sha1 = xmalloc(20);
- i = get_sha1(line, sha1);
+ origin_data = xcalloc(1, sizeof(struct origin_data));
+ i = get_sha1(line, origin_data->sha1);
line[40] = '\t';
- if (i)
+ if (i) {
+ free(origin_data);
return 3;
+ }
if (line[len - 1] == '\n')
line[len - 1] = 0;
@@ -93,6 +105,7 @@ static int handle_line(char *line)
origin = src;
src_data->head_status |= 1;
} else if (!prefixcmp(line, "branch ")) {
+ origin_data->is_local_branch = 1;
origin = line + 7;
string_list_append(&src_data->branch, origin);
src_data->head_status |= 2;
@@ -119,7 +132,9 @@ static int handle_line(char *line)
sprintf(new_origin, "%s of %s", origin, src);
origin = new_origin;
}
- string_list_append(&origins, origin)->util = sha1;
+ if (strcmp(".", src))
+ origin_data->is_local_branch = 0;
+ string_list_append(&origins, origin)->util = origin_data;
return 0;
}
@@ -140,9 +155,30 @@ static void print_joined(const char *singular, const char *plural,
}
}
-static void shortlog(const char *name, unsigned char *sha1,
- struct commit *head, struct rev_info *rev, int limit,
- struct strbuf *out)
+static void add_branch_desc(struct strbuf *out, const char *name)
+{
+ struct strbuf desc = STRBUF_INIT;
+
+ if (!read_branch_desc(&desc, name)) {
+ const char *bp = desc.buf;
+ while (*bp) {
+ const char *ep = strchrnul(bp, '\n');
+ if (*ep)
+ ep++;
+ strbuf_addf(out, " : %.*s", (int)(ep - bp), bp);
+ bp = ep;
+ }
+ if (out->buf[out->len - 1] != '\n')
+ strbuf_addch(out, '\n');
+ }
+ strbuf_release(&desc);
+}
+
+static void shortlog(const char *name,
+ struct origin_data *origin_data,
+ struct commit *head,
+ struct rev_info *rev, int limit,
+ struct strbuf *out)
{
int i, count = 0;
struct commit *commit;
@@ -150,6 +186,7 @@ static void shortlog(const char *name, unsigned char *sha1,
struct string_list subjects = STRING_LIST_INIT_DUP;
int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
struct strbuf sb = STRBUF_INIT;
+ const unsigned char *sha1 = origin_data->sha1;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
@@ -188,6 +225,9 @@ static void shortlog(const char *name, unsigned char *sha1,
else
strbuf_addf(out, "\n* %s:\n", name);
+ if (origin_data->is_local_branch && use_branch_desc)
+ add_branch_desc(out, name);
+
for (i = 0; i < subjects.nr; i++)
if (i >= limit)
strbuf_addf(out, " ...\n");
@@ -303,8 +343,9 @@ static int do_fmt_merge_msg(int merge_title, struct strbuf *in,
strbuf_addch(out, '\n');
for (i = 0; i < origins.nr; i++)
- shortlog(origins.items[i].string, origins.items[i].util,
- head, &rev, shortlog_len, out);
+ shortlog(origins.items[i].string,
+ origins.items[i].util,
+ head, &rev, shortlog_len, out);
}
return 0;
}
diff --git a/builtin/merge.c b/builtin/merge.c
index ab4077f..fe56aad 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -26,6 +26,7 @@
#include "merge-recursive.h"
#include "resolve-undo.h"
#include "remote.h"
+#include "fmt-merge-msg.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -525,6 +526,8 @@ static void parse_branch_merge_options(char *bmo)
static int git_merge_config(const char *k, const char *v, void *cb)
{
+ int status;
+
if (branch && !prefixcmp(k, "branch.") &&
!prefixcmp(k + 7, branch) &&
!strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
@@ -541,15 +544,7 @@ static int git_merge_config(const char *k, const char *v, void *cb)
return git_config_string(&pull_octopus, k, v);
else if (!strcmp(k, "merge.renormalize"))
option_renormalize = git_config_bool(k, v);
- else if (!strcmp(k, "merge.log") || !strcmp(k, "merge.summary")) {
- int is_bool;
- shortlog_len = git_config_bool_or_int(k, v, &is_bool);
- if (!is_bool && shortlog_len < 0)
- return error(_("%s: negative length %s"), k, v);
- if (is_bool && shortlog_len)
- shortlog_len = DEFAULT_MERGE_LOG_LEN;
- return 0;
- } else if (!strcmp(k, "merge.ff")) {
+ else if (!strcmp(k, "merge.ff")) {
int boolval = git_config_maybe_bool(k, v);
if (0 <= boolval) {
allow_fast_forward = boolval;
@@ -562,6 +557,9 @@ static int git_merge_config(const char *k, const char *v, void *cb)
default_to_upstream = git_config_bool(k, v);
return 0;
}
+ status = fmt_merge_msg_config(k, v, cb);
+ if (status)
+ return status;
return git_diff_ui_config(k, v, cb);
}
diff --git a/fmt-merge-msg.h b/fmt-merge-msg.h
new file mode 100644
index 0000000..9217fdb
--- /dev/null
+++ b/fmt-merge-msg.h
@@ -0,0 +1,6 @@
+#ifndef FMT_MERGE_MSG_H
+#define FMT_MERGE_MSG_H
+
+extern int fmt_merge_msg_config(const char *key, const char *value, void *cb);
+
+#endif /* FMT_MERGE_MSG_H */
--
1.7.7.138.g7f41b6
^ permalink raw reply related
* Re: [PATCH] fetch: plug two leaks on error exit in store_updated_refs
From: Tay Ray Chuan @ 2011-10-07 6:49 UTC (permalink / raw)
To: René Scharfe; +Cc: Chris Wilson, git, Junio C Hamano
In-Reply-To: <4E8E98A7.8010008@lsrfire.ath.cx>
On Fri, Oct 7, 2011 at 2:13 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 7a4e41c..79db796 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -379,8 +379,12 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
> url = xstrdup("foreign");
>
> rm = ref_map;
> - if (check_everything_connected(iterate_ref_map, 0, &rm))
> - return error(_("%s did not send all necessary objects\n"), url);
> + if (check_everything_connected(iterate_ref_map, 0, &rm)) {
> + error(_("%s did not send all necessary objects\n"), url);
> + free(url);
> + fclose(fp);
> + return -1;
> + }
>
> for (rm = ref_map; rm; rm = rm->next) {
> struct ref *ref = NULL;
> --
> 1.7.7
How about reusing the function's cleanup calls, like this?
-- >8 --
diff --git a/builtin/fetch.c b/builtin/fetch.c
index fc254b6..56267c4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -423,8 +423,10 @@ static int store_updated_refs(const char
*raw_url, const char *remote_name,
else
url = xstrdup("foreign");
- if (check_everything_connected(ref_map, 0))
- return error(_("%s did not send all necessary objects\n"), url);
+ if (check_everything_connected(ref_map, 0)) {
+ rc = error(_("%s did not send all necessary objects\n"), url);
+ goto abort;
+ }
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -506,12 +508,15 @@ static int store_updated_refs(const char
*raw_url, const char *remote_name,
fprintf(stderr, " %s\n", note);
}
}
- free(url);
- fclose(fp);
+
if (rc & STORE_REF_ERROR_DF_CONFLICT)
error(_("some local refs could not be updated; try running\n"
" 'git remote prune %s' to remove any old, conflicting "
"branches"), remote_name);
+
+abort:
+ free(url);
+ fclose(fp);
return rc;
}
--
--
Cheers,
Ray Chuan
^ permalink raw reply related
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