Re: [PATCH 2/2] Unify usage strings declaration
Hi, Junio C Hamano wrote:
I do not have preference either way, and I've already merged
them, but why char[] not char*?
A char* is a variable which points to the char[].
That's four (or eight) bytes we don't need. ;-)
C conflates the two concepts somewhat, which is one of the reasons
optimizing compiled C is somewhat more challenging than, say, FORTRAN.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Giving every man a vote has no more made men wise
and free than Christianity has made them good.
-- H.L. Mencken
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Teach parse_commit_buffer about grafting.
Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
which is a list of fake commit parent records. Each line of
this file is a commit ID, followed by parent commit IDs, all
40-byte hex SHA1 separated by a single SP in between. The
records override the parent information we would normally read
from the commit objects, allowing both adding fake parents
(i.e. grafting), and pretending as if a commit is not a child of
some of its real parents (i.e. cauterizing).
Bugs are mine, but the credits for the idea and implementation
outline all go to Linus, who kept hinting how this thing should
work.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
cache.h |2 +
commit.c| 114 ++-
sha1_file.c | 13 ++-
3 files changed, 127 insertions(+), 2 deletions(-)
0f16b172aa7f0757b2af50ec7be58dc0e23913a6
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -127,10 +127,12 @@ extern unsigned int active_nr, active_al
#define DEFAULT_GIT_DIR_ENVIRONMENT .git
#define DB_ENVIRONMENT GIT_OBJECT_DIRECTORY
#define INDEX_ENVIRONMENT GIT_INDEX_FILE
+#define GRAFT_ENVIRONMENT GIT_GRAFT_FILE
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
+extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT GIT_ALTERNATE_OBJECT_DIRECTORIES
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -91,11 +91,108 @@ static unsigned long parse_commit_date(c
return date;
}
+static struct commit_graft {
+ unsigned char sha1[20];
+ int nr_parent;
+ unsigned char parent[0][20]; /* more */
+} **commit_graft;
+static int commit_graft_alloc, commit_graft_nr;
+
+static int commit_graft_pos(const unsigned char *sha1)
+{
+ int lo, hi;
+ lo = 0;
+ hi = commit_graft_nr;
+ while (lo hi) {
+ int mi = (lo + hi) / 2;
+ struct commit_graft *graft = commit_graft[mi];
+ int cmp = memcmp(sha1, graft-sha1, 20);
+ if (!cmp)
+ return mi;
+ if (cmp 0)
+ hi = mi;
+ else
+ lo = mi + 1;
+ }
+ return -lo - 1;
+}
+
+static void prepare_commit_graft(void)
+{
+ char *graft_file = get_graft_file();
+ FILE *fp = fopen(graft_file, r);
+ char buf[1024];
+ if (!fp) {
+ commit_graft = (struct commit_graft **) hack;
+ return;
+ }
+ while (fgets(buf, sizeof(buf), fp)) {
+ /* The format is just Commit Parent1 Parent2 ...\n */
+ int len = strlen(buf);
+ int i;
+ struct commit_graft *graft = NULL;
+
+ if (buf[len-1] == '\n')
+ buf[--len] = 0;
+ if (buf[0] == '#')
+ continue;
+ if ((len + 1) % 41) {
+ bad_graft_data:
+ error(bad graft data: %s, buf);
+ free(graft);
+ continue;
+ }
+ i = (len + 1) / 41 - 1;
+ graft = xmalloc(sizeof(*graft) + 20 * i);
+ graft-nr_parent = i;
+ if (get_sha1_hex(buf, graft-sha1))
+ goto bad_graft_data;
+ for (i = 40; i len; i += 41) {
+ if (buf[i] != ' ')
+ goto bad_graft_data;
+ if (get_sha1_hex(buf + i + 1, graft-parent[i/41]))
+ goto bad_graft_data;
+ }
+ i = commit_graft_pos(graft-sha1);
+ if (0 = i) {
+ error(duplicate graft data: %s, buf);
+ free(graft);
+ continue;
+ }
+ i = -i - 1;
+ if (commit_graft_alloc = ++commit_graft_nr) {
+ commit_graft_alloc = alloc_nr(commit_graft_alloc);
+ commit_graft = xrealloc(commit_graft,
+ sizeof(*commit_graft) *
+ commit_graft_alloc);
+ }
+ if (i commit_graft_nr)
+ memmove(commit_graft + i + 1,
+ commit_graft + i,
+ (commit_graft_nr - i - 1) *
+ sizeof(*commit_graft));
+ commit_graft[i] = graft;
+ }
+ fclose(fp);
+}
+
+static struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
+{
+ int pos;
+ if (!commit_graft)
+ prepare_commit_graft();
+ pos = commit_graft_pos(sha1);
+ if (pos 0)
+ return NULL;
+ return commit_graft[pos];
+}
+
int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
{
Re: Last mile to 1.0?
[EMAIL PROTECTED] writes: I still have the patch to make git-http-pull download packs, and I should be able to get it to read the objects/info/packs file without too much trouble. Another thing that may help you gain more parallelism in the initial set of requests is the rev-cache file. You can find out the ancestry information upfront by reading it, without waiting for the commits you asked to arrive. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
Hi, Junio C Hamano wrote:
Introduce a new file $GIT_DIR/info/grafts
Nice work.
Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Whatever occurs from love is always beyond good and evil.
-- Friedrich Nietzsche
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
Linus Torvalds [EMAIL PROTECTED] writes: This corner-case was triggered by a kernel commit that was not in date order, due to a misconfigured time zone that made the commit appear three hours older than it was. I have problems pulling linux kernel changes from 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first I thought your patch would fix it, but it doesn't: r3000:~/git$ cat linux/.git/HEAD b0825488a642cadcf39709961dde61440cb0731c r3000:~/git$ git-clone-script -l linux linux.test defaulting to local storage area 0 blocks r3000:~/git$ cd linux.test/ r3000:~/git/linux.test$ echo 33ac02aa4cef417871e128ab4a6565e751e5f3b2 .git/HEAD r3000:~/git/linux.test$ git-pull-script ../linux Packing 291 objects Unpacking 291 objects 100% (291/291) done Trying to merge b0825488a642cadcf39709961dde61440cb0731c into 33ac02aa4cef417871e128ab4a6565e751e5f3b2 Simple merge failed, trying Automatic merge Removing arch/mips/vr41xx/common/giu.c Auto-merging arch/s390/kernel/head.S. Auto-merging arch/s390/kernel/head64.S. Auto-merging arch/um/os-Linux/elf_aux.c. merge: warning: conflicts during merge ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c. Auto-merging arch/x86_64/kernel/smp.c. Auto-merging arch/x86_64/kernel/smpboot.c. merge: warning: conflicts during merge ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c. Auto-merging drivers/i2c/busses/i2c-mpc.c. merge: warning: conflicts during merge ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c. Removing drivers/ide/cris/ide-v10.c Removing drivers/media/dvb/frontends/lgdt3302.c Removing drivers/media/dvb/frontends/lgdt3302.h Removing drivers/media/dvb/frontends/lgdt3302_priv.h Removing drivers/serial/bast_sio.c Auto-merging drivers/usb/input/hid-input.c. Auto-merging drivers/video/fbmem.c. Auto-merging include/asm-i386/bitops.h. merge: warning: conflicts during merge ERROR: Merge conflict in include/asm-i386/bitops.h. Auto-merging include/asm-x86_64/smp.h. Auto-merging kernel/sys.c. merge: warning: conflicts during merge ERROR: Merge conflict in kernel/sys.c. Removing net/ipv4/utils.c Removing sound/pcmcia/vx/vx_entry.c Removing sound/pcmcia/vx/vxp440.c fatal: merge program failed Automatic merge failed, fix up by hand -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Bits from git-pb
Dear diary, on Fri, Jul 29, 2005 at 10:58:19AM CEST, I got a letter where Petr Baudis [EMAIL PROTECTED] told me that... (i) Keep the git-pb branch polished and nice-to-merge, if you want to pull from it. (ii) Keep the git-pb branch polished and nice-to-merge and rebase it regularily if you don't want loong edges in your history graph, but want to pull from it. (iii) Do wild things in the git-pb branch and send you patches. So I assume (iii) holds? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
Hi, is it possible that you forgot to initialize commit_graft_nr to 0? Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: Add asciidoc.conf file and gitlink: macro
Introduce an asciidoc.conf file with the purpose of adding a gitlink: macro
which will improve the manpage output. Most notably this changes the following
in cogito.7
...
cg-add: cg-add.html [-N] FILE...
Add files to the GIT repository.
cg-branch-add: cg-branch-add.html BRANCH_NAME LOCATION
Add new branch to the GIT repository.
...
to
...
cg-add [-N] FILE...
Add files to the GIT repository.
cg-branch-add BRANCH_NAME LOCATION
Add new branch to the GIT repository.
...
Signed-off-by: Jonas Fonseca [EMAIL PROTECTED]
---
I only did the Cogito part, since it was a lot easier. If this is
desirable for the GIT core manpages I'd be happy to provide a similar
patch to remove the confusing .html links from GIT manpages.
Documentation/Makefile |4 ++--
Documentation/asciidoc.conf| 18 ++
Documentation/make-cg-asciidoc |6 +++---
Documentation/make-cogito-asciidoc | 19 ++-
4 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -48,13 +48,13 @@ clean:
rm -f *.xml *.html *.1 *.7 cg-*.txt cogito.txt
%.html : %.txt
- asciidoc -b xhtml11 -d manpage $
+ asciidoc -b xhtml11 -d manpage -f asciidoc.conf $
%.1 %.7 : %.xml
xmlto man $
%.xml : %.txt
- asciidoc -b docbook -d manpage $
+ asciidoc -b docbook -d manpage -f asciidoc.conf $
cogito.txt : make-cogito-asciidoc
./make-cogito-asciidoc $@
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
new file mode 100644
--- /dev/null
+++ b/Documentation/asciidoc.conf
@@ -0,0 +1,18 @@
+## gitlink: macro
+#
+# Usage: gitlink:command[manpage-section]
+#
+# Note, {0} is the manpage section, while {target} is the command.
+#
+# Show GIT link as: command(section); if section is defined, else just show
+# the command.
+
+ifdef::backend-docbook[]
+[gitlink-inlinemacro]
+{target}{0?({0})}
+endif::backend-docbook[]
+
+ifdef::backend-xhtml11[]
+[gitlink-inlinemacro]
+a href={target}.html{target}{0?({0})}/a
+endif::backend-xhtml11[]
diff --git a/Documentation/make-cg-asciidoc b/Documentation/make-cg-asciidoc
--- a/Documentation/make-cg-asciidoc
+++ b/Documentation/make-cg-asciidoc
@@ -40,7 +40,7 @@ CAPTION=$(echo $HEADER | head -n 1 | t
# were referenced as `cg-command`. This way references from cg-* combos in
# code listings will be ignored.
BODY=$(echo $HEADER | sed '0,/^$/d' \
- | sed 's/`\(cg-[a-z-]\+\)`/link:\1.html[\1]/')
+ | sed 's/`\(cg-[a-z-]\+\)`/gitlink:\1[1]/')
DESCRIPTION=
OPTIONS=
@@ -108,6 +108,6 @@ $COPYRIGHT
SEE ALSO
-$COMMAND command is part of link:cogito.html[cogito(7)],
-a toolkit for managing link:git.html[git(1)] trees.
+$COMMAND command is part of gitlink:cogito[7],
+a toolkit for managing gitlink:git[7] trees.
__END__
diff --git a/Documentation/make-cogito-asciidoc
b/Documentation/make-cogito-asciidoc
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -8,10 +8,11 @@ ADVANCED_COMMANDS=$(ls ../cg-admin-*)
HELPER_COMMANDS=$(ls ../cg-X*) $(ls ../*-id | grep -v git-)
# Shorthand for the link markup.
-link()
+man()
{
- command=$1
- echo link:$command.html['$command']
+ section=$1
+ command=$2
+ echo gitlink:$command[$section]
}
# Print description list entry.
@@ -28,7 +29,7 @@ print_command_info()
;;
cg-*)
usage=$(sed -n '/^USAGE=/,0s/.*cg-[^ ]*\(.*\)/\1/p' $command)
- echo link:$cmdname.html[$cmdname] $usage::
+ echo gitlink:$cmdname[] $usage::
;;
esac
echo $caption
@@ -62,7 +63,7 @@ storage system. Amongst some of the note
for branching, tagging and multiple backends for distributing repositories
(local files, rsync, HTTP, ssh).
-'Cogito' is implemented as a series of 'bash(1)' scripts on top of $(link git)
+'Cogito' is implemented as a series of 'bash(1)' scripts on top of $(man 7 git)
(a content-tracking filesystem) with the goal of providing an interface for
working with the 'GIT' database in a manner similar to other SCM tools (like
'CVS', 'BitKeeper' or 'Monotone').
@@ -107,21 +108,21 @@ $(print_command_listing $HELPER_COMMANDS
Command Identifiers
---
BRANCH_NAME::
- Indicates a branch name added with the $(link cg-branch-add) command.
+ Indicates a branch name added with the $(man 1 cg-branch-add) command.
COMMAND::
Indicates a 'Cogito' command. The \`cg-\` prefix is optional.
LOCATION::
- Indicates a local file path or a URI. See $(link cg-branch-add) for a
+ Indicates a local file path or a URI. See $(man 1 cg-branch-add) for a
list of supported URI schemes.
COMMIT_ID, FROM_ID, TO_ID,
Re: [PATCH] Under NO_OPENSSL -lssl should not be used
On Fri, 29 Jul 2005, Junio C Hamano wrote: Would this be OK? I think it is ugly but it gets the job done. Looks ok. I'd suggest having some option to turn of curl too - I have one machine that doesn't have curl installed, and I just turn the things that depend on it off by hand by editing the makefile right now.. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Peter Osterlund wrote: I have problems pulling linux kernel changes from 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first I thought your patch would fix it, but it doesn't: No, this is a merge conflict failure, and you simply have conflicts in the tree. git did everything right, it just couldn't do an automatic merge. ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c. ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c. ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c. ERROR: Merge conflict in include/asm-i386/bitops.h. ERROR: Merge conflict in kernel/sys.c. We don't have any nice graphical tools to show these to you like BitKeeper had, although it shouldn't be fundamentally hard. What you need to do is basically edit all those five files, and look for the conflicts (they are just like normal CVS conflicts: orig-branch conflict-contents === pulled-branch conflict-contents and then you edit them to your liking until you have no more conflicts, and then you have to commit your manual resolve with git commit --all which will commit the merge _and_ your manual conflict resolution. This is something where a nice wrapper layer could do a lot better. I know there are graphical three-way merge programs available. But core git is no worse (and in fact a _lot_ better) than CVS in this regard, so I feel that the git merge, while obviously not perfect or even very smart, is sufficient for what git is (ie it's up to porcelain to do anything better). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Making it easier to find which change introduced a bug
On Sat, 30 Jul 2005, Alexander Nyberg wrote: Linus, do you think we could have something like patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's be placed into patches/ in a tree? Not really. The thing is, since the git patches really _aren't_ serial, and merging isn't based on patch-merging at all (unlike quilt, that literally merges patches as patches), you can't really linearize a git tree without getting some really strange behaviour. As it stands today it's easier for us who don't know git to just find out in which mainline kernel it works and which -mm it doesn't work in, get the broken-out and start push/pop. And I know I'm not the only one who has noticed this. What we can do is try to script the git bisection thing so that it's really trivial. It's actually very simple to use, and I think somebody had some example scripts around. Here's a simple starting point for somebody who wants to try.. It's not very well tested, but I've done _some_ testing on it to try to make sure it's at least reasonable. It adds four new git commands: - git bisect-start reset bisect state - git bisect-bad mark some version known-bad (if no arguments, then current HEAD) - git bisect-good mark some version known-good (if no arguments, then current HEAD) - git bisect do a bisection between the known bad and the known good heads, and check that version out. Then, the way you use it is: git bisect-start git bisect-bad # Current version is bad git bisect-good v2.6.13-rc2 # v2.6.13-rc2 was the last version tested that was good git bisect which will say something like Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect-good # this one is good git bisect which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say git-bisect-good or git-bisect-bad, and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in refs/bisect/bad. Oh, and then after you want to reset to the original head, do a git checkout master to get back to the master branch, instead of being in one of the bisection branches (git bisect-start will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of quilt push and quilt pop, now is it? Linus --- diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -62,7 +62,9 @@ SCRIPTS=git git-apply-patch-script git-m git-format-patch-script git-sh-setup-script git-push-script \ git-branch-script git-parse-remote git-verify-tag-script \ git-ls-remote-script git-clone-dumb-http git-rename-script \ - git-request-pull-script + git-request-pull-script git-bisect-bad-script git-bisect-good-script \ + git-bisect-script git-bisect-start-script + PROG= git-update-cache git-diff-files git-init-db git-write-tree \ git-read-tree git-commit-tree git-cat-file git-fsck-cache \ diff --git a/git-bisect-bad-script b/git-bisect-bad-script new file mode 100755 --- /dev/null +++ b/git-bisect-bad-script @@ -0,0 +1,4 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit +echo $rev $GIT_DIR/refs/bisect/bad diff --git a/git-bisect-good-script b/git-bisect-good-script new file mode 100755 --- /dev/null +++ b/git-bisect-good-script @@ -0,0 +1,4 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit +echo $rev $GIT_DIR/refs/bisect/good-$rev diff --git a/git-bisect-script b/git-bisect-script new file mode 100755 --- /dev/null +++ b/git-bisect-script @@ -0,0 +1,15 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +bad=$(git-rev-parse --revs-only --verify refs/bisect/bad) || exit +good=($(git-rev-parse --revs-only --not $(cd $GIT_DIR ; ls refs/bisect/good-*))) || exit +rev=$(git-rev-list --bisect $bad [EMAIL PROTECTED]) || exit +nr=$(git-rev-list $rev [EMAIL PROTECTED] | wc -l) || exit +if [ $nr = 0 ]; then + echo $bad is first bad commit + git-diff-tree --pretty $bad + exit 0 +fi +echo Bisecting: $nr revisions left to test after this +echo $rev $GIT_DIR/refs/heads/new-bisect +git checkout new-bisect || exit +cd $GIT_DIR mv refs/heads/new-bisect refs/heads/bisect ln -sf refs/heads/bisect HEAD diff --git a/git-bisect-start-script b/git-bisect-start-script new file mode 100755 --- /dev/null +++
Re: [PATCH 0/2] Bits from git-pb
Petr Baudis [EMAIL PROTECTED] writes: (iii) Do wild things in the git-pb branch and send you patches. So I assume (iii) holds? I have not answered this because I have not made up my mind. Certainly (iii) is probably the least work for me. My gut feeling is that I can deal with any of the above, but even when I pull from your tree, I expect to pull into pu first and after that the patches will go through my regular reshuffling cycle just like other patches I receive from e-mails. This may or may not cause interesting troubles when I merge again from git-pb, but we will see. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Bits from git-pb
Junio C Hamano [EMAIL PROTECTED] writes: I have not answered this because I have not made up my mind. Certainly (iii) is probably the least work for me. Certainly? Probably? Which one? I should not start typing before having a cup of coffee. **BLUSH** Anyway, yes I would appreciate if you take (iii) for the time being but if that is too much work for you then don't worry I'll learn to cope with any of the above. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
Linus Torvalds [EMAIL PROTECTED] writes: On Sat, 30 Jul 2005, Peter Osterlund wrote: I have problems pulling linux kernel changes from 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first I thought your patch would fix it, but it doesn't: No, this is a merge conflict failure, and you simply have conflicts in the tree. git did everything right, it just couldn't do an automatic merge. OK, but note that I didn't do any editing of any local files myself. Both commit ids are from your public linux kernel git tree. What I did was equivalent to: 1. rsync from rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ 2. waited a day or so. 3. git-pull-script from the same kernel.org repository. Is it expected that you end up with merge conflicts in this case? If that's the case, is there a better way to pull changes that doesn't involve having to resolve conflicts in files you didn't even know existed? I think it should be possible to just fast forward to the new HEAD in this situation. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Linus Torvalds wrote: On Sat, 30 Jul 2005, Peter Osterlund wrote: OK, but note that I didn't do any editing of any local files myself. Both commit ids are from your public linux kernel git tree. What I did was equivalent to: 1. rsync from rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ 2. waited a day or so. 3. git-pull-script from the same kernel.org repository. Is it expected that you end up with merge conflicts in this case? Nope. Something went wrong. I think it should be possible to just fast forward to the new HEAD in this situation. Indeed. Can you send me your HEAD and MERGE_HEAD (don't do the merge). HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2 MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Peter Osterlund wrote: Can you send me your HEAD and MERGE_HEAD (don't do the merge). HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2 MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c Bingo. Yup, it's git-merge-base, and it is confused by the same thing that confused git-rev-list. Thanks, I'll fix it. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Shipping gitk as part of core git.
It appears that gitk gets wider test coverage only after it is
pulled into git.git repository. I think it would be a good idea
for me to pull from you often.
Recently there was a discussion with binary packaging folks.
While I do not mind, and actually I would prefer, shipping gitk
as part of the core GIT, I have never heard about your
preference. As long as gitk is just a single file (or even a
handful files in the future) project that does not have a
filename that overlaps with core GIT, I can continue pulling
from you and I think the binary packaging folks can produce
separate git-core and gitk package out of git.git tree without
problems. However, once you start wanting to have your own
Makefile and maybe debian/rules file for packaging, for example,
I suspect the way currently things are set up would break
miserably. It's all Linus' fault to have merged with your tree
in the first place ;-).
Anyhow, I have one bug to report. I selected one rev, and then
said diff this - selected from right-click menu on an
adjacent one, and I got this:
wrong # args: should be startdiff ids
wrong # args: should be startdiff ids
while executing
startdiff $newid [list $oldid]
(procedure diffvssel line 28)
invoked from within
diffvssel 0
invoked from within
.rowctxmenu invoke active
(uplevel body line 1)
invoked from within
uplevel #0 [list $w invoke active]
(procedure tk::MenuInvoke line 47)
invoked from within
tk::MenuInvoke .rowctxmenu 1
(command bound to event)
The following seems to fix it.
Fix diff invoked from the right-click menu.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
# - master: [PATCH] Making it easier to find which change introduced a bug
# + (working tree)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -2700,7 +2700,7 @@ proc diffvssel {dirn} {
$ctext conf -state disabled
$ctext tag delete Comments
$ctext tag remove found 1.0 end
-startdiff $newid [list $oldid]
+startdiff [list $newid $oldid]
}
proc mkpatch {} {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Junio C Hamano [EMAIL PROTECTED] writes: Having said that, I do not particulary think allowing push to write into different ref is an unreasonable thing. As you pointed out long time ago when send-pack was first done, the protocol is not so easily extensible, so this may require either backward incompatible protocol change, or introduction of a new program pair send-pack-2 / receive-pack-2. I'll take a look sometime this weekend. Bedtime. Again, what Linus designed turns out to be perfect. It does not appear to need a protocol level change at all. I'll code up something over the weekend if I am lucky. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
Linus Torvalds [EMAIL PROTECTED] writes: On Sat, 30 Jul 2005, Linus Torvalds wrote: Yup, it's git-merge-base, and it is confused by the same thing that confused git-rev-list. Thanks, I'll fix it. Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe somebody else can come up with a better one. I think this one ends up being quite a bit more expensive than the old one (it will look up _all_ common parents that have a child that isn't common, and then select the newest one of the bunch), but I haven't really thought it through very much. I bet there is a smarter way to do this, but this _should_ fix the problem Peter sees. Peter? Yes, it does fix the problem. Thanks. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Making it easier to find which change introduced a bug
I have placed this, after slight reworking, in the master
branch.
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the next thing you would want to do after telling it
bad and good is always to bisect, this version does it
automatically for you.
- I think the termination condition was wrong. The original
version checked if the set of revisions reachable from next
bisection but not rechable from any of the known good ones
is empty, but if the current bisection was a bad one, this
would not terminate, so I changed it to terminate it when
the set becomes a singleton or empty.
- Removed the use of shell array variable.
]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
Makefile |2 -
git-bisect-script | 158 +
2 files changed, 159 insertions(+), 1 deletions(-)
create mode 100755 git-bisect-script
8cc6a083198877fc32224b73c61ec6e6cf8a96f5
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -62,7 +62,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
- git-request-pull-script
+ git-request-pull-script git-bisect-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-bisect-script b/git-bisect-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-script
@@ -0,0 +1,158 @@
+#!/bin/sh
+. git-sh-setup-script || dir Not a git archive
+
+usage() {
+echo 2 'usage: git bisect [start | bad | good | next | reset]
+git bisect start reset bisect state and start bisection.
+git bisect bad [rev] mark rev a known-bad revision.
+git bisect good [rev...] mark rev... known-good revisions.
+git bisect nextfind next bisection to test and check
it out.
+git bisect reset [branch]finish bisection search and go back to branch.'
+exit 1
+}
+
+bisect_autostart() {
+ test -d $GIT_DIR/refs/bisect || {
+ echo 2 'You need to start by git bisect start'
+ if test -t 0
+ then
+ echo 2 -n 'Do you want me to do it for you [Y/n]? '
+ read yesno
+ case $yesno in
+ [Nn]*)
+ exit ;;
+ esac
+ bisect_start
+ else
+ exit 1
+ fi
+ }
+}
+
+bisect_start() {
+case $# in 0) ;; *) usage ;; esac
+ #
+ # Verify HEAD. If we were bisecting before this, reset to the
+ # top-of-line master first!
+ #
+ head=$(readlink $GIT_DIR/HEAD) || die Bad HEAD - I need a symlink
+ case $head in
+ refs/heads/bisect*)
+ git checkout master || exit
+ ;;
+ refs/heads/*)
+ ;;
+ *)
+ die Bad HEAD - strange symlink
+ ;;
+ esac
+
+ #
+ # Get rid of any old bisect state
+ #
+ rm -f $GIT_DIR/refs/heads/bisect
+ rm -rf $GIT_DIR/refs/bisect/
+ mkdir $GIT_DIR/refs/bisect
+}
+
+bisect_bad() {
+ bisect_autostart
+case $# in 0 | 1) ;; *) usage ;; esac
+ rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit
+ echo $rev $GIT_DIR/refs/bisect/bad
+ bisect_auto_next
+}
+
+bisect_good() {
+ bisect_autostart
+case $# in
+ 0)revs=$(git-rev-parse --verify HEAD) || exit ;;
+ *)revs=$(git-rev-parse --revs-only $@) || exit ;;
+ esac
+ for rev in $revs
+ do
+ echo $rev $GIT_DIR/refs/bisect/good-$rev
+ done
+ bisect_auto_next
+}
+
+bisect_next_check() {
+ next_ok=no
+test -f $GIT_DIR/refs/bisect/bad
+ case $(cd $GIT_DIR echo refs/bisect/good-*) in
+ refs/bisect/good-\*) ;;
+ *) next_ok=yes ;;
+ esac
+ case $next_ok,$1 in
+ no,) false ;;
+ no,fail)
+ echo 2 'You need to give me at least one good and one bad
revisions.'
+ exit 1 ;;
+ *)
+ true ;;
+ esac
+}
+
+bisect_auto_next() {
+ bisect_next_check bisect_next
+}
+
+bisect_next() {
+case $# in 0) ;; *) usage ;; esac
+ bisect_autostart
+ bisect_next_check fail
+ bad=$(git-rev-parse --verify refs/bisect/bad)
+ good=$(git-rev-parse --sq --revs-only --not \
+ $(cd $GIT_DIR ls refs/bisect/good-*))
+ rev=$(eval git-rev-list
Re: [PATCH] add NO_CURL option to the Makefile
Johannes Schindelin [EMAIL PROTECTED] writes: This patch implements Linus' idea that if you are not interested in pulling by HTTP, you can now say NO_CURL=1 make to compile everything except git-http-pull (thus not needing curl at all). Thanks. Obviously this does not take care of the use of curl executable to handle http:// URL in clone and fetch, but I do not think that is worth the trouble (we should document it though). I love it I can just slow down and let others submit obviously correct patches, which I can just slurp in. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add NO_CURL option to the Makefile
On Sat, 30 Jul 2005, Junio C Hamano wrote: I love it I can just slow down and let others submit obviously correct patches, which I can just slurp in. You're obviously doing well as a maintainer. Only stupid people try to do everything themselves. Personally, I spend a _lot_ of time communicating, because even if it's a lot more work to explain (in detail) what I want done, and it doesn't work out all the time, and I sometimes have to do it myself _anyway_, if it works even just occasionally, it not only gets people involved, it makes them do it themselves next time around without prodding, and then you just sit back, sip a foofy tropical drink, and take the credit. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix interesting git-rev-list corner case
Linus Torvalds [EMAIL PROTECTED] writes: On Sat, 31 Jul 2005, Peter Osterlund wrote: I bet there is a smarter way to do this, but this _should_ fix the problem Peter sees. Peter? Yes, it does fix the problem. Thanks. Ok, Junio, can you apply the git-merge-base patch? It's not perfect, but it's clearly better than what's there right now. Add a Signed-off-by: Linus Torvalds [EMAIL PROTECTED] and edit the description a bit, perhaps. OK. It's already sitting at the top of the pu branch, so I'll just advance master with your sign off added. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
send-pack question.
I have been looking at send-pack because some people seem to
want to push into a remote repository that names heads
differently from local. I have some questions that do not have
to do with anything about their request, but about what
the current code intends to do.
* Right now, send-pack --all into an empty repository does
not do anything, but send-pack --all master into an empty
repository pushes all local heads. This is because we do not
check send_all when deciding if we want to call try_match
on local references. I am assuming this is an oversight; am
I correct? If so, does the attached patch look OK?
* It appears to me that you can say send-pack net, and
depending on how the remote lists its refs, you can end up
updating their refs/heads/net or refs/tags/net. More
confusingly, you could say send-pack net net to update
both. More realistically, you could get confused with a
remote that has refs/heads/jgarzik/net and
refs/heads/dsmiller/net in this way. I think it should
detect, stop and warn about the ambiguity and require the
user to be more explicit. Am I reading the current code
correctly?
I've always _hated_ the interface to path_match() which
pretends to be just a boolean function but actually has a
grave side effect, by the way.
---
# - pu: git-fetch-script http fix.
# + (working tree)
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -4,7 +4,8 @@
#include pkt-line.h
static const char send_pack_usage[] =
-git-send-pack [--exec=git-receive-pack] [host:]directory [heads]*;
+git-send-pack [--all] [--exec=git-receive-pack] remote [head...]\n
+ --all and explicit head specification are mutually exclusive.;
static const char *exec = git-receive-pack;
static int send_all = 0;
static int force_update = 0;
@@ -214,7 +215,7 @@ static int send_pack(int in, int out, in
/*
* See if we have any refs that the other end didn't have
*/
- if (nr_match) {
+ if (nr_match || send_all) {
local_ref_nr_match = nr_match;
local_ref_match = match;
local_ref_list = ref_list;
@@ -281,6 +282,8 @@ int main(int argc, char **argv)
}
if (!dest)
usage(send_pack_usage);
+ if (heads send_all)
+ usage(send_pack_usage);
pid = git_connect(fd, dest, exec);
if (pid 0)
return 1;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
