* Re: Hello All and Seeking Information
From: Bruce Stephens @ 2008-11-24 16:35 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
[...]
> However, there are some issues that I can't wrap my head around,
> such as how you can guarantee that all developers are working on the
> same code-base without a central repo.
You can't. That's the point.
If developers wish to use a central repository and always to work
based on that, then they can. But the tool doesn't enforce that.
<http://koweycode.blogspot.com/2008/11/iterative-commiting.html>
describes a common (IME) benefit.
[...]
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Christian MICHON @ 2008-11-24 16:39 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
On Mon, Nov 24, 2008 at 5:28 PM, Tim Visher <tim.visher@gmail.com> wrote:
> Hello Everyone,
>
> I'm new to the list so I figured I'd introduce myself instead of just
> wall-flowering... "Hello"... :)
>
> Anyway, I really like a lot of the concepts found in Git and the
> reported power and flexibility of it are very intriguing. However,
> there are some issues that I can't wrap my head around, such as how
> you can guarantee that all developers are working on the same
> code-base without a central repo. I would classify a lot of my issues
> as paradigm rather than technically related. I understand a lot of
> Git's underpinnings and the basic usage of it, I just can't wrap my
> head around the higher-order parts of it.
>
> I've done some Googling and I can't find a good 'Introduction to
> Distributed SCM Concepts for Centralized SCM Developers' article yet.
> Ideally, this would be an article all about the high-level thought
> processes that go into utilizing Distributed SCM in a team environment
> where having a single canonical representation of your project that
> all developers are working off of is important.
>
http://git.or.cz/gitwiki/LinusTalk200705Transcript
but the video is obviously more fun
http://www.youtube.com/watch?v=4XpnKHJAok8
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: git-svn and svnsync
From: Michael J Gruber @ 2008-11-24 17:15 UTC (permalink / raw)
To: Andriy Gapon; +Cc: git
In-Reply-To: <492AA464.5070404@icyb.net.ua>
Andriy Gapon venit, vidit, dixit 24.11.2008 13:56:
> on 16/10/2008 11:07 Andriy Gapon said the following:
>> I did the following:
>> 1. mirror svn repository using svnsync
>> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
>> 3. run git svn info in the clone
>> 4. get error "Unable to determine upstream SVN information from working
>> tree history"
>>
>> git svn log and git svn rebase do not work either.
>> git log does work.
>>
>> I have git version 1.6.0.2 (from FreeBSD ports).
>> [*] About the tweaking - I manually massaged config file to get the
>> branches I was interested in, so .git/config is this:
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [svn-remote "svn"]
>> useSvnsyncProps = 1
>> url = file:///system/devel/svn/base
>> fetch = head:refs/remotes/trunk
>> fetch = stable/6:refs/remotes/stable_6
>> fetch = stable/7:refs/remotes/stable_7
>> fetch = releng/6.3:refs/remotes/releng_6_3
>> fetch = releng/6.4:refs/remotes/releng_6_4
>> fetch = releng/7.0:refs/remotes/releng_7_0
>> fetch = release/6.3.0:refs/remotes/release_6_3_0
>> fetch = release/7.0.0:refs/remotes/release_7_0_0
>>
>> This is .git/svn/.metadata:
>> ; This file is used internally by git-svn
>> ; You should not have to edit it
>> [svn-remote "svn"]
>> reposRoot = file:///system/devel/svn/base
>> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> svnsync-url = svn://svn.freebsd.org/base
>>
>> So you can see the original svn repository URL.
>>
>> git log reports svn info like the following:
>> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>
>> It seems that the problem is that the code in find_by_url() and/or
>> read_all_remotes() subroutines (in git-svn.perl) are not aware of
>> svnsync and do not realize an URL in logs and URL in svn-remote are
>> different.
>> BTW, I see that there is some special svm logic in read_all_remotes.
>>
>> Thank you very much for any help in advance.
>>
>
> Anyone?
> I wonder if this is my local problem/misconfiguration or an issue with
> git-svn.
Same happens here, so it's a general issue ;)
I think I encountered that before and ended up experimenting with
git-svn cloning from a svnsync source until I found the final config,
with which I git-svn cloned directly from upstream, so that I had to
wait only twice.
Michael
^ permalink raw reply
* Re: Not-quite-a-bug in pickaxe
From: Johannes Schindelin @ 2008-11-24 17:36 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: git, gitster
In-Reply-To: <237967ef0811240708t58d48c84ud0626ba3aaed47b6@mail.gmail.com>
Hi,
On Mon, 24 Nov 2008, Mikael Magnusson wrote:
> 2008/11/24 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > I do not know if I hit that behavior before,
>
> I'm pretty sure it has,
> http://thread.gmane.org/gmane.comp.version-control.git/100113/focus=100115
> (at least i think that's the same case?)
Ah, I finally got around to read Junio's reply. It did not stick back
then.
Thanks,
Dscho
^ permalink raw reply
* Re: git-svn and svnsync
From: Andriy Gapon @ 2008-11-24 17:33 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <492AE13D.5070102@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]
on 24/11/2008 19:15 Michael J Gruber said the following:
> Andriy Gapon venit, vidit, dixit 24.11.2008 13:56:
>> on 16/10/2008 11:07 Andriy Gapon said the following:
>>> I did the following:
>>> 1. mirror svn repository using svnsync
>>> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
>>> 3. run git svn info in the clone
>>> 4. get error "Unable to determine upstream SVN information from working
>>> tree history"
>>>
>>> git svn log and git svn rebase do not work either.
>>> git log does work.
>>>
>>> I have git version 1.6.0.2 (from FreeBSD ports).
>>> [*] About the tweaking - I manually massaged config file to get the
>>> branches I was interested in, so .git/config is this:
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> [svn-remote "svn"]
>>> useSvnsyncProps = 1
>>> url = file:///system/devel/svn/base
>>> fetch = head:refs/remotes/trunk
>>> fetch = stable/6:refs/remotes/stable_6
>>> fetch = stable/7:refs/remotes/stable_7
>>> fetch = releng/6.3:refs/remotes/releng_6_3
>>> fetch = releng/6.4:refs/remotes/releng_6_4
>>> fetch = releng/7.0:refs/remotes/releng_7_0
>>> fetch = release/6.3.0:refs/remotes/release_6_3_0
>>> fetch = release/7.0.0:refs/remotes/release_7_0_0
>>>
>>> This is .git/svn/.metadata:
>>> ; This file is used internally by git-svn
>>> ; You should not have to edit it
>>> [svn-remote "svn"]
>>> reposRoot = file:///system/devel/svn/base
>>> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>> svnsync-url = svn://svn.freebsd.org/base
>>>
>>> So you can see the original svn repository URL.
>>>
>>> git log reports svn info like the following:
>>> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>>
>>> It seems that the problem is that the code in find_by_url() and/or
>>> read_all_remotes() subroutines (in git-svn.perl) are not aware of
>>> svnsync and do not realize an URL in logs and URL in svn-remote are
>>> different.
>>> BTW, I see that there is some special svm logic in read_all_remotes.
>>>
>>> Thank you very much for any help in advance.
>>>
>> Anyone?
>> I wonder if this is my local problem/misconfiguration or an issue with
>> git-svn.
>
> Same happens here, so it's a general issue ;)
>
> I think I encountered that before and ended up experimenting with
> git-svn cloning from a svnsync source until I found the final config,
> with which I git-svn cloned directly from upstream, so that I had to
> wait only twice.
I hacked together an ugly patch that replaces svm support with snvsync
support. This works for me, not sure if it will be useful in general.
--
Andriy Gapon
[-- Attachment #2: git-svn.patch --]
[-- Type: text/plain, Size: 1113 bytes --]
--- git-svn 2008-11-11 10:20:38.714620442 +0200
+++ git-svn 2008-11-07 17:10:49.245681213 +0200
@@ -1433,7 +1433,7 @@
sub read_all_remotes {
my $r = {};
my $use_svm_props = eval { command_oneline(qw/config --bool
- svn.useSvmProps/) };
+ svn.useSvnsyncProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=\s*(.*)\s*:\s*(.+)\s*$!) {
@@ -1445,7 +1445,7 @@
$local_ref =~ s{^/}{};
$r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
$r->{$remote}->{svm} = {} if $use_svm_props;
- } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
+ } elsif (m!^(.+)\.usesvnsyncprops=\s*(.*)\s*$!) {
$r->{$1}->{svm} = {};
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
@@ -1471,9 +1471,8 @@
my $section = "svn-remote.$_";
$svm = {
source => tmp_config('--get',
- "$section.svm-source"),
- replace => tmp_config('--get',
- "$section.svm-replace"),
+ "$section.svnsync-url"),
+ replace => '',
}
};
$r->{$_}->{svm} = $svm;
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Jakub Narebski @ 2008-11-24 18:22 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> Hello Everyone,
>
> I'm new to the list so I figured I'd introduce myself instead of just
> wall-flowering... "Hello"... :)
>
> Anyway, I really like a lot of the concepts found in Git and the
> reported power and flexibility of it are very intriguing. However,
> there are some issues that I can't wrap my head around, such as how
> you can guarantee that all developers are working on the same
> code-base without a central repo. I would classify a lot of my issues
> as paradigm rather than technically related. I understand a lot of
> Git's underpinnings and the basic usage of it, I just can't wrap my
> head around the higher-order parts of it.
The idea behind Git repository format is content adressed filesystem,
which if I remember correctly was taken from Monotone (well, not
addressed by actual content, but SHA-1 cryptographic hash of
content+type). So if there is 134b8687c59e65ce06562ffb0e8be63ab7aa618b
object in some repository, it is the same object in all repositories,
even if it was created independently. That is one thing.
The other thing is that typical workflow calls for downloading changes
(fetching in git jargon) from some 'upstream' repository, the official
repository (one of official repositories) with code you are supposed
to base your changes upon.
Also easy to create branches, and very good support for merging (and
rebasing) makes it possible and easy to join (merge) lines of
development done independently from some older point of history. So
that even if you are not working on the same code-base I can
incorporate your changes, and you can incorporate mine.
>
> I've done some Googling and I can't find a good 'Introduction to
> Distributed SCM Concepts for Centralized SCM Developers' article yet.
> Ideally, this would be an article all about the high-level thought
> processes that go into utilizing Distributed SCM in a team environment
> where having a single canonical representation of your project that
> all developers are working off of is important.
See http://git.or.cz/gitwiki/GitDocumentation (and also main page of
this git wiki, Documentation mentioned on git homepage
(http://git.or.cz) including "Git User's Manual", and "The Git
Community Book" at http://book.git-scm.com
> P.S. Anyone want to tell me why the Git Mailing List was set-up
> monolithically rather than the typical git-dev, git-user, git-admin,
> git-x etc.? I don't plan on hacking on Git so having the Dev mail in
> the list is just noise for me. I'm sure other people think that too.
> Just wondering.
Because this Git is not so large project, and traffic on git mailing
list is not so large to support split? IIRC there was "Git for Human
Beings" aka git-users Google Group, but it doesn't seem to be there
any more. Also having common mailing list allow for better contact
between developers and git users (which hopefully would allow us to
avoid comon pitfalls with 'developers for developers' approach).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] config.txt: alphabetize configuration variable groups
From: Matt McCutchen @ 2008-11-24 20:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <492A579B.5000304@viscovery.net>
On Mon, 2008-11-24 at 08:28 +0100, Johannes Sixt wrote:
> Matt McCutchen schrieb:
> > @@ -963,6 +953,8 @@ man.<tool>.path::
> > Override the path for the given tool that may be used to
> > display help in the 'man' format. See linkgit:git-help[1].
> >
> > +include::merge-config.txt[]
> > +
> > merge.conflictstyle::
> > Specify the style in which conflicted hunks are written out to
> > working tree files upon merge. The default is "merge", which
>
> Here, the list is not in alphabetic order anymore.
After my change, the list is in alphabetical order by the first
component (before the first dot). I assume you're pointing out that I
haven't separated the merge.<driver> parameters from the non-<driver>
merge parameters.
The reason I left it that way was I thought there might be some reason
why merge.conflictstyle is in config.txt rather than merge-config.txt
(the difference being that it appears in "man git-config" but not
"man git-merge"), and to keep that arrangement while grouping together
the non-<driver> merge parameters, I would have to split
merge-config.txt into two separately included files.
I went back and looked at the commit (b5412484) that documented
merge.conflictstyle, and it appears that the placement in config.txt may
have been a mistake arising from the unsortedness of config.txt rather
than a conscious decision. Thus, I'll move that entry to
merge-config.txt for the better grouping. That does mean "man
git-merge" will contain two explanations of merge.conflictstyle (the
brief config-parameter one and the "HOW CONFLICTS ARE PRESENTED"
section), but I don't see that as a big problem.
> BTW, your commit message should emphasize the use-cases where an
> alphabetic order is a real benefit. Otherwise, this is just code churn.
I don't see alphabetization as a major benefit except that it might help
people add new parameters in the right place (case in point: the
addition of merge.conflictstyle). And I figured that the config
parameters might as well be in /some/ order. I'll state that in the
commit message.
Updated patch to follow.
Matt
^ permalink raw reply
* [PATCH 2/9 v5] bisect: add test cases for "git bisect replace"
From: Christian Couder @ 2008-11-24 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6035-bisect-replace.sh | 130 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 130 insertions(+), 0 deletions(-)
create mode 100755 t/t6035-bisect-replace.sh
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
new file mode 100755
index 0000000..6ab3667
--- /dev/null
+++ b/t/t6035-bisect-replace.sh
@@ -0,0 +1,130 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Couder
+#
+test_description='Test git bisect replace functionality'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+add_and_commit_file()
+{
+ _file="$1"
+ _msg="$2"
+
+ git add $_file || return $?
+ test_tick || return $?
+ git commit --quiet -m "$_file: $_msg"
+}
+
+HASH1=
+HASH2=
+HASH3=
+HASH4=
+HASH5=
+HASH6=
+HASH7=
+
+test_expect_success 'set up buggy branch' '
+ echo "line 1" >> hello &&
+ echo "line 2" >> hello &&
+ echo "line 3" >> hello &&
+ echo "line 4" >> hello &&
+ add_and_commit_file hello "4 lines" &&
+ HASH1=$(git rev-parse --verify HEAD) &&
+ echo "line BUG" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with a BUG" &&
+ HASH2=$(git rev-parse --verify HEAD) &&
+ echo "line 9" >> hello &&
+ echo "line 10" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH3=$(git rev-parse --verify HEAD) &&
+ echo "line 11" >> hello &&
+ add_and_commit_file hello "1 more line" &&
+ HASH4=$(git rev-parse --verify HEAD) &&
+ sed -e "s/BUG/5/" hello > hello.new &&
+ mv hello.new hello &&
+ add_and_commit_file hello "BUG fixed" &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ echo "line 12" >> hello &&
+ echo "line 13" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH6=$(git rev-parse --verify HEAD)
+ echo "line 14" >> hello &&
+ echo "line 15" >> hello &&
+ echo "line 16" >> hello &&
+ add_and_commit_file hello "again 3 more lines" &&
+ HASH7=$(git rev-parse --verify HEAD)
+'
+
+HASHFIX2=
+HASHFIX3=
+HASHFIX4=
+
+test_expect_success 'set up fixed branch' '
+ git checkout $HASH1 &&
+ echo "line 5" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with no BUG" &&
+ HASHFIX2=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH3 &&
+ HASHFIX3=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH4 &&
+ HASHFIX4=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success '"git bisect replace" buggy branch with fixed one' '
+ git bisect replace $HASH5 HEAD
+'
+
+test_expect_success 'replace works when bisecting with a later bad commit' '
+ git rev-list --bisect-all $HASH7 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'replace works starting just after replaced commit' '
+ git rev-list --bisect-all $HASH6 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'replace works starting from replaced commit' '
+ git rev-list --bisect-all $HASH5 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'standard bisect works' '
+ git bisect start $HASH6 $HASH1 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX3" &&
+ git bisect good &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH5" &&
+ git bisect bad &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX4" &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASHFIX4 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+#
+#
+test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH 3/9 v5] Documentation: add "git bisect replace" documentation
From: Christian Couder @ 2008-11-24 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 61 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 39034ec..be7518c 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -24,6 +24,7 @@ on the subcommand:
git bisect visualize
git bisect replay <logfile>
git bisect log
+ git bisect replace <rev> [<rev>]
git bisect run <cmd>...
This command uses 'git rev-list --bisect' to help drive the
@@ -186,6 +187,66 @@ $ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc4 and v2.6.20-rc1 are good
------------
+Bisect replace
+~~~~~~~~~~~~~~
+
+This subcommand should be used when you have a branch or a part of a
+branch that isn't easily bisectable because of a bug that has been
+fixed latter.
+
+We suppose that a bug as been introduced at some point, say A, and
+that it has been fixed latter at another point, say B, but that
+between these points the code is not easily testable because of the
+bug, so it's not easy to bisect between these points.
+
+In this case you can create a branch starting at the parent of A, say
+O, that has a fixed history. In this fixed history for example, there
+could be first a commit C that is the result of squashing A and B
+together and then all the commits between A and B that have been cherry
+picked.
+
+For example, let's say the commits between A and B are X1, X2, ... Xn
+and they have been cherry picked after C as Y1, Y2, ... Yn:
+
+------------
+ C--Y1--Y2--...--Yn
+ /
+...--O--A--X1--X2--...--Xn--B--...
+------------
+
+By design, the last cherry picked commit (Yn) should point to the same
+tree as commit B.
+
+So in this case you can say:
+
+------------
+$ git bisect replace B Yn
+------------
+
+and a special ref will be created that points to commit Yn. This ref
+will be named: "refs/replace/bisect/B"
+
+When bisecting, the refs in "refs/replace/bisect/" will be scanned and
+each ref named X found there and pointing to commit Y will be grafted
+so that X will only have Y as parent.
+
+In the example above, that means that instead of the above graph, the
+following graph will be bisected:
+
+------------
+ C--Y1--Y2--...--Yn
+ / \
+...--O B--...
+------------
+
+This means that the bisections on this branch may be much easier
+because the bug introduced by commit A and fixed by commit B will not
+annoy you anymore.
+
+As the refs created by "git bisect replace" can be shared between
+developers, this feature might be especially usefull on big projects
+where many people often bisect the same code base.
+
Bisect run
~~~~~~~~~~
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH 7/9 v5] bisect: use "--bisect-replace" options when checking merge bases
From: Christian Couder @ 2008-11-24 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 4 ++--
t/t6035-bisect-replace.sh | 10 ++++++++++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index ed7c620..c8d5905 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -401,7 +401,7 @@ check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
- for _mb in $(git merge-base --all $_bad $_good)
+ for _mb in $(git merge-base --all --bisect-replace $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
@@ -436,7 +436,7 @@ check_good_are_ancestors_of_bad() {
# Bisecting with no good rev is ok
test -z "$_good" && return
- _side=$(git rev-list $_good ^$_bad)
+ _side=$(git rev-list --bisect-replace $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index 8fe7cc5..dabf1ae 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -144,6 +144,16 @@ test_expect_success '"git merge-base --bisect-replace" works' '
test "$hash" = "$HASH1"
'
+test_expect_success 'git bisect works when starting on the replace branch' '
+ git bisect start $HASH7 $HASHFIX3 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH5" &&
+ git bisect bad &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX4" &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH 8/9 v5] rev-list: make it possible to disable replacing using "--no-bisect-replace"
From: Christian Couder @ 2008-11-24 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 1 +
Documentation/rev-list-options.txt | 10 ++++++++++
builtin-rev-list.c | 20 ++++++++++++++++----
t/t6035-bisect-replace.sh | 10 ++++++++++
4 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4cc8abf..b466da3 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -42,6 +42,7 @@ SYNOPSIS
[ \--bisect-vars ]
[ \--bisect-all ]
[ \--bisect-replace ]
+ [ \--no-bisect-replace ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b35f9d8..9abdaee 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -589,6 +589,16 @@ default when they perform their bisection calculations. With the
"--bisect-replace" option, you can see what is the result of using the
"refs/replace/bisect/*" refs without the effects of other bisection
calculations.
+
+--no-bisect-replace::
+
+With this option, 'rev-list' will not make use of the
+"refs/replace/bisect/*" refs, even if another `--bisect*` option is
+used.
+
+By default, if any `--bisect*` option is used, 'rev-list' will graft
+commits given by "refs/replace/bisect/*" refs into other branches when
+bisecting, so that bisection can be performed on a fixed up history.
endif::git-rev-list[]
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 1b18c65..e8febd0 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -48,13 +48,20 @@ static const char rev_list_usage[] =
" --bisect\n"
" --bisect-vars\n"
" --bisect-all\n"
-" --bisect-replace"
+" --bisect-replace\n"
+" --no-bisect-replace"
;
static struct rev_info revs;
+enum {
+ REPLACE_UNSET,
+ REPLACE_DEFAULT,
+ REPLACE_SET
+};
+
static int bisect_list;
-static int bisect_replace_only;
+static int bisect_force_replace = REPLACE_DEFAULT;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
@@ -684,7 +691,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--bisect-replace")) {
- bisect_replace_only = 1;
+ bisect_force_replace = REPLACE_SET;
+ continue;
+ }
+ if (!strcmp(arg, "--no-bisect-replace")) {
+ bisect_force_replace = REPLACE_UNSET;
continue;
}
if (!strcmp(arg, "--stdin")) {
@@ -719,7 +730,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list || bisect_replace_only)
+ if (bisect_force_replace != REPLACE_UNSET &&
+ (bisect_list || bisect_force_replace == REPLACE_SET))
bisect_replace_all();
if (bisect_list)
revs.limited = 1;
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index dabf1ae..f22a2e5 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -154,6 +154,16 @@ test_expect_success 'git bisect works when starting on the replace branch' '
git bisect reset
'
+test_expect_success '"git rev-list --no-bisect-replace" works' '
+ git rev-list --bisect-all --no-bisect-replace $HASH6 > rev_list.txt &&
+ test_must_fail grep $HASHFIX2 rev_list.txt &&
+ test_must_fail grep $HASHFIX3 rev_list.txt &&
+ test_must_fail grep $HASHFIX4 rev_list.txt &&
+ grep $HASH2 rev_list.txt &&
+ grep $HASH3 rev_list.txt &&
+ grep $HASH4 rev_list.txt
+'
+
#
#
test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH 9/9 v5] bisect: add "--no-replace" option to bisect without using replace refs
From: Christian Couder @ 2008-11-24 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 6 +++++-
git-bisect.sh | 26 ++++++++++++++++++++------
t/t6035-bisect-replace.sh | 10 ++++++++++
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index be7518c..8d892bb 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -16,7 +16,7 @@ The command takes various subcommands, and different options depending
on the subcommand:
git bisect help
- git bisect start [<bad> [<good>...]] [--] [<paths>...]
+ git bisect start [--no-replace] [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [<rev>...]
@@ -247,6 +247,10 @@ As the refs created by "git bisect replace" can be shared between
developers, this feature might be especially usefull on big projects
where many people often bisect the same code base.
+If you give the `--no-replace` to "git bisect start", then the
+"refs/replace/bisect/*" refs will not be used for the bisection you
+start.
+
Bisect run
~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index c8d5905..7d09bb0 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -3,7 +3,7 @@
USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|replace|run]'
LONG_USAGE='git bisect help
print this long help message.
-git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
+git bisect start [--no-replace] [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
mark <rev> a known-bad revision.
@@ -119,6 +119,10 @@ bisect_start() {
shift
break
;;
+ --no-replace)
+ shift
+ touch "$GIT_DIR/BISECT_NO_REPLACE"
+ ;;
*)
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
test $has_double_dash -eq 1 &&
@@ -386,6 +390,16 @@ We continue anyway.
EOF
}
+replace_option() {
+ test -f "$GIT_DIR/BISECT_NO_REPLACE" ||
+ echo "--bisect-replace"
+}
+
+no_replace_option() {
+ test ! -f "$GIT_DIR/BISECT_NO_REPLACE" ||
+ echo "--no-bisect-replace"
+}
+
#
# "check_merge_bases" checks that merge bases are not "bad".
#
@@ -401,7 +415,7 @@ check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
- for _mb in $(git merge-base --all --bisect-replace $_bad $_good)
+ for _mb in $(git merge-base --all $(replace_option) $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
@@ -436,7 +450,7 @@ check_good_are_ancestors_of_bad() {
# Bisecting with no good rev is ok
test -z "$_good" && return
- _side=$(git rev-list --bisect-replace $_good ^$_bad)
+ _side=$(git rev-list $(replace_option) $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
@@ -465,9 +479,8 @@ bisect_next() {
test "$?" -eq "1" && return
# Get bisection information
- BISECT_OPT=''
- test -n "$skip" && BISECT_OPT='--bisect-all'
- eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
+ BISECT_OPTS="$(no_replace_option) --bisect-vars ${skip:+--bisect-all}"
+ eval="git rev-list $BISECT_OPTS $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
eval "$eval" || exit
@@ -534,6 +547,7 @@ bisect_clean_state() {
do
git update-ref -d $ref $hash || exit
done
+ rm -f "$GIT_DIR/BISECT_NO_REPLACE" &&
rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index f22a2e5..b9cc739 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -164,6 +164,16 @@ test_expect_success '"git rev-list --no-bisect-replace" works' '
grep $HASH4 rev_list.txt
'
+test_expect_success 'git bisect works with --no-replace' '
+ git bisect start --no-replace $HASH5 $HASH1 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH3" &&
+ git bisect good &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH4" &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH4 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-24 21:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <7vy6zl7drn.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 14, 2008 at 09:35:08PM -0800, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
>
> > This option stops git mergetool from aborting at the first failed merge.
> > This allows some additional use patterns. Merge conflicts can now be
> > previewed one at time and merges can also be skipped so that they can be
> > performed in a later pass.
>
> Hmm, with this command line:
>
> > -'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]...
>
> I wonder why this even needs to be an option. If you do not want to
> resolve all of them, you can limit the amount of work you would do by
> giving list of paths to work on, can't you?
>
I have to say that since having this in my tree I've benefitted hugely
from using a visual diff tool as a merge preview tool. I'm working on
a (far from ideal) project where two branches are diverging fast due
to differing goals, yet there is a need for an end product with the
functionality of both branches in it.
This means that I often end up needing to do frequent large merges.
Often it is not until I have the merge open in front of me that it
becomes obvious that while a particular file needs merging, the best
merge strategy will only be obvious after resolving the conflicts in
other parts of the system.
Often several hours of work will just be four or five invocations of
git mergetool until something which compiles emerges. Stopping to view
what the next unmerged file path is and pasting it into another
mergetool command line seems like an unnecessary distraction.
Charles.
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-24 22:03 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson, William Pursell
In-Reply-To: <20081115155603.GD22948@mit.edu>
On Sat, Nov 15, 2008 at 10:56:03AM -0500, Theodore Tso wrote:
> Instead of making this be a command-line and configuration option,
> maybe it would be better to prompt the user after an aborted merge,
> and give the user the opportunity to continue or abort? i.e., instead
> of just saying "merge of foo.c failed" and then exiting, to ask the
> user instad something like, "Merge of foo.c failed; continue
> attempting to merge the rest of the files? <y>"
>
> I suspect this might be more friendly than Yet Another command-line
> option and configuration parameter. What do you think?
>
> - Ted
This sounds like a really good alternative interface option. The next
time I have a moment (could be a while!) I'll try and make a patch
based on this idea.
Charles.
^ permalink raw reply
* [PATCH 4/9 v5] rev-list: add "--bisect-replace" to list revisions with fixed up history
From: Christian Couder @ 2008-11-24 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
This should help both human and scripts deal better with
"refs/replace/bisect/*" refs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 1 +
Documentation/rev-list-options.txt | 15 +++++++++++++++
builtin-rev-list.c | 12 +++++++++---
t/t6035-bisect-replace.sh | 12 ++++++++++++
4 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 1c9cc28..4cc8abf 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -41,6 +41,7 @@ SYNOPSIS
[ \--bisect ]
[ \--bisect-vars ]
[ \--bisect-all ]
+ [ \--bisect-replace ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b9f6e4d..b35f9d8 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -574,6 +574,21 @@ may not compile for example).
This option can be used along with `--bisect-vars`, in this case,
after all the sorted commit objects, there will be the same text as if
`--bisect-vars` had been used alone.
+
+--bisect-replace::
+
+This option will make use of the "refs/replace/bisect/*" refs if any,
+but will not perform other bisection calculation.
+
+The purpose of the "refs/replace/bisect/*" refs is to be grafted into
+other branches when bisecting, so that bisection can be performed on a
+fixed up history.
+
+The other `--bisect*` options use the "refs/replace/bisect/*" refs by
+default when they perform their bisection calculations. With the
+"--bisect-replace" option, you can see what is the result of using the
+"refs/replace/bisect/*" refs without the effects of other bisection
+calculations.
endif::git-rev-list[]
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 8adf269..693023f 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -47,12 +47,14 @@ static const char rev_list_usage[] =
" special purpose:\n"
" --bisect\n"
" --bisect-vars\n"
-" --bisect-all"
+" --bisect-all\n"
+" --bisect-replace"
;
static struct rev_info revs;
static int bisect_list;
+static int bisect_replace_only;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
@@ -681,6 +683,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_show_vars = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-replace")) {
+ bisect_replace_only = 1;
+ continue;
+ }
if (!strcmp(arg, "--stdin")) {
if (read_from_stdin++)
die("--stdin given twice?");
@@ -713,10 +719,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list) {
+ if (bisect_list || bisect_replace_only)
bisect_replace_all();
+ if (bisect_list)
revs.limited = 1;
- }
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index 6ab3667..bc07206 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -125,6 +125,18 @@ test_expect_success 'standard bisect works' '
git bisect reset
'
+test_expect_success '"git rev-list --bisect-replace" works' '
+ echo "$HASH7" >> rev_list.expect &&
+ echo "$HASH6" >> rev_list.expect &&
+ echo "$HASH5" >> rev_list.expect &&
+ echo "$HASHFIX4" >> rev_list.expect &&
+ echo "$HASHFIX3" >> rev_list.expect &&
+ echo "$HASHFIX2" >> rev_list.expect &&
+ echo "$HASH1" >> rev_list.expect &&
+ git rev-list --bisect-replace $HASH7 > rev_list.output &&
+ test_cmp rev_list.expect rev_list.output
+'
+
#
#
test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH] tg export: implement skipping empty patches for quilt mode
From: Uwe Kleine-König @ 2008-11-24 21:56 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, Petr Baudis
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: martin f. krafft <madduck@debian.org>
Cc: Petr Baudis <pasky@suse.cz>
---
tg-export.sh | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tg-export.sh b/tg-export.sh
index 52af88d..6f1d226 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -7,6 +7,7 @@ name=
branches=
output=
driver=collapse
+skipempty=false
## Parse options
@@ -20,6 +21,8 @@ while [ -n "$1" ]; do
driver=quilt;;
--collapse)
driver=collapse;;
+ -n)
+ skipempty=true;;
-*)
echo "Usage: tg [...] export ([--collapse] NEWBRANCH | [-b BRANCH1,BRANCH2...] --quilt DIRECTORY)" >&2
exit 1;;
@@ -34,6 +37,9 @@ done
[ -z "$branches" -o "$driver" = "quilt" ] ||
die "-b works only with the quilt driver"
+! "$skipempty" || [ "$driver" = "quilt" ] ||
+ die "-n is only implemented for the quilt driver"
+
if [ -z "$branches" ]; then
# this check is only needed when no branches have been passed
name="$(git symbolic-ref HEAD | sed 's#^refs/heads/##')"
@@ -140,10 +146,14 @@ quilt()
return
fi
- echo "Exporting $_dep"
- mkdir -p "$(dirname "$filename")"
- $tg patch "$_dep" >"$filename"
- echo "$_dep.diff -p1" >>"$output/series"
+ if "$skipempty" && branch_empty "$_dep"; then
+ echo "Skip empty patch $_dep";
+ else
+ echo "Exporting $_dep"
+ mkdir -p "$(dirname "$filename")"
+ $tg patch "$_dep" >"$filename"
+ echo "$_dep.diff -p1" >>"$output/series"
+ fi
}
--
1.5.6.5
^ permalink raw reply related
* Confusion with git rebase -i
From: Jean-Luc Herren @ 2008-11-24 23:02 UTC (permalink / raw)
To: Git Mailing List
Hi list!
I often edit recent commits I haven't pushed out yet using "git
rebase -i HEAD~5". And it's very helpful that whenever "git
rebase" stops, it tells me what to do next. So normally it stops
and tells me that I can now ammend the commit and then run "git
rebase --continue", or if a conflict happens, it tells to fix
that, "git add", "git rebase --continue". But I stumbled over a
situation where doing what it says doesn't do what I want.
Let's say my HEAD commit is fine, but I want to edit HEAD~1 and
HEAD~2, so I run "git rebase -i HEAD~3" and change 'pick' to
'edit' on the two lines I'm interested in. It stops after the
first commit, letting me amend it and then I do "git rebase
--continue". Unfortunately my fix to the first commit conflicts
with the second commit, and I get this:
Auto-merged filename
CONFLICT (content): Merge conflict in filename
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
run 'git rebase --continue'
Could not apply abcdefa... Commit message
Reading this message, I understand this isn't yet my chance to
amend the second commit, this is merely a rebase conflict I need
to fix before I can proceed. So I do what it says and fix only
the conflict and do "git add" and "git rebase --continue", but
then to my surprise I now won't get a chance to edit the second
commit.
What I have to do instead in that situation, is to resolve the
conflict *and also* add my fix to the second commit, and then
remember to do "git add" and "git commit" *without the --amend*.
And then finally "git rebase --continue". But it doesn't tell me
any of that...
I don't know if the message above is wrong, or if there's a bug
that just prevents it to stop again after a conflict of a commit
that has been marked "edit". Though stopping twice (once to
resolve conflict, once to amend the commit) at almost the same
place can be just as confusing, so fixing the conflict *and*
introduce my change to the commit at once is fine, but then it
should say so, or I'll be confused.
Or am I missing something? Using git 1.6.0.4.
Thanks,
jlh
^ permalink raw reply
* javagit
From: Johannes Schindelin @ 2008-11-24 23:46 UTC (permalink / raw)
To: git
Dear list,
I just had a giggle and thought I'd share it with you.
By pure chance, I stumbled upon this project:
http://sourceforge.net/projects/javagit/. It sports 12 members, has a
Subversion repository (!) and aims to simplify working with Git using Java
by providing an easy API to the Git commands.
It seems to be pretty close to http://sourceforge.net/projects/gitclipse,
which has only 8 members, however. At least they do something very new,
namely bringing Git to Eclipse. ;-)
Of course, all that without so much as saying "Hi" on the Git mailing
list. Tsk, tsk.
Ciao,
Dscho "who's whistling 'jgit, egit, jgit, egit, jaaaay-git!'"
P.S.: It is also quite a miracle to me how javagit can be LGPL, being
pretty much tied to Git, which is GPL. And it is an even bigger miracle
to me how gitclipse, linking to javagit, can be EPL...
^ permalink raw reply
* [EGIT PATCH] Avoid breaking the walk prematurely
From: Robin Rosenberg @ 2008-11-24 23:45 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
The optimization broke the walk when all changes we adds, assuming
the parent was an empty tree. This assumption was wrong. The tree does
not have to bee empty, it can contain other trees and blobs.
http://code.google.com/p/egit/issues/detail?id=46
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../spearce/jgit/revwalk/RewriteTreeFilter.java | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
We could introduce a fixed version later on if we supply an option to select
whether to optimize the walk this way. The problem with doing it without an
option is that imports from legacy SCMs do not necessarily record file moves
as add/removes in direct sucession, but other events may happen in beteens
for various reasons.
-- robin
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RewriteTreeFilter.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RewriteTreeFilter.java
index 587d6d2..a5edbf0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RewriteTreeFilter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RewriteTreeFilter.java
@@ -118,13 +118,6 @@ public boolean include(final RevWalk walker, final RevCommit c)
//
c.flags |= REWRITE;
return false;
- } else if (chgs == adds) {
- // We added everything, so the parent may as well just
- // be an empty tree. Kill our parent, we can assume
- // it did not supply interesting changes.
- //
- c.parents = RevCommit.NO_PARENTS;
- return true;
} else {
// We have interesting items, but neither of the special
// cases denoted above.
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [PATCH 1/9 v5] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-24 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
This subcommand should be used when you have a branch or a part of a
branch that isn't easily bisectable because of a bug that has been
fixed latter.
We suppose that a bug as been introduced at some point, say A, and
that it has been fixed latter at another point, say B, but that
between these points the code is not easily testable because of the
bug, so it's not easy to bisect between these points.
In this case you can create a branch starting at the parent of A, say
O, that has a fixed history. In this fixed history for example, there
could be first a commit C that is the result of squashing A and B
together and then all the commits between A and B that have been
cherry picked.
For example, let's say the commits between A and B are X1, X2, ... Xn
and they have been cherry picked after C as Y1, Y2, ... Yn:
C--Y1--Y2--...--Yn
/
...--O--A--X1--X2--...--Xn--B--...
By design, the last cherry picked commit (Yn) should point to the same
tree as commit B.
So in this case you can say:
$ git bisect replace B Yn
and a special ref will be created that points to commit Yn. This ref
will be named: "refs/replace/bisect/B"
When bisecting, the refs in "refs/replace/bisect/" will be scanned and
each ref named X found there and pointing to commit Y will be grafted
so that X will only have Y as parent.
In the example above, that means that instead of the above graph, the
following graph will be bisected:
C--Y1--Y2--...--Yn
/ \
...--O B--...
This means that the bisections on this branch will be much easier
because the bug introduced by commit A and fixed by commit B will not
annoy you anymore.
As the refs created by "git bisect replace" can be shared between
developers, this feature might be especially usefull on big projects
where many people often bisect the same code base.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++-
git-bisect.sh | 36 +++++++++++++++++++++++++-
refs.c | 5 +++
refs.h | 1 +
4 files changed, 110 insertions(+), 3 deletions(-)
Junio wrote:
>
> I have a separate idea make 'grafts' easier on object transfer, that is
> somewhat related to this one, by the way. Instead of making the grafts
> completely a local matter as we do now, we can reserve refs/replace/
> namespace, and record a new commit object to replace an existing commit
> whose object name is $sha1 as refs/replace/$sha1. We make almost all the
> commands except object enumeration (fsck, receive-pack, send-pack, prune,
> etc. Roughly speaking, anything that involves "rev-list --objects") honor
> this commit replacement, so that any time you ask for commit $sha1, the
> object layer gives you the replacement commit object back. In this way,
> you can clone or fetch from such a repository (along with refs in
> refs/replace/ hierarchy) and fsck/prune won't lose the original parents
> (because it does not see replacements). Things like paranoid update hook
> needs to become very careful about refs/replace/ for security reasons, but
> I think this would make the grafts much easier to use.
In this new version the "bisect-replace-*" branches have been replaced by
refs like "refs/replace/bisect/$sha1". Most of the code changes are in the
first patch. But there are also many documentation changes in the series.
I will see later if I can change usual grafts into refs in "refs/replace/grafts/"
or something like that.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 857742a..8adf269 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -574,6 +574,72 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
+static void replace_parents(struct commit *commit,
+ const char *refname,
+ const unsigned char *sha1)
+{
+ struct commit *new_parent = lookup_commit(sha1);
+ if (!new_parent) {
+ warning("replace ref '%s' points to unknown commit '%s'",
+ refname, sha1_to_hex(sha1));
+ return;
+ }
+
+ free_commit_list(commit->parents);
+ commit->parents = NULL;
+ commit_list_insert(new_parent, &commit->parents);
+}
+
+static int bisect_replace(const char *refname, const unsigned char *sha1,
+ int flag, void *cb_data)
+{
+ unsigned char child[20];
+ struct object *obj;
+ struct commit_graft *graft;
+
+ if (prefixcmp(refname, "bisect/"))
+ return 0;
+
+ if (get_sha1_hex(refname + 7, child)) {
+ warning("bad sha1 in replace ref named '%s'", refname);
+ return 0;
+ }
+
+ /* Check if child commit exist and is already parsed */
+
+ obj = lookup_object(child);
+ if (obj) {
+ struct commit *commit;
+ if (obj->type != OBJ_COMMIT) {
+ warning("replace ref name '%s' refers to non commit '%s'",
+ refname, refname + 7);
+ return 0;
+ }
+ commit = (struct commit *) obj;
+ if (commit->object.parsed) {
+ replace_parents(commit, refname, sha1);
+ return 0;
+ }
+ }
+
+ /* Create a graft to replace child commit parents */
+
+ graft = xmalloc(sizeof(*graft) + 20);
+
+ hashcpy(graft->sha1, child);
+ graft->nr_parent = 1;
+ hashcpy(graft->parent[0], sha1);
+
+ register_commit_graft(graft, 1);
+
+ return 0;
+}
+
+static void bisect_replace_all(void)
+{
+ for_each_replace_ref(bisect_replace, NULL);
+}
+
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
@@ -646,8 +712,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list)
+
+ if (bisect_list) {
+ bisect_replace_all();
revs.limited = 1;
+ }
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
diff --git a/git-bisect.sh b/git-bisect.sh
index 0d0e278..ed7c620 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|replace|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -21,6 +21,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect replace <rev> [<rev>]
+ use another branch for bisection.
git bisect run <cmd>...
use <cmd>... to automatically bisect.
@@ -566,6 +568,35 @@ bisect_replay () {
bisect_auto_next
}
+bisect_replace() {
+ test "$#" -ge 1 -a "$#" -le 2 ||
+ die "'git bisect replace' accept one or two arguments"
+
+ source="$1"
+ target="${2:-HEAD}"
+
+ # Check arguments
+ src_commit=$(git rev-parse --verify "$source^{commit}") ||
+ die "Bad rev input: $source"
+ tgt_commit=$(git rev-parse --verify "$target^{commit}") ||
+ die "Bad rev input: $target"
+
+ test "$src_commit" != "tgt_commit" ||
+ die "source and target should be different commits"
+
+ # Check that trees from source and target are identical
+ src_tree=$(git rev-parse --verify "$src_commit^{tree}") ||
+ die "Could not get tree for source: $source"
+ tgt_tree=$(git rev-parse --verify "$tgt_commit^{tree}") ||
+ die "Could not get tree for target: $target"
+
+ test "$src_tree" = "$tgt_tree" ||
+ die "source and target should point to the same tree"
+
+ # Create a ref in "refs/replace/bisect/" for the target commit
+ git update-ref -m bisect "refs/replace/bisect/$src_commit" "$tgt_commit"
+}
+
bisect_run () {
bisect_next_check fail
@@ -618,7 +649,6 @@ bisect_run () {
done
}
-
case "$#" in
0)
usage ;;
@@ -643,6 +673,8 @@ case "$#" in
bisect_replay "$@" ;;
log)
cat "$GIT_DIR/BISECT_LOG" ;;
+ replace)
+ bisect_replace "$@" ;;
run)
bisect_run "$@" ;;
*)
diff --git a/refs.c b/refs.c
index 33ced65..042106d 100644
--- a/refs.c
+++ b/refs.c
@@ -632,6 +632,11 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
}
+int for_each_replace_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/replace/", fn, 13, cb_data);
+}
+
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
* We do not like it if:
diff --git a/refs.h b/refs.h
index 06ad260..8d2ee5a 100644
--- a/refs.h
+++ b/refs.h
@@ -23,6 +23,7 @@ extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
+extern int for_each_replace_ref(each_ref_fn, void *);
/*
* Extra refs will be listed by for_each_ref() before any actual refs
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* Re: javagit
From: Shawn O. Pearce @ 2008-11-24 23:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811250036560.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I just had a giggle and thought I'd share it with you.
>
> By pure chance, I stumbled upon this project:
> http://sourceforge.net/projects/javagit/. It sports 12 members, has a
> Subversion repository (!) and aims to simplify working with Git using Java
> by providing an easy API to the Git commands.
I think we already discussed this project back in August:
http://thread.gmane.org/gmane.comp.version-control.git/91381
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH] Avoid breaking the walk prematurely
From: Shawn O. Pearce @ 2008-11-25 0:12 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1227570348-20092-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> The optimization broke the walk when all changes we adds, assuming
> the parent was an empty tree. This assumption was wrong. The tree does
> not have to bee empty, it can contain other trees and blobs.
>
> http://code.google.com/p/egit/issues/detail?id=46
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> .../spearce/jgit/revwalk/RewriteTreeFilter.java | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> We could introduce a fixed version later on if we supply an option to select
> whether to optimize the walk this way. The problem with doing it without an
> option is that imports from legacy SCMs do not necessarily record file moves
> as add/removes in direct sucession, but other events may happen in beteens
> for various reasons.
This is a fairly useful optimization in git. Most people use it,
because most people don't pass "--full-history" when they run
"git log -- path". So I think we really want to do it by default
in jgit.
Enabling this optimization again probably requires adding a new
method to TreeFilter which allows the filter graph to return only
nodes which select paths by name, and then do something like:
else if (chgs == adds && isPathSetEmpty(c.getTree())) {
c.parents = RevCommit.NO_PARENTS;
return true;
}
where isPathSetEmpty runs a second TreeWalk iteration but uses the
new (smaller) filter graph that only matches on paths.
I'm not going to write that out today. But I thought I'd at least
write an email while the idea was fresh in my head.
--
Shawn.
^ permalink raw reply
* How to hide a git repository?
From: Gary Yang @ 2008-11-25 0:32 UTC (permalink / raw)
To: git
We have two repositories, one is /pub/git/dev/linux/kernel, another is /pub/git/pub/linux/kernel. The /pub/git/pub/linux/kernel is open to public for people to download released code. /pub/git/dev/linux/kernel is used for our development. We would like to hide /pub/git/dev/linux/kernel from public. How to do it?
Why we want to hide /pub/git/dev/linux/kernel from public?
We work on our development at /pub/git/dev/linux/kernel. We push our released code to /pub/git/pub/linux/kernel from /pub/git/dev/linux/kernel once we completed our development. We do not want people to download code from /pub/git/dev/linux/kernel since it is not stable.
^ permalink raw reply
* Re: javagit
From: Johannes Schindelin @ 2008-11-25 0:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081124235900.GG2932@spearce.org>
Hi,
On Mon, 24 Nov 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I just had a giggle and thought I'd share it with you.
> >
> > By pure chance, I stumbled upon this project:
> > http://sourceforge.net/projects/javagit/. It sports 12 members, has a
> > Subversion repository (!) and aims to simplify working with Git using Java
> > by providing an easy API to the Git commands.
>
> I think we already discussed this project back in August:
>
> http://thread.gmane.org/gmane.comp.version-control.git/91381
Heh, I had forgotten about that, even if I participated in the discussion,
praising jgit.
Oh well,
Dscho
^ permalink raw reply
* [PATCH 5/9 v5] commit: add "bisect_replace_all" prototype to "commit.h"
From: Christian Couder @ 2008-11-24 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 2 +-
commit.h | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 693023f..1b18c65 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -637,7 +637,7 @@ static int bisect_replace(const char *refname, const unsigned char *sha1,
return 0;
}
-static void bisect_replace_all(void)
+void bisect_replace_all(void)
{
for_each_replace_ref(bisect_replace, NULL);
}
diff --git a/commit.h b/commit.h
index 3a7b06a..a0ec2a0 100644
--- a/commit.h
+++ b/commit.h
@@ -144,4 +144,6 @@ static inline int single_parent(struct commit *commit)
struct commit_list *reduce_heads(struct commit_list *heads);
+void bisect_replace_all(void);
+
#endif /* COMMIT_H */
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
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