* [PATCH v3 0/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-09 3:35 UTC (permalink / raw)
To: Git; +Cc: Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor,
W. Trevor King
In-Reply-To: <20121029222759.GI20513@sigill.intra.peff.net>
From: "W. Trevor King" <wking@tremily.us>
Here's my revised patch. Changes from v2:
* Revised Ævar-vs-Gerrit usage to show agreement, following Shawn's
comments.
* Added a cleaned up version of Phil's $submodule_* export patch, with
docs and tests.
* Added a caveat to the -r/--record documentation to make it explicit
that submodule.<name>.branch is not used internally by Git. Give an
example of how the user may use it explicitly for Ævar-style
updates.
W. Trevor King (3):
git-submodule add: Add -r/--record option
git-submodule foreach: export .gitmodules settings as variables
git-submodule: Motivate --record with an example use case
Documentation/git-submodule.txt | 22 +++++++++++++++++++++-
git-sh-setup.sh | 20 ++++++++++++++++++++
git-submodule.sh | 35 ++++++++++++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++
t/t7407-submodule-foreach.sh | 29 +++++++++++++++++++++++++++++
5 files changed, 129 insertions(+), 2 deletions(-)
mode change 100644 => 100755 git-sh-setup.sh
--
1.8.0.3.gc2eb43a
^ permalink raw reply
* [PATCH v3 3/3] git-submodule: Motivate --record with an example use case
From: W. Trevor King @ 2012-11-09 3:35 UTC (permalink / raw)
To: Git; +Cc: Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor,
W. Trevor King
In-Reply-To: <cover.1352431674.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 9a99826..d4e993f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -220,6 +220,14 @@ OPTIONS
is not set either, `HEAD` will be recorded. Because the branch name
is optional, you must use the equal-sign form (`-r=<branch>`), not
`-r <branch>`.
++
+The recorded setting is not actually used by git; however, some
+external tools and workflows may make use of it. For example, if the
+upstream branches still exist and you have a recorded branch setting
+for each of your submodules, you can update all of the submodules to
+the current branch tips with:
++
+ git submodule foreach 'git checkout $submodule_branch && git pull'
-f::
--force::
--
1.8.0.3.gc2eb43a
^ permalink raw reply related
* [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-09 3:35 UTC (permalink / raw)
To: Git; +Cc: Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor,
W. Trevor King
In-Reply-To: <cover.1352431674.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This option allows you to record a submodule.<name>.branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current consumers:
Ævar uses this setting to designate the upstream branch for pulling
submodule updates:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
By remaining agnostic on the variable usage, this patch makes
submodule setup more convenient for all parties.
[1] https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 11 ++++++++++-
git-submodule.sh | 19 ++++++++++++++++++-
t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..cbec363 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
+'git submodule' [--quiet] add [-b branch] [--record[=<branch>]] [-f|--force]
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
@@ -209,6 +209,15 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-r::
+--record::
+ Record a branch name used as `submodule.<path>.branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form (`-r=<branch>`), not
+ `-r <branch>`.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..bc33112 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
+USAGE="[--quiet] add [-b branch] [--record[=<branch>]] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+record_branch=
+record_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ -r | --record)
+ record_branch_empty=true
+ ;;
+ -r=* | --record=*)
+ record_branch="${1#*=}"
+ ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$sm_path' already exists in the index")"
+ if test -z "$record_branch" && test "$record_branch_empty" = "true"
+ then
+ record_branch="${branch:=HEAD}"
+ fi
+
if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path" > /dev/null 2>&1
then
eval_gettextln "The following path is ignored by one of your .gitignore files:
@@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$record_branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..88ae74c 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test -z "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
git submodule init
) &&
@@ -211,6 +212,30 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
test_cmp empty untracked
'
+test_expect_success 'submodule add --record' '
+ (
+ cd addtest &&
+ git submodule add -r "$submodurl" submod-record-head &&
+ test "$(git config -f .gitmodules submodule.submod-record-head.branch)" = "HEAD"
+ )
+'
+
+test_expect_success 'submodule add --record --branch' '
+ (
+ cd addtest &&
+ git submodule add -r -b initial "$submodurl" submod-auto-record &&
+ test "$(git config -f .gitmodules submodule.submod-auto-record.branch)" = "initial"
+ )
+'
+
+test_expect_success 'submodule add --record=<name> --branch' '
+ (
+ cd addtest &&
+ git submodule add -r=final -b initial "$submodurl" submod-record &&
+ test "$(git config -f .gitmodules submodule.submod-record.branch)" = "final"
+ )
+'
+
test_expect_success 'setup - add an example entry to .gitmodules' '
GIT_CONFIG=.gitmodules \
git config submodule.example.url git://example.com/init.git
--
1.8.0.3.gc2eb43a
^ permalink raw reply related
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-09 2:14 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20121108190944.GO15560@sigill.intra.peff.net>
On Fri, Nov 9, 2012 at 3:09 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:
>
>> > So, then the question is: What do you know/have? Is your patch the
>> > output of "git format-patch", "git diff", or just some sort of diff
>> > without any git information?
>>
>> That doesn't matter, all the info can be obtained from the SHA1 id, the
>> question is: do we have a mechanism in git (or hopefully we could add)
>> to record the patchset or series the patch belongs to, without people to
>> guess heuristically.
>>
>> E.g. when we merged a series of patches:
>>
>> [PATCH 00/08]
>> [PATCH 01/08]
>> ...
>> [PATCH 08/08]
>>
>> How do we know this whole series after merged when only one of these
>> commits are known?
>
> Others have described how you can infer this structure from the history
> graph, but as you noted, the graph does not always match the series that
> was sent, nor does it contain some of the meta information about the
> cover letter, associated discussions, etc.
>
> If you want to track the mapping between mailed patches (or any other
> form of changeset id) to commits, you can put it in git in one of two
> places:
>
> 1. In a pseudo-header at the end of the commit message. E.g., you
> could use the message-id of the cover letter as a unique identifier
> for the changeset, and put "Changeset: $MID" at the end of each
> commit message. Then you can use "--grep" to find other entries
> from the same changeset.
>
> 2. You can use git-notes to store the same information outside of the
> commit message. This doesn't get pushed around automatically with
> the history, but it means your commit messages are not polluted,
> and you can make annotations after the commits are set in stone.
>
> I do not use Gerrit, but I recall that they do something like (1) to
> mark changesets. For git development, one of the contributors does (2)
> to point notes at mailing list threads (I think he uses a script to
> match up mails and commits after the fact).
Thanks Jeff, this is the answer I'm looking for, really appreciated to
get it explained so clearly.
>
> But fundamentally the idea of "this is a set of logical changes" is not
> represented in git's DAG. It's up to you to store changeset tokens
> if you care about them.
Sure, I completely understand and agree we should keep git simple enough.
^ permalink raw reply
* Re: orphan blob or what?
From: Tomas Carnecky @ 2012-11-09 1:08 UTC (permalink / raw)
To: bruce, git
In-Reply-To: <87a9urlj23.fsf@intel.com>
On Thu, 08 Nov 2012 16:24:36 -0800, bruce <bruce.e.robertson@intel.com> wrote:
> In today's and older clones of https://github.com/mirrors/linux.git I
> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
> in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
> can't see it via 'git log'. And yet
>
> linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
> 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
> 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
> f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile,
2010-09-29) references this blob.
^ permalink raw reply
* orphan blob or what?
From: bruce @ 2012-11-09 0:24 UTC (permalink / raw)
To: git
In today's and older clones of https://github.com/mirrors/linux.git I
find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
can't see it via 'git log'. And yet
linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee
6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673
8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee
Thanks,
bruce
^ permalink raw reply
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-11-08 23:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121108223319.GA11734@sigill.intra.peff.net>
I tried on the local disk as well and it didn't help. I managed to
find a SUSE11 machine and tried it there but no luck so I think we can
eliminate NFS and OS as significant factors now.
I ran with perf and here's the report:
ESC[31m 69.07%ESC[m git /lib64/libc-2.11.1.so
[.] memcpy
ESC[31m 12.33%ESC[m git
<prefix>/git-1.8.0.rc2.suse11/bin/git [.]
blk_SHA1_Block
ESC[31m 5.11%ESC[m git
<prefix>/zlib/local/lib/libz.so.1.2.5 [.]
inflate_fast
ESC[32m 2.61%ESC[m git
<prefix>/zlib/local/lib/libz.so.1.2.5 [.]
adler32
ESC[32m 1.98%ESC[m git /lib64/libc-2.11.1.so
[.] _int_malloc
ESC[32m 0.86%ESC[m git [kernel]
[k] clear_page_c
Does this help? Machine has 396GB of RAM if it matters.
On Thu, Nov 8, 2012 at 4:33 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote:
>
>> I ran "git cat-file commit some-tag" for every tag. They seem to be
>> roughly uniformly distributed between 0s and 2s and about 2/3 of the
>> time seems to be system. My disk is mounted over NFS so I tried on the
>> local disk and it didn't make a difference.
>>
>> I have only one 1.97GB pack. I ran "git gc --aggressive" before.
>
> Ah. NFS. That is almost certainly the source of the problem. Git will
> aggressively mmap. I would not be surprised to find that RHEL4's NFS
> implementation is not particularly fast at mmap-ing 2G files, and is
> spending a bunch of time in the kernel servicing the requests.
>
> Aside from upgrading your OS or getting off of NFS, I don't have a lot
> of advice. The performance characteristics you are seeing are so
> grossly off of what is normal that using git is probably going to be
> painful. Your 2s cat-files should be more like .002s. I don't think
> there's anything for git to fix here.
>
> You could try building with NO_MMAP, which will emulate it with pread.
> That might fare better under your NFS implementation. Or it might be
> just as bad.
>
> -Peff
^ permalink raw reply
* Re: Long clone time after "done."
From: Jeff King @ 2012-11-08 22:33 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5ATX5Ru9Orp2t3p39q7tsNRfGjqDYGnf4-9QYNSTpQ-YuA@mail.gmail.com>
On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote:
> I ran "git cat-file commit some-tag" for every tag. They seem to be
> roughly uniformly distributed between 0s and 2s and about 2/3 of the
> time seems to be system. My disk is mounted over NFS so I tried on the
> local disk and it didn't make a difference.
>
> I have only one 1.97GB pack. I ran "git gc --aggressive" before.
Ah. NFS. That is almost certainly the source of the problem. Git will
aggressively mmap. I would not be surprised to find that RHEL4's NFS
implementation is not particularly fast at mmap-ing 2G files, and is
spending a bunch of time in the kernel servicing the requests.
Aside from upgrading your OS or getting off of NFS, I don't have a lot
of advice. The performance characteristics you are seeing are so
grossly off of what is normal that using git is probably going to be
painful. Your 2s cat-files should be more like .002s. I don't think
there's anything for git to fix here.
You could try building with NO_MMAP, which will emulate it with pread.
That might fare better under your NFS implementation. Or it might be
just as bad.
-Peff
^ permalink raw reply
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-11-08 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121108221128.GA11186@sigill.intra.peff.net>
I ran "git cat-file commit some-tag" for every tag. They seem to be
roughly uniformly distributed between 0s and 2s and about 2/3 of the
time seems to be system. My disk is mounted over NFS so I tried on the
local disk and it didn't make a difference.
I have only one 1.97GB pack. I ran "git gc --aggressive" before.
On Thu, Nov 8, 2012 at 4:11 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote:
>
>> I'm using RHEL4. Looks like perf is only available with RHEL6.
>
> Yeah, RHEL4 is pretty ancient; I think it predates the invention of
> "perf".
>
>> heads: 308
>> tags: 9614
>>
>> Looking up the tags that way took a very long time by the way. "git
>> tag | wc -l" was much quicker. I've already pruned a lot of tags to
>> get to this number as well. The original repository had ~37k tags
>> since we used to tag every commit with CVS.
>
> Hmm. I think for-each-ref will actually open the tag objects, but "git
> tag" will not. That would imply that reading the refs is fast, but
> opening objects is slow. I wonder why.
>
> How many packs do you have in .git/objects/pack of the repository?
>
>> All my tags are packed so cat-file doesn't work:
>> fatal: git cat-file refs/tags/some-tag: bad file
>
> The packing shouldn't matter. The point of the command is to look up the
> refs/tags/some-tag ref (in packed-refs or in the filesystem), and then
> open and write the pointed-to object to stdout. If that is not working,
> then there is something seriously wrong going on.
>
> -Peff
^ permalink raw reply
* Re: Long clone time after "done."
From: Jeff King @ 2012-11-08 22:11 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5ARLCk_WQTbyLciv0LnrMa_J0YstNsrq-hLYM5DXiO0hLA@mail.gmail.com>
On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote:
> I'm using RHEL4. Looks like perf is only available with RHEL6.
Yeah, RHEL4 is pretty ancient; I think it predates the invention of
"perf".
> heads: 308
> tags: 9614
>
> Looking up the tags that way took a very long time by the way. "git
> tag | wc -l" was much quicker. I've already pruned a lot of tags to
> get to this number as well. The original repository had ~37k tags
> since we used to tag every commit with CVS.
Hmm. I think for-each-ref will actually open the tag objects, but "git
tag" will not. That would imply that reading the refs is fast, but
opening objects is slow. I wonder why.
How many packs do you have in .git/objects/pack of the repository?
> All my tags are packed so cat-file doesn't work:
> fatal: git cat-file refs/tags/some-tag: bad file
The packing shouldn't matter. The point of the command is to look up the
refs/tags/some-tag ref (in packed-refs or in the filesystem), and then
open and write the pointed-to object to stdout. If that is not working,
then there is something seriously wrong going on.
-Peff
^ permalink raw reply
* Re: Long clone time after "done."
From: Uri Moszkowicz @ 2012-11-08 21:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121108203332.GQ15560@sigill.intra.peff.net>
I'm using RHEL4. Looks like perf is only available with RHEL6.
heads: 308
tags: 9614
Looking up the tags that way took a very long time by the way. "git
tag | wc -l" was much quicker. I've already pruned a lot of tags to
get to this number as well. The original repository had ~37k tags
since we used to tag every commit with CVS.
All my tags are packed so cat-file doesn't work:
fatal: git cat-file refs/tags/some-tag: bad file
On Thu, Nov 8, 2012 at 2:33 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote:
>
>> I tried the patch but it doesn't appear to have helped :( Clone time
>> with it was ~32m.
>
> That sounds ridiculously long.
>
>> Do you all by any chance have a tool to obfuscate a repository?
>> Probably I still wouldn't be permitted to distribute it but might make
>> the option slightly more palatable. Anything else that I can do to
>> help debug this problem?
>
> I don't have anything already written. What platform are you on? If it's
> Linux, can you try using "perf" to record where the time is going?
>
> How many refs do you have? What does:
>
> echo "heads: $(git for-each-ref refs/heads | wc -l)"
> echo " tags: $(git for-each-ref refs/tags | wc -l)"
>
> report? How long does it take to look up a tag, like:
>
> time git cat-file tag refs/tags/some-tag
>
> ?
>
> -Peff
^ permalink raw reply
* Re: [PATCH 2/3] diff: introduce diff.submodule configuration variable
From: Jeff King @ 2012-11-08 20:51 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jens Lehmann
In-Reply-To: <1351766630-4837-3-git-send-email-artagnon@gmail.com>
On Thu, Nov 01, 2012 at 04:13:49PM +0530, Ramkumar Ramachandra wrote:
> diff --git a/builtin/diff.c b/builtin/diff.c
> index 9650be2..6d00311 100644
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -297,6 +297,10 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
> DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
> DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
>
> + /* Set SUBMODULE_LOG if diff.submodule config var was set */
> + if (submodule_format_cfg && !strcmp(submodule_format_cfg, "log"))
> + DIFF_OPT_SET(&rev.diffopt, SUBMODULE_LOG);
> +
Yuck. Why is this parsing happening in cmd_diff?
Wouldn't you want it to kick in for "git log --submodule", too? It seems
like it should go into diff_setup(), and the porcelain/plumbing aspect
should be controlled by parsing it in git_diff_ui_config or
git_diff_basic_config. See how diff_no_prefix and diff_mnemonic prefix
are handled for an example.
Then you can keep the parsing logic for "log" in diff.c. And you should
factor it out into a function so that the command-line option and the
config parser can share the same code. I know it's only one line now,
but anybody who wants to add an option will have to update both places.
See the parsing of diff.dirstat for an example.
> else if (!prefixcmp(arg, "--submodule=")) {
> if (!strcmp(arg + 12, "log"))
> DIFF_OPT_SET(options, SUBMODULE_LOG);
> + if (!strcmp(arg + 12, "short"))
> + DIFF_OPT_CLR(options, SUBMODULE_LOG);
> }
Much better (although arguably should go in a separate patch). Should we
also produce an error if somebody says "--submodule=foobar"?
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/3] Introduce diff.submodule
From: Jeff King @ 2012-11-08 20:43 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jens Lehmann, Git List
In-Reply-To: <CALkWK0kdMbiTUYcSmY1OZOt6fjLTesi9y3S2LZvagjhu-0fn4g@mail.gmail.com>
On Sun, Nov 04, 2012 at 11:28:17PM +0530, Ramkumar Ramachandra wrote:
> Jens Lehmann wrote:
> > Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra:
> >> Hi,
> >>
> >> v1 is here:
> >> http://mid.gmane.org/1349196670-2844-1-git-send-email-artagnon@gmail.com
> >>
> >> I've fixed the issues pointed out in the review by Jens.
> >
> > Thanks, looking good to me.
>
> Peff, can we pick this up?
Thanks for prodding, I missed the original. I have a few comments, but
I'll respond directly.
Also, I was coincidentally looking at the same code today. You might
find this interesting:
http://article.gmane.org/gmane.comp.version-control.git/209188
-Peff
^ permalink raw reply
* Re: Long clone time after "done."
From: Jeff King @ 2012-11-08 20:33 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5AQ24u11BH6rMAHvR95N4ys6KHfEQKD1uLzr+=TDgN_69Q@mail.gmail.com>
On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote:
> I tried the patch but it doesn't appear to have helped :( Clone time
> with it was ~32m.
That sounds ridiculously long.
> Do you all by any chance have a tool to obfuscate a repository?
> Probably I still wouldn't be permitted to distribute it but might make
> the option slightly more palatable. Anything else that I can do to
> help debug this problem?
I don't have anything already written. What platform are you on? If it's
Linux, can you try using "perf" to record where the time is going?
How many refs do you have? What does:
echo "heads: $(git for-each-ref refs/heads | wc -l)"
echo " tags: $(git for-each-ref refs/tags | wc -l)"
report? How long does it take to look up a tag, like:
time git cat-file tag refs/tags/some-tag
?
-Peff
^ permalink raw reply
* [PATCH] custom log formats for "diff --submodule=log"
From: Jeff King @ 2012-11-08 20:29 UTC (permalink / raw)
To: git; +Cc: Jeffrey S. Haemer
An off-list discussion made me wonder if something like this would be
useful:
git log -p --submodule=log:' %m %an <%ae>: %s'
where the format could be whatever you find useful.
I do not use submodules myself, so writing the patch below was just a
fun exercise. I'm not planning on polishing it for inclusion. But I
thought I would publish it here in case anybody who is more interested
feels like picking it up. It would need documentation and tests at the
very least.
---
diff --git a/diff.c b/diff.c
index 86e5f2a..f2adaca 100644
--- a/diff.c
+++ b/diff.c
@@ -2241,7 +2241,7 @@ static void builtin_diff(const char *name_a,
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o->file, one ? one->path : two->path,
one->sha1, two->sha1, two->dirty_submodule,
- del, add, reset);
+ del, add, reset, o->submodule_log_format);
return;
}
@@ -3654,8 +3654,13 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
} else if (!strcmp(arg, "--submodule"))
DIFF_OPT_SET(options, SUBMODULE_LOG);
else if (!prefixcmp(arg, "--submodule=")) {
- if (!strcmp(arg + 12, "log"))
+ const char *v = arg + 12;
+ if (!strcmp(v, "log"))
DIFF_OPT_SET(options, SUBMODULE_LOG);
+ else if (!prefixcmp(v, "log:")) {
+ DIFF_OPT_SET(options, SUBMODULE_LOG);
+ options->submodule_log_format = xstrdup(v + 4);
+ }
}
/* misc options */
diff --git a/diff.h b/diff.h
index a658f85..9726375 100644
--- a/diff.h
+++ b/diff.h
@@ -132,6 +132,8 @@ struct diff_options {
const char *stat_sep;
long xdl_opts;
+ char *submodule_log_format;
+
int stat_width;
int stat_name_width;
int stat_graph_width;
diff --git a/submodule.c b/submodule.c
index e3e0b45..149bd87 100644
--- a/submodule.c
+++ b/submodule.c
@@ -217,12 +217,16 @@ static int prepare_submodule_summary(struct rev_info *rev, const char *path,
}
static void print_submodule_summary(struct rev_info *rev, FILE *f,
- const char *del, const char *add, const char *reset)
+ const char *del, const char *add, const char *reset,
+ const char *format)
{
- static const char format[] = " %m %s";
+ static const char default_format[] = " %m %s";
struct strbuf sb = STRBUF_INIT;
struct commit *commit;
+ if (!format)
+ format = default_format;
+
while ((commit = get_revision(rev))) {
struct pretty_print_context ctx = {0};
ctx.date_mode = rev->date_mode;
@@ -259,7 +263,8 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
unsigned dirty_submodule,
- const char *del, const char *add, const char *reset)
+ const char *del, const char *add, const char *reset,
+ const char *format)
{
struct rev_info rev;
struct commit *left = left, *right = right;
@@ -304,7 +309,7 @@ void show_submodule_summary(FILE *f, const char *path,
fwrite(sb.buf, sb.len, 1, f);
if (!message) {
- print_submodule_summary(&rev, f, del, add, reset);
+ print_submodule_summary(&rev, f, del, add, reset, format);
clear_commit_marks(left, ~0);
clear_commit_marks(right, ~0);
}
diff --git a/submodule.h b/submodule.h
index f2e8271..49a7b75 100644
--- a/submodule.h
+++ b/submodule.h
@@ -21,7 +21,8 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
unsigned dirty_submodule,
- const char *del, const char *add, const char *reset);
+ const char *del, const char *add, const char *reset,
+ const char *format);
void set_config_fetch_recurse_submodules(int value);
void check_for_new_submodule_commits(unsigned char new_sha1[20]);
int fetch_populated_submodules(const struct argv_array *options,
^ permalink raw reply related
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Jeff King @ 2012-11-08 20:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <5093DC0C.5000603@drmicha.warpmail.net>
On Fri, Nov 02, 2012 at 03:43:24PM +0100, Michael J Gruber wrote:
> It seems that our fast-import is super picky with regards to author
> names. I've encountered author names like
>
> Foo Bar<foo.bar@dev.null>
> Foo Bar <foo.bar@dev.null
> foo.bar@dev.null
>
> in the self-hosting repo of some other dvcs, and the question is how to
> translate them faithfully into a git author name.
It is not just fast-import. Git's author field looks like an rfc822
address, but it's much simpler. It fundamentally does not allow angle
brackets in the "name" field, regardless of any quoting. As you noted in
your followup, we strip them out if you provide them via
GIT_AUTHOR_NAME.
I doubt this will change anytime soon due to the compatibility fallout.
So it is up to generators of fast-import streams to decide how to encode
what they get from another system (you could come up with an encoding
scheme that represents angle brackets).
> In general, we try to do
>
> fullotherdvcsname <none@none>
>
> if the other system's entry does not parse as a git author name, but
> fast-import does not accept either of
>
> Foo Bar<foo.bar@dev.null> <none@none>
> "Foo Bar<foo.bar@dev.null>" <none@none>
>
> because of the way it parses for <>. While the above could be easily
> turned into
>
> Foo Bar <foo.bar@dev.null>
>
> it would not be a faithful representation of the original commit in the
> other dvcs.
I'd think that if a remote system has names with angle brackets and
email-looking things inside them, we would do better to stick them in
the email field rather than putting in a useless <none@none>. The latter
should only be used for systems that lack the information.
But that is a quality-of-implementation issue for the import scripts
(and they may even want to have options, just like git-cvsimport allows
mapping cvs usernames into full identities).
-Peff
^ permalink raw reply
* Re: Revert option for git add --patch
From: Jeff King @ 2012-11-08 20:04 UTC (permalink / raw)
To: Nathan Broadbent; +Cc: Jonathon Mah, git@vger.kernel.org
In-Reply-To: <CAPXHQbPrjZ_Ezi3RkHny-fW0=mQCTmX9NVJfgUh7P-Xx9pgBcg@mail.gmail.com>
On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote:
> It sounds like we want a tool that combines the functionality of 'git add
> --patch', 'git checkout --patch', and other features, so that we can
> perform various actions on 'hunks' without switching context. What do you
> think about naming this command 'git patch'?
I think it would be a slightly confusing name, given that it is not
related to the usual Unix "patch" command (git's analog to that is "git
apply").
I was thinking something like "git organize" because it is about
organizing muddled changes. Duy mentioned my earlier "git put", which is
based around the same ideas. This could be thought of as "git put
--patch", I suppose.
> I'm not sure how dropping hunks into 'buckets' would work, but the main
> idea is to be able to stage, discard or edit hunks in a single pass.
Buckets are really just patches you are building up from hunks. So I
think you are dealing with two buckets either way: a to-stage bucket and
a to-discard bucket. Adding more buckets isn't hard; you just turn the
to-stage bucket into an array of buckets.
The tricky part is figuring out how to keep the state persistent across
multiple invocations. The simplest program flow for the 2-bucket case
would be something like:
for h in hunks
do
show hunk to user
ask user what they want to do
if they want to stage
append to to-stage patch
else if they want to discard
append to to-discard patch
else
ignore the hunk
done
feed to-stage patch to "git apply --cached"
feed to-discard patch to "git apply -R"
Modifying the loop to have more buckets is easy. But the end is probably
something like:
feed to-discard patch to "git apply -R"
feed bucket[0] to "git apply --cached"
save bucket[1..n] somewhere
exit
Then the user gets control back, builds, tests, commits, whatever, and
then runs "git organize --continue" to apply bucket[1], and so on. And
since we don't know what the user did in between, we have to be ready
for conflicts in applying the buckets. Hmm, this is sounding a lot like
how "rebase --interactive" works.
One way to implement this would be to store each bucket as a commit
against HEAD (i.e., stage it into a temporary index, then run "git
write-tree" and "git commit-tree"), and then make a "rebase -i"
instruction sheet like:
pick $sha1_of_bucket_1_commit
edit
pick $sha1_of_bucket_2_commit
edit
and so forth, except that we would not want our picks to actually commit
(just pull the changes into the working tree and/or index).
That's just me thinking off the top of my head. Obviously what you are
proposing is way simpler, and it is probably sane to start with the
simple thing, and then build the more complex thing on top. But it might
be worth keeping in mind the complex case when building out the
infrastructure for the simple case.
-Peff
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Jeff King @ 2012-11-08 19:09 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git
In-Reply-To: <CAMPhdO-Z3E352KbTvnrxJqCecAUGfHCwOoFRUKzObh35uLnrSw@mail.gmail.com>
On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:
> > So, then the question is: What do you know/have? Is your patch the
> > output of "git format-patch", "git diff", or just some sort of diff
> > without any git information?
>
> That doesn't matter, all the info can be obtained from the SHA1 id, the
> question is: do we have a mechanism in git (or hopefully we could add)
> to record the patchset or series the patch belongs to, without people to
> guess heuristically.
>
> E.g. when we merged a series of patches:
>
> [PATCH 00/08]
> [PATCH 01/08]
> ...
> [PATCH 08/08]
>
> How do we know this whole series after merged when only one of these
> commits are known?
Others have described how you can infer this structure from the history
graph, but as you noted, the graph does not always match the series that
was sent, nor does it contain some of the meta information about the
cover letter, associated discussions, etc.
If you want to track the mapping between mailed patches (or any other
form of changeset id) to commits, you can put it in git in one of two
places:
1. In a pseudo-header at the end of the commit message. E.g., you
could use the message-id of the cover letter as a unique identifier
for the changeset, and put "Changeset: $MID" at the end of each
commit message. Then you can use "--grep" to find other entries
from the same changeset.
2. You can use git-notes to store the same information outside of the
commit message. This doesn't get pushed around automatically with
the history, but it means your commit messages are not polluted,
and you can make annotations after the commits are set in stone.
I do not use Gerrit, but I recall that they do something like (1) to
mark changesets. For git development, one of the contributors does (2)
to point notes at mailing list threads (I think he uses a script to
match up mails and commits after the fact).
But fundamentally the idea of "this is a set of logical changes" is not
represented in git's DAG. It's up to you to store changeset tokens
if you care about them.
-Peff
^ permalink raw reply
* Re: git commit/push can fail silently when clone omits ".git"
From: Jeff King @ 2012-11-08 18:56 UTC (permalink / raw)
To: Jeffrey S. Haemer; +Cc: Jens Lehmann, Heiko Voigt, Git Issues
In-Reply-To: <CAABvdFyn=_2JKHYA_jAduoNAti3U0YFHbdU94esm=m8R0s2LcA@mail.gmail.com>
On Sun, Nov 04, 2012 at 12:50:58PM -0700, Jeffrey S. Haemer wrote:
> I got bitten by what follows. Yes, it's an edge case. Yes I now understand
> why it does what it does. Yes the right answer is "Don't do that, Jeff." :-)
>
> Still, it took me a little time to figure out what I'd done wrong because
> the failure is silent, so I thought I'd document it. Perhaps there's even
> some way to issue an error message for cases like this.
>
> The attached test script shows the issue in detail, but here's the basic
> failure:
>
> $ ls
> hello.git
> $ git clone hello # *Mistake!* Succeeds, but should have cloned "hello.git"
> or into something else.
It does clone hello.git into "hello", but it sets remote.origin.url in
the cloned repository to "/path/to/hello". I.e., to itself, rather than
the correct hello.git.
The reason is that "clone" sets the config from the repo name you gave
it, not the path it finds on disk. The name you gave was not ambiguous
at the time of clone, but it became so during the clone. I am tempted to
say that we should set the config to the path we found on disk, not what
the user gave us. That includes the ugly "/.git" for non-bare repos, but
we should be able to safely strip that off without adding any ambiguity
(i.e, it is only "foo" versus "foo.git" that is ambiguous).
Unfortunately, the patch below which does that seems to make t7407 very
unhappy. It looks like the submodule test uses "git clone ." and
"git-submodule add" expects the "/." to still be at the end of the
configured URL when processing relative submodule paths. I'm not sure if
that is important, or an unnecessary brittleness in the submodule code.
Jens, Heiko?
---
diff --git a/builtin/clone.c b/builtin/clone.c
index 0d663e3..687d5c0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -713,8 +713,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
repo_name = argv[0];
path = get_repo_path(repo_name, &is_bundle);
- if (path)
- repo = xstrdup(absolute_path(repo_name));
+ if (path) {
+ if (!suffixcmp(path, "/.git"))
+ repo = xstrndup(path, strlen(path) - 5);
+ else
+ repo = xstrdup(path);
+ }
else if (!strchr(repo_name, ':'))
die(_("repository '%s' does not exist"), repo_name);
else
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 67869b4..0eeeb2d 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -280,4 +280,20 @@ test_expect_success 'clone checking out a tag' '
test_cmp fetch.expected fetch.actual
'
+test_expect_success 'clone does not create ambiguous config' '
+ git init --bare ambiguous.git &&
+ git clone ambiguous &&
+ (
+ cd ambiguous &&
+ test_commit one &&
+ git push --all
+ ) &&
+ echo one >expect &&
+ (
+ cd ambiguous.git &&
+ git log -1 --format=%s
+ ) >actual &&
+ test_cmp expect actual
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] gitweb.perl: fix %highlight_ext mappings
From: rh @ 2012-11-08 18:36 UTC (permalink / raw)
To: git
In-Reply-To: <20121108180157.GK15560@sigill.intra.peff.net>
On Thu, 8 Nov 2012 13:01:57 -0500
Jeff King <peff@peff.net> wrote:
> On Sun, Nov 04, 2012 at 09:45:55AM -0800, rh wrote:
>
> > The previous change created a dictionary of one-to-one elements when
> > the intent was to map mutliple related types to one main type.
> > e.g. bash, ksh, zsh, sh all map to sh since they share similar
> > syntax This makes the mapping as the original change intended.
> >
> > Signed-off-by: Richard Hubbell <richard_hubbe11@lavabit.com>
>
> Thanks.
>
> > diff --git a/gitweb.cgi.orig b/gitweb.cgi
> > index 060db27..155b238 100755
> > --- a/gitweb.cgi.orig
> > +++ b/gitweb.cgi
>
> This is not the name of the source file in git.git, so "git am"
> choked. I was able to fix it up locally, though. No need to resend.
Somehow I knew that it wouldn't be a slam dunk!
Thanks for doing what you do. FWIW maybe others can follow
this thread to know what not to do. And save you extra work.
>
> -Peff
--
"Now, in his heart, Ahab had some glimpse of this, namely; all my means
are sane, my motive and my object mad."
^ permalink raw reply
* Re: [PATCH] Clarify how content states are to be built as the fast-import stream is interpreted.
From: Jeff King @ 2012-11-08 18:32 UTC (permalink / raw)
To: Eric; +Cc: git
In-Reply-To: <20121108183038.GA4003@thyrsus.com>
On Thu, Nov 08, 2012 at 01:30:38PM -0500, Eric wrote:
> > Looks reasonable. Sign-off?
> >
>
> Ah, right. Shall resend with signoff. Probably Tuesday - I'm on the
> road, and the git instance on my laptop is prone to library-load issues.
>
> Or you can just add
>
> Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
That's fine. I can fix it up locally. Thanks.
-Peff
^ permalink raw reply
* Re: git svn problem, probably a regression
From: Jeff King @ 2012-11-08 18:06 UTC (permalink / raw)
To: Joern Huxhorn; +Cc: git
In-Reply-To: <36370AA5-4BB9-4D36-95A7-BB3DA315C9E6@googlemail.com>
On Sun, Nov 04, 2012 at 09:31:17PM +0100, Joern Huxhorn wrote:
> git svn failed on me with the following error while cloning an SVN repository:
> r1216 = fcf69d5102378ee41217d60384b96549bf2173cb (refs/remotes/svn/trunk)
> Found possible branch point: svn+ssh://<repositoryName>@<IP address>/trunk => svn+ssh://<repositoryName>@<IP address>/tags/xxxx_2008-10-22, 1216
> Use of uninitialized value $u in substitution (s///) at /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106.
> Use of uninitialized value $u in concatenation (.) or string at /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106.
> refs/remotes/svn/asset-manager-redesign: 'svn+ssh://<IP address>' not found in ''
>
> I'm running git 1.8.0 via Homebrew on OS X. It was called via svn2git but I doubt that this is the culprit.
> A colleague of mine was able to perform the same operation with git 1.7.x (not sure which) on Debian so I assume that this is a regression.
>
> I just wanted to let you know.
If you have time and can reproduce the bug at will, it would be very
helpful to use "git-bisect" to pinpoint the exact commit that causes the
breakage.
-Peff
^ permalink raw reply
* Re: [PATCH as/check-ignore] t0007: fix tests on Windows
From: Jeff King @ 2012-11-08 18:04 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano,
Adam Spiers
In-Reply-To: <5096D92A.7090600@kdbg.org>
On Sun, Nov 04, 2012 at 10:07:54PM +0100, Johannes Sixt wrote:
> The value of $global_excludes is sometimes part of the output
> that is tested for. Since git on Windows only sees DOS style paths,
> we have to ensure that the "expected" values are constructed in
> the same manner. To account for this, use $(pwd) to set the value
> of global_excludes.
>
> Additionally, add a SYMLINKS prerequisite to the tests involving
> symbolic links.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Thanks. I put this on top of as/check-ignore in 'pu' for reference, but
I am still expecting a re-roll from Adam or Duy at some point.
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb.perl: fix %highlight_ext mappings
From: Jeff King @ 2012-11-08 18:01 UTC (permalink / raw)
To: rh; +Cc: git
In-Reply-To: <20121104094555.a46992b6d836c1e09524d2cc@lavabit.com>
On Sun, Nov 04, 2012 at 09:45:55AM -0800, rh wrote:
> The previous change created a dictionary of one-to-one elements when
> the intent was to map mutliple related types to one main type.
> e.g. bash, ksh, zsh, sh all map to sh since they share similar syntax
> This makes the mapping as the original change intended.
>
> Signed-off-by: Richard Hubbell <richard_hubbe11@lavabit.com>
Thanks.
> diff --git a/gitweb.cgi.orig b/gitweb.cgi
> index 060db27..155b238 100755
> --- a/gitweb.cgi.orig
> +++ b/gitweb.cgi
This is not the name of the source file in git.git, so "git am" choked.
I was able to fix it up locally, though. No need to resend.
-Peff
^ permalink raw reply
* Re: [PATCH] git p4: RCS expansion should not span newlines
From: Jeff King @ 2012-11-08 17:47 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Chris Goard
In-Reply-To: <20121104220402.GA9160@padd.com>
On Sun, Nov 04, 2012 at 05:04:02PM -0500, Pete Wyckoff wrote:
> This bug was introduced in cb585a9 (git-p4: keyword
> flattening fixes, 2011-10-16). The newline character
> is indeed special, and $File$ expansions should not try
> to match across multiple lines.
>
> Based-on-patch-by: Chris Goard <cgoard@gmail.com>
> Signed-off-by: Pete Wyckoff <pw@padd.com>
Thanks, I'll queue this for 'maint'. Seems obviously correct to me.
-Peff
^ 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