* 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: 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: [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: 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: 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: 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
* 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: 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
* [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: 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
* [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: [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
* Re: requesting info page (and pdf) doc releases
From: Michael J Gruber @ 2009-10-23 8:39 UTC (permalink / raw)
To: Rustom Mody; +Cc: Sebastian Pipping, git
In-Reply-To: <f46c52560910221513w1cb19949lfa05ef964987d809@mail.gmail.com>
Rustom Mody venit, vidit, dixit 23.10.2009 00:13:
> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>
>> hi there!
>>
>>
>> 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.
>>
>> thanks,
>>
>>
>>
>> sebastian
>
> +1
> Why only gentoo? I would use it on ubuntu or windows as well
Because they don't build from source!? ;)
Michael
^ permalink raw reply
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
...OK, finally found it: Dscho did just that in f0298cf (revision
walker: include a detached HEAD in --all, 2009-01-16) which is in
v1.6.1.3 and later.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-23 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, git
In-Reply-To: <7vljj3dkid.fsf@alter.siamese.dyndns.org>
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).
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.
I tried to keep the general structure of the message ("cannot describe
..."), and with this restriction I can't seem to find a clearer
wording. However, it could be written e.g.
No annotated tags can describe '%s'. However, there were
unannotated tags: try --tags.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git bisect Vs branch
From: Johannes Sixt @ 2009-10-23 8:34 UTC (permalink / raw)
To: Grégory Romé; +Cc: git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>
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
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
Commit 77abcbd (Let --decorate show HEAD position, 2009-10-12) goes a
little bit in that direction, adding HEAD to the "labels" that
--decorate may use, but not to the list of refs specified by "--all". But:
Well, after playing around a bit: git rev-list --all does list my
detached HEAD, git log --all shows it (which is the same statement, of
course), whether I use --decorate or not. Are you seeing different
behaviour?
git describe --all HEAD does not describe the detached HEAD (other than
v1.6.5-87-g4584daf in my case), which may or may not be desirable
(because describe outputs at most one description, unlike --decorate).
Michael
^ permalink raw reply
* [cvsimport] Import CVS repository from a specified date or branch name
From: Klaus Rödel @ 2009-10-23 7:52 UTC (permalink / raw)
To: git
Hello,
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?
If no, is it possible to include such a function in the git-cvsimport
script?
Thanks for any help.
Greets Klaus
^ permalink raw reply
* Re: git bisect Vs branch
From: Grégory Romé @ 2009-10-23 7:09 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com>
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.
Cheers!
Grégory
Santi Béjar wrote:
> On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
>> Considering the following story what is the method to find the regression
>> with bisect?
>>
>> I cloned a git repository (origin) which derives from another one
>> (first-origin). A merge is done from first-origin to origin at each stable
>> release (identified by a tag).
>>
>> first-origin/master *---A---------B-----------------------C-
>> \ \ \
>> origin/master ----------B'----------U-----------C'-
>> \ \ \ master
>> ------------U'----------C''-
>>
>> Now, after that I merged C' I fixed the conflicts and compiled without error
>> but I have a regression. It could come from any commit between B and C or U
>> and C', and I need to modify my code to correct the issue.
>>
>> I would like to find the commit which introduce this regression by using git
>> bisect but as the history is not linear it is not so easy (1). It though to
>> create a linear history but I have no idea how to proceed...
>
> You just have to proceed as normal, but you may test more commits than
> with a linear history.
>
> The only problem is iff the culprit is a merge commit (as in the
> user-manual chapter you linked). And the "problem" is to know where
> exactly in the (merge) commit is the bug, but not the procedure.
>
> HTH,
> Santi
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023060751.GA14477@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
> > From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> > From: Adam Brewster <adambrewster@gmail.com>
> > Date: Thu, 22 Oct 2009 21:26:32 -0700
> > Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
>
> Actually, no, something is broken here it seems... Ugh, falling asleep :x
Oops, I was running the tests from the wrong machine that didn't have
the patch on that one.
As noted in my previous email, the leading slashes cause
SVN::Ra::get_log to fail with an assertion if the path passed to it
has a leading slash but is not a standalone slash.
Here's my original patch which seems to work fine (but doesn't allow the
more flexible, bare "*" in "branches = *:refs/remotes/*" Adam's one did.
>From 42079a567bef745996b6272ad546d682dfcf57d6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 22 Oct 2009 23:39:04 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Thanks to Daniel Cordero for the original bug report and
bisection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..56af221 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1765,7 +1765,7 @@ sub read_all_remotes {
my $use_svm_props = eval { command_oneline(qw/config --bool
svn.useSvmProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
- my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
+ my $svn_refspec = qr{\s*(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
@@ -1979,7 +1979,7 @@ sub find_ref {
my ($ref_id) = @_;
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
- \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
+ \s*(.*?)\s*:\s*(.+?)\s*$!x;
my ($repo_id, $path, $ref) = ($1, $2, $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
--
Eric Wong
^ permalink raw reply related
* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-23 6:38 UTC (permalink / raw)
To: Adam Brewster; +Cc: Daniel Cordero, git
In-Reply-To: <c376da900910220824g2948dc2sa1156bda59b49405@mail.gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> > I'm not sure why Adam decided the leading slash needed to be removed for
> > the git refspec. That said, the globbing/branching code still makes me
> > want to hide under a rock and I'm generally afraid to touch it.
> > I'll wait for Adam to chime in since he's braver than I am :)
> >
> How's this for brave: I'm not sure why I did that either.
>
> Looking at it again it seems correct for the leading / to be ignored because
> it has no meaning. What's the difference between the above config and
> "branches = *:refs/remotes/*" (besides the fact that one works and one
> doesn't)? In both cases I think I've asked for all of the top-level
> directories to be branches. But that has nothing to do with the rest of the
> patch, so it shouldn't have been included.
<snip>
> That is, continue disregard the / on the actual input because it means
> nothing, and add a / in places where the code will crash if it's not there.
> Even better would be to find out _why_ $path and $local_ref need a leading /
> and fix it that way, but that's more work that I don't have time for right
> now.
Actually, SVN 1.5+ does not like the leading "/" and trips on an
assertion failure on all cases except a standalone "/". That is, "/*"
continues to work since we send "/" to SVN::Ra::get_log().
--
Eric Wong
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Junio C Hamano @ 2009-10-23 6:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Howard Miller, Jakub Narebski, git
In-Reply-To: <4AE143BC.7040507@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The easiest way (IMHO) to achieve this is certainly:
>
> # start a new branch at the tip of the series
> $ git checkout -b all-in-one the-series
>
> # squash 17 commits
> $ git reset --soft HEAD~17
> $ git commit
>
> Now you have a new branch 'all-in-one' that has the same contents as the
> original series 'the-series', but with only one commit:
>
> $ git diff the-series..all-in-one # must show no differences
I think --squash "*merge*" is conceptually simpler to explain *and*
has an added advantage that it helps preparing the consolidated log
message.
# start from the last customer dump
$ git checkout -b customer-update last-release
# give the customer the greatness in the series, content-wise
$ git merge --squash the-series
$ git commit
This will start the "customer-update" branch starting from the
last dump you gave to the customer, merge in the changes made
in the series without history, and when you make a commit, you
will have access to all the individual log messages in the
series to look at as reference, so that you can cut and paste
from them to summarized message instead of typing everything anew.
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023044843.GA16169@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> From: Adam Brewster <adambrewster@gmail.com>
> Date: Thu, 22 Oct 2009 21:26:32 -0700
> Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
Actually, no, something is broken here it seems... Ugh, falling asleep :x
--
Eric Wong
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Junio C Hamano @ 2009-10-23 5:58 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, git
In-Reply-To: <76c5b8580910221930s4b31b180t8298c262d9d9f421@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I was looking for this info in order to create second tag for the same
> commit. For example if the first tag created by somebody or
> automatically (CI, release system), so i could add a verbose tag.
>
> But i just realized that i don't need commit id for that - just tag
> the tag, stupid...
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}".
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Johannes Sixt @ 2009-10-23 5:48 UTC (permalink / raw)
To: Howard Miller; +Cc: Jakub Narebski, git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
Howard Miller schrieb:
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
The easiest way (IMHO) to achieve this is certainly:
# start a new branch at the tip of the series
$ git checkout -b all-in-one the-series
# squash 17 commits
$ git reset --soft HEAD~17
$ git commit
Now you have a new branch 'all-in-one' that has the same contents as the
original series 'the-series', but with only one commit:
$ git diff the-series..all-in-one # must show no differences
-- Hannes
^ 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