* Re: [PATCH 3/3] git checkout --nodwim
From: Michael J Gruber @ 2009-10-23 8:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Avery Pennarun, Junio C Hamano, Alex Riesen,
git, Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 22.10.2009 02:27:
> Hi,
>
> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
>
>> Quoting Avery Pennarun <apenwarr@gmail.com>
>>
>>> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Helping hands in polishing it up is very welcome.
>>>
>>> I find the idea of an option for "don't do what I mean" to be pretty
>>> entertaining. Or maybe just misleading :)
>>>
>>> Have fun,
>>>
>>> Avery
>>
>> As Junio asked for helping hands, let's try to be helpful and constructive.
>>
>> Maybe "don't second-guess" explains it better?
>
> My take on it:
>
> 1) --no-porcelain
Between --no-dwim and --no-porcelain, maybe --no-wimp is a good compromise?
> 2) we all are bike-shedding, not being constructive at all
That's the fun part!
Michael
^ permalink raw reply
* [git question] how to handle few projects with common parts?
From: Ivan Dimitrov @ 2009-10-23 9:01 UTC (permalink / raw)
To: git
Hi list,
Maybe my question relates rather to configuration management, but it
is over GIT.
In short - I have to manage two projects with 95% same files
(components) and all the rest are platform depended. I am trying to
keep different platforms in different branches, but I can't figure out
how keep the common part of the project synchronized?
--
Best Regards,
Ivan Dimitrov
^ permalink raw reply
* Re: git bisect Vs branch
From: Grégory Romé @ 2009-10-23 9:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE16A82.1010103@viscovery.net>
Thanks even if that's what scared me :)
The draw is very simple comparing to the reality (much more merge points) and
rebase will require lot of conflicts resolutions but now I'm sure that's what I
have to do.
Grégory
Johannes Sixt wrote:
> Grégory Romé schrieb:
>> Thanks Santi but I have a problem, due to the fact that the commit which
>> has an impact on my code is in origin/master or first-origin/master
>>
>> When bisect checkout a commit from those branch I have none of my own
>> modifications... So I can' test if my code is good or bad excepted if I
>> can merge my commits in the bisect branch...
>> ᐁ
>> first-origin/master *---A---------B----------------o------C-
>> \ \ \
>> origin/master ----------B'----------U-----------C'-
>> \ \ \
>> master ------------U'----------C''-
>
> C" is the commit that merges upstream changes into your changes. You are
> saying that your changes alone (before the merge) are good, and that
> upstream before the merge is also good (since it doesn't contain your
> changes, it is good by definition, more or less). That indeed means that
> the merge commit is the first bad one; i.e., this is exactly the situation
> that the user manual describes.
>
> You should do:
>
> $ git checkout -b tmp master # master is at C"
> $ git rebase origin/master
> $ git bisect start tmp orgin/master
>
> That is, you rebuild your history on top of origin/master in a linear
> fashion. (If you had merge conflicts in U', then you will see them again.)
> Then you bisect the linearized history. This will point you to the bad
> commit and you will understand what is going wrong.
>
> With this new knowledge, go back to master (C") and fix the problem.
>
> -- Hannes
>
^ permalink raw reply
* [PATCH] add tests for git diff --submodule
From: Jens Lehmann @ 2009-10-23 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Copied from the submodule summary test and changed to reflect the
differences in the output of git diff --submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Junio C Hamano schrieb:
> * js/diff-verbose-submodule (2009-10-14) 2 commits.
> - add tests for git diff --submodule-summary
> - Add the --submodule option to the diff option family
>
> I should retitle and fix some comments in the tip commit (the tests have
> already been adjusted to use the real option name), but otherwise I think
> this is ready for 'next'.
Sorry for sending the updated test so late, i haven't had much time for
git in the last few days.
Apart from your changes necessary to make the test run again my changes are:
- rename from "t4041-diff-submodule-summary.sh" to "t4041-diff-submodule.sh"
- corrected all comments still speaking of "summary"
- added tests to test the behaviour of "--submodule" and "--submodule=short"
t/t4041-diff-submodule.sh | 260 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 260 insertions(+), 0 deletions(-)
create mode 100755 t/t4041-diff-submodule.sh
diff --git a/t/t4041-diff-submodule.sh b/t/t4041-diff-submodule.sh
new file mode 100755
index 0000000..5bb4fed
--- /dev/null
+++ b/t/t4041-diff-submodule.sh
@@ -0,0 +1,260 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+#
+
+test_description='Support for verbose submodule differences in git diff
+
+This test tries to verify the sanity of the --submodule option of git diff.
+'
+
+. ./test-lib.sh
+
+add_file () {
+ sm=$1
+ shift
+ owd=$(pwd)
+ cd "$sm"
+ for name; do
+ echo "$name" > "$name" &&
+ git add "$name" &&
+ test_tick &&
+ git commit -m "Add $name"
+ done >/dev/null
+ git rev-parse --verify HEAD | cut -c1-7
+ cd "$owd"
+}
+commit_file () {
+ test_tick &&
+ git commit "$@" -m "Commit $*" >/dev/null
+}
+
+test_create_repo sm1 &&
+add_file . foo >/dev/null
+
+head1=$(add_file sm1 foo1 foo2)
+
+test_expect_success 'added submodule' "
+ git add sm1 &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+head2=$(add_file sm1 foo3)
+
+test_expect_success 'modified submodule(forward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward)' "
+ git diff --submodule=log >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward) --submodule' "
+ git diff --submodule >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
+test_expect_success 'modified submodule(forward) --submodule=short' "
+ git diff --submodule=short >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+index $head1..$head2 160000
+--- a/sm1
++++ b/sm1
+@@ -1 +1 @@
+-Subproject commit $fullhead1
++Subproject commit $fullhead2
+EOF
+"
+
+commit_file sm1 &&
+cd sm1 &&
+git reset --hard HEAD~2 >/dev/null &&
+head3=$(git rev-parse --verify HEAD | cut -c1-7) &&
+cd ..
+
+test_expect_success 'modified submodule(backward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+head4=$(add_file sm1 foo4 foo5) &&
+head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
+test_expect_success 'modified submodule(backward and forward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2...$head4:
+ > Add foo5
+ > Add foo4
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+commit_file sm1 &&
+mv sm1 sm1-bak &&
+echo sm1 >sm1 &&
+head5=$(git hash-object sm1 | cut -c1-7) &&
+git add sm1 &&
+rm -f sm1 &&
+mv sm1-bak sm1
+
+test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+ git diff --submodule=log --cached >actual &&
+ diff actual - <<-EOF
+Submodule sm1 41fbea9...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..9da5fb8
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff --submodule=log >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index 9da5fb8..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head4 (new submodule)
+EOF
+"
+
+rm -rf sm1 &&
+git checkout-index sm1
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..$head5
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+rm -f sm1 &&
+test_create_repo sm1 &&
+head6=$(add_file sm1 foo6 foo7)
+fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
+test_expect_success 'nonexistent commit' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...$head6 (commits not present)
+EOF
+"
+
+commit_file
+test_expect_success 'typechanged submodule(blob->submodule)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index $head5..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head6 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+rm -rf sm1
+test_expect_success 'deleted submodule' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+EOF
+"
+
+test_create_repo sm2 &&
+head7=$(add_file sm2 foo8 foo9) &&
+git add sm2
+
+test_expect_success 'multiple submodules' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'path filter' "
+ git diff-index -p --submodule=log HEAD sm2 >actual &&
+ diff actual - <<-EOF
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+commit_file sm2
+test_expect_success 'given commit' "
+ git diff-index -p --submodule=log HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'given commit --submodule' "
+ git diff-index -p --submodule HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+
+test_expect_success 'given commit --submodule=short' "
+ git diff-index -p --submodule=short HEAD^ >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 160000
+index $head6..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-Subproject commit $fullhead6
+diff --git a/sm2 b/sm2
+new file mode 160000
+index 0000000..$head7
+--- /dev/null
++++ b/sm2
+@@ -0,0 +1 @@
++Subproject commit $fullhead7
+EOF
+"
+
+test_done
--
1.6.5.rc2.19.gcbaec.dirty
^ permalink raw reply related
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-23 14:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wf2ejna.fsf@alter.siamese.dyndns.org>
> You do not have to live with a tag that points at another tag that points
> at a commit.
>
> You can still tag the commit directly with your new tag, and you do not
> need to have the exact commit object name to do so. You just tell the
> tool to follow the tag chain to get to the pointed-to object, like this:
>
> $ git tag -a -m "my message" newtag oldtag^0
>
> This assumes [*1*] that the old tag points at (strictly speaking, "might
> point at") a commit object, and uses "^0" (zeroth parent of) operator to
> make sure that the object the newtag points at (the last argument to the
> "git tag" command, i.e. "oldtag^0" in this example) is a commit object,
> not an annotated tag "oldtag" itself.
>
> That is what I meant by "just as usable as hexadecimal to the tools".
>
>>> ... "v0.1" is
>>> much more useful than 8794hke to humans, and these tag names are just as
>>> usable as the hexadecimal commit object names to the tools. You can say
>>> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> [Footnote]
>
> *1* A tag can point at any object, not necessarily a commit. If oldtag
> points at a tree object (or a blob object), oldtag^0 will fail, because
> the operator "^0" is "zeroth parent of", and is applicable only to a
> commit. In general, you can write
>
> $ git tag -a -m "my message" newtag oldtag^{}
>
> The "^{}" operator is a special case of "^{type}" operator; the former
> means "dereference the tag repeatedly until it becomes something that is
> not a tag", and the latter means "dereference the tag repeatedly until it
> becomes something of that type". I.e. "oldtag^0" is "oldtag^{commit}".
>
Junio,
Thank you very much for such detailed explanation! I do appreciate it.
Eugene
^ permalink raw reply
* Unreachable code in builtin-merge.c ?
From: Zivkov, Sasa @ 2009-10-23 15:03 UTC (permalink / raw)
To: git@vger.kernel.org
In the try_merge_strategy function the expression in the following if statement seems to always evaluate to TRUE:
if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
If strategy is "recursive" then !strcmp(strategy, "subtree") evaluates to TRUE.
If strategy is "subtree" then !strcmp(strategy, "recursive") evaluates to TRUE.
If strategy is neither "recursive" nor "subtree" then any side of || evaluates to TRUE.
Looks like the code in the else block is unreachable?
Saša Živkov
^ permalink raw reply
* Re: Unreachable code in builtin-merge.c ?
From: Mikael Magnusson @ 2009-10-23 15:12 UTC (permalink / raw)
To: Zivkov, Sasa; +Cc: git@vger.kernel.org
In-Reply-To: <B221C4384AE5104EB414A877DFD0372C0B0092C0C5@DEWDFECCR04.wdf.sap.corp>
2009/10/23 Zivkov, Sasa <sasa.zivkov@sap.com>:
> In the try_merge_strategy function the expression in the following if statement seems to always evaluate to TRUE:
>
> if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
>
> If strategy is "recursive" then !strcmp(strategy, "subtree") evaluates to TRUE.
> If strategy is "subtree" then !strcmp(strategy, "recursive") evaluates to TRUE.
> If strategy is neither "recursive" nor "subtree" then any side of || evaluates to TRUE.
>
> Looks like the code in the else block is unreachable?
You seem to have forgotten that strcmp returns 0 when the strings
match. (It returns -1 or 1 when they don't, depending on their
alphabetical ordering).
--
Mikael Magnusson
^ permalink raw reply
* Re: Unreachable code in builtin-merge.c ?
From: Joshua Roys @ 2009-10-23 15:14 UTC (permalink / raw)
To: Zivkov, Sasa; +Cc: git@vger.kernel.org
In-Reply-To: <B221C4384AE5104EB414A877DFD0372C0B0092C0C5@DEWDFECCR04.wdf.sap.corp>
On 10/23/2009 11:03 AM, Zivkov, Sasa wrote:
> In the try_merge_strategy function the expression in the following if statement seems to always evaluate to TRUE:
>
> if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
>
> If strategy is "recursive" then !strcmp(strategy, "subtree") evaluates to TRUE.
> If strategy is "subtree" then !strcmp(strategy, "recursive") evaluates to TRUE.
> If strategy is neither "recursive" nor "subtree" then any side of || evaluates to TRUE.
>
> Looks like the code in the else block is unreachable?
>
>
> Saša Živkov
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
Not quite :) The strcmp() function actually returns 0 when the strings
match (I know, it looks weird "!strcmp" -> "not string compare?!"), so
the "if" really means: "if strategy is equal to 'recursive' or
'subtree', do the following..."
Hope to help,
Josh
^ permalink raw reply
* RE: Unreachable code in builtin-merge.c ?
From: Zivkov, Sasa @ 2009-10-23 15:39 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4AE1C863.3070907@gmail.com>
> Not quite :) The strcmp() function actually returns 0 when the strings
> match (I know, it looks weird "!strcmp" -> "not string compare?!"), so
Right! Now I remember it :-)
This is what happens when one looks at C code after some 10+ years of !C development ;-)
Saša Živkov
^ permalink raw reply
* Re: [git question] how to handle few projects with common parts?
From: Avery Pennarun @ 2009-10-23 16:07 UTC (permalink / raw)
To: Ivan Dimitrov; +Cc: git
In-Reply-To: <368bc75e0910230201y8e4310dme6276d436c6a6ab6@mail.gmail.com>
On Fri, Oct 23, 2009 at 5:01 AM, Ivan Dimitrov <ivand58@gmail.com> wrote:
> Maybe my question relates rather to configuration management, but it
> is over GIT.
> In short - I have to manage two projects with 95% same files
> (components) and all the rest are platform depended. I am trying to
> keep different platforms in different branches, but I can't figure out
> how keep the common part of the project synchronized?
Are the other files (1) *completely* different across branches, or (2)
the same in each branch, but customized?
If (1), I don't think branches are the answer. You probably just want
a subdir per platform and a simple config file that points at which
branch to use. Or maybe use some #ifdefs, or whatever the equivalent
is in your system.
If (2), perhaps what you want is three branches: a main development
branch, and two customized branches that you merge (or rebase) master
into. I do this sometimes when I want a "development" branch and then
some specific customizations for a particular production deployment.
(eg. a default config file and the "live" config file, and I want both
to be version controlled separately)
Have fun,
Avery
^ permalink raw reply
* Re: git bisect Vs branch
From: Daniel Barkalow @ 2009-10-23 16:31 UTC (permalink / raw)
To: Grégory Romé
Cc: Johannes Sixt, git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE17645.2000408@maxim-ic.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1260 bytes --]
On Fri, 23 Oct 2009, Grégory Romé wrote:
> Thanks even if that's what scared me :)
> The draw is very simple comparing to the reality (much more merge points) and
> rebase will require lot of conflicts resolutions but now I'm sure that's what
> I have to do.
Alternatively, you could say that your testing procedure is to merge with
your branch and check for the regression. Instead of bisecting U''-C'',
bisect U'-C', but merge master (or rather, the first parent of the merge
that started not working) before testing each commit. Pose the problem as
upstream having a regression in that it doesn't work when merged with your
code, and solve that problem with bisect.
But, before you start, verify that merging U'' and origin/master doesn't
work; if it does work, you recently introduced the change that doesn't
work with upstream, and it's probably a lot easier to find what you did
that's not okay any more than what made it not okay upstream. That is,
make C*; if it works, rebase your recent changes on it and debug that.
This should have fewer conflicts and be easier than the full rebase, if C*
actually turns out to work:
U'--o-o--C'
\ |\
U''-y-y--C''
\ |
-----C*--y-y
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Sverre Rabbelier @ 2009-10-23 18:27 UTC (permalink / raw)
To: gitzilla; +Cc: git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <4AE0E542.8010501@gmail.com>
Heya,
On Thu, Oct 22, 2009 at 18:05, A Large Angry SCM <gitzilla@gmail.com> wrote:
> Your original email included 'make && make install'; it's the "make install"
> part I'm concerned about.
Ah, no, I meant that as part of my semi-regular git update (during
which I do 'make && make install') I want to have up-to-date bash
completion, preferably installed somewhere system-wide; currently I am
forced to have a 'source
/home/sverre/code/git/contrib/completion/git-completion.bash' in my
.bashrc,..
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git bisect Vs branch
From: Junio C Hamano @ 2009-10-23 18:29 UTC (permalink / raw)
To: Grégory Romé; +Cc: git@vger.kernel.org
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>
Grégory Romé <gregory.rome@maxim-ic.com> writes:
> Thanks Santi but I have a problem, due to the fact that the commit
> which has an impact on my code is in origin/master or
> first-origin/master
>
> When bisect checkout a commit from those branch I have none of my own
> modifications... So I can' test if my code is good or bad excepted if
> I can merge my commits in the bisect branch...
> ᐁ
> first-origin/master *---A---------B----------------o------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \
> master ------------U'----------C''-
>
>
> I generalized the problem but I can give a real example. My problem
> concerns an Linux USB driver for MIPS based SoC. first-origin is the
> official kernel repository and origin/master is the MIPS repository.
So the breakage is about the feature you added on your tree, which neither
of the grandparent upstream nor your direct upstream has. U' worked, C''^1
(i.e. immediately before you merged from your direct upstream at C'')
worked, and C'' doesn't.
This happens when a commit in the upstream (either in your direct upstream
or its upstream) changed the semantics of a function (or a variable's
value) in such a way that it invalidates some assumption that your code
has been relying on.
You can restate the problem into a slightly different form:
- If I merge C' to my master (C''^1), it breaks;
- If I merge U to my master (C''^1), it works;
- Starting from (U = good, C' = bad) pair, find the first "bad" commit,
where the badness is defined as "when it is merged to C''^1, it
breaks".
The restated problem is "where in their code did they change something
that breaks my code?"
You do not have to make a merge in the repository you are bisecting in.
For example, I would try something along this line:
$ git clone . ../test-build ;# make a build directory
$ M=$(git rev-parse master^1) ;# before the latest merge
$ U=$(git merge-base $M origin/master)
$ git bisect start
$ git bisect bad origin/master
$ git bisect good $U
This will check out one commit between U and C' (that will include commits
beetween B and C, as they are reachable from C' but not from U) for you to
test. Since the condition you are testing is "Does the result of merging
a commit to $M work?", you check exactly that condition:
$ H=$(git rev-parse HEAD)
$ cd ../test-build
$ git reset --hard
$ git checkout $M
$ git merge $H
... do your testing here ...
And go back to the repository you are bisecting, and tell the result to
bisect to continue:
$ cd -
$ git bisect good ;# or bad
And do the same for the next commit to be tested.
The result will tell you which commit in the upstream changed the
semantics of what you were relying on under you, and by examining that
change, hopefully you will know how to adjust your code to the new world
order the upstream (re-)defines.
^ permalink raw reply
* Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 18:46 UTC (permalink / raw)
To: linux-newbie, kernel-janitors, git
Hi,
Just before I send my patch I got this error with:
./scripts/checkpatch.pl --terse --file
0001-Staging-comedi-driver-fix-coding-style.patch
0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
I have done a step by step explanation of what I have done:
http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
It seem to me that the whitespace are added after I do this command:
git format-patch -s -n master..mybranch
Can someone help me with that because google did help me to found the answer?
Thx
kap
^ permalink raw reply
* Re: Issue 356 in msysgit: 'git describe --always' doesn't work
From: Junio C Hamano @ 2009-10-23 18:46 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <0016367b63e60b2cdb0476969d11@google.com>
msysgit@googlecode.com writes:
> Comment #1 on issue 356 by snaury: 'git describe --always' doesn't work
> http://code.google.com/p/msysgit/issues/detail?id=356
>
> This is not msysgit fault, the same happens on Mac OS X with
> 1.6.5.1. I guess --always doesn't work anymore...
Thanks for noticing. I think it is a regression in d68dc34 (git-describe:
Die early if there are no possible descriptions, 2009-08-06)
-- >8 --
Subject: [PATCH] Do not fail "describe --always" in a tag-less repository
This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-describe.c | 2 +-
t/t6120-describe.sh | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..7542b57 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -197,7 +197,7 @@ static void describe(const char *arg, int last_one)
for_each_ref(get_name, NULL);
}
- if (!found_names)
+ if (!found_names && !always)
die("cannot describe '%s'", sha1_to_hex(sha1));
n = cmit->util;
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..f5a1b61 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -34,6 +34,8 @@ test_expect_success setup '
echo one >file && git add file && git commit -m initial &&
one=$(git rev-parse HEAD) &&
+ git describe --always HEAD &&
+
test_tick &&
echo two >file && git add file && git commit -m second &&
two=$(git rev-parse HEAD) &&
^ permalink raw reply related
* Re: requesting info page (and pdf) doc releases
From: Junio C Hamano @ 2009-10-23 18:57 UTC (permalink / raw)
To: Rustom Mody; +Cc: Sebastian Pipping, git
In-Reply-To: <f46c52560910221513w1cb19949lfa05ef964987d809@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>
>> would be nice to get info pages (and pdf) doc releases in addition to
>> html and man pages. i imagine such a change to the release machine
>> should not be too hard to integrate. we could use it in gentoo.
>
> +1
> Why only gentoo? I would use it on ubuntu or windows as well
As I understand it, Gentoo is supposed to build everything from the source
anyway, you would not want to use pregenerated info nor pdf, no? You
shouldn't be using pregenerated html nor man for that matter...
FWIW, you can already say "make info" and "make pdf" yourselves if you
have necessary toolchains installed. Integration is not an issue.
Neither my primary development box (Debian, which I would test before
pushing things out) nor the machine at k.org I use for the final sanity
check (FC11, on which the documents are automatically generated) has
dblatex nor docbook2x installed. I am not particularly enthused about
installing a lot of dependencies for these packages on my machine. I do
not want to bother k.org admins who are already overloaded to install
these on their machines either.
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 18:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <200910231034.09747.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>> > @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
>> > printf("%s\n", find_unique_abbrev(sha1, abbrev));
>> > return;
>> > }
>> > - die("cannot describe '%s'", sha1_to_hex(sha1));
>> > + if (unannotated_cnt)
>> > + die("cannot describe '%s'"
>> > + " with only\nannotated tags. Try --tags.",
>>
>> Did you mean UNannotated tags here?
>
> No, but I think I see where the misunderstanding came from.
>
> This code path means that we did not find a tag to describe with, but
> we counted some unannotated tags (and because of how the counting
> logic is wrapped, this only triggers when neither --all nor --tags are
> in effect).
I think I read the code right ;-).
> So I wanted it to say "it is impossible to describe this with the tags
> you told me to use", which in this case are the annotated ones.
The way I read it was "it is impossible to describe it in the way you told
me to, when the tags you have are only unannotated kind."
> However, it could be written e.g.
>
> No annotated tags can describe '%s'. However, there were
> unannotated tags: try --tags.
Sounds better.
^ permalink raw reply
* Re: ks/precompute-completion
From: Junio C Hamano @ 2009-10-23 18:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: gitzilla, git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <fabb9a1e0910231127i3ab469qebdc17168a58f22a@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Ah, no, I meant that as part of my semi-regular git update (during
> which I do 'make && make install') I want to have up-to-date bash
> completion, preferably installed somewhere system-wide; currently I am
> forced to have a 'source
> /home/sverre/code/git/contrib/completion/git-completion.bash' in my
> .bashrc,..
If you have enough privilege to run 'make && make install' regularly into
a system-wide place, I presume you can have a system-wide rc that sources
/home/sverre/code/git/contrib/completion/git-completion.bash, no?
I think there are two issues.
1. The series will break your rc script (either $HOME/.bashrc, or
system-side) that sources $git/contrib/completion/git-completion.bash
because it has to be built; having "make" generate it may alleviate
the issue, but "make clean" will break it again, so it is not
something you can solve in any way other than changing your setting.
2. Some people have been expecting "make install" not to install the bash
completion anywhere.
So perhaps "make && make install-contrib"?
^ permalink raw reply
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 19:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <7vd44eaqc5.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Oct 23, 2009 at 13:59, Junio C Hamano <gitster@pobox.com> wrote:
> 1. The series will break your rc script (either $HOME/.bashrc, or
> system-side) that sources $git/contrib/completion/git-completion.bash
> because it has to be built; having "make" generate it may alleviate
> the issue, but "make clean" will break it again, so it is not
> something you can solve in any way other than changing your setting.
This is my main concern, adding 'bash_completion' as a target to all:
would be ok; why would 'make clean' break it? As long as you don't add
"make -C contrib/completion clean' to the main clean target there's no
problem?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Sebastian Pipping @ 2009-10-23 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rustom Mody, git, Robin H. Johnson
In-Reply-To: <7vtyxqaqg5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Rustom Mody <rustompmody@gmail.com> writes:
>
>> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>> would be nice to get info pages (and pdf) doc releases in addition to
>>> html and man pages. i imagine such a change to the release machine
>>> should not be too hard to integrate. we could use it in gentoo.
>> +1
>> Why only gentoo? I would use it on ubuntu or windows as well
>
> As I understand it, Gentoo is supposed to build everything from the source
> anyway, you would not want to use pregenerated info nor pdf, no? You
> shouldn't be using pregenerated html nor man for that matter...
With "compiling" documentation things are a bit different.
Simplified, in contrast to source code compiling documentation leads to
the same results on all machines while sources produces lots of
different results depending on the configuration of the machine ("use
flags", compile flags, versions of linked libraries, ..) which differ
heavily from one machine to another.
Generating documentation downstream means more dependencies for us
without any advantages that I would be aware of. In case of dblatex the
dependencies get quite extreme actually :-) So we thought why not just
ask for it if you provide similar things already.
> FWIW, you can already say "make info" and "make pdf" yourselves if you
> have necessary toolchains installed. Integration is not an issue.
We use make info at the moment. (On a sidenote I hope you get it
working with the latest asciidoc again. See my earlier mail on this list.)
> Neither my primary development box (Debian, which I would test before
> pushing things out) nor the machine at k.org I use for the final sanity
> check (FC11, on which the documents are automatically generated) has
> dblatex nor docbook2x installed. I am not particularly enthused about
> installing a lot of dependencies for these packages on my machine. I do
> not want to bother k.org admins who are already overloaded to install
> these on their machines either.
I see, thanks for your explanation.
Sebastian
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Michal Nazarewicz @ 2009-10-23 19:41 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231219l600d3579i57c7580fe798d445@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
>> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>>
>>> I have done a step by step explanation of what I have done:
>>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html>>
>>> It seem to me that the whitespace are added after I do this command:
>>> git format-patch -s -n master..mybranch
> On Fri, Oct 23, 2009 at 3:13 PM, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> Do "git rebase --whitespace=fix master" and git will try to fix whitespaces.
Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
> thx Michal,
>
> But the problem remain:
If I'm not mistaken "git rebase --whitespace=fix master" should do the
trick. I'm out of good ideas if it does not. Best I can advice is to
fix the patch by hand -- just edit it in some decent editor and remove
trailing whitespaces from those lines.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Junio C Hamano @ 2009-10-23 19:52 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231146y14028f4el9753debdf334103@mail.gmail.com>
Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
> Just before I send my patch I got this error with:
> ./scripts/checkpatch.pl --terse --file
> 0001-Staging-comedi-driver-fix-coding-style.patch
>
> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>
> I have done a step by step explanation of what I have done:
> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>
> It seem to me that the whitespace are added after I do this command:
> git format-patch -s -n master..mybranch
"The whitespace are added after..." sounds to me that what you committed
were checkpatch compliant, and format-patch somehow broke it. If that is
the case we need to fix format-patch.
Please check if "git show $commit" output for the commit that corresponds
to the "[Staging] comedi driver: fix coding style" patch has trailing
whitespaces. That is what you committed.
If there already is whitespace breakage in what you committed, then we do
not have to blame format-patch and look for bugs in it to fix.
Otherwise, please send 0001-*.patch (output from format-patch) and output
from that "git show $commit" as separate attachments, so that we can debug
and fix format-patch.
Thanks.
^ permalink raw reply
* Re: ks/precompute-completion
From: Junio C Hamano @ 2009-10-23 20:05 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <fabb9a1e0910231216j2a024ac5mf5b5ccb5322722f8@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> This is my main concern, adding 'bash_completion' as a target to all:
> would be ok; why would 'make clean' break it? As long as you don't add
> "make -C contrib/completion clean' to the main clean target there's no
> problem?
"make clean" should remove it, because it is a normal build product,
if you make your "make all" build completion scripts.
The word _should_ is used in the RFC2119 sense: there may exist valid
reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing
a different course.
^ permalink raw reply
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 20:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <7v1vktc1uk.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Oct 23, 2009 at 15:05, Junio C Hamano <gitster@pobox.com> wrote:
> "make clean" should remove it, because it is a normal build product,
> if you make your "make all" build completion scripts.
Hmm, I guess that's fair enough, if you 'make clean' you want all
build products to be removed; this problem would be solved by
installing the completion script in the share dir, that way it doens't
matter if 'make clean' removes the one in ~/code/git, as long as the
one in ~/share/git-completion remains.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [cvsimport] Import CVS repository from a specified date or branch name
From: Andreas Schwab @ 2009-10-23 20:10 UTC (permalink / raw)
To: Klaus Rödel; +Cc: git
In-Reply-To: <4AE160BC.5000608@vipco.de>
Klaus Rödel <klaus.roedel@vipco.de> writes:
> I have a very large and old (serveral years) cvs repository and I want to
> import this in git.
> For my work it is not nessecary to import all the revision history from
> the cvs repository.
> It is engough to import only the revisions from a specified date or branch
> name of the cvs repo.
>
> Is this possible with git-cvsimport?
> If yes, how?
You may be able to do that by passing the right arguments to cvsps.
From cvsps --help:
-d <date1> -d <date2> if just one date specified, show
revisions newer than date1. If two dates specified,
show revisions between two dates.
-b <branch> restrict output to patch sets affecting history of branch
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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