* [PATCH v16 2/7] bisect: use && to connect statements that are deferred with eval.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
Christian Couder pointed out that the existing eval strategy
swallows an initial non-zero return. Using && to connect
the statements should fix this.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 20f6dd5..a44ffe1 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -86,7 +86,7 @@ bisect_start() {
0) state='bad' ; bad_seen=1 ;;
*) state='good' ;;
esac
- eval="$eval bisect_write '$state' '$rev' 'nolog'; "
+ eval="$eval bisect_write '$state' '$rev' 'nolog' &&"
shift
;;
esac
@@ -145,7 +145,7 @@ bisect_start() {
#
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
- eval "$eval" &&
+ eval "$eval true" &&
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
#
# Check if we can proceed to the next bisect state.
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 1/7] bisect: move argument parsing before state modification.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
Currently 'git bisect start' modifies some state prior to checking
that its arguments are valid.
This change moves argument validation before state modification
with the effect that state modification does not occur
unless argument validations succeeds.
An existing test is changed to check that new bisect state
is not created if arguments are invalid.
A new test is added to check that existing bisect state
is not modified if arguments are invalid.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 66 +++++++++++++++++++++---------------------
t/t6030-bisect-porcelain.sh | 14 +++++++--
2 files changed, 44 insertions(+), 36 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index b2186a8..20f6dd5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -60,6 +60,39 @@ bisect_autostart() {
bisect_start() {
#
+ # Check for one bad and then some good revisions.
+ #
+ has_double_dash=0
+ for arg; do
+ case "$arg" in --) has_double_dash=1; break ;; esac
+ done
+ orig_args=$(git rev-parse --sq-quote "$@")
+ bad_seen=0
+ eval=''
+ while [ $# -gt 0 ]; do
+ arg="$1"
+ case "$arg" in
+ --)
+ shift
+ break
+ ;;
+ *)
+ rev=$(git rev-parse -q --verify "$arg^{commit}") || {
+ test $has_double_dash -eq 1 &&
+ die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
+ break
+ }
+ case $bad_seen in
+ 0) state='bad' ; bad_seen=1 ;;
+ *) state='good' ;;
+ esac
+ eval="$eval bisect_write '$state' '$rev' 'nolog'; "
+ shift
+ ;;
+ esac
+ done
+
+ #
# Verify HEAD.
#
head=$(GIT_DIR="$GIT_DIR" git symbolic-ref -q HEAD) ||
@@ -98,39 +131,6 @@ bisect_start() {
bisect_clean_state || exit
#
- # Check for one bad and then some good revisions.
- #
- has_double_dash=0
- for arg; do
- case "$arg" in --) has_double_dash=1; break ;; esac
- done
- orig_args=$(git rev-parse --sq-quote "$@")
- bad_seen=0
- eval=''
- while [ $# -gt 0 ]; do
- arg="$1"
- case "$arg" in
- --)
- shift
- break
- ;;
- *)
- rev=$(git rev-parse -q --verify "$arg^{commit}") || {
- test $has_double_dash -eq 1 &&
- die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
- break
- }
- case $bad_seen in
- 0) state='bad' ; bad_seen=1 ;;
- *) state='good' ;;
- esac
- eval="$eval bisect_write '$state' '$rev' 'nolog'; "
- shift
- ;;
- esac
- done
-
- #
# Change state.
# In case of mistaken revs or checkout error, or signals received,
# "bisect_auto_next" below may exit or misbehave.
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index b5063b6..b3d1b14 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -138,15 +138,23 @@ test_expect_success 'bisect start: back in good branch' '
grep "* other" branch.output > /dev/null
'
-test_expect_success 'bisect start: no ".git/BISECT_START" if junk rev' '
- git bisect start $HASH4 $HASH1 -- &&
- git bisect good &&
+test_expect_success 'bisect start: no ".git/BISECT_START" created if junk rev' '
+ git bisect reset &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
test_must_fail test -e .git/BISECT_START
'
+test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if junk rev' '
+ git bisect start $HASH4 $HASH1 -- &&
+ git bisect good &&
+ cp .git/BISECT_START saved &&
+ test_must_fail git bisect start $HASH4 foo -- &&
+ git branch > branch.output &&
+ grep "* (no branch)" branch.output > /dev/null &&
+ test_cmp saved .git/BISECT_START
+'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
git bisect start $HASH4 $HASH1 -- &&
git bisect good &&
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 0/7] bisect: Add support for --no-checkout option
From: Jon Seymour @ 2011-08-03 21:56 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
Motivation
==========
For some bisection tasks, checking out the commit at each stage of the bisection process is unecessary or undesirable.
This series adds support for a --no-checkout option to git-bisect.
If specified on a start command, --no-checkout causes 'git bisect' to update BISECT_HEAD at each stage of the bisection process instead of checking out the commit at that point.
One application of the --no-checkout option is to find, within a partially damaged repository, a commit that has at least one parent whose graph is fully reachable in the sense of 'git pack-objects'.
For example:
git bisect start BISECT_HEAD <some-known-good-commit> <boundary-commits> --no-checkout
git bisect run sh -c '
GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git pack-objects --stdout >/dev/null <tmp.$$
rc=$?
rm -f tmp.$$
test $rc = 0'
<some-known-good-commit> is a known good commit, for which the test passes.
<boundary-commits> are commits chosen to prevent the bisection visiting missing or corrupt commit objects.
Assuming this git bisect run completes successfully, bisect/bad will refer to a commit which has at least one parent that is fully reachable in the sense of 'git pack-objects'.
Patch Synopsis
==============
Remediation
-----------
Patch 1/7 changes existing behaviour in the case that an invalid revision argument is supplied to 'git bisect start'. In particular, in this case, bisection state is neither created or modified if argument validation fails. Previously, existing bisection state would be cleared even if the revision arguments were subsequently determined to be invalid.
Patch 2/7 remediates a potential flaw that might hide a failure in a chain of pasted statements.
Patch 3/7 adds a test which documents the existing behaviour of git bisect in the presence of tree damage.
New Function
------------
Patch 4/7 modifies the C code that supports bisection.
Patch 5/7 modifies porcelain to enable option exposed by 4/7.
Patch 6/7 adds some tests.
Patch 7/7 adds some documentation.
Revision History
----------------
v16:
Use --no-def with update-ref -d.
Ensure update-ref BISECT_HEAD is created after BISECT_START and destroyed before BISECT_START. (Christian Couder)
dash compatability (Jonathan Nieder).
Documentation and test tweaks (Junio Hamano).
v15:
Fixed reset behaviour in --no-checkout case. Added one test for same.
Simplified implementation so that no-checkout mode is inferred by presence of
$GIT_DIR/BISECT_HEAD eliminating the need for a separate BISECT_MODE control file.
Patch 8/8 from v13/14 was redistributed and squashed into earlier commits.
Style and documentation edits based on feedback from Christian Coulder.
v14:
Reverted --bisect-mode aspect of v13 change so C code matches v11.
v13:
Following suggestions from Junio:
* Replaced BISECT_NO_CHECKOUT control file with BISECT_MODE.
* Changed name of internal option on bisect--helper from --no-checkout to --bisect-mode=checkout|update-ref.
* Changed --no-checkout bisections to update BISECT_HEAD instead of HEAD.
v11:
Removed support for --update-ref=<ref>, per Junio's preference.
v10:
Changed the way deferred statements are connected. Reverted some whitespace minimization.
v8:
Further feedback from Christian Couder. Support --update-ref <ref>.
v6:
This series includes numerous improvements suggested by Christian Couder.
Reworks:
"bisect: allow git bisect to be used with repos containing damaged trees."
Replaced --ignore-checkout-failure with --no-checkout option suggested by Junio.
Future series
-------------
* Implement full support for bisection in bare repositories.
Jon Seymour (7):
bisect: move argument parsing before state modification.
bisect: use && to connect statements that are deferred with eval.
bisect: add tests to document expected behaviour in presence of
broken trees.
bisect: introduce support for --no-checkout option.
bisect: introduce --no-checkout support into porcelain.
bisect: add tests for the --no-checkout option.
bisect: add documentation for --no-checkout option.
Documentation/git-bisect.txt | 32 +++++++++-
bisect.c | 33 +++++++---
bisect.h | 2 +-
builtin/bisect--helper.c | 7 ++-
git-bisect.sh | 112 +++++++++++++++++++-------------
t/t6030-bisect-porcelain.sh | 144 +++++++++++++++++++++++++++++++++++++++++-
6 files changed, 267 insertions(+), 63 deletions(-)
--
1.7.6.352.g172e
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 21:49 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Heiko Voigt, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <4E399C62.30604@web.de>
Le mercredi 03 août 2011 à 21:07 +0200, Jens Lehmann a écrit :
> Am 03.08.2011 19:11, schrieb Junio C Hamano:
> > henri GEIST <henri.geist@flying-robots.com> writes:
> >
> >> I plan to use a config file containing lines like
> >>
> >> "path_to_poited_repo SHA1_of_intended_commit URL_of_origin"
> >>
> >> the URL part will not be required.
> >>
> >> this file will be a list of pointer to other project.
> >
> > I wasn't paying attention to this thread, but I have to ask "why" here.
> >
> > The first two are what gitlink was designed to do in the superproject that
> > ties multiple submodules together, and the last one is also supplied by
> > the .gitmodules in that superproject. This seems to be adding the same
> > information in a redundant way by saying "this version A0 of submodule A
> > wants version B0 of submodule B and version C0 of submodule C" when the
> > supermodule can say "the consistent view I record is to have version A0,
> > B0 and C0 of submodules A, B and C, respectively".
>
> During the discussion this evolved from a simple "I need that submodule
> with exactly this version" to something I believe is more generic and
> very useful for others. As I see it now a submodule should be able to say:
>
> 1) To use me, you need another submodule "foo"
>
> This is very helpful when you want to add the Gimp submodule and it
> can tell you you'll need the libpng submodule too in your superproject
> (but I'd vote to use the submodule name here, not the path as that
> should be the superproject's decision).
>
> In addition to that, it can (but mustn't) specify any of the following:
>
> a) Of this submodule "foo" I need at least that version because I won't
> compile/work with older versions of that. (this can be tightened to
> "exactly that version" to give henri the behavior he wants, but that
> should be policy, not mandatory)
>
Of corse and git will not enforce this policy.
Git status will only say the version is unrelated, match or is higher.
And it is left to the human reading the status to decide if it is OK
with his policy.
> Gimp could say it needs at least libpng 012345 because in that version
> the function foobar() was added it now depends on. Normally this won't
> be updated very often, but if people like henri use that to say "I'll
> only promise to work well with that exact version, as that went through
> extensive QA" they might change that on virtually every commit.
>
In fact I do so very rarely I do not update my project to track the last
version of the library until the project need it. If the library get new
features and improvement that I do not need I keep the old version.
I will not rewrite the tones of certification papers to certify the use
of the new library version without needs. It will destroy all the
forests.
> b) And if you don't know where to get it, use this url
>
> That can give the superproject a hint where it can clone that
> repository from. That could be helpful for distributions to sort out
> the dependencies of the packages they pull in.
>
> That is all stuff the submodule knows better than the superproject. And
> that information can be used to *inform* the user about the submodule's
> needs, maybe using "git status --submodule-dependencies" will print:
>
> # submodule "Gimp" requests a libpng 567890 or newer
> # submodule "foo" has missing dependency "bar"
> But the user can choose to ignore that (because he knows he has the png
> support disabled and he doesn't need the fancy help files from bar).
>
> And maybe "git submodule add" learns an option to automatically add all
> the other submodules the new one depends on too (for that we would need
> the url).
>
Provided that you use a superproject. But my goal is to eliminate it.
> But the superproject is still the place to say: I know these versions of
> all submodules work together, so I commit their gitlinks here. But this
> scheme enables submodules to give hints to help the superproject's user.
>
or they can do it by them selves has now they have all the needed infos.
> > I also suspect that allowing each submodule to know and demand specific
> > versions of other submodules will lead to inconsistencies. Which version
> > of submodule C would you demand to have when submodule A wants version C0
> > and submodule B wants version C1 of it?
>
> Right, in the discussion so far it seemed like henri seems to be the only
> user who is wanting an exact match, and he says he needs to see these
> inconsistencies.
I suspect I am just the only one you now about.
Because that is just what actual submodules does, and nobody complain.
If you
- cd into one of your submodules
- make a commit
- go back into the main repository
- make git status
It will tell you :
"modified: the_submodule_name/ (new commits)"
Note it actually will say "new commits" even if it is older or totally
unrelated. It just signal a mismatch.
Then what I need on this point is just what it actually do.
> But I think he can modify the "version xxx or newer" to
> his needs without imposing these inconsistencies on users (like me) who
> don't want to see them.
>
Of corse git status has never imposed anything.
But I will enabling it to make the distinction between unmatched and
newer version.
Henri
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Heiko Voigt @ 2011-08-03 21:45 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, henri GEIST, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <4E399C62.30604@web.de>
Hi,
On Wed, Aug 03, 2011 at 09:07:14PM +0200, Jens Lehmann wrote:
> Am 03.08.2011 19:11, schrieb Junio C Hamano:
> But the superproject is still the place to say: I know these versions of
> all submodules work together, so I commit their gitlinks here. But this
> scheme enables submodules to give hints to help the superproject's user.
>
> > I also suspect that allowing each submodule to know and demand specific
> > versions of other submodules will lead to inconsistencies. Which version
> > of submodule C would you demand to have when submodule A wants version C0
> > and submodule B wants version C1 of it?
>
> Right, in the discussion so far it seemed like henri seems to be the only
> user who is wanting an exact match, and he says he needs to see these
> inconsistencies. But I think he can modify the "version xxx or newer" to
> his needs without imposing these inconsistencies on users (like me) who
> don't want to see them.
And I imagine if a submodule has such hints we could add a command say
git submodule resolve-dependencies
which could resolve such "I need a version newer than" hints given by a
submodule to help the user to update a submodule in the superproject.
Disclaimer: I think we need to think about all the implications such a
scheme introduces very carefully. The picture is still a bit blurry for
me.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jonathan Nieder @ 2011-08-03 21:45 UTC (permalink / raw)
To: Jon Seymour; +Cc: Junio C Hamano, git, chriscool, j6t, jnareb
In-Reply-To: <CAH3AnrrMUiWkRk0ocr4RY05qj7GU5hqSkaxy+zYJRx12o=hwNA@mail.gmail.com>
Jon Seymour wrote:
> On Thu, Aug 4, 2011 at 4:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> We are very inconsistent about such usage, generally, and of course
>> POSIX is very clear about the 'z' not being needed in a three-argument
>> "test" used for string comparison. Is there any platform that is
>> usable for git (e.g., that implements "$( ... )") and has that
>> problem?
>
> Thanks. Applied.
Hm --- I was just asking a question, not meant to be rhetorical. I
guess the question was applied, or that you inferred some patch from
it. :)
^ permalink raw reply
* Re: [PATCH 1/2] gitattributes: Clarify discussion of attribute macros
From: Junio C Hamano @ 2011-08-03 21:40 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git
In-Reply-To: <20110803194632.GB23848@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't know if that was intentional, or if the behavior is simply
> accidental and the original code was simply never meant to have
> "-binary" called at all.
The latter. You were never expected to say -macro at all.
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-03 21:40 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, chriscool, j6t, jnareb
In-Reply-To: <20110803185719.GA4275@elie.Hillsp>
On Thu, Aug 4, 2011 at 4:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>
>> Just a minor worry but I would not be surprised if somebody's "test"
>> implementation barfs upon:
>>
>> test "--no-checkout" = "--no-checkout"
>>
>> mistaking the string with a dash at the beginning as an option unknown to
>> it. That is why we often have "z$variable" in our comparison, like so:
>>
>> if test "z$BISECT_MODE" = "z--no-checkout"
>
> Hmm.
>
> $ git grep -e 'test "\$' | wc -l
> 712
> $ git grep -e 'test ".\$' | wc -l
> 183
>
> We are very inconsistent about such usage, generally, and of course
> POSIX is very clear about the 'z' not being needed in a three-argument
> "test" used for string comparison. Is there any platform that is
> usable for git (e.g., that implements "$( ... )") and has that
> problem?
>
Thanks. Applied.
^ permalink raw reply
* Re: [PATCH v15 7/7] bisect: add documentation for --no-checkout option.
From: Jon Seymour @ 2011-08-03 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, chriscool, j6t, jnareb
In-Reply-To: <7v62meb4a3.fsf@alter.siamese.dyndns.org>
On Thu, Aug 4, 2011 at 6:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> +This option is useful in circumstances in which checkout is either not
>> +possible (because the repository is damaged) or is otherwise not required.
>
> I do not think "because the repository is damaged" is a particularly good
> example to single out here. For one thing, you may not be able to bisect
> the history in a damaged repository due to unreadable commits. There are
> other valid and more plausible reasons that the users do not want to
> update the working tree while bisecting, e.g. they have local changes,
> they do not want to rebuild everything after bisection is done, etc.
>
> Also the above description muddies what is prerequisite and what is user's
> wish.
>
> - "is otherwise not required" is the prerequisite: "if and only if the
> test you would perform during bisection does not need a checkout of the
> version being tested, you can use this option";
>
> - Even if the user wishes to use this option for various reasons (e.g. so
> that the next "make" wouldn't have to rebuild everything unnecessarily;
> or the repository has corrupt blobs and checkout of some versions may
> fail), if the test _needs_ a checkout, it is not an option to use this
> feature.
>
> So I would suggest toning it down perhaps like this:
>
> This option may be useful when the test you would perform in each step
> does not require a checked out tree.
>
Sounds good.
>> +$ git bisect run eval '
>> +rc=1;
>> +if git rev-list --objects BISECT_HEAD >tmp.$$; then
>> + git pack-objects --stdout >/dev/null < tmp.$$ && rc=0;
>> +fi;
>> +rm tmp.$$;
>> +test $rc -eq 0;'
>
> Hmm, "eval"?
>
> More importantly, aren't these excessive and unnecessary semicolons
> unsightly?
>
> $ git bisect run sh -c '
> git rev-list --objects BISECT_HEAD >tmp.$$ &&
> git pack-objects --stdout >/dev/null <tmp.$$
> rc=$?
> rm -f tmp.$$
> test $rc = 0'
>
>> +In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
>> +has at least one parent whose reachable graph is fully traversable in the sense
>> +required by 'git pack objects'.
>
> Also "everything reachable from BISECT_HEAD" feels unnecessarily
> wasteful. By the time you invoke "bisect run", you already know one good
> commit, everything reachable from which are known to be good.
>
How about?
git bisect run sh -c '
GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git pack-objects --stdout >/dev/null <tmp.$$
rc=$?
rm -f tmp.$$
test $rc = 0'
^ permalink raw reply
* Re: [PATCH 0/2] Clarify semantics of git attribute macros
From: Philip Oakley @ 2011-08-03 21:34 UTC (permalink / raw)
To: Michael Haggerty, git; +Cc: gitster, peff, Michael Haggerty
In-Reply-To: <1312378890-31703-1-git-send-email-mhagger@alum.mit.edu>
From: "Michael Haggerty"
> Make it clearer that attribute macros do not only affect other
> attributes, but are attributes themselves.
I felt that this summary was the better wording. It is simple and direct.
i.e. "Note: Attribute macros not only affect attributes, but are attributes
themselves."
Philip Oakley
Scotland
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Jens Lehmann @ 2011-08-03 21:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: henri GEIST, Heiko Voigt, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <7vaabqb7vf.fsf@alter.siamese.dyndns.org>
Am 03.08.2011 21:41, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> 1) To use me, you need another submodule "foo"
>>
>> This is very helpful when you want to add the Gimp submodule and it
>> can tell you you'll need the libpng submodule too in your superproject
>> (but I'd vote to use the submodule name here, not the path as that
>> should be the superproject's decision).
>
> That is something you can add to .gitmodules in the superproject, no?
> E.g.
>
> [submodule "Gimp"]
> url = http://some/where/
> path = gimp/
> depends = version 1.2.3 of "Glib"
>
> [submodule "Glib"]
> url = http://some/where/else/
> path = libs/glib
The "depends" information is not very useful inside the superproject,
because when you already know that there you can simply commit version
1.2.3 of Glib together with Gimp instead of adding that information.
That's what gitlinks are for, no?
But when you fetch a new version of Gimp into your submodule, it would be
really nice if the superproject could be notified that the Gimp developers
updated to 1.2.4 of Glib and inform you that an update of Glib might be
appropriate. That could avoid having you to dig through compiler errors to
find out that the new foobar() function from Glib 1.2.4 is needed (and if
you need to pull in a bugfix in Glib, you might notice that *a lot* later
when you forget to do that).
>> In addition to that, it can (but mustn't) specify any of the following:
>
> I am guessing you meant "does not have to", instead of mustn't, here...
Sure, thanks for deciphering that.
>> a) Of this submodule "foo" I need at least that version because I won't
>> compile/work with older versions of that. (this can be tightened to
>> "exactly that version" to give henri the behavior he wants, but that
>> should be policy, not mandatory)
>
> The "loose collection of projects" approach like that has its uses, and it
> is called "repo". Why re-invent it? The behaviour Henri wants to specify
> the exact version is how git submodules work already, so I do not see
> there is anything to be done here.
Let me make this clear: this is not about changing how submodules are
committed in a superproject. It is not about having a loose collection of
projects, they stay tied together in a defined state by the superproject.
Henri wanted it a bit upside down: any submodule could request a certain
version of another submodule somewhere else in the repo. And he wanted to
use gitlinks from one submodule to another for that, which I - hopefully -
convinced him was no good idea.
But I understand his need to have some kind of "version hint" from one
submodule to another. Just that he wants to take the hint very serious,
while I see it as means to communicate from the submodule maintainer to
the superproject developers that another submodule might have to be
updated too when they do that to his.
>> b) And if you don't know where to get it, use this url
>
> Again that is the job of .gitmodules in the superproject.
Yes. But this idea is about how the url could get into the .gitmodules of
the superproject in the first place. That can make it easier for the
superproject's developer to import a submodule into his repo and much more
important: it makes it possible to pull in submodule dependencies
automatically e.g. when running "git submodule add --resolve-dependencies
Gimp".
>> That is all stuff the submodule knows better than the superproject.
>
> Not necessarily. The version A0 of submodule A may depend on submodule B
> and may also know it must have at least version B0 of that submodule, but
> the superproject would know other constraints, e.g. the superproject
> itself also calls into submodule B and wants a newer version B1 of it.
Right. That's what I tried to explain to Henri, the superproject ties it all
together. But I also like his idea to add a way to communicate information
from the submodule to the superproject, and give the superproject a choice
if it wants to use it.
^ permalink raw reply
* Re: Cleaning up history with git rebase
From: pbegeland @ 2011-08-03 20:58 UTC (permalink / raw)
To: Michael Witten; +Cc: Ricky Egeland, git
In-Reply-To: <1b66c8efe0214915be2c52a5aacd22de-mfwitten@gmail.com>
Dear Michael,
I tried to run the script in my repo. However, seems like the 'git
merge $other_parents' process fails. In the script output I see some
lines saying that files were not able to be merged, ie:
warning: Cannot merge binary files:
scienceportal/images/tabs/tabs-gray.png (HEAD vs.
84f6fc283861aa7c5798f58769789dd0b91a5e9d)
warning: Cannot merge binary files: scienceportal/images/waiting.gif
(HEAD vs. e033cbbf1e9d24b66cb55a04701c059dc945c1c3)
Do you have some suggestion?
Thanks,
Patricia
On Mon, 01 Aug 2011 01:07:33 -0000, Michael Witten <mfwitten@gmail.com>
wrote:
> Michael Witten wrote:
>
>> On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:
>>
>>> On Jul 31, 2011, at 6:33 PM, Michael Witten wrote:
>>>
>>>> On Sun, Jul 31, 2011 at 20:21, Michael Witten <mfwitten@gmail.com>
>>>> wrote:
>>>>> Why are there conflicts anyway?
>>>>
>>>> Oh...
>>>>
>>>> I guess there were conflicts when the merge commit was made in
>>>> the original repository, and these conflicts were resolved by
>>>> the merge commit itself. Hence, when rebase tries to split up
>>>> a merge by dealing with just the non-merge parents, you end up
>>>> having to deal with the conflict again.
>>>
>>> Yes, I thought it was something like this going on, too. In the
>>> pre-rebase history, when there is a commit with "Conflict:" and
>>> listing file which is in the sub-repository history, this is a
>>> point where rebase stops with a conflict.
>>>
>>>> Shouldn't rebase take this into account?
>>>
>>> Not sure. Seems that it does not, it makes me resolve the conflict
>>> =
>>> again.
>>
>> I think git rebase should take this into account is what I'm saying.
>>
>> The following implements what I think `git rebase' should be doing;
>> run it instead of `git rebase' in your repo:
>>
>> git branch saved
>> git rev-list HEAD --reverse --first-parent --parents |
>> {
>> read root
>> git reset --hard $root
>> rebase_head=$root
>>
>> while read commit first_parent other_parents; do
>>
>> if [ -z "$other_parents" ]; then
>>
>> git cherry-pick $commit
>> rebase_head=$commit
>>
>> else
>>
>> for parent in $other_parents; do
>>
>> if ! git cherry-pick $parent; then
>>
>> git reset --hard $rebase_head
>> git merge $other_parents
>> git rm -rf .
>> git checkout -- $commit
>> git commit -aC $commit
>> break
>>
>> fi
>>
>> done
>>
>> rebase_head=$(git rev-parse HEAD)
>>
>> fi
>>
>> done
>> }
>
> Woops!
>
> This line:
>
> git checkout -- $commit
>
> should be:
>
> git checkout $commit -- .
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 21:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Heiko Voigt, Jens Lehmann, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <7v8vractdw.fsf@alter.siamese.dyndns.org>
Le mercredi 03 août 2011 à 10:11 -0700, Junio C Hamano a écrit :
> henri GEIST <henri.geist@flying-robots.com> writes:
>
> > I plan to use a config file containing lines like
> >
> > "path_to_poited_repo SHA1_of_intended_commit URL_of_origin"
> >
> > the URL part will not be required.
> >
> > this file will be a list of pointer to other project.
>
> I wasn't paying attention to this thread, but I have to ask "why" here.
>
> The first two are what gitlink was designed to do in the superproject that
> ties multiple submodules together, and the last one is also supplied by
> the .gitmodules in that superproject.
Yes my only problem is that it is forbidden to put a submodule outside
of the repository.
That is way I had done a patch witch enable me to do so and I use it
flawlessly every day. with total satisfaction.
> This seems to be adding the same information in a redundant way by saying
> "this version A0 of submodule A wants version B0 of submodule B and
> version C0 of submodule C" when the supermodule can say "the consistent
> view I record is to have version A0, B0 and C0 of submodules A, B and C,
> respectively".
>
Exact but my goal is to get ride of the superproject.
This is how I will remove the redondency.
Cause creating a projet just to said to other project what they need is
a wast. Each project has to now by itself what it need.
And each user will have his own list of project to work on.
Then they we will create one different superproject for each user.
One user can work on a superproject containing :
gimp, gqview, libpng
One other will work on a superproject containing :
gimp, gphoto, libpng, libusb
The next one will work on a superproject containing :
xsane, libusb
They can absolutely not share there superproject only the normal
projects.
And if the dependency are defined in superproject, and not in the
projects themselves. Users can not share their dependency constructs.
I have no intend to have "sub"modules but to have generic modules with
no hierarchies only dependence relations. Which could even be crossed.
(Module A require module B and module B require module A.)
Even if in this particular case I do not see the point to make two
distinct modules.
> I also suspect that allowing each submodule to know and demand specific
> versions of other submodules will lead to inconsistencies. Which version
> of submodule C would you demand to have when submodule A wants version C0
> and submodule B wants version C1 of it?
>
That is already the case with normal submodules.
And of corse if you have a project which recursively depend of to
version of the same library, you need to update it, and it has nothing
to do with git. Git will just make it obvious.
The reason we decide to make a parallel file ".gitdependencies",
containing something really similar to the content of ".gitmodules"
is that in .gitdependencies we will put references outside of repository
and in ".gitmodules" the references inside git repository as actual.
This separation will be done because Jens Lehmann show us
that .gitmodules are lot more that what I expected from those reference
and do not think that the others abilities of submodules should apply to
external modules.
Henri
^ permalink raw reply
* Re: [PATCH v15 7/7] bisect: add documentation for --no-checkout option.
From: Junio C Hamano @ 2011-08-03 20:59 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, gitster, j6t, jnareb
In-Reply-To: <1312383811-7130-8-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> +This option is useful in circumstances in which checkout is either not
> +possible (because the repository is damaged) or is otherwise not required.
I do not think "because the repository is damaged" is a particularly good
example to single out here. For one thing, you may not be able to bisect
the history in a damaged repository due to unreadable commits. There are
other valid and more plausible reasons that the users do not want to
update the working tree while bisecting, e.g. they have local changes,
they do not want to rebuild everything after bisection is done, etc.
Also the above description muddies what is prerequisite and what is user's
wish.
- "is otherwise not required" is the prerequisite: "if and only if the
test you would perform during bisection does not need a checkout of the
version being tested, you can use this option";
- Even if the user wishes to use this option for various reasons (e.g. so
that the next "make" wouldn't have to rebuild everything unnecessarily;
or the repository has corrupt blobs and checkout of some versions may
fail), if the test _needs_ a checkout, it is not an option to use this
feature.
So I would suggest toning it down perhaps like this:
This option may be useful when the test you would perform in each step
does not require a checked out tree.
> +$ git bisect run eval '
> +rc=1;
> +if git rev-list --objects BISECT_HEAD >tmp.$$; then
> + git pack-objects --stdout >/dev/null < tmp.$$ && rc=0;
> +fi;
> +rm tmp.$$;
> +test $rc -eq 0;'
Hmm, "eval"?
More importantly, aren't these excessive and unnecessary semicolons
unsightly?
$ git bisect run sh -c '
git rev-list --objects BISECT_HEAD >tmp.$$ &&
git pack-objects --stdout >/dev/null <tmp.$$
rc=$?
rm -f tmp.$$
test $rc = 0'
> +In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
> +has at least one parent whose reachable graph is fully traversable in the sense
> +required by 'git pack objects'.
Also "everything reachable from BISECT_HEAD" feels unnecessarily
wasteful. By the time you invoke "bisect run", you already know one good
commit, everything reachable from which are known to be good.
^ permalink raw reply
* Re: git clone does not checkout active branch
From: Jeff King @ 2011-08-03 20:04 UTC (permalink / raw)
To: Udo; +Cc: Junio C Hamano, git
In-Reply-To: <loom.20110803T185528-8@post.gmane.org>
On Wed, Aug 03, 2011 at 04:56:43PM +0000, Udo wrote:
> I have a remote bare repository with two branches 'master' and 'testing', where
> HEAD refers to 'testing'. When cloning this repository git checks out 'master',
> if 'master' and 'testing' are on the same revision (i.e. HEAD == testing ==
> master). Only if 'testing' is one (or more) commit(s) behind or ahead, git clone
> checks out the 'testing' branch on the local side. I tried this with git 1.7.5
> on Mac OS X (10.6.8).
Yes, this is a known issue.
The git protocol just sends the list of refs and the objects they point
to. So the local clone is forced to guess which ref HEAD is pointing to.
E.g., with something like:
28f599b... HEAD
1234abc... refs/heads/master
28f599b... refs/heads/testing
it can see that HEAD is probably "testing". But if it sees:
28f599b... HEAD
28f599b... refs/heads/master
28f599b... refs/heads/testing
then it has to pick one arbitrarily. Our current heuristic is to prefer
"master" over others, and otherwise pick first alphabetically. So it's
at least deterministic, but as you noticed, it's not always right.
The real solution to this would be to extend the git protocol to convey
symbolic ref information (and then wait for both client and server to be
upgraded). Some patches have been floated in the past, but nothing came
of it[1]. Maybe it's time to resurrect them.
As a workaround, you can use "git clone -b testing ..." if you know
ahead of time that "testing" is what you want.
-Peff
[1] See:
http://thread.gmane.org/gmane.comp.version-control.git/102039
and also:
http://article.gmane.org/gmane.comp.version-control.git/113567
^ permalink raw reply
* Re: [PATCH 1/2] gitattributes: Clarify discussion of attribute macros
From: Jeff King @ 2011-08-03 19:46 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster
In-Reply-To: <1312378890-31703-2-git-send-email-mhagger@alum.mit.edu>
On Wed, Aug 03, 2011 at 03:41:29PM +0200, Michael Haggerty wrote:
> -which is equivalent to the above. Note that the attribute macros can only
> -be "Set" (see the above example that sets "binary" macro as if it were an
> -ordinary attribute --- setting it in turn unsets "text" and "diff").
> +Setting the "binary" attribute also unsets the "text" and "diff"
> +attributes as above. Note that attribute macros can only be "Set",
> +though setting one might have the effect of setting or unsetting other
> +attributes or even returning other attributes to the "Unspecified"
> +state.
This is slightly confusing. You can "unset" an attribute macro, and it
will be reported as "unset". Which seems to contradict what is written
above (although the error comes from the previous text). I think there
are two possibilities for what a user might expect unsetting a macro to
do for the sub-attributes:
1. Leave them unspecified.
2. Negate them (i.e., "-binary" means "text diff".
and we do (1).
I don't know if that was intentional, or if the behavior is simply
accidental and the original code was simply never meant to have
"-binary" called at all.
-Peff
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Junio C Hamano @ 2011-08-03 19:41 UTC (permalink / raw)
To: Jens Lehmann
Cc: henri GEIST, Heiko Voigt, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <4E399C62.30604@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> 1) To use me, you need another submodule "foo"
>
> This is very helpful when you want to add the Gimp submodule and it
> can tell you you'll need the libpng submodule too in your superproject
> (but I'd vote to use the submodule name here, not the path as that
> should be the superproject's decision).
That is something you can add to .gitmodules in the superproject, no?
E.g.
[submodule "Gimp"]
url = http://some/where/
path = gimp/
depends = version 1.2.3 of "Glib"
[submodule "Glib"]
url = http://some/where/else/
path = libs/glib
> In addition to that, it can (but mustn't) specify any of the following:
I am guessing you meant "does not have to", instead of mustn't, here...
> a) Of this submodule "foo" I need at least that version because I won't
> compile/work with older versions of that. (this can be tightened to
> "exactly that version" to give henri the behavior he wants, but that
> should be policy, not mandatory)
The "loose collection of projects" approach like that has its uses, and it
is called "repo". Why re-invent it? The behaviour Henri wants to specify
the exact version is how git submodules work already, so I do not see
there is anything to be done here.
> b) And if you don't know where to get it, use this url
Again that is the job of .gitmodules in the superproject.
> That is all stuff the submodule knows better than the superproject.
Not necessarily. The version A0 of submodule A may depend on submodule B
and may also know it must have at least version B0 of that submodule, but
the superproject would know other constraints, e.g. the superproject
itself also calls into submodule B and wants a newer version B1 of it.
^ permalink raw reply
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 19:41 UTC (permalink / raw)
To: Jon Seymour; +Cc: Christian Couder, git, gitster, j6t, jnareb
In-Reply-To: <CAH3Anro1Hs5VBT9901PoDdhGjtzTEZHWd9hgHvjfB_ivSErHMw@mail.gmail.com>
On Wednesday 03 August 2011 17:13:13 Jon Seymour wrote:
> On Thu, Aug 4, 2011 at 12:09 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
> > On Wed, Aug 3, 2011 at 3:24 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> >> Mmmm.
> >>
> >> Actually, there is a neater way to do this.
> >>
> >> I'll such use the existence of BISECT_HEAD to inform the
> >> implementation of bisect_mode().
> >>
> >> This avoids the need for a separate .git/BISECT_MODE file.
> >
> > Yeah, but then you have to be careful of the fact that BISECT_HEAD
> > might have not been properly deleted or might have been created by the
> > user for other purposes.
>
> I have removed $GIT_DIR/BISECT_MODE in v15.
>
> If BISECT_HEAD was being used for other purposes, it is going to get
> deleted anyway, irrespective of whether we have a separate BISECT_MODE
> file, so I am not sure we need to consider that when deciding when we
> need a separate BISECT_MODE file.
Yeah, I was probably worrying too much.
> FWIW: bisect_mode() was only going to get called from one place so I
> just inlined the implementation in that place. (on the call to
> bisect--helper).
Ok.
Thanks,
Christian.
^ permalink raw reply
* Re: Strange O(N^3) behavior in "git filter-branch"
From: Jeff King @ 2011-08-03 19:37 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano, Drew Northup, Jakub Narebski
In-Reply-To: <4E394E33.4060107@alum.mit.edu>
On Wed, Aug 03, 2011 at 03:33:39PM +0200, Michael Haggerty wrote:
> On 07/15/2011 11:19 AM, Michael Haggerty wrote:
> > On 07/14/2011 11:24 AM, Michael Haggerty wrote:
> >> On 07/14/2011 09:16 AM, Michael Haggerty wrote:
> >>> I have noticed that "git filter-branch" gets pathologically slow when it
> >>> operates on a repository that has many references in a complicated
> >>> directory hierarchy. The time seems to go like O(N^3), where N is the
> >>> number of references being rewritten.
> > [...]
> > A many possible improvements come to mind, in increasing order of
> > intrusiveness and generality:
> > [...]
> > 5. Organize the loose refs cache in memory as a tree, and only populate
> > the parts of it that are accessed. This should also speed up iteration
> > through a subtree by avoiding a linear search through all loose references.
>
> FYI: I am working on (5), namely storing a linked list of loose refs for
> each directory and only populating those directories that are accessed.
> The directories themselves will be held in a tree/trie (AFAICT the
> distinction is primarily whether each node holds its whole key or only
> the part of the key relative to its parent, which is an implementation
> detail). As a bonus, the caches for submodules will be handled
> correctly (they are currently never used).
>
> It might be another week or so before I have patches ready.
Great. That is exactly the solution I was going to pursue, as well, but
I didn't actually start on it yet. I look forward to seeing your
patches.
-Peff
^ permalink raw reply
* Re: [PATCH v15 5/7] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 19:33 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, j6t, jnareb
In-Reply-To: <CAH3Anrrt-FPqWmDhv0ucQfGKmgVbGLFBE5Pf8ma1LWroydNWLQ@mail.gmail.com>
On Wednesday 03 August 2011 17:32:09 Jon Seymour wrote:
> On Thu, Aug 4, 2011 at 1:03 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> rm -f "$GIT_DIR/head-name" &&
>
> > -
> > - rm -f "$GIT_DIR/BISECT_START"
> > + rm -f "$GIT_DIR/BISECT_START" &&
> > + git update-ref -d BISECT_HEAD
> > }
>
> I'll reverse the order of the last two statements and restore the blank
> line...
Great!
It would be nice too if the "git update-ref" call that creates the ref in the
first place was after the creation of the $GIT_DIR/BISECT_START file.
This way we start by creating the $GIT_DIR/BISECT_START file and we finish by
deleting it.
That is change this:
...
+ test "$mode" != "--no-checkout" ||
+ git update-ref --no-deref BISECT_HEAD "$start_head" &&
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
into something like this:
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
+ {
+ test "$mode" != "--no-checkout" ||
+ git update-ref --no-deref BISECT_HEAD "$start_head"
+ } &&
...
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH v2] commit: allow partial commits with relative paths
From: Clemens Buchacher @ 2011-08-03 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git, Reuben Thomas
In-Reply-To: <7vbow7ebzw.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Tue, Aug 02, 2011 at 02:31:47PM -0700, Junio C Hamano wrote:
>
> Perhaps "common_prefix()"?
Yes, I was thinking the same thing actually.
> Don't you also want to consolidate dir.c:common_prefix() with this?
I wasn't aware of it. I'm really swamped right now, but I'll take a
look at it soon.
Clemens
^ permalink raw reply
* Re: [PATCH] add technical documentation about ref iteration
From: Junio C Hamano @ 2011-08-03 19:10 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20110803180319.GA13057@sandbox-rc>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
> Documentation/technical/api-ref-iteration.txt | 73 +++++++++++++++++++++++++
> 1 files changed, 73 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/api-ref-iteration.txt
> +Submodules
> +----------
> +
> +If you want to iterate the refs of a submodule you first need to call
> +
> + add_submodule_odb(submodule)
> +
> +and test whether that succeeds.
Hmm, this should probably be explained a bit deeper or not at all. For
example, what is "submodule" here? A path to the submodule directory? The
name of submodule? What is the unwanted consequence of adding this extra
object database into your process (e.g. you can no longer tell if an
object exists in the superproject, as it may now come from the submodule's
object database)? Can you get rid of it? How does this function signal
failures? What is the symptom if you forget this call and used the
iteration in the submodule (e.g. "we do not see any ref"; "we see only
some ref but not all"; "the call crashes the process")?
> +
> +(Heiko Voigt)
Please drop this line for two reasons.
Initially I added these parenthesized names at the end for placeholder
pages to name people who are responsible for the _code_ the document
describes, so that the ones who help documentation would know who to nag
to get the necessary information. With your description, people who are
interested in documenting this API more would know that for_each_ref() and
friends are the topic and can find out whom to harrass.
Besides, with only two commits to refs.c, I doubt you would want to be the
primary source of information for other people to bug in order to enhance
the API description in this file.
Thanks.
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Jens Lehmann @ 2011-08-03 19:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: henri GEIST, Heiko Voigt, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <7v8vractdw.fsf@alter.siamese.dyndns.org>
Am 03.08.2011 19:11, schrieb Junio C Hamano:
> henri GEIST <henri.geist@flying-robots.com> writes:
>
>> I plan to use a config file containing lines like
>>
>> "path_to_poited_repo SHA1_of_intended_commit URL_of_origin"
>>
>> the URL part will not be required.
>>
>> this file will be a list of pointer to other project.
>
> I wasn't paying attention to this thread, but I have to ask "why" here.
>
> The first two are what gitlink was designed to do in the superproject that
> ties multiple submodules together, and the last one is also supplied by
> the .gitmodules in that superproject. This seems to be adding the same
> information in a redundant way by saying "this version A0 of submodule A
> wants version B0 of submodule B and version C0 of submodule C" when the
> supermodule can say "the consistent view I record is to have version A0,
> B0 and C0 of submodules A, B and C, respectively".
During the discussion this evolved from a simple "I need that submodule
with exactly this version" to something I believe is more generic and
very useful for others. As I see it now a submodule should be able to say:
1) To use me, you need another submodule "foo"
This is very helpful when you want to add the Gimp submodule and it
can tell you you'll need the libpng submodule too in your superproject
(but I'd vote to use the submodule name here, not the path as that
should be the superproject's decision).
In addition to that, it can (but mustn't) specify any of the following:
a) Of this submodule "foo" I need at least that version because I won't
compile/work with older versions of that. (this can be tightened to
"exactly that version" to give henri the behavior he wants, but that
should be policy, not mandatory)
Gimp could say it needs at least libpng 012345 because in that version
the function foobar() was added it now depends on. Normally this won't
be updated very often, but if people like henri use that to say "I'll
only promise to work well with that exact version, as that went through
extensive QA" they might change that on virtually every commit.
b) And if you don't know where to get it, use this url
That can give the superproject a hint where it can clone that
repository from. That could be helpful for distributions to sort out
the dependencies of the packages they pull in.
That is all stuff the submodule knows better than the superproject. And
that information can be used to *inform* the user about the submodule's
needs, maybe using "git status --submodule-dependencies" will print:
# submodule "Gimp" requests a libpng 567890 or newer
# submodule "foo" has missing dependency "bar"
But the user can choose to ignore that (because he knows he has the png
support disabled and he doesn't need the fancy help files from bar).
And maybe "git submodule add" learns an option to automatically add all
the other submodules the new one depends on too (for that we would need
the url).
But the superproject is still the place to say: I know these versions of
all submodules work together, so I commit their gitlinks here. But this
scheme enables submodules to give hints to help the superproject's user.
> I also suspect that allowing each submodule to know and demand specific
> versions of other submodules will lead to inconsistencies. Which version
> of submodule C would you demand to have when submodule A wants version C0
> and submodule B wants version C1 of it?
Right, in the discussion so far it seemed like henri seems to be the only
user who is wanting an exact match, and he says he needs to see these
inconsistencies. But I think he can modify the "version xxx or newer" to
his needs without imposing these inconsistencies on users (like me) who
don't want to see them.
^ permalink raw reply
* Re: Why do some commits not appear in "git log"?
From: Junio C Hamano @ 2011-08-03 18:57 UTC (permalink / raw)
To: Dov Grobgeld; +Cc: Michael Witten, git
In-Reply-To: <CA++fsGGhzVkXTPLui+DfTFcjve7w80Kud4RxC0p=5AenOcBSDw@mail.gmail.com>
Dov Grobgeld <dov.grobgeld@gmail.com> writes:
> --full-history indeed made the missing commits show up! So why was the
> commit pruned? It contains some substantial source changes...
I suspect that these "substantial changes" did not make any contribution
to the end result. Read
http://thread.gmane.org/gmane.comp.version-control.git/89400/focus=90659
These days, the --post-simplify option implemented in that discussion
thread is called --simplify-merges or something, I think.
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jonathan Nieder @ 2011-08-03 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Seymour, git, chriscool, j6t, jnareb
In-Reply-To: <7voc07ct9z.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Just a minor worry but I would not be surprised if somebody's "test"
> implementation barfs upon:
>
> test "--no-checkout" = "--no-checkout"
>
> mistaking the string with a dash at the beginning as an option unknown to
> it. That is why we often have "z$variable" in our comparison, like so:
>
> if test "z$BISECT_MODE" = "z--no-checkout"
Hmm.
$ git grep -e 'test "\$' | wc -l
712
$ git grep -e 'test ".\$' | wc -l
183
We are very inconsistent about such usage, generally, and of course
POSIX is very clear about the 'z' not being needed in a three-argument
"test" used for string comparison. Is there any platform that is
usable for git (e.g., that implements "$( ... )") and has that
problem?
^ 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