* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-08-02 11:41 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20110801234323.GB31614@book.hvoigt.net>
On Tue, 2 Aug 2011, Heiko Voigt wrote:
> On Mon, Jul 25, 2011 at 10:33:01PM +0200, Jakub Narebski wrote:
> > === 17. Which of the following features would you like to see implemented in git? ===
> > (multiple choice)
[...]
> > NOTES:
> > ^^^^^^
> > What features should be mentioned besides those above? What criteria
> > should we have for including features in this list?
>
> How about adding:
>
> + improved submodule support
>
> ?
Added, thanks.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v11->v13] bisect: patch bisect-no-checkout in pu to
From: Jon Seymour @ 2011-08-02 11:41 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, Jon Seymour
This patch can be applied on top of the version of bisect-no-checkout currently
in pu to:
* change the internal control file from BISECT_NO_CHECKOUT to BISECT_MODE
* change bisect--helper option from --no-checkout to --bisect-mode
* change the reference used to track bisection cursor from HEAD to BISECT_HEAD
* update documentation and tests to match.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Documentation/git-bisect.txt | 8 ++++----
bisect.c | 2 +-
builtin/bisect--helper.c | 8 +++++---
git-bisect.sh | 41 ++++++++++++++++++++++++-----------------
t/t6030-bisect-porcelain.sh | 30 +++++++++++++++---------------
5 files changed, 49 insertions(+), 40 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 2014894..a9b217b 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -267,9 +267,9 @@ OPTIONS
-------
--no-checkout::
+
-This option is used to specify that 'git bisect' should not modify the working
-tree or index on each iteration of the bisection process but should
-update HEAD instead.
+This option is used to specify that 'git bisect' should not checkout the
+new working tree at each iteration of the bisection process but should
+instead update BISECT_HEAD.
+
This option is useful in circumstances in which checkout is either not
possible (because of a damaged respository) or is otherwise not required.
@@ -360,7 +360,7 @@ on a single line.
$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
$ git bisect run eval '
rc=1;
-if git rev-list --objects HEAD >tmp.$$; then
+if git rev-list --objects BISECT_HEAD >tmp.$$; then
git pack-objects --stdout >/dev/null < tmp.$$ && rc=0;
fi;
rm tmp.$$;
diff --git a/bisect.c b/bisect.c
index 0427117..46874be 100644
--- a/bisect.c
+++ b/bisect.c
@@ -24,7 +24,7 @@ struct argv_array {
static const char *argv_checkout[] = {"checkout", "-q", NULL, "--", NULL};
static const char *argv_show_branch[] = {"show-branch", NULL, NULL};
-static const char *argv_update_ref[] = {"update-ref", "--no-deref", "HEAD", NULL, NULL};
+static const char *argv_update_ref[] = {"update-ref", "--no-deref", "BISECT_HEAD", NULL, NULL};
/* bits #0-15 in revision.h */
diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index d96a193..5cfac13 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -4,7 +4,7 @@
#include "bisect.h"
static const char * const git_bisect_helper_usage[] = {
- "git bisect--helper --next-all [--no-checkout]",
+ "git bisect--helper --next-all [--bisect-mode=checkout|update-ref]",
NULL
};
@@ -12,11 +12,12 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
{
int next_all = 0;
int no_checkout = 0;
+ char *bisect_mode=NULL;
struct option options[] = {
OPT_BOOLEAN(0, "next-all", &next_all,
"perform 'git bisect next'"),
- OPT_BOOLEAN(0, "no-checkout", &no_checkout,
- "update HEAD instead of checking out the current commit"),
+ OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
+ "the bisection mode either checkout or update-ref. defaults to checkout."),
OPT_END()
};
@@ -26,6 +27,7 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
if (!next_all)
usage_with_options(git_bisect_helper_usage, options);
+ no_checkout = bisect_mode && !strcmp(bisect_mode, "update-ref");
/* next-all */
return bisect_next_all(prefix, no_checkout);
}
diff --git a/git-bisect.sh b/git-bisect.sh
index 81d2344..c9aabc0 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -34,7 +34,16 @@ require_work_tree
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
-BISECT_NO_CHECKOUT=$(test -f "$GIT_DIR/BISECT_NO_CHECKOUT" && cat "$GIT_DIR/BISECT_NO_CHECKOUT")
+BISECT_MODE=$(test -f "$GIT_DIR/BISECT_MODE" && cat "$GIT_DIR/BISECT_MODE")
+
+bisect_head()
+{
+ if test "$BISECT_MODE" = "update-ref"; then
+ echo BISECT_HEAD;
+ else
+ echo HEAD
+ fi
+}
bisect_autostart() {
test -s "$GIT_DIR/BISECT_START" || {
@@ -71,7 +80,7 @@ bisect_start() {
orig_args=$(git rev-parse --sq-quote "$@")
bad_seen=0
eval=''
- BISECT_NO_CHECKOUT=
+ BISECT_MODE=checkout
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
@@ -80,7 +89,7 @@ bisect_start() {
break
;;
--no-checkout)
- BISECT_NO_CHECKOUT=$arg;
+ BISECT_MODE=update-ref;
shift ;;
--*)
die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
@@ -115,10 +124,10 @@ bisect_start() {
then
# Reset to the rev from where we started.
start_head=$(cat "$GIT_DIR/BISECT_START")
- if test -z "$BISECT_NO_CHECKOUT"; then
- git checkout "$start_head" --
+ if test "$BISECT_MODE" = "update-ref"; then
+ git update-ref --no-deref $(bisect_head) "$start_head"
else
- git update-ref --no-deref HEAD "$start_head"
+ git checkout "$start_head" --
fi
else
# Get rev from where we start.
@@ -156,10 +165,8 @@ bisect_start() {
# Write new start state.
#
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
- git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" && {
- test -z "$BISECT_NO_CHECKOUT" ||
- echo "$BISECT_NO_CHECKOUT" > "$GIT_DIR/BISECT_NO_CHECKOUT"
- } &&
+ git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES"
+ echo "$BISECT_MODE" > "$GIT_DIR/BISECT_MODE" &&
eval "$eval true" &&
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
#
@@ -221,8 +228,8 @@ bisect_state() {
0,*)
die "$(gettext "Please call 'bisect_state' with at least one argument.")" ;;
1,bad|1,good|1,skip)
- rev=$(git rev-parse --verify HEAD) ||
- die "$(gettext "Bad rev input: HEAD")"
+ rev=$(git rev-parse --verify $(bisect_head)) ||
+ die "$(gettext "Bad rev input: $(bisect_head)")"
bisect_write "$state" "$rev"
check_expected_revs "$rev" ;;
2,bad|*,good|*,skip)
@@ -306,7 +313,7 @@ bisect_next() {
bisect_next_check good
# Perform all bisection computation, display and checkout
- git bisect--helper --next-all ${BISECT_NO_CHECKOUT}
+ git bisect--helper --next-all ${BISECT_MODE:+--bisect-mode=}${BISECT_MODE}
res=$?
# Check if we should exit because bisection is finished
@@ -355,15 +362,15 @@ bisect_reset() {
*)
usage ;;
esac
- if test -z "$BISECT_NO_CHECKOUT"; then
+ if test "$BISECT_MODE" = "update-ref"; then
+ git symbolic-ref $(bisect_head) $(git rev-parse --symbolic-full-name "${branch}")
+ else
if git checkout "$branch" --; then
bisect_clean_state
else
die "$(eval_gettext "Could not check out original HEAD '\$branch'.
Try 'git bisect reset <commit>'.")"
fi
- else
- git symbolic-ref HEAD $(git rev-parse --symbolic-full-name "${branch}")
fi
}
@@ -379,7 +386,7 @@ bisect_clean_state() {
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
- rm -f "$GIT_DIR/BISECT_NO_CHECKOUT" &&
+ rm -f "$GIT_DIR/BISECT_MODE" &&
# Cleanup head-name if it got left by an old version of git-bisect
rm -f "$GIT_DIR/head-name" &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index a1e0ddc..ef422a1 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -641,24 +641,24 @@ test_expect_success 'bisect fails if tree is broken on trial commit' '
test_expect_success 'bisect: --no-checkout - start commit bad' '
git bisect reset &&
git bisect start BROKEN_HASH7 BROKEN_HASH4 --no-checkout &&
- check_same BROKEN_HASH6 HEAD &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - trial commit bad' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
- check_same BROKEN_HASH6 HEAD &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
git bisect reset
'
test_expect_success 'bisect: --no-checkout - target before breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
- check_same BROKEN_HASH6 HEAD &&
- git bisect bad HEAD &&
- check_same BROKEN_HASH5 HEAD &&
- git bisect bad HEAD &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
+ check_same BROKEN_HASH5 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
check_same BROKEN_HASH5 bisect/bad &&
git bisect reset
'
@@ -666,10 +666,10 @@ test_expect_success 'bisect: --no-checkout - target before breakage' '
test_expect_success 'bisect: --no-checkout - target in breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
- check_same BROKEN_HASH6 HEAD &&
- git bisect bad HEAD &&
- check_same BROKEN_HASH5 HEAD &&
- git bisect good HEAD &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
+ check_same BROKEN_HASH5 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
check_same BROKEN_HASH6 bisect/bad &&
git bisect reset
'
@@ -677,10 +677,10 @@ test_expect_success 'bisect: --no-checkout - target in breakage' '
test_expect_success 'bisect: --no-checkout - target after breakage' '
git bisect reset &&
git bisect start broken BROKEN_HASH4 --no-checkout &&
- check_same BROKEN_HASH6 HEAD &&
- git bisect good HEAD &&
- check_same BROKEN_HASH8 HEAD &&
- git bisect good HEAD &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
+ check_same BROKEN_HASH8 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
check_same BROKEN_HASH9 bisect/bad &&
git bisect reset
'
@@ -691,7 +691,7 @@ test_expect_success 'bisect: demonstrate identification of damage boundary' "
git bisect start broken master --no-checkout &&
git bisect run eval '
rc=1;
-if git rev-list --objects HEAD >tmp.$$; then
+if git rev-list --objects BISECT_HEAD >tmp.$$; then
git pack-objects --stdout >/dev/null < tmp.$$ && rc=0;
fi;
rm tmp.$$;
--
1.7.6.359.g2d20bc
^ permalink raw reply related
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-02 12:04 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, gitster, j6t, jnareb
In-Reply-To: <1312284545-2426-6-git-send-email-jon.seymour@gmail.com>
On Tue, Aug 2, 2011 at 1:29 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> @@ -34,6 +34,8 @@ require_work_tree
> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
>
> +BISECT_MODE=$(test -f "$GIT_DIR/BISECT_MODE" && cat "$GIT_DIR/BISECT_MODE")
Could you put this line just where it is needed, that is in
bisect_next() and bisect_reset()?
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH v13 4/8] bisect: introduce support for --no-checkout option.
From: Christian Couder @ 2011-08-02 12:16 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, gitster, j6t, jnareb
In-Reply-To: <1312284545-2426-5-git-send-email-jon.seymour@gmail.com>
On Tue, Aug 2, 2011 at 1:29 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> If --no-checkout is specified, then the bisection process uses:
Yeah, but in this patch you are changing "git bisect--helper" by
adding the [--bisect-mode=checkout|update-ref] option. So it is
strange that you still talk about a --no-checkout option.
> git update-ref --no-deref HEAD <trial>
>
> at each trial instead of:
>
> git checkout <trial>
[...]
> int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> {
> int next_all = 0;
> + int no_checkout = 0;
> + char *bisect_mode=NULL;
> struct option options[] = {
> OPT_BOOLEAN(0, "next-all", &next_all,
> "perform 'git bisect next'"),
> + OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
> + "the bisection mode either checkout or update-ref. defaults to checkout."),
Nit: I would say : "bisection mode: 'checkout' (default) or 'update-ref'"
Thanks,
Christian.
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-02 12:19 UTC (permalink / raw)
To: Jens Lehmann
Cc: Alexei Sholik, Junio C Hamano, git, Sverre Rabbelier, Heiko Voigt
In-Reply-To: <4E370107.3050002@web.de>
Le lundi 01 août 2011 à 21:39 +0200, Jens Lehmann a écrit :
> Am 30.07.2011 23:55, schrieb henri GEIST:
> > Le samedi 30 juillet 2011 à 16:16 +0200, Jens Lehmann a écrit :
> >> Am 29.07.2011 11:39, schrieb henri GEIST:
> >>> Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :
> >>>> Am 28.07.2011 10:57, schrieb henri GEIST:
> >
> >> That will then be registered in other git repositories too in your model,
> >> which gets rid of the "one file/submodule, one repo" assumption we now have
> >> and will introduce ambiguities which are *really* hard to handle.
> >
> > I am sorry, I am not a native English speaker. This sentence is to
> > complex for me. And google translator is of no help in this case.
>
> Your proposal of letting multiple gitlinks in different repos point to the
> same submodule will break the assumption that each file is only handled by
> a single git repo.
I Agree
This is not an issue for me but I can understand that it could be for
some one else. Even if I do not see why. As it only do it for other git
repository that you already now they could have there own autonomous
live.
> For example when you have a conflict and do a "git
> submodule update --recursive" in the superproject, the SHA1 used for "lib"
> will depend on the alphabetical order of "project1" and "project2".
Exact.
> And normally after running "git submodule update --recursive" you expect all
> submodules of the superproject to be clean.
Not me. and the next "git status" will immediately tell me.
I do not know about you but "git status" is for me a reflex after any
important command.
> But your change breaks this expectation, it will still contain unclean
> submodule entries even though you just told git it should clean them.
> What will a "git submodule sync --recursive" do when "project1" and
> "project2" use different urls in their gitmodules? And so on.
I suspect exactly the same conflict as with "git submodule update
--recursive" or any recursive submodule management.
But again if I deliberately chose this model I know what I am doing.
> Commands won't always behave like you expect them to and sometimes will
> give different results just because different names are used. That's what
> I meant with ambiguities and that's why I don't think gitlinks are the
> right method here.
I am sorry. but I do not understand the relation with names.
> > But I agree the step is really weak before enabling to put any regular
> > file outside of the directory.
> > I do not see any reasonable workflow (to my eyes) for it but' maybe some
> > day someone will came with a justifiable workflow which need it. we will
> > never know.
> >
> > But in this case we need solve some questions :
> > - Will we extend git status signaling untracked files out of the
> > repository ?
>
> I don't think that would work well.
Me to but it is not me to decide.
>
> > - What will do git-clean ? it is already dangerous inside the
> > repository. and it will be worst if it can access outside of it.
>
> Hopefully git clean will learn the --recurse-submodules option in the not
> too distant future, then you will have just the same danger for the files
> inside a submodule.
Then this command will be once again more dangerous.
But it was before and pepole using it already knows then I suspect it is
not worst than before.
> > But they are still confined in an another git repository not
> > disseminated all over the file system.
> > And it never corrupt this pointed repository. just ask it to do by it's
> > own regular git commands.
>
> The only difference here is that a submodule can contain more than one file,
> but you can corrupt those files just as easily as a single file using git
> commands.
Your right.
> > I can do a second patch to prevent git submodule command to make clones
> > outside of the repository.
> > It will requires the user to do those clones manually.
> > In fact this is already what I do.
> > My only use of this is to track dependencies.
>
> But gitlinks are more than simple dependencies, they are followed! "git
> submodule", status, diff and fetch already follow them. push is learning
> that right now. checkout, reset, merge and friends are being taught that
> too (see the enhance_submodule branch in my github repo for the current
> state). So a gitlink is more than just a simple reference, it is followed
> by a lot of commands and the submodule it points to is manipulated by
> those commands. We had a patch for "git archive --recurse-submodules" on
> the list, what will that do when used in "project1"?
I think your right. I will make a parallel way not using gitlinks but
something similar which is not followed!
> > In fact I work in the world of "high integrity programming" then It is
> > just what I need.
> > If there is a bugfix in any library, used by the program it is no more
> > the same program.
> > I need the "SHA1" to correspond to the exact and complete source code
> > involved in my executable.
> >
> > And this way the "SHA1" of the project sign the "SHA1" of the
> > libraries.
>
> I cannot believe you want single commits in your "Gimp" repo for every
> combination of distributions and library versions where someone said
> "this works". This is insane and won't scale at all.
>
That is exactly what I do. but my team is only 9 people.
But we do not make a commit for each possible solution.
It. is only when I work on gimp to improve it that I made a commit which
is update for the ne libpng. but between to commit on the gimp there may
bu 10 update of libpng an I do not do a commit for each of them only the
last stable one.
It is only on the gnome project that I also need tu update my old
version of gqview to work with the libpng used by gimp but as long I do
not work on gnome I do not need to synchronize them.
But I write aircraft autopilot and if I am not at least as strict as
that. The certification department of the FAA and EASA will reject my
code and my boss will fire me.
> What you do is that each distribution tests their combination of programs
> and libraries and says "that works". And that is why the only sane way to
> record this "high integrity programming" test result is in the superproject
> (= distribution) and not in each of the program repositories.
>
> I also see that it would be cool when a program could record "I do work with
> that library version, if you use another you are on your own". But it will
> never say "I only work with *this* specific library version", which is what
> your proposal is trying to do.
No git status only said "modified: ../libpng (new commits)"
For me modified just mean "you are on your own" It do not prevent to
compile, execute or do anything else.
> >> I understood that, but what are you proposing to do to solve all the
> >> problems your approach introduces? You can't just hand wave them away.
> >
> > There is some solutions :
> >
> > - First it is one more **feature** if it does not correspond to your
> > work flow it does not prevent you to work exactly the way you did
> > until now.
> >
> > - Second if you want to use the feature but not want to have the
> > conflict **feature** (for me it is one), just put the independent
> > project with there libs in different directory
> >
> > -+- foo -+- lib1 (in version N)
> > | +- project1
> > |
> > +- bar -+- lib1 (in version M)
> > +- project2
> >
> > - Third if you really need to have project 1 & 2 in the same
> > directory foo, that means they are needed by a third BigProject in
> > the same directory foo depending on project 1 & 2.
> > And then you really need git to declare a conflict.
>
> No you don't. You just need to git to tell you: this is not the version I
> was tested against, repeat the tests to be sure.
>
That is just what it will do.
> >> Cool, that is a real life example resembling what we have a my dayjob. But
> >> a "gimp" and "gqview" project will only have dependencies like "use libpng
> >> of version 1.2.3 or newer (because we need a feature/bugfix introduced
> >> there)" and won't be tied to a special version of that library. This means
> >> they need a dependency like "SHA1 or newer" instead of "exactly this SHA1".
> >
> > It is useful and simpler to work like this but could introduce some
> > bugs.
>
> But that model is awfully successful and is used by all distributions I know,
> so I suspect it is not that dangerous (especially when you do your own QA).
>
Depending of how critical is a bug.
For an image manipulation programme the ratio effort/needed safety is in
the favor of your approche.
But will you be confident if the nuclear power-plant 50 km from you use
this kind of devloppement to contrôle the uranium bars ?
In any case in my workflow it is not about testing and not seeing
obvious bugs. It is about having a development process that permit to
prove there is obviously no bugs. And that model obviously break the
proof process.
> > The "gimp" team has tested it with libpng 1.2.3 and maybe know that it
> > did not work with previous versions but if they do not have any crystal
> > ball they never know if newer versions will not break something.
> > In fact I doubt that the first version of gimp will work with the last
> > version of libpng.
>
> But in the real world it is exactly like that: gimp will work with all libpng
> 1.2.3 and newer, only when libpng is updated to 2.0.0 you have to check that
> again. Of course there will be bugs in some combinations. But the advantage of
> being able to then only fix libpng and have the bug fixed in Gimp without
> having to change it is far greater than the possible problem you are describing
> here.
>
In this case the commit is not about a change in gimp code, but is a
stamp to validate the use of gimp with this new version of libpng is
certified.
But just like in your current use of submodules.
> >>> It is just the same with aptitude on debian.
> >>> Each package know there dependency by themselves, does not contain there
> >>> dependencies, and do not need a bigger superpackage to tell them what
> >>> are there own dependencies.
> >>
> >> And this is a very good point for the "version x.yy-z *or newer*" argument,
> >> they are /never/ tied to the /exact/ x.yy-z version, as that would make the
> >> dependencies pretty much unusable. They use a "newer than x.yy-z" scheme.
> >
> > It is an other feature that the one I need.
> > But it is a good idea.
> >
> > Nothing prevent us to make a patch to add a new test in git status to
> > see if the current SHA1 in the libpng repository has the SHA1 of the
> > gitlink in the gimp in its ancestor.
>
> To make that feature useful for others (e.g. at my dayjob) this would be
> necessary. And we would never want the exact SHA1 match, even though that
> information might be what others (like you) want.
>
Ok I will do it.
> > But if git handle this config file.
> > Update it on a "git add ../libpng && git commit"
>
> I'm not sure an automatic update at "git commit" would be the right thing to
> do, as I think that should only happen after all tests have run successful,
> not at the time you commit it. But anyways, that could be done with a post
> commit hook. Or the test script can do it when it succeeded.
>
I am sorry "make && make test && git add ../libpng && git commit"
> > And control the matching between the project and libraries on
> > "git status".
>
> An extension to "git status" to display the dependencies that aren't met is
> a valid goal. What about starting with a script ("git depends"?) and then see
> what can go into status?
>
> > I can not see the difference with a gitlink.
>
> Then you can just use a config file for that, no? ;-)
>
Off corse, I immediately start to work on it.
Henri GEIST
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-02 12:58 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Alexei Sholik, Junio C Hamano, git,
Sverre Rabbelier
In-Reply-To: <20110801221203.GA31614@book.hvoigt.net>
Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :
> Hi,
>
> On Fri, Jul 29, 2011 at 11:39:37AM +0200, henri GEIST wrote:
> > Let say a concret exemple
> >
> > 3 different teams work on libtiff, libpng, and libjpeg they are totally
> > unrelated.
> >
> > One more team is working on the "gimp". And they need those 3 libs in
> > specific versions not necessarily there heads.
> >
> > One other unrelated team is working on "gqview" and need the same libs
> > in other specifics versions (Why should they know what te gimp team
> > does)
> >
> > Neither "gimp" and "gqview" project will contain directory with those
> > libs inside. They just depend on them.
> >
> > And the last team work on the gnome project which need the "gimp" and
> > "gqview". It will be this team witch have to care about having both
> > "gimp" and "gqview" sharing the same libs version>
> > And has well the gnome project will not contain "gqview" and "gimp" in
> > its own tree.
> > It will also depend on them.
> >
> > It is just the same with aptitude on debian.
> > Each package know there dependency by themselves, does not contain there
> > dependencies, and do not need a bigger superpackage to tell them what
> > are there own dependencies.
>
> As Jens mentioned already in this example you have a
>
> somemodule A needs a version of lib C higher than X
> somemodule B needs a version of lib C higher than Y
>
> relation. Which in the case of submodules is A points to X and B points
> to Y. Lets assume X is contained in Y. Since only the superproject knows
> about both A and B its the only instance that can resolve this conflict
> of dependence on C and can choose Y. In your example aptitude would be
> the superproject containing everything.
>
I do not want to have a superproject. just as with aptitude. Each
package store its own dependencies itself.
I do not want to need a super package who now every dependencies of
every possible packages.
First because it is impractical to maintain an exhaustive list of all
possible packages (including unofficial ones.)
Secondly because I have no need for this and it will require somme more
works.
Third for different people witch use and share there own subset off
unofficial package they needs to cook a specific super package for each
unique case.
> This is actually (simplified) the way submodule merge is implemented. So
> you see if you want both A and B to use the same version of C you need a
> superproject recording this knowledge.
And tha is my problem.
> Adding the ability to point to git repositories outside of the worktree
> does not solve anything but rather creates more problems. Resolving such
> dependencies can not be achieved if only A knows that it needs version X
> and only B knows that it needs version Y.
>
Why not it work perfect for me and for debian as well.
Yes I now for speed purpose they scans all the package header and store
their dependency requirement in a database. but it is only for speed and
it is automatic generated by the info "In the packages them selves". I
do not think they ever edit it by hand to define the dependency in the
DB.
In fact I suppose this by what I seen by using it I never looked in the
apt source code.
Henri GEIST
^ permalink raw reply
* Re: filenames in repo are in CP1251; I have linux and UTF-8
From: Dmitry Potapov @ 2011-08-02 13:02 UTC (permalink / raw)
To: Ilya Basin; +Cc: git
In-Reply-To: <1167098359.20110802115414@gmail.com>
Hi!
On Tue, Aug 2, 2011 at 11:54 AM, Ilya Basin <basinilya@gmail.com> wrote:
>
> Unlike on Cygwin, LANG has no effect for git filenames on Linux. Good
> thing, there's no conversion to unicode, so files aren't lost at
> checkout.
LANG has no effect on open() or other system functions on Linux, so
all filenames are created as they were stored in Git, in your case,
it is CP1251.
AFAIK, it should not be difficult to configure CP1251 on Linux. You
generate the required locale and then start xterm with this locale
and specifying some CP1251 font.
I have never done it before, but the following steps seem to work:
# generate CP1251
sudo localedef -c -i ru_RU -f CP1251 ru_RU.CP1251
# make sure that it was generated
# you should see ru_RU.cp1251 in the output
locale -a | grep ru_RU
# start xterm
LANG=ru_RU.cp1251 xterm -fn '-monotype-courier
new-semilight-r-normal--0-0-0-0-c-0-microsoft-cp1251' &
You can try another font. See the output of xlsfonts:
xlsfonts | grep -i cp1251
>
> Question: is there a way to tell git on Linux to use UTF-8 filenames
> for the working tree, while storing them in CP1251?
The short answer is no. A more detail answer is that there was
a series of patches that should allow filename conversation:
http://article.gmane.org/gmane.comp.version-control.git/119224
but a proper implementation turned out to be very invasive and
no one seems to care about it very deeply, so it was dropped.
See details here:
http://article.gmane.org/gmane.comp.version-control.git/122860
Dmitry
^ permalink raw reply
* Re: Branch dependencies
From: Bert Wesarg @ 2011-08-02 13:06 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis
In-Reply-To: <20110801121946.GA575@fishbowl.rw.madduck.net>
Hi,
On Mon, Aug 1, 2011 at 14:19, martin f krafft <madduck@madduck.net> wrote:
> Dear list,
while I appreciate, that you dig this topic up. I think you are trying
to solve the wrong problem first. My main problem with the TopGit
approach is, that you can't freely change the dependencies of a topic.
This may be not the most common case in distro development. But in my
eyes more problematic than maintaining the meta data.
Please note, that I'm more than aware the the TopGit approach for
handling the meta data is awful and we need a new way here. My
personal impression is, that the git notes is the best we can have.
For my first mentioned problem, I think a new 'system' needs to be
'rebase' based, not merge based like TopGit.
Bert
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-08-02 13:37 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s2CWvzKyBAskVRq6Vte-CyCKwxBCZbSw_mbp=4a6ngCOw@mail.gmail.com>
On Sun, 31 Jul 2011, Felipe Contreras wrote:
> 2011/7/25 Jakub Narebski <jnareb@gmail.com>:
> > I am planning doing annual Git User's Survey, and I'd like to ask for
> > feedback.
>
> > === 16. Which of the following Git features do you use? ===
> > (multiple choice, with other)
[...]
> > + interactive commit / per-hunk comitting / partial commit
[...]
> > + Other, please specify
> >
> > NOTES:
> > ^^^^^^
> > The problem is come up not with exhaustive list of features: there are
> > too many of them to list. The problem is coming up with list of
> > important and used enough often features.
> >
> > So: what features should be included in this list? What features
> > should be removed from above list of answers?
>
> *staging*! I have suggested this multiple times, it should be here this one!
>
> - stage add / partial commit / interactive commit / per-hunk comitting
> (e.g. git add -u/-i/-p)
> + stage / partial or interactive commits (e.g. git add -u/-i/-p, git
> diff --cached)
Well, it is there... sort of. I can certainly extend this answer.
> > === 19. Overall, how happy are you with Git? ===
> > (single choice)
> >
> > * unhappy
> > * not so happy
> > * happy
> > * very happy
> > * completely ecstatic
> >
> > NOTES:
> > ^^^^^^
> > I'm not sure if this question is at all useful.
> >
> > There is also problem, that the current wording is considered biased
> > by some, but on the other hand changing wording of answers would make
> > it impossible to compare it to answers from previous surveys...
>
> What wording would you use?
I think I'll keep what we used before.
> > === 20. In your opinion, which areas in Git need improvement? ===
> > Please state your preference.
> > (matrix)
> >
> > Columns: don't need / a little / some / much
> > + user-interface
> > + documentation
> > + performance
> > + more features
> > + tools (e.g. GUI)
> > + localization (translation)
> >
> > NOTES:
> > ^^^^^^
> > Are there any general areas that are missing from this list?
> > What are they?
>
> IDE integration, portability?
Portability, certainly.
IDE integration is a bit out of scope, as it is not strictly about Git
itself, but about Git "ecosystem".
As I wrote in separate email, I am thinking about adding a new question:
21. In your opinion, what Git tools are needed, and which need improvements?
> > == About this survey. Open forum. ==
> >
> > === 26. How did you hear about this Git User's Survey? ===
> > (single choice, with other)
> >
> > * git mailing list
> > * git-related mailing list (e.g. msysGit, Git for Human Beings)
> > * mailing list or forum of some project
> > * #git IRC channel topic
> > * announcement on IRC channel
> > * git homepage
> > * git wiki
> > * git hosting site (or blog related to such site)
> > * software-related web site
> > * news or social news site (e.g. Digg, Reddit)
> > * blog (or blog planet)
> > * other kind of web site
> > * Twitter or other microblogging platform
> >
> > * other - please specify
> >
> > NOTES:
> > ^^^^^^
> > This list would of course be updated to reflect the list of (planned)
> > announcement channels.
> >
> > There of course will be announcement on Git Mailing List, and perhaps
> > also on msysGit list / Google Group, and on Git For Human Beings
> > Google Group (if it exists). I'll announce it on #git, and ask op to
> > put short announcement in channel description, and I can announce it
> > on other IRC channels. I would add announcement to main page of Git
> > Wiki, and as Git Homepage administrator to put announcement about Git
> > User's Survey.
> >
> > I usually tried to contact administrators of git hosting sites,
> > including git.kernel.org, repo.or.cz, GitHub, Gitorious, Assembla,
> > Codebase and Unfuddle, asking them to put announcement about
> > Git User's Survey either somewhere on the site, or in their blog
> > (if there is any). What git hosting sites it is worth to ask?
>
> Google+ (maybe facebook).
They are not git hosting sites ;-)
Anyway, on Google+ there are 36 people who have me in their circles,
I have 28 followers on Twitter. Identi.ca, Plurk, Facebook - here
I don't have or almost don't have "friends"/"subscribers"/"fans".
That's not much, so please: forward / share.
> > I would like to have announcement of Git User's Survey 2010 at
> > LWN.net, but this would need to be send at least two weeks in advance,
> > if I remember correctly. Is it worth it? What other news site should
> > I (or you) send announcement to?
> >
> > If you can Digg / Reddit announcment on some site, please do. I can
> > announce Git User's Survey 2-1- at Twitter, Identi.ca and Plurk, but I
> > don't have wide area of followers. So please RT.
>
> I can post it on reddit :)
Thanks in advance.
> > Should we contact some bloggers (besides asking Junio to put
> > announcement on his blog) to post an anouncement? Which bloggers
> > would respond positively (perhaps Linus...)?
>
> I can post it on gitlog. It looks like there are now many people checking it.
Thanks in advance, again.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Storing additional information in commit headers
From: Michael Haggerty @ 2011-08-02 13:53 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110801182015.GA3100@fishbowl.rw.madduck.net>
On 08/01/2011 08:20 PM, martin f krafft wrote:
> Are there any strong reasons against my use of commit headers for
> specific, well-defined purposes in contained use-cases? E.g. are
> there tools known to only copy "known" headers, which could
> potentially break my assumptions?
Before you store important information in a git-internal data structure,
please consider:
* Some of your developers might prefer using another DVCS (e.g.,
Mercurial via hg-git) and they will not be able to see the information
at all
* Some day the main project might want to (god forbid!) switch to a
successor to git, and your extra information might be difficult to migrate.
* Somebody might want to work with your project from a tarball rather
than having to install and use git.
Therefore, I recommend a strong bias towards storing information in as
transparent, non-system-specific a way as possible. Metadata and
scripts stored within the file tree part of the repository are typically
a lot easier to work with and more transparent than git-specific hacks.
That being said, I haven't understood your application well enough to
know whether these biases might be trumped by convenience in your
particular situation.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-02 14:41 UTC (permalink / raw)
To: Christian Couder; +Cc: git, chriscool, gitster, j6t, jnareb
In-Reply-To: <CAP8UFD3XzUjxiz6QQzyTOYzfiWrF4ckiv0h+gvi7YuZkma6yiw@mail.gmail.com>
On Tue, Aug 2, 2011 at 10:04 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 1:29 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> @@ -34,6 +34,8 @@ require_work_tree
>> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
>> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
>>
>> +BISECT_MODE=$(test -f "$GIT_DIR/BISECT_MODE" && cat "$GIT_DIR/BISECT_MODE")
>
> Could you put this line just where it is needed, that is in
> bisect_next() and bisect_reset()?
>
Ultimately, it is also needed in paths that call bisect_state(), such
as bisect_run() and bisect_skip() so I am not keen to do this.
If I was to do this, I'd prefer to change uses of $BISECT_MODE with a
call to a function bisect_mode() that does the same thing.
jon.
^ permalink raw reply
* Re: [PATCH v13 4/8] bisect: introduce support for --no-checkout option.
From: Jon Seymour @ 2011-08-02 14:42 UTC (permalink / raw)
To: Christian Couder; +Cc: git, chriscool, gitster, j6t, jnareb
In-Reply-To: <CAP8UFD0kB+dS4cP=4MXKShhMw3-f_uKjtOmYKahNM0uQQkojsQ@mail.gmail.com>
On Tue, Aug 2, 2011 at 10:16 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 1:29 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> If --no-checkout is specified, then the bisection process uses:
>
> Yeah, but in this patch you are changing "git bisect--helper" by
> adding the [--bisect-mode=checkout|update-ref] option. So it is
> strange that you still talk about a --no-checkout option.
>
>> git update-ref --no-deref HEAD <trial>
>>
>> at each trial instead of:
>>
>> git checkout <trial>
>
> [...]
>
>> int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
>> {
>> int next_all = 0;
>> + int no_checkout = 0;
>> + char *bisect_mode=NULL;
>> struct option options[] = {
>> OPT_BOOLEAN(0, "next-all", &next_all,
>> "perform 'git bisect next'"),
>> + OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
>> + "the bisection mode either checkout or update-ref. defaults to checkout."),
>
> Nit: I would say : "bisection mode: 'checkout' (default) or 'update-ref'"
>
Thanks. Will address iboth comments s a future iteration.
jon.
^ permalink raw reply
* Re: git-svn and comitter names
From: Thomas Ferris Nicolaisen @ 2011-08-02 14:59 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <6517-1311952613-96947@sneakemail.com>
On Fri, Jul 29, 2011 at 5:16 PM, John M. Dlugosz
<ngnr63q02@sneakemail.com> wrote:
> I just grabbed a repository using git-svn, and the commiter name shows a
> GUID for the domain name. For example,
>
> first.last <first.last@5ab5abacd-6ff9-f940-aeea-106a2a325327>
>
> I set my git name and email address to show what I want in the end, the real
> company email address. Will this apparent mapping be a problem when I
> dcommit?
Hi John,
No, it won't be a problem. This is the default "mapping" in git-svn.
The committer name is only visible in your git-svn clone. When you
dcommit, it will use your normal SVN username, the same one which is
used when you use SVN normally.
Your configured git name and email will be used in your local commits,
but as soon as you dcommit, those commits are rewritten to use this
username@uuid style.
If you think this is really annoying, or you are planning to make a
permanent migration away from SVN, you can use an authors-file when
doing the initial git-svn clone. See
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html for more
info on the --authors-file option.
^ permalink raw reply
* Re: use remote repository as webroot
From: Michael Schubert @ 2011-08-02 15:00 UTC (permalink / raw)
To: lunarnet76; +Cc: git
In-Reply-To: <1312283829487-6644436.post@n2.nabble.com>
On 08/02/2011 01:17 PM, lunarnet76 wrote:
> I have a small issue (I hope), I have a git repository in an apache folder
> accessed by http://ip/git, I can clone, pull push and stuff, but I don't get
> how to get the remote repository (http://ip/git) to update the files to the
> one I have just pushed!
This may help:
https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F
http://toroid.org/ams/git-website-howto
^ permalink raw reply
* working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)
From: martin f krafft @ 2011-08-02 15:03 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802082810.GC29887@fishbowl.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2011.08.02.1028 +0200]:
> What do you think about using the idea of orphan parent commits
> (OPC) for now? These are conceptually closest to the x-*-ref
> pointers, do not require extra setup, pollute history only a little
> bit (IMHO), and slot in with Git and fsck/gc alright.
>
> Here's the idea again, graphically:
>
> o--o--o--●
> /
> #
>
> while at HEAD, I would backtrack history until I found HEAD^, which
> has a parent with a well-defined commit message and holding the data
> I am looking for.
>
> Later, when x-*-ref is mainline, instead of parent pointers, it can
> be used in place.
>
> When there is a merge and the TopGit data need updating, a new
> OPC is slotted into place, on the merge commit. In
> the following graph, the user then decided also at a later point to
> update e.g. the TopGit patch description (.topmsg), which is also
> stored in this OPC:
>
> o--o-o
> / \ maint master
> o--o--o--o--+--o--O--o--o--o--●
> / / /
> # # #
>
> To keep things simple, every OPC copies the unchanged data from the
> previous one as well (compression will reduce the overhead).
I have published a working prototype of this kind of datastore, in
case people are interested:
http://git.madduck.net/v/code/topgit-ng.git
Here's a bit of synopsis:
% ./tg-datastore list
I: returns non-zero if no datastore found at given commit.
I: prints contents of datastore otherwise.
message: this is a proof-of-concept
% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
dc58ec49df849ec1aef6929cd40c759a6018e056
% git commit --allow-empty -mone
[master 78918bb] one
% git commit --allow-empty -mtwo
[master 7eca0cd] two
% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a proof-of-concept
% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
dc58ec49df849ec1aef6929cd40c759a6018e056
% ./tg-datastore add message='this is a new message'
I: returns non-zero if there is already a datastore on HEAD.
I: adding the following data to the datastore of HEAD:
I: message: this is a new message
% ./tg-datastore find commitref
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
8e6179050a1aca5485f3e1702780f1b555d8643b
% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a new message
tig output now:
2011-08-02 16:52 martin f. krafft M─┐ [master] two
2011-08-02 16:54 TopGit │ I TopGit data node
2011-08-02 16:52 martin f. krafft I one
2011-08-02 16:50 martin f. krafft M─┐ [origin/master] import first prototype
2011-08-02 16:50 TopGit │ I TopGit data node
2011-08-02 16:48 martin f. krafft I Initial (empty) root commit
% ./tg-datastore remove
I: always returns zero, even if there was nothing to remove.
% ./tg-datastore find message
I: prints the value of the parameter, or empty if parameter is not found.
I: returns non-zero if no datastore was found.
this is a proof-of-concept
Note three things:
1. I am actually using a x-* header in the TopGit data node commit
object to help identify it as a commit. This could be done
differently (e.g. parse the commit message for some magic), but
I chose to do this on purpose to see how well it fares.
2. If Git grew x-*-ref headers (refs to objects in general),
I could use that instead and drop the parent pointer, which
would make the DAG cleaner.
3. Right now, you cannot add parent orphan commits to orphans
themselves, but it would be trivial to enable. I just couldn't
be bothered.
Enjoy, and comments of course welcome.
--
martin | http://madduck.net/ | http://two.sentenc.es/
windoze nt crashed.
i am the blue screen of death.
no one hears your screams.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* [PATCH v13 4a/8] bisect: introduce support for --bisect-mode option in bisect--helper.
From: Jon Seymour @ 2011-08-02 15:30 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, Jon Seymour
In-Reply-To: <AP8UFD0kB+dS4cP=4MXKShhMw3-f_uKjtOmYKahNM0uQQkojsQ@mail.gmail.com>
If --bisect-mode=update-ref is specified, then the bisection process uses:
git update-ref --no-deref HEAD <trial>
at each trial instead of:
git checkout <trial>
Improved-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
bisect.c | 33 ++++++++++++++++++++++-----------
bisect.h | 2 +-
builtin/bisect--helper.c | 9 +++++++--
3 files changed, 30 insertions(+), 14 deletions(-)
A replacement for [PATCH v13 4/8].
diff --git a/bisect.c b/bisect.c
index dd7e8ed..0427117 100644
--- a/bisect.c
+++ b/bisect.c
@@ -24,6 +24,7 @@ struct argv_array {
static const char *argv_checkout[] = {"checkout", "-q", NULL, "--", NULL};
static const char *argv_show_branch[] = {"show-branch", NULL, NULL};
+static const char *argv_update_ref[] = {"update-ref", "--no-deref", "HEAD", NULL, NULL};
/* bits #0-15 in revision.h */
@@ -707,16 +708,23 @@ static void mark_expected_rev(char *bisect_rev_hex)
die("closing file %s: %s", filename, strerror(errno));
}
-static int bisect_checkout(char *bisect_rev_hex)
+static int bisect_checkout(char *bisect_rev_hex, int no_checkout)
{
int res;
mark_expected_rev(bisect_rev_hex);
argv_checkout[2] = bisect_rev_hex;
- res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
- if (res)
- exit(res);
+ if (no_checkout) {
+ argv_update_ref[3] = bisect_rev_hex;
+ if (run_command_v_opt(argv_update_ref, RUN_GIT_CMD))
+ die("update-ref --no-deref HEAD failed on %s",
+ bisect_rev_hex);
+ } else {
+ res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
+ if (res)
+ exit(res);
+ }
argv_show_branch[1] = bisect_rev_hex;
return run_command_v_opt(argv_show_branch, RUN_GIT_CMD);
@@ -788,7 +796,7 @@ static void handle_skipped_merge_base(const unsigned char *mb)
* - If one is "skipped", we can't know but we should warn.
* - If we don't know, we should check it out and ask the user to test.
*/
-static void check_merge_bases(void)
+static void check_merge_bases(int no_checkout)
{
struct commit_list *result;
int rev_nr;
@@ -806,7 +814,7 @@ static void check_merge_bases(void)
handle_skipped_merge_base(mb);
} else {
printf("Bisecting: a merge base must be tested\n");
- exit(bisect_checkout(sha1_to_hex(mb)));
+ exit(bisect_checkout(sha1_to_hex(mb), no_checkout));
}
}
@@ -849,7 +857,7 @@ static int check_ancestors(const char *prefix)
* If a merge base must be tested by the user, its source code will be
* checked out to be tested by the user and we will exit.
*/
-static void check_good_are_ancestors_of_bad(const char *prefix)
+static void check_good_are_ancestors_of_bad(const char *prefix, int no_checkout)
{
const char *filename = git_path("BISECT_ANCESTORS_OK");
struct stat st;
@@ -868,7 +876,7 @@ static void check_good_are_ancestors_of_bad(const char *prefix)
/* Check if all good revs are ancestor of the bad rev. */
if (check_ancestors(prefix))
- check_merge_bases();
+ check_merge_bases(no_checkout);
/* Create file BISECT_ANCESTORS_OK. */
fd = open(filename, O_CREAT | O_TRUNC | O_WRONLY, 0600);
@@ -908,8 +916,11 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
* We use the convention that exiting with an exit code 10 means that
* the bisection process finished successfully.
* In this case the calling shell script should exit 0.
+ *
+ * If no_checkout is non-zero, the bisection process does not
+ * checkout the trial commit but instead simply updates HEAD.
*/
-int bisect_next_all(const char *prefix)
+int bisect_next_all(const char *prefix, int no_checkout)
{
struct rev_info revs;
struct commit_list *tried;
@@ -920,7 +931,7 @@ int bisect_next_all(const char *prefix)
if (read_bisect_refs())
die("reading bisect refs failed");
- check_good_are_ancestors_of_bad(prefix);
+ check_good_are_ancestors_of_bad(prefix, no_checkout);
bisect_rev_setup(&revs, prefix, "%s", "^%s", 1);
revs.limited = 1;
@@ -966,6 +977,6 @@ int bisect_next_all(const char *prefix)
"(roughly %d step%s)\n", nr, (nr == 1 ? "" : "s"),
steps, (steps == 1 ? "" : "s"));
- return bisect_checkout(bisect_rev_hex);
+ return bisect_checkout(bisect_rev_hex, no_checkout);
}
diff --git a/bisect.h b/bisect.h
index 0862ce5..22f2e4d 100644
--- a/bisect.h
+++ b/bisect.h
@@ -27,7 +27,7 @@ struct rev_list_info {
const char *header_prefix;
};
-extern int bisect_next_all(const char *prefix);
+extern int bisect_next_all(const char *prefix, int no_checkout);
extern int estimate_bisect_steps(int all);
diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index 5b22639..1f072d4 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -4,16 +4,20 @@
#include "bisect.h"
static const char * const git_bisect_helper_usage[] = {
- "git bisect--helper --next-all",
+ "git bisect--helper --next-all [--bisect-mode=checkout|update-ref]",
NULL
};
int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
{
int next_all = 0;
+ int no_checkout = 0;
+ char *bisect_mode=NULL;
struct option options[] = {
OPT_BOOLEAN(0, "next-all", &next_all,
"perform 'git bisect next'"),
+ OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
+ "bisection mode: 'checkout' (default) or 'update-ref'"),
OPT_END()
};
@@ -23,6 +27,7 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
if (!next_all)
usage_with_options(git_bisect_helper_usage, options);
+ no_checkout = bisect_mode && !strcmp(bisect_mode, "update-ref");
/* next-all */
- return bisect_next_all(prefix);
+ return bisect_next_all(prefix, no_checkout);
}
--
1.7.6.353.g794b
^ permalink raw reply related
* Re: [PATCH v2 09/19] Allow querying all attributes on a file
From: Junio C Hamano @ 2011-08-02 15:34 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <1311828418-2676-10-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Add a function, git_allattrs(), that reports on all attributes that
> are set on a path.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Documentation/technical/api-gitattributes.txt | 45 +++++++++++++++++-------
> attr.c | 43 +++++++++++++++++++++++
> attr.h | 9 +++++
> 3 files changed, 84 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt
> index ab3a84d..640240e 100644
> --- a/Documentation/technical/api-gitattributes.txt
> +++ b/Documentation/technical/api-gitattributes.txt
> @@ -22,19 +22,6 @@ Data Structure
> ...
> (JC)
The last line, I think, can now be dropped. This was a marker saying "we
lack documentation for this API; bug this person for necessary information
and write one".
> diff --git a/attr.c b/attr.c
> index bfa1f43..9c2fca8 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -737,6 +737,49 @@ int git_checkattr(const char *path, int num, struct git_attr_check *check)
> return 0;
> }
>
> +int git_allattrs(const char *path, int *num, struct git_attr_check **check)
> +{
> + struct attr_stack *stk;
> + const char *cp;
> + int dirlen, pathlen, i, rem, count, j;
> +
> + bootstrap_attr_stack();
> + for (i = 0; i < attr_nr; i++)
> + check_all_attr[i].value = ATTR__UNKNOWN;
> +
> + pathlen = strlen(path);
> + cp = strrchr(path, '/');
> + if (!cp)
> + dirlen = 0;
> + else
> + dirlen = cp - path;
> + prepare_attr_stack(path, dirlen);
> + rem = attr_nr;
> + for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
> + rem = fill(path, pathlen, stk, rem);
Shouldn't the above part at least should be refactored instead of copied
and pasted from git_checkattr()?
^ permalink raw reply
* Why do some commits not appear in "git log"?
From: Dov Grobgeld @ 2011-08-02 15:38 UTC (permalink / raw)
To: git
In-Reply-To: <CA++fsGGG7pLt4xoeJozGnYEwOrs6NuzStYPKF_L5k49uzFB-4A@mail.gmail.com>
Hi,
This is my first post to this list, so I hope this is the appropriate place.
I'm having a problem understanding why "git log file" does not show
some of the commits where file is changed. Consider the following
commit history:
> git log --pretty=oneline --abbrev-commit | head -20
e86d3b1 Merge remote-tracking branch 'git-svn' into MultiDataPath
05e7103 Made the system convert DP geometric info to MultiDP info and
load it at machine start.
2de7375 Fixed compilation under Linux.
b520873 Error handling!!
73110bd New Group manager for multi data processor
dce3ae9 Merge branch 'MultiDataPath' of
ssh://swteam/home/machine/git/SolarJet into MultiDataPath
25dff3c Merge branch 'MultiDataPath' of
ssh://swteam/home/machine/git/SolarJet into MultiDataPath
247f418 Rewrite of the Finger heightmap nozzle selection algorithm for
better load balancing.
026fec8 Stop all the jobs on async stop or on exception Choice nozzles
using max nozzles number
84a60b7 avoid CarouselSimulationParams
c40df74 git-svn-id: svn://swteam/SolarJet/trunk@4684
d8e1dcc2-e5e0-4eb0-83da-8cedbf775ddd
:
Now let's limit this to the history of a single file:
> git log --pretty=oneline --abbrev-commit Apps/SolarJet/Project/qt/SysScripts/init.py | head
84a60b7 avoid CarouselSimulationParams
c40df74 git-svn-id: svn://swteam/SolarJet/trunk@4684
d8e1dcc2-e5e0-4eb0-83da-8cedbf775ddd
:
As can be see above there were lots of commits omitted now. E.g.
05e7103 (the second commit above). But if I list the changes in
05e7103 I then get:
> git show 05e7103 --name-only | grep init.py
Apps/SolarJet/Project/qt/SysScripts/init.py
Running without --name-only show that there is a substantial change in init.py
So why does this commit not show up in in "git log file"?
One interesting observation is that the only commits that appear in
the "git log file" command are the commits that were imported from
svn. All other commits are filtered out.
So is this a bug, or am I doing something wrong?
Thanks in advance!
Dov
^ permalink raw reply
* Re: [PATCH v2 19/19] Rename struct git_attr_check to git_attr_value
From: Junio C Hamano @ 2011-08-02 15:46 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <1311828418-2676-20-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> This described its purpose better, especially when used with
> git_allattrs().
You probably meant s/described/describes/ but more importantly does it
really? It is a structure used to probe into the attributes system for the
state of various attributes on a path, and the set of possible states
includes "there is no value" (aka unset), so it feels actively wrong to
call it attr_value and that is why I didn't call it in the first place.
I also think git_all_attrs() (i.e. word-break underscore after "all") is
more in line with the naming throughout the codebase, after looking at
output from
$ git grep -e _all'[a-z]' --and --not -e alloc -e _all_ -- '*.c'
Other than these, and the earlier comment about the copy&paste done from
git_checkattr (which by the way should probably be "git_check_attr"), it
seems that the series mostly consist of good clean-ups and an addition of
a new and (probably) useful feature that is straightforward. Nice.
Thanks.
^ permalink raw reply
* Re: Why do some commits not appear in "git log"?
From: Michael Witten @ 2011-08-02 15:56 UTC (permalink / raw)
To: Dov Grobgeld; +Cc: git
In-Reply-To: <CA++fsGEht+UDp9EnFyfvn-uT1DYPcnhpwmPy_H4PTWvsvUceAQ@mail.gmail.com>
On Tue, Aug 2, 2011 at 15:38, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
> git log --pretty=oneline --abbrev-commit | head -20
Try `--full-history' maybe? Also, rather than `head -20', you can
limit the output directly with `-20':
git log --pretty=oneline --abbrev-commit --full-history -20
It's hard to know what's going on in your particular example; perhaps
give us the output of `git log' when using the `--graph' option.
^ permalink raw reply
* [PATCH] commit: write out cache-tree information
From: trast @ 2011-08-02 16:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Carlos Martín Nieto, Thomas Rast
From: Thomas Rast <trast@student.ethz.ch>
While write-tree has code to write out the cache-tree information
(since we have to compute it anyway if the cache is stale), commit
lost this capability when it became a builtin and moved away from
using write-tree.
Add the necessary code to write out the cache. This is extremely
similar to what write_cache_as_tree() does.
Reported-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Reported on IRC.
There's a similar disparity between read-tree and checkout, but I
first have to understand the exact conditions in or around
unpack_trees() [checkout.c:417] where the read-tree reasoning applies.
builtin/commit.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index e1af9b1..47b0eea 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -637,6 +637,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
const char *hook_arg2 = NULL;
int ident_shown = 0;
int clean_message_contents = (cleanup_mode != CLEANUP_NONE);
+ int fd;
+ struct lock_file *lock_file;
if (!no_verify && run_hook(index_file, "pre-commit", NULL))
return 0;
@@ -861,6 +863,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
* the editor and after we invoke run_status above.
*/
discard_cache();
+ lock_file = xcalloc(1, sizeof(struct lock_file));
+ fd = hold_lock_file_for_update(lock_file, index_file, LOCK_DIE_ON_ERROR);
read_cache_from(index_file);
if (!active_cache_tree)
active_cache_tree = cache_tree();
@@ -869,6 +873,11 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
error(_("Error building trees"));
return 0;
}
+ if (0 <= fd) {
+ if (write_cache(fd, active_cache, active_nr) ||
+ commit_lock_file(lock_file))
+ rollback_lock_file(lock_file);
+ }
if (run_hook(index_file, "prepare-commit-msg",
git_path(commit_editmsg), hook_arg1, hook_arg2, NULL))
--
1.7.6.668.g17b0a
^ permalink raw reply related
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: René Scharfe @ 2011-08-02 16:46 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <20110802040004.GC17494@sigill.intra.peff.net>
Am 02.08.2011 06:00, schrieb Jeff King:
> On Mon, Aug 01, 2011 at 11:52:43PM +0200, René Scharfe wrote:
>
>> Am 01.08.2011 23:20, schrieb Johannes Sixt:
>>> Am 01.08.2011 22:48, schrieb René Scharfe:
>>>> So git archive gives the right results when writing to a pipe, but
>>>> always the same wrong result when writing directly to a file.
>>>
>>> This could indeed be a CRLF issue. archive-tar.c runs gzip to let it
>>> write to the original fd 1 (stdout). gzip is an MSYS program, and MSYS
>>> is "clever" and sets up the channel in text mode (CRLF conversion) if it
>>> is a regular file, but in binary mode if it is a pipe.
>>>
>>> Without the gzip filter, git-archive writes to stdout itself. Since we
>>> have set up all our channels in binary mode, we do not suffer from the
>>> same problem for plain tar format.
>>>
>>> So, I don't think we can do a lot about it, short of patching MSYS again...
>>
>> Or we could pipe the output through us, i.e. attach a builtin version of
>> cat at the output end of the called command. Only on Windows, of
>> course. Better ugly and limping then wrong, right?
>
> Yeah, that would work. But I am confused. If what Johannes says is true,
> isn't MSYS gzip totally broken for:
>
> # works
> echo foo | gzip -c | cat >foo.gz
>
> # broken; introduces CR
> echo foo | gzip -c >foo.gz
>
> ? (The "works" and "broken" there are my guesses; I don't have a Windows
> box to test on). IOW, is it simply gzip that is broken, and any fix we
> do is simply working around a bug in gzip? And therefore the right
> solution is for MSYS people to fix gzip?
"foo" may be too short to trigger the issue as the small resulting gz
file has a low probability of containing LFs.
The output of gzip is not simply always mangled, though (taken from my
earlier email, all three are working):
$ git archive v1.7.6 | gzip -cn | md5sum
a0ca1c873a533a5fcd41d248fb325a5b *-
$ git archive --format=tar.gz v1.7.6 | md5sum
a0ca1c873a533a5fcd41d248fb325a5b *-
$ git archive v1.7.6 | gzip -cn >a.tgz && md5sum <a.tgz
a0ca1c873a533a5fcd41d248fb325a5b *-
It's only broken if we call it from git archive:
$ git archive --format=tar.gz v1.7.6 >a.tgz && md5sum <a.tgz
30886283af1aed05ae6a36fc5aeda077 *-
$ git archive -o a.tgz v1.7.6 && md5sum <a.tgz
30886283af1aed05ae6a36fc5aeda077 *-
But not if we stuff the result into a pipe instead of a file:
$ git archive --format=tar.gz v1.7.6 | cat >a.tgz && md5sum <a.tgz
a0ca1c873a533a5fcd41d248fb325a5b *-
It _is_ confusing.
René
^ permalink raw reply
* Re: [PATCH 2/5] fast-import: don't fail on omitted committer name
From: Junio C Hamano @ 2011-08-02 16:53 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, SASAKI Suguru
In-Reply-To: <1311831844-13123-3-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> fast-import format declares 'committer_name SP' to be optional. But SP
> between empty or not name and a email is obligatory and checked by
Sorry, cannot parse this.
> git-fsck, so fast-import must prepend the SP if the name is omitted.
> Currently it doesn't.
>
> Name cannot contain LT or GT and ident always comes after SP in
> fast-import. So reuse that SP as if a valid 'SP <email>' ident was passed.
>
> This fixes a ident parsing bug for a well-formed fast-import input.
> Though the parsing is still loose and can accept a ill-formed input.
>
> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
> ---
> fast-import.c | 4 ++++
> t/t9300-fast-import.sh | 2 +-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index 9e8d186..3194f4e 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1972,6 +1972,10 @@ static char *parse_ident(const char *buf)
> size_t name_len;
> char *ident;
>
> + /* ensure there is a space delimiter even if there is no name */
> + if (*buf == '<')
> + --buf;
> +
> gt = strrchr(buf, '>');
> if (!gt)
> die("Missing > in ident string: %s", buf);
> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
> index a659dd4..09ef6ba 100755
> --- a/t/t9300-fast-import.sh
> +++ b/t/t9300-fast-import.sh
> @@ -352,7 +352,7 @@ data <<COMMIT
> empty commit
> COMMIT
> INPUT_END
> -test_expect_failure 'B: accept and fixup committer with no name' '
> +test_expect_success 'B: accept and fixup committer with no name' '
> git fast-import <input &&
> out=$(git fsck) &&
> echo "$out" &&
^ permalink raw reply
* Re: [PATCH 5/5] fsck: improve committer/author check
From: Junio C Hamano @ 2011-08-02 17:00 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, SASAKI Suguru
In-Reply-To: <1311831844-13123-6-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> Neither name nor email should contain < or >, so split the string with
> these and check they come in that order and < is preceeded with a space.
>
> If < is missing don't say a confusing "missing space", say "bad name" if
>> isn't missing and "missing email" if both < and > are missing.
>
> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
> ---
Same comment as 3/5; before starting to talk about how you implemented
your validation, please state what rules you are enforcing.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/5] fast-import: check committer name more strictly
From: Junio C Hamano @ 2011-08-02 17:01 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, SASAKI Suguru
In-Reply-To: <1311831844-13123-4-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
> ---
Please describe how you check this field "more strictly" in the body of
the log message, iow, against what rule you are validating, perhaps
something like:
The identifier must be either "<address>" or "Name <address>" where
neither address nor Name can contain '<' nor '>'; otherwise the input
stream is rejected.
As fast-import is used to _create_ new objects, its input is a simple text
file that can be fixed-up as needed, it is a good idea to validate the
input more strictly and rejecting bad ones.
^ 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