* 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 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: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 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
* 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: 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
* 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
* [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
* [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 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
* Re: [PATCH] gitweb: make remote_heads config setting work.
From: Junio C Hamano @ 2012-11-09 4:40 UTC (permalink / raw)
To: Phil Pennock; +Cc: git, peff
In-Reply-To: <20121105235047.GA78156@redoubt.spodhuis.org>
Phil Pennock <phil@apcera.com> writes:
> @@ -2702,6 +2702,7 @@ sub git_get_project_config {
> $key = lc($key);
> }
> $key =~ s/^gitweb\.//;
> + $key =~ s/_//g;
> return if ($key =~ m/\W/);
>
> # type sanity check
The idea to strip "_" from "remote_heads" to create "remoteheads" is
fine, but I am not sure if the implementation is good.
Looking at the code before this part:
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
$key = join(".", lc($hi), $mi, lc($lo));
} else {
$key = lc($key);
}
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
the new code is munding the $hi and $mi parts, while the mistaken
configuration this patch is trying to correct is about the $lo part,
and possibly the $hi part, but never the $mi part.
It is expected that $hi will always be gitweb, and I suspect that
there may not be any "per something" configuration variable (e.g.
"gitweb.master.blame" may be used to override the default value
given by "gitweb.blame" only for the master branch), that uses $mi
part, so it might not matter to munge the entire $key like this
patch does with the current code.
But that makes it even more important to get this part right _now_;
otherwise, it is likely that this new code will introduce a bug to
a future patch that adds "per something" configuration support.
^ permalink raw reply
* [PATCH v3 2/3] git-submodule foreach: export .gitmodules settings as variables
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 makes it easy to access per-submodule variables. For example,
git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
can now be reduced to
git submodule foreach 'git checkout $submodule_branch && git pull'
Every submodule.<name>.<opt> setting from .gitmodules is available as
a $submodule_<sanitized-opt> variable. These variables are not
propagated recursively into nested submodules.
Signed-off-by: W. Trevor King <wking@tremily.us>
Based-on-patch-by: Phil Hord <phil.hord@gmail.com>
---
Documentation/git-submodule.txt | 3 +++
git-sh-setup.sh | 20 ++++++++++++++++++++
git-submodule.sh | 16 ++++++++++++++++
t/t7407-submodule-foreach.sh | 29 +++++++++++++++++++++++++++++
4 files changed, 68 insertions(+)
mode change 100644 => 100755 git-sh-setup.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cbec363..9a99826 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -175,6 +175,9 @@ foreach::
$path is the name of the submodule directory relative to the
superproject, $sha1 is the commit as recorded in the superproject,
and $toplevel is the absolute path to the top-level of the superproject.
+ In addition, every submodule.<name>.<opt> setting from .gitmodules
+ is available as the variable $submodule_<sanitized_opt>. These
+ variables are not propagated recursively into nested submodules.
Any submodules defined in the superproject but not checked out are
ignored by this command. Unless given `--quiet`, foreach prints the name
of each submodule before evaluating the command.
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
old mode 100644
new mode 100755
index ee0e0bc..179a920
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -222,6 +222,26 @@ clear_local_git_env() {
unset $(git rev-parse --local-env-vars)
}
+# Remove any suspect characters from a user-generated variable name.
+sanitize_variable_name() {
+ VAR_NAME="$1"
+ printf '%s' "$VAR_NAME" |
+ sed -e 's/^[^a-zA-Z]/_/' -e 's/[^a-zA-Z0-9]/_/g'
+}
+
+# Return a command for setting a new variable.
+# Neither the variable name nor the variable value passed to this
+# function need to be sanitized. You need to eval the returned
+# string, because new variables set by the function itself don't
+# effect the calling process.
+set_user_variable() {
+ VAR_NAME="$1"
+ VAR_VALUE="$2"
+ VAR_NAME=$(sanitize_variable_name "$VAR_NAME")
+ VAR_VALUE=$(printf '%s' "$VAR_VALUE" |
+ sed -e 's/\\/\\\\/g' -e 's/"/\\"/g')
+ printf '%s=%s;\n' "$VAR_NAME" "\"$VAR_VALUE\""
+}
# Platform specific tweaks to work around some commands
case $(uname -s) in
diff --git a/git-submodule.sh b/git-submodule.sh
index bc33112..e4d26f9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -434,8 +434,24 @@ cmd_foreach()
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+ # make all submodule variables available to scripts
+ eval $(
+ git config -f .gitmodules --get-regexp "^submodule\.${name}\..*" |
+ sed -e "s|^submodule\.${name}\.||" |
+ while read VAR_NAME VAR_VALUE ; do
+ VAR_NAME=$(printf '%s' "$VAR_NAME" | tr A-Z a-z)
+ set_user_variable "submodule_${VAR_NAME}" "$VAR_VALUE"
+ done)
+ UNSET_CMD=$(set |
+ sed -n -e 's|^\(submodule_[a-z_]*\)=.*$|\1|p' |
+ while read VAR_NAME ; do
+ printf 'unset %s;\n' "$VAR_NAME"
+ done)
+
cd "$sm_path" &&
eval "$@" &&
+ eval "$UNSET_CMD" &&
if test -n "$recursive"
then
cmd_foreach "--recursive" "$@"
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 9b69fe2..46ac746 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -313,4 +313,33 @@ test_expect_success 'command passed to foreach --recursive retains notion of std
test_cmp expected actual
'
+cat > expect <<EOF
+Entering 'nested1'
+nested1 nested1 wonky"value
+Entering 'nested1/nested2'
+nested2 nested2 another wonky"value
+Entering 'nested1/nested2/nested3'
+nested3 nested3
+Entering 'nested1/nested2/nested3/submodule'
+submodule submodule
+Entering 'sub1'
+sub1 sub1
+Entering 'sub2'
+sub2 sub2
+Entering 'sub3'
+sub3 sub3
+EOF
+
+test_expect_success 'test foreach environment variables' '
+ (
+ cd clone2 &&
+ git config -f .gitmodules submodule.nested1.wonky-var "wonky\"value" &&
+ git config -f nested1/.gitmodules submodule.nested2.wonky-var "another wonky\"value" &&
+ git submodule foreach --recursive "echo \$path \$submodule_path \$submodule_wonky_var" > ../actual
+ ) &&
+ test_i18ncmp expect actual
+'
+#
+#"echo \$toplevel-\$name-\$submodule_path-\$submodule_url"
+
test_done
--
1.8.0.3.gc2eb43a
^ permalink raw reply related
* RE: orphan blob or what?
From: Robertson, Bruce E @ 2012-11-09 6:23 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <87a9urlj23.fsf@intel.com>
Please excuse one inaccuracy: I did a 'git pull' not a clone. So it could be an old .idx file at my end possibly.
Thanks,
bruce
-----Original Message-----
From: Robertson, Bruce E
Sent: Thursday, November 08, 2012 4:25 PM
To: git@vger.kernel.org
Subject: orphan blob or what?
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: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Junio C Hamano @ 2012-11-09 7:34 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <fb2d915cf60160c200b84df88c6112c1c2d4eefd.1352431674.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> By remaining agnostic on the variable usage, this patch makes
> submodule setup more convenient for all parties.
I personally do not think "remaining agnostic on the usage" is a
good thing, at least for any option to commands at the higher level
on the stack, such as "git submodule". I am afraid that giving an
easier way to set up a variable with undefined semantics may make
setup more confusing for all parties. One party gives one specific
meaning to the field, while another party uses it for something
slightly different.
I would not object to "git config submodule.$name.branch $value", on
the other hand. "git config" can be used to set a piece of data
that has specific meaning, but as a low-level tool, it is not
_limited_ to variables that have defined meaning.
^ permalink raw reply
* Rename edge case...
From: John Szakmeister @ 2012-11-09 9:10 UTC (permalink / raw)
To: git
I've been browsing StackOverflow answering git-related questions, and
ran across this one:
<http://stackoverflow.com/questions/13300675/git-merge-rename-conflict>
It's a bit of an interesting situation. The user did a couple of
renames in a branch:
foo.txt => fooOld.txt
fooNew.txt => foo.txt
Meanwhile, master had an update to fooNew.txt. When the user tried to
merge master to the branch, it gave a merge conflict saying fooNew.txt
was deleted, but master tried to update it.
I was a bit surprised that git didn't follow the rename here, though I
do understand why: git only sees it as a rename if the source
disappears completely. So I played locally with a few ideas, and was
surprised to find out that even breaking up the two renames into two
separate commits git still didn't follow it.
I'm just curious--I don't run into this often myself--but is there a
good strategy for dealing with this that avoids the conflict?
Thanks!
-John
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Michael J Gruber @ 2012-11-09 9:28 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20121108200919.GP15560@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 08.11.2012 21:09:
> 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).
I don't expect our requirements to change. For one thing, I was
surprised that git-commit is more tolerant than git-fast-import, but it
makes a lot of sense to avoid any behind-the-back conversions in the
importer.
>> 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).
That was more my real concern. In our cvs and svn interfaces, we even
encourage the use of author maps. For example, if you use an author map,
git-svn errors out if it encounters an svn user name which is not in the
map. On the other hand, we can map all (most?) svn user names faithfully
without using a map (e.g. to "username <none@none>").
Hg seems to store just anything in the author field ("committer"). The
various interfaces that are floating around do some behind-the-back
conversion to git format. The more conversions they do, the better they
seem to work (no erroring out) but I'm wondering whether it's really a
good thing, or whether we should encourage a more diligent approach
which requires a user to map non-conforming author names wilfully.
Michael
^ permalink raw reply
* Re: Rename edge case...
From: Tomas Carnecky @ 2012-11-09 9:27 UTC (permalink / raw)
To: John Szakmeister, git
In-Reply-To: <CAEBDL5U+OSTCAqgWoApE_m21Nef24Wqvt78oB6qqV4oEvU0vXQ@mail.gmail.com>
On Fri, 09 Nov 2012 04:10:31 -0500, John Szakmeister <john@szakmeister.net> wrote:
> I've been browsing StackOverflow answering git-related questions, and
> ran across this one:
> <http://stackoverflow.com/questions/13300675/git-merge-rename-conflict>
>
> It's a bit of an interesting situation. The user did a couple of
> renames in a branch:
> foo.txt => fooOld.txt
> fooNew.txt => foo.txt
>
> Meanwhile, master had an update to fooNew.txt. When the user tried to
> merge master to the branch, it gave a merge conflict saying fooNew.txt
> was deleted, but master tried to update it.
>
> I was a bit surprised that git didn't follow the rename here, though I
> do understand why: git only sees it as a rename if the source
> disappears completely. So I played locally with a few ideas, and was
> surprised to find out that even breaking up the two renames into two
> separate commits git still didn't follow it.
>
> I'm just curious--I don't run into this often myself--but is there a
> good strategy for dealing with this that avoids the conflict?
When merging two branches, git only looks at the tips. It doesn't inspect
their histories to see how the files were moved around. So i doesn't matter
whether you rename the files in a single commit or multiple commits. The
resulting tree is always the same.
tom
^ permalink raw reply
* Re: Rename edge case...
From: John Szakmeister @ 2012-11-09 10:25 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1352453243-ner-1164@calvin>
On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
[snip]
> When merging two branches, git only looks at the tips. It doesn't inspect
> their histories to see how the files were moved around. So i doesn't matter
> whether you rename the files in a single commit or multiple commits. The
> resulting tree is always the same.
I guess I figured that when I saw the final result, but didn't know if
there was a way to coax Git into doing a better job here. I guess not
though. At least it's a situation that doesn't come up often.
-John
^ permalink raw reply
* Re: Rename edge case...
From: Nguyen Thai Ngoc Duy @ 2012-11-09 10:30 UTC (permalink / raw)
To: John Szakmeister; +Cc: Tomas Carnecky, git
In-Reply-To: <CAEBDL5WeQEWdyaJuuNbnnQbbsLYv8NO1ZSj3eHHpjW+ToS9X1A@mail.gmail.com>
On Fri, Nov 9, 2012 at 5:25 PM, John Szakmeister <john@szakmeister.net> wrote:
> On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> [snip]
>> When merging two branches, git only looks at the tips. It doesn't inspect
>> their histories to see how the files were moved around. So i doesn't matter
>> whether you rename the files in a single commit or multiple commits. The
>> resulting tree is always the same.
>
> I guess I figured that when I saw the final result, but didn't know if
> there was a way to coax Git into doing a better job here. I guess not
> though.
There is not (yet). There were a few patches around that allow users
to override git's automatic renames. You can search the mail archive.
I think the keywords are "rename cache". Thanks for reminding me for
putting a higher priority on that.
--
Duy
^ permalink raw reply
* [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Nguyễn Thái Ngọc Duy @ 2012-11-09 11:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Jonathon Mah,
Nguyễn Thái Ngọc Duy
In-Reply-To: <3E62F933-76CD-4578-8684-21444EAA454F@JonathonMah.com>
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), an index with i-t-a entries can
write trees. However, the commit forgets to invalidate all paths
leading to i-t-a entries. With fully valid cache-tree (e.g. after
commit or write-tree), diff operations may prefer cache-tree to index
and not see i-t-a entries in the index, because cache-tree does not
have them.
The invalidation is done after calling update_one() in
cache_tree_update() for simplicity because it's probably not worth the
complexity of changing a recursive function and the performance
bottleneck won't likely fall to this new loop, rather in
write_sha1_file or hash_sha1_file. But this means that if update_one()
has new call sites, they must re-do the same what this commit does to
avoid the same fault.
Reported-by: Jonathon Mah <me@JonathonMah.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
cache-tree.c | 3 +++
t/t2203-add-intent.sh | 20 ++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..30a8018 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
+ for (i = 0; i < entries; i++)
+ if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
+ cache_tree_invalidate_path(it, cache[i]->name);
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..2a4a749 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'cache-tree invalidates i-t-a paths' '
+ git reset --hard &&
+ mkdir dir &&
+ : >dir/foo &&
+ git add dir/foo &&
+ git commit -m foo &&
+
+ : >dir/bar &&
+ git add -N dir/bar &&
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual &&
+
+ git write-tree >/dev/null &&
+
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Junio C Hamano @ 2012-11-09 11:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <1352459040-14452-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/cache-tree.c b/cache-tree.c
> index 28ed657..30a8018 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
> i = update_one(it, cache, entries, "", 0, flags);
> if (i < 0)
> return i;
> + for (i = 0; i < entries; i++)
> + if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
> + cache_tree_invalidate_path(it, cache[i]->name);
> return 0;
> }
I notice there is another special case for CE_REMOVE but there is
nothing that adjusts the cache-tree for these entries in the current
codebase.
I suspect the original code before we (perhaps incorrectly) updated
the code not to error out upon I-T-A entries was fine only because
we do not attempt to fully populate the cache-tree during a merge in
the unpack-trees codepath, which will mark the index entries that
are to be removed with CE_REMOVE in the resulting index.
The solution implemented with this patch will break if we start
updating the cache tree after a successful merge in unpack-trees, I
suspect.
An alternative might be to add a "phoney" bit next to "used" in the
cache_tree structure, mark the cache tree as phoney when we skip an
entry marked as CE_REMOVE or CE_ITA, and make the postprocessing
loop this patch adds aware of that bit, instead of iterating over
the index entries; instead, it would recurse the resulting cache
tree and invalidate parts of the tree that have subtrees with the
"phoney" bit set, or something.
^ permalink raw reply
* Re: Rename edge case...
From: Johannes Sixt @ 2012-11-09 13:17 UTC (permalink / raw)
To: John Szakmeister; +Cc: Tomas Carnecky, git
In-Reply-To: <CAEBDL5WeQEWdyaJuuNbnnQbbsLYv8NO1ZSj3eHHpjW+ToS9X1A@mail.gmail.com>
Am 11/9/2012 11:25, schrieb John Szakmeister:
> On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> [snip]
>> When merging two branches, git only looks at the tips. It doesn't inspect
>> their histories to see how the files were moved around. So i doesn't matter
>> whether you rename the files in a single commit or multiple commits. The
>> resulting tree is always the same.
>
> I guess I figured that when I saw the final result, but didn't know if
> there was a way to coax Git into doing a better job here.
If the renames are split in two commits, you can merge the first, and then
the second on top of the result.
-- Hannes
^ permalink raw reply
* bash completion of "addable" files for `git add`
From: Andreas Zeidler @ 2012-11-09 13:22 UTC (permalink / raw)
To: git; +Cc: gitster
hi,
i've always been annoyed by having to type — or copy & paste — paths when i wanted to simply add some files to the index. i know about the `add -i` interface, and that improves things a little, but having bash completion for so many other things it still seemed to much hassle.
so here's a patch adding bash completion on `git add` for modified, updated and untracked files. i've also set up a pull request — before i found `Documentation/SubmittingPatches`. fwiw, it's at https://github.com/git/git/pull/29
best regards,
andi
From cbac6caee7e788569562cb7138eb698cc46a1b8f Mon Sep 17 00:00:00 2001
From: Andreas Zeidler <az@zitc.de>
Date: Fri, 9 Nov 2012 13:05:43 +0100
Subject: [PATCH] add bash completion for "addable" files
this adds support for completing only modified, updated and untracked
files on `git add`, since almost always these are what you want to add
to the index.
the list of possible completions is determined using `git status` and
filtered using `egrep` and `sed`.
Signed-off-by: Andreas Zeidler <az@zitc.de>
---
contrib/completion/git-completion.bash | 15 +++++++++++++++
t/t9902-completion.sh | 11 +++++++++++
2 files changed, 26 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e0..4aa0981 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -799,6 +799,16 @@ _git_apply ()
COMPREPLY=()
}
+__git_addable ()
+{
+ local dir="$(__gitdir)"
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" status --short --untracked=all |\
+ egrep '^.[UM?] ' | sed 's/^.. //'
+ return
+ fi
+}
+
_git_add ()
{
__git_has_doubledash && return
@@ -810,6 +820,11 @@ _git_add ()
--ignore-errors --intent-to-add
"
return
+ ;;
+ *)
+ __gitcomp "$(__git_addable)"
+ return
+ ;;
esac
COMPREPLY=()
}
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb6..a7c81d3 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -288,4 +288,15 @@ test_expect_failure 'complete tree filename with metacharacters' '
EOF
'
+test_expect_success 'add completes untracked and modified names' '
+ echo other content >file1 &&
+ echo content >file2 &&
+ echo more >file3 &&
+ git add file1 &&
+ test_completion_long "git add f" <<-\EOF
+ file2_
+ file3_
+ EOF
+'
+
test_done
--
1.8.0.1.g43af610
--
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
upgrade to plone 4! -- http://plone.org/4
^ permalink raw reply related
* Re: git svn problem, probably a regression
From: Joseph Crowell @ 2012-11-09 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <20121108180657.GM15560@sigill.intra.peff.net>
> > 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 ''
>
> 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
>
I just encountered the exact same issue while converting an svn repo to git on
Windows through Git Bash. Same error.
^ permalink raw reply
* git merge commits are non-deterministic? what changed?
From: Ulrich Spörlein @ 2012-11-09 13:31 UTC (permalink / raw)
To: git
Hi all,
I'm running a couple of conversions from SVN to git, using a slightly
hacked version of svn2git (because it can cope with multiple branches
and is several orders of magnitude faster than git-svn).
Anyway, when doing some verification runs, using the same version of
svn2git, but different versions of git, I get different commit hashes,
and I tracked it down to the ordering of the parents inside a merge
commit.
version 1.7.9.2
% git show --format=raw e209a83|head
commit e209a83c1e0a387c88a44f3a8f2be2670ed85eae
tree de2d7c6726a45428d4a310da2acd8839daf9f85f
parent 5fba0401c23a594e4ad5e807bf14a5439645a358
parent 25062ba061871945759b3baa833fe64969383e40
parent 89bebeef185ed08424fc548f8569081c6add2439
parent c7d5f60d3a7e2e3c4da23b157c62504667344438
parent e7bc108f0d6a394050818a4af64a59094d3c793e
parent 48231afadc40013e6bfda56b04a11ee3a602598f
author rgrimes <rgrimes@FreeBSD.org> 739897097 +0000
committer rgrimes <rgrimes@FreeBSD.org> 739897097 +0000
vs
git version 1.8.0
% git show --format=raw 42f0fad|head
commit 42f0fadccab6eefc7ffdc1012345b42ad45e36c2
tree de2d7c6726a45428d4a310da2acd8839daf9f85f
parent 5fba0401c23a594e4ad5e807bf14a5439645a358
parent 25062ba061871945759b3baa833fe64969383e40
parent 89bebeef185ed08424fc548f8569081c6add2439
parent 48231afadc40013e6bfda56b04a11ee3a602598f
parent c7d5f60d3a7e2e3c4da23b157c62504667344438
parent e7bc108f0d6a394050818a4af64a59094d3c793e
author rgrimes <rgrimes@FreeBSD.org> 739897097 +0000
committer rgrimes <rgrimes@FreeBSD.org> 739897097 +0000
I haven't verified to see if that ordering is stable within a git
version, but the fact that it changed across versions clearly means that
I cannot depend on this currently (I have never seen this problem in two
years, so I blame git 1.8.0 ...)
Two questions:
1. Can we impose a stable ordering of the commits being recorded in a
merge commit? Listing parents in chronological order or something like
that.
2. Why the hell is the commit hash dependent on the ordering of the
parent commits? IMHO it should sort the set of parents before
calculating the hash ...
Help?
Uli
^ 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