* Re: [PATCH 1/8] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Johannes Schindelin @ 2008-12-01 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vtz9oq92i.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 1 Dec 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > As it is, the patch series is _already_ hard to review (as it is large
> > not only in term of number of patches, but also individual patch
> > size), _especially_ given the fact that there is no clear, precise and
> > short description of why/how the sparse checkout is implemented.
>
> Hmm, can you really tell the lack of such description without reading
> the series, I have to wonder...
Okay, I thought it was obvious, but here is a template for the BLURP of
the cover letter that would at least get me started:
-- snip --
A "sparse checkout" is an index/working directory pair where not all
files/directories of the HEAD commit are actually checked out in the
working directory. Instead, they are marked as "not being checked out" in
the index.
The real meat of this series is patch *** M/N *** which teaches Git to
understand the *** XYZ flag *** for index entries.
The following operations are affected by sparse checkout: *** X, Y, Z ***
These operations respect sparse checkouts by *** THIS, THIS AND THIS ***.
The first patch really should be independent, but patch *** M/N *** would
fail without it.
-- snap --
And of course, the whole BLURP should not consist of 10-20 line
paragraphs, but try to fit everything into 3-4 line paragraphs (I seem to
remember that there was a mail on this list saying than more than 4
lines/paragraph are too much for the average attention span...).
Ciao,
Dscho
^ permalink raw reply
* SPEC files for Git
From: Nicolas Morey-Chaisemartin @ 2008-12-01 15:16 UTC (permalink / raw)
To: git
Hi,
I'm trying to recompile gitweb1.6.0.4-1 for RHEL5, but I'm missing the
spec file.
I've checked the git SRP. It generates a lot of things but no RPM for
gitweb.
Is there any place with an official spec file? Or has anyone made one
which he could share?
Best regards
Nicolas
^ permalink raw reply
* Re: two questions about the format of loose object
From: Shawn O. Pearce @ 2008-12-01 15:21 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <4933AE55.2090007@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
> Thanks for your explanation, but I doubt if it's too costly to change the
> format of loose object, after all this doesn't change the format of pack
> file and affect git-pull/fetch of old git client.
It is too costly; Jakub pointed out the dumb protocol clients
would have issues with the new format. Anyone copying a repository
between machines using scp or a USB memory stick may also run into
a problem. Etc.
> Some cons and pros.
>
> cons:
>
> * old git client can't read loose objects in new format
> (People degrade git rarely and old git can read pack files
> generated by new git, so it's not a big problem)
That's a pretty big con. We can also add slower performance on NFS,
as has been reported already by others.
> pros:
>
> * avoid compressing and uncompressing loose objects that are likely
> frequently used when you are coding/merging
True, loose objects are among the more frequently accessed items.
> * share loose objects among multipe git processes
Probably not a huge issue. How many concurrent git processes are
you running on the same object store at once? During development?
Its probably not more than 1. So sharing the objects doesn't make
a very compelling argument.
> * the new code path is simpler although we will have more code paths for
> compatibility
The new code path is more complex, because although one branch is
very simple (mmap and use) the other code paths have to stay for
backwards compatibility. Every time you add a branch point the
code gets more complex. It works well enough now, and is at least
one branch point simpler than what you are proposing. So I'm not
really interested in seeing the change made.
--
Shawn.
^ permalink raw reply
* gitk: git bisect view doesn't work
From: Johannes Sixt @ 2008-12-01 14:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
gitk bails out like this if I do "git bisect view":
$ git bisect start HEAD HEAD~2
Bisecting: 0 revisions left to test after this
[9a61060c7e0d112d0742f5b845210ea8c41b6c6b] Added encoding
$ git bisect view
Error in startup script: can't read "notflag": no such variable
while executing
"expr {!$notflag}"
("--not" arm line 2)
invoked from within
"switch -glob -- $arg {
"-d" -
"--date-order" {
set vdatemode($n) 1
# remove from origargs in case we hit an unknown option
set origarg..."
(procedure "parseviewargs" line 21)
invoked from within
"parseviewargs $view $args"
(procedure "start_rev_list" line 27)
invoked from within
"start_rev_list $curview"
(procedure "getcommits" line 5)
invoked from within
"getcommits {}"
(file "/usr/local/bin/gitk" line 10897)
$ git version
git version 1.6.1.rc1
-- Hannes
^ permalink raw reply
* Re: [TOPGIT] Resolving conflicts
From: Uwe Kleine-König @ 2008-12-01 14:36 UTC (permalink / raw)
To: Sascha Hauer; +Cc: git, Petr Baudis, martin f krafft
In-Reply-To: <20081201121819.GB13495@pengutronix.de>
[added martin f krafft to Cc:]
Hi,
> Another thing is that the exported branch contains an empty commit
> resulting from t/whatever (and a corresponding empty patch when exported
> as a quilt series)
I fixed one half of this in with a patch sent to the ML:
http://article.gmane.org/gmane.comp.version-control.git/101728
it didn't made it upstream yet, though.
Best regards
Uwe
^ permalink raw reply
* [PATCH 6/6 (v2)] clone: test the new HEAD detection logic
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-6-git-send-email-gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5601-clone.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 78a3fa6..6d4665b 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -125,4 +125,15 @@ test_expect_success 'clone to destination with extra trailing /' '
'
+test_expect_success 'clone from a repository with two identical branches' '
+
+ (
+ cd src &&
+ git checkout -b another master
+ ) &&
+ git clone src target-3 &&
+ test "z$( cd target-3 && git symbolic-ref HEAD )" = zrefs/heads/another
+
+'
+
test_done
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-5-git-send-email-gitster@pobox.com>
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent after the terminating NUL
that comes after the server capabilities list, to cause older clients to
ignore it, while allowing newer clients to make use of that information
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
upload-pack.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..4aa444a 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -579,9 +579,17 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
- if (capabilities)
- packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname,
- 0, capabilities);
+ if (capabilities) {
+ unsigned char dummy[20];
+ const char *target = resolve_ref("HEAD", dummy, 0, NULL);
+
+ if (!target)
+ packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname,
+ 0, capabilities);
+ else
+ packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
+ 0, capabilities, 0, target);
+ }
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
capabilities = NULL;
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 4/6 (v2)] clone: find the current branch more explicitly
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-4-git-send-email-gitster@pobox.com>
This makes "git clone" use the HEAD information sent by an updated
uploader to point the resulting HEAD at the current branch that is not
'master' but happens to point at the same commit as 'master'.
IOW, immediately after doing:
$ git checkout -b another master
a clone made out of that repository will check out 'another' branch, not
'master'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-clone.c | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 2feac9c..a8b8d56 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -299,13 +299,27 @@ static const struct ref *locate_head(const struct ref *refs,
const struct ref *remote_head = NULL;
const struct ref *remote_master = NULL;
const struct ref *r;
- for (r = refs; r; r = r->next)
- if (!strcmp(r->name, "HEAD"))
+
+ for (r = refs; r; r = r->next) {
+ if (!strcmp(r->name, "HEAD")) {
remote_head = r;
+ break;
+ }
+ }
- for (r = mapped_refs; r; r = r->next)
- if (!strcmp(r->name, "refs/heads/master"))
- remote_master = r;
+ if (remote_head && remote_head->symref) {
+ for (r = mapped_refs; r; r = r->next)
+ if (!strcmp(r->name, remote_head->symref)) {
+ remote_master = r;
+ break;
+ }
+ }
+
+ if (!remote_master) {
+ for (r = mapped_refs; r; r = r->next)
+ if (!strcmp(r->name, "refs/heads/master"))
+ remote_master = r;
+ }
if (remote_head_p)
*remote_head_p = remote_head;
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 3/6 (v2)] connect.c::read_extra_info(): find where HEAD points at
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-3-git-send-email-gitster@pobox.com>
This actually implements the protocol extension to receive the HEAD symref
information that is hidden after the server capabilities list. Nobody
uses the information yet, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
connect.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index 114d691..aa4757a 100644
--- a/connect.c
+++ b/connect.c
@@ -53,7 +53,7 @@ static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1
* NUL". "len" is the remaining number of bytes. The caller knows
* that the original packet contains more information than that.
*/
-static void read_extra_info(char *line, int len)
+static void read_extra_info(char *line, int len, char **hpa)
{
/*
* The first such "extra" piece of information is the list of
@@ -64,6 +64,20 @@ static void read_extra_info(char *line, int len)
free(server_capabilities);
server_capabilities = xmalloc(infolen);
memcpy(server_capabilities, line, infolen);
+ if (infolen == len)
+ return;
+ /*
+ * The uploader can optionally tell us where the HEAD pointer
+ * points at after that.
+ */
+ line += infolen;
+ len -= infolen;
+
+ infolen = strlen(line) + 1;
+
+ free(*hpa);
+ *hpa = xmalloc(infolen);
+ memcpy(*hpa, line, infolen);
}
/*
@@ -74,6 +88,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
unsigned int flags,
struct extra_have_objects *extra_have)
{
+ struct ref **ref_list = list;
+ char *head_points_at = NULL;
+
*list = NULL;
for (;;) {
struct ref *ref;
@@ -97,7 +114,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
name_len = strlen(name);
if (len != name_len + 41)
- read_extra_info(name + name_len + 1, len - (name_len + 41));
+ read_extra_info(name + name_len + 1, len - (name_len + 41),
+ &head_points_at);
if (extra_have &&
name_len == 5 && !memcmp(".have", name, 5)) {
@@ -114,6 +132,11 @@ struct ref **get_remote_heads(int in, struct ref **list,
*list = ref;
list = &ref->next;
}
+ if (head_points_at) {
+ struct ref *head = find_ref_by_name(*ref_list, "HEAD");
+ if (head)
+ head->symref = head_points_at;
+ }
return list;
}
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 1/6 (v2)] get_remote_heads(): refactor code to read "server capabilities"
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-1-git-send-email-gitster@pobox.com>
This just moves the code to read the server capability list that is hidden
after "40-byte hex object name, SP, refname, NUL" on the information the
uploading end initially sends.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
connect.c | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/connect.c b/connect.c
index 584e04c..932c503 100644
--- a/connect.c
+++ b/connect.c
@@ -49,6 +49,21 @@ static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1
}
/*
+ * "line" points at the byte just after "40-byte hex, SP, refname,
+ * NUL". "len" is the remaining number of bytes. The caller knows
+ * that the original packet contains more information than that.
+ */
+static void read_extra_info(char *line, int len)
+{
+ /*
+ * The first such "extra" piece of information is the list of
+ * server capabilities.
+ */
+ free(server_capabilities);
+ server_capabilities = xstrdup(line);
+}
+
+/*
* Read all the refs from the other end
*/
struct ref **get_remote_heads(int in, struct ref **list,
@@ -78,10 +93,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
name = buffer + 41;
name_len = strlen(name);
- if (len != name_len + 41) {
- free(server_capabilities);
- server_capabilities = xstrdup(name + name_len + 1);
- }
+ if (len != name_len + 41)
+ read_extra_info(name + name_len + 1, len - (name_len + 41));
if (extra_have &&
name_len == 5 && !memcmp(".have", name, 5)) {
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 2/6 (v2)] connect.c::read_extra_info(): prepare to receive more than server capabilities
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-2-git-send-email-gitster@pobox.com>
This still does not actually parse and accept anything more than the list
of server capabilities, but prepares for the uploader that sends more
"extra" information than that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
connect.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/connect.c b/connect.c
index 932c503..114d691 100644
--- a/connect.c
+++ b/connect.c
@@ -59,8 +59,11 @@ static void read_extra_info(char *line, int len)
* The first such "extra" piece of information is the list of
* server capabilities.
*/
+ int infolen = strlen(line) + 1;
+
free(server_capabilities);
- server_capabilities = xstrdup(line);
+ server_capabilities = xmalloc(infolen);
+ memcpy(server_capabilities, line, infolen);
}
/*
--
1.6.0.4.864.g0f47a
^ permalink raw reply related
* [PATCH 0/6 (v2)] Detecting HEAD more reliably while cloning
From: Junio C Hamano @ 2008-12-01 14:12 UTC (permalink / raw)
To: git
This is another approach to the same problem that a repository cloned from
another repository whose default branch is not 'master' can use 'master'
as the default.
The current code has to guess where the HEAD in the original repository
points at, because the original protocol tells what object each ref points
at but does not talk about which other ref a symbolic ref points at. The
implication of this is that if you prepare another branch that points at
your master, like this:
$ git checkout -b another master
and keep that other branch checked out (and in sync with 'master'), a
clone made from such a repository may incorrectly have its HEAD pointing
at 'master', not 'another'.
Instead of introducing a full-fledged protocol extension, this round hides
the new information in the same place as the server capabilities list that
is used to implement protocol extension is hidden from older clients.
This way, it does not have to work around the code structure imposed by
the transport API, does not have to introduce an extra round trip, and
does not have to trigger an annoying (but harmless) error message when an
older client contacts a new uploader.
[1/6] get_remote_heads(): refactor code to read "server capabilities"
[2/6] connect.c::read_extra_info(): prepare to receive more than server
capabilities
[3/6] connect.c::read_extra_info(): find where HEAD points at
[4/6] clone: find the current branch more explicitly
[5/6] upload-pack: send the HEAD information
[6/6] clone: test the new HEAD detection logic
The first four are the client side, the fifth one is the uploader side,
and the last one is the test. After storing these patches in separate
files, you would build this history (on top of 'master'):
git am 1 2 3 4
git reset --hard HEAD~4 5---------------M---6
git am 5 / /
git merge HEAD@{2} ---1---2---3---4
git am 6
builtin-clone.c | 24 +++++++++++++++++++-----
connect.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
t/t5601-clone.sh | 11 +++++++++++
upload-pack.c | 14 +++++++++++---
4 files changed, 84 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/8] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Junio C Hamano @ 2008-12-01 14:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.DEB.1.00.0812011505551.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 30 Nov 2008, Nguyễn Thái Ngọc Duy wrote:
>
>> In "common" man pages there is luckily no "NAME" anywhere except at
>> beginning of documents. If there is another "NAME", sed could mis-select
>> it and lead to common-cmds.h corruption. So better nail it at beginning
>> of line, which would reduce corruption chance.
>
> I have no idea why you put this into the sparse checkout patch series.
That is because a documentation that triggers the misfortune this patch
fixes is introduced in the series. I actually scratched head myself,
though, and come to think of it, I should have complained that this patch
should state that because it does not look like it has anything do with
the main topic of the series.
> As it is, the patch series is _already_ hard to review (as it is large not
> only in term of number of patches, but also individual patch size),
> _especially_ given the fact that there is no clear, precise and short
> description of why/how the sparse checkout is implemented.
Hmm, can you really tell the lack of such description without reading the
series, I have to wonder...
^ permalink raw reply
* Re: [PATCH 1/8] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Nguyen Thai Ngoc Duy @ 2008-12-01 14:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812011505551.30769@pacific.mpi-cbg.de>
On 12/1/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Sun, 30 Nov 2008, Nguyn Thái Ng÷c Duy wrote:
>
> > In "common" man pages there is luckily no "NAME" anywhere except at
> > beginning of documents. If there is another "NAME", sed could mis-select
> > it and lead to common-cmds.h corruption. So better nail it at beginning
> > of line, which would reduce corruption chance.
>
>
> I have no idea why you put this into the sparse checkout patch series.
It's more an independent bug fix. I posted this once but it was not
caught up. I intended to just put some comments in BLURB area to tell
people to get this patch from mail archive. But that way seems
inconvenient. Without this patch, you won't be able to compile the
series because of common-cmds.h corruption.
--
Duy
^ permalink raw reply
* Re: [PATCH 4/5] upload-pack: implement protocol extension "symbolic-ref"
From: Junio C Hamano @ 2008-12-01 14:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081130180214.GA10375@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 30, 2008 at 01:57:29AM -0800, Junio C Hamano wrote:
> ...
>> This is unfortunate because it forces an extra round trip (receiving end
>> sends a "please tell me symbolic-ref" packet, and then upload side sends
>> "here are the requested information" packet), but it has to be implemented
>> this way because (1) ls-remote may need to ask for this information, in
>> which case there is no "want" to be sent; and (2) the transport API
>> insists that transport_get_remote_refs() returns the final list, and does
>> not allow augmenting what was initially obtained from the call to it by
>> later calls to transport_fetch_refs() easily.
>
> Hrm. For (1), could we allow either interaction method? IOW, allow
> requesting a symref on the first want line, _or_ by separate "symbolic
> ref" packet? That would allow clients who are using "want" to
> piggy-back the symref request as an optimization, but not restrict those
> that just want to ask for it?
I think I found another hole in the protocol that we can use to carry the
"which branch does HEAD points at" information in a backward compatible
way, and it would be a much less intrusive although more sneaky way. And
it would not have to suffer from the above issues at all.
A patchset follows shortly...
^ permalink raw reply
* Re: [PATCH 1/8] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Johannes Schindelin @ 2008-12-01 14:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1228042478-1886-2-git-send-email-pclouds@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 972 bytes --]
Hi,
On Sun, 30 Nov 2008, Nguyễn Thái Ngọc Duy wrote:
> In "common" man pages there is luckily no "NAME" anywhere except at
> beginning of documents. If there is another "NAME", sed could mis-select
> it and lead to common-cmds.h corruption. So better nail it at beginning
> of line, which would reduce corruption chance.
I have no idea why you put this into the sparse checkout patch series.
As it is, the patch series is _already_ hard to review (as it is large not
only in term of number of patches, but also individual patch size),
_especially_ given the fact that there is no clear, precise and short
description of why/how the sparse checkout is implemented.
For example, instead of using the BLURP area of the cover letter to put
forth convincing arguments why this is needed, and why it is implemented
in the best possible manner, you wasted two lines stating the obvious.
IMO that is almost like _asking_ people not to have a look at it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] Documentation: describe how to "bisect skip" a range of commits
From: Christian Couder @ 2008-12-01 13:39 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Johannes Sixt; +Cc: git, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 21 ++++++++++++++++++++-
git-bisect.sh | 2 +-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 39034ec..147ea38 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -19,7 +19,7 @@ on the subcommand:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
- git bisect skip [<rev>...]
+ git bisect skip [(<rev>|<range>)...]
git bisect reset [<branch>]
git bisect visualize
git bisect replay <logfile>
@@ -164,6 +164,25 @@ But computing the commit to test may be slower afterwards and git may
eventually not be able to tell the first bad among a bad and one or
more "skip"ped commits.
+You can even skip a range of commits, instead of just one commit,
+using the "'<commit1>'..'<commit2>'" notation. For example:
+
+------------
+$ git bisect skip v2.5..v2.6
+------------
+
+would mean that no commit between `v2.5` excluded and `v2.6` included
+can be tested.
+
+Note that if you want to also skip the first commit of a range you can
+use something like:
+
+------------
+$ git bisect skip v2.5 v2.5..v2.6
+------------
+
+and the commit pointed to by `v2.5` will be skipped too.
+
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index 58d6276..da92d1e 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -9,7 +9,7 @@ git bisect bad [<rev>]
mark <rev> a known-bad revision.
git bisect good [<rev>...]
mark <rev>... known-good revisions.
-git bisect skip [<rev>...]
+git bisect skip [(<rev>|<range>)...]
mark <rev>... untestable revisions.
git bisect next
find next bisection to test and check it out.
--
1.6.0.4.837.g71a67
^ permalink raw reply related
* [PATCH 1/2] bisect: fix "git bisect skip <commit>" and add tests cases
From: Christian Couder @ 2008-12-01 13:39 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Johannes Sixt; +Cc: git, H. Peter Anvin
The patch that allows "git bisect skip" to be passed a range of
commits using the "<commit1>..<commit2>" notation is flawed because
it introduces a regression when it was passed a simple rev or commit.
"git bisect skip <commit>" doesn't work any more, because <commit>
is quoted but not properly unquoted.
This patch fixes that and add tests cases to better check when it is
passed commits and range of commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 2 +-
t/t6030-bisect-porcelain.sh | 19 ++++++++++++++++++-
2 files changed, 19 insertions(+), 2 deletions(-)
Sorry I overlooked something in my previous patch (v2).
diff --git a/git-bisect.sh b/git-bisect.sh
index 6706bc1..58d6276 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -203,7 +203,7 @@ bisect_skip() {
esac
all="$all $revs"
done
- bisect_state 'skip' $all
+ eval bisect_state 'skip' $all
}
bisect_state() {
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 85fa39c..dd7eac8 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -313,8 +313,25 @@ test_expect_success 'bisect run & skip: find first bad' '
grep "$HASH6 is first bad commit" my_bisect_log.txt
'
-test_expect_success 'bisect starting with a detached HEAD' '
+test_expect_success 'bisect skip only one range' '
+ git bisect reset &&
+ git bisect start $HASH7 $HASH1 &&
+ git bisect skip $HASH1..$HASH5 &&
+ test "$HASH6" = "$(git rev-parse --verify HEAD)" &&
+ test_must_fail git bisect bad > my_bisect_log.txt &&
+ grep "first bad commit could be any of" my_bisect_log.txt
+'
+test_expect_success 'bisect skip many ranges' '
+ git bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect skip $HASH2 $HASH2.. ..$HASH5 &&
+ test "$HASH6" = "$(git rev-parse --verify HEAD)" &&
+ test_must_fail git bisect bad > my_bisect_log.txt &&
+ grep "first bad commit could be any of" my_bisect_log.txt
+'
+
+test_expect_success 'bisect starting with a detached HEAD' '
git bisect reset &&
git checkout master^ &&
HEAD=$(git rev-parse --verify HEAD) &&
--
1.6.0.4.837.g71a67
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: add support for cvs pserver password scrambling.
From: Johannes Schindelin @ 2008-12-01 13:43 UTC (permalink / raw)
To: Dirk Hörner; +Cc: git
In-Reply-To: <5794AED2-43FF-4441-8292-0C9BFB3139A2@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 332 bytes --]
Hi,
On Fri, 28 Nov 2008, Dirk Hörner wrote:
> Instead of a cleartext password, the CVS pserver expects a scrambled one
> in the authentication request. With this patch it is possible to import
> CVS repositories only accessible via pserver and user/password.
The patch looks obvious enough; care to add a testcase?
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 13:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <e3f230850812010507y54dff6dh3757bf97c78c0329@mail.gmail.com>
Hi,
Sorry for all the noise, I pushed the files. I had to use:
$ git push mob@repo.or.cz:/srv/git/msysgit.git
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 13:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <e3f230850812010402n69cced19s3f36a5bcb84977c6@mail.gmail.com>
Hi,
I am trying to push to 'mob'.
$ git branch --track mob origin/mob
$ tar -zxvf ~/pthread.tar.gz
$ make prefix= html all install
$ git push repo.or.cz:/srv/git/msysgit.git
fatal: protocol error: bad line length charact
@:/
[531]$ Access denied
Access denied
Access denied
Access denied
Access denied
Access denied
FATAL ERROR: Server sent disconnect message
type 2 (protocol error):
"Too many authentication failures for dhruva"
Could someone help me out with this?
-dhruva
On Mon, Dec 1, 2008 at 5:32 PM, dhruva <dhruvakm@gmail.com> wrote:
> Hello,
>
> On Mon, Dec 1, 2008 at 5:27 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> dhruva schrieb:
>>> I got the mob branch and I fail to see the Makefile. I decided to
>>> just add the pthread related files and push so that someone could
>>> build, I get authentication failures. I had tried to push perl
>>> sometime back when I had a gcc compiler perl (before strawberry perl)
>>> and had similar problems. I am fairly certain I am doing something
>>> wrong but cannot figure it out!
>>
>> msysgit.git is *not* a git.git clone; it is the MSYS/MinGW environment to
>> build git.git on Windows.
>>
>> You should apply the steps 1. to 4. that you mentioned in an earlier mail
>> and push the result; but you cannot apply 5. because that is a change to
>> git itself.
>
> I request someone to just pull the archive I have placed just this
> time, I will try again for other patches. I will create a clone in a
> separate folder for msysgit and keep it ready. Unknowingly, I just
> cleaned up the remote and lost all the changes I had pulled earlier :(
>
> -dhruva
>
> --
> Contents reflect my personal views only!
>
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: two questions about the format of loose object
From: Nick Andrew @ 2008-12-01 12:16 UTC (permalink / raw)
To: Liu Yubao; +Cc: git list
In-Reply-To: <493399B7.5000505@gmail.com>
On Mon, Dec 01, 2008 at 04:00:55PM +0800, Liu Yubao wrote:
> I did a simple benchmark on my notebook and a server in my company,
> writing a big file to disk is faster than compressing it first and
> writing the result out. The former's performance for reading should
> also be better because of file cache.
In a corporate environment (and not related to git) I found the
opposite. The disk was fairly slow (over NFS) and it was in fact
quicker to read and write compressed files.
Nick.
^ permalink raw reply
* Re: Is rebase always destructive?
From: Nick Andrew @ 2008-12-01 12:11 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngj7jch.2srb.csaba-ml@beastie.creo.hu>
On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
> When doing a rebase, I can find a number of reasons for which one might
> feel like to preserve the rebased branch (that is, perform an operation
> which copies the branch over a new base, not moves).
[...]
> I can't see any option for rebase which would yield this cp-like
> behaviour. Am I missing something?
How about this:
git checkout topic
git branch keepme
git rebase master
Your 'topic' branch will now be rebased against master, and due
to the 'keepme' branch pointer at the original topic HEAD, you can
see the original commits before rebasing.
Nick.
^ permalink raw reply
* [TOPGIT] Resolving conflicts
From: Sascha Hauer @ 2008-12-01 12:18 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Uwe Kleine-Koenig
Hi,
I'm going my first steps with topgit and this tool seems to add the
missing link for my git experience.
I have a little problem with conflicts resulting from different topgit
branches though. What I'm trying to do is this (taken from the topgit
README):
## Create another topic branch depending on two others non-trivially
$ tg create t/whatever t/revlist/author-fixed t/gitweb/nifty-links
tg: Creating t/whatever base from t/revlist/author-fixed...
tg: Merging t/whatever base with t/gitweb/nifty-links...
Merge failed!
tg: Please commit merge resolution and call: tg create
tg: It is also safe to abort this operation using `git reset --hard`
tg: but please remember you are on the base branch now;
tg: you will want to switch to a different branch.
$ ..resolve..
After resolving I exported t/whatever to a quilt series. The series does
not apply because it does not contain the conflict resolution. If I export
to a git branch instead the merge is a commit of its own, resulting in a
non linear history.
Any chance to fix this or am I missing something?
Another thing is that the exported branch contains an empty commit
resulting from t/whatever (and a corresponding empty patch when exported
as a quilt series)
Best regards,
Sascha
--
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 12:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <4933D10E.6020706@viscovery.net>
Hello,
On Mon, Dec 1, 2008 at 5:27 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> dhruva schrieb:
>> I got the mob branch and I fail to see the Makefile. I decided to
>> just add the pthread related files and push so that someone could
>> build, I get authentication failures. I had tried to push perl
>> sometime back when I had a gcc compiler perl (before strawberry perl)
>> and had similar problems. I am fairly certain I am doing something
>> wrong but cannot figure it out!
>
> msysgit.git is *not* a git.git clone; it is the MSYS/MinGW environment to
> build git.git on Windows.
>
> You should apply the steps 1. to 4. that you mentioned in an earlier mail
> and push the result; but you cannot apply 5. because that is a change to
> git itself.
I request someone to just pull the archive I have placed just this
time, I will try again for other patches. I will create a clone in a
separate folder for msysgit and keep it ready. Unknowingly, I just
cleaned up the remote and lost all the changes I had pulled earlier :(
-dhruva
--
Contents reflect my personal views only!
^ 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