* [PATCH] Fix debian doc-base
From: Kalle Valo @ 2005-08-03 23:39 UTC (permalink / raw)
To: git
Fixed location of HTML documents in debian doc-base file.
Without this fix debian package won't install properly (complains
about missing /usr/share/doc/git-core/html directory).
---
debian/git-core.doc-base | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
194759c0447f88804dfb43615bdf7a6e412c3240
diff --git a/debian/git-core.doc-base b/debian/git-core.doc-base
--- a/debian/git-core.doc-base
+++ b/debian/git-core.doc-base
@@ -5,8 +5,8 @@ Abstract: This manual describes git
Section: Devel
Format: HTML
-Index: /usr/share/doc/git-core/html/git.html
-Files: /usr/share/doc/git-core/html/*.html
+Index: /usr/share/doc/git-core/git.html
+Files: /usr/share/doc/git-core/*.html
Format: text
Files: /usr/share/doc/git-core/git-core.txt
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Linus Torvalds @ 2005-08-03 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek9a8uy9.fsf_-_@assigned-by-dhcp.cox.net>
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> This allows git-send-pack to push local refs to a destination
> repository under different names.
Looks good, except I was almost hoping for one modification:
> Here is the name mapping rules for refs.
>
> * If there is no ref mapping on the command line:
>
> - if '--all' is specified, it is equivalent to specifying
> <local> ":" <local> for all the existing local refs on the
> command line
> - otherwise, it is equivalent to specifying <ref> ":" <ref> for
> all the refs that exist on both sides.
>
> * <name> is just a shorthand for <name> ":" <name>
>
> * <src> ":" <dst>
>
> push ref that matches <src> to ref that matches <dst>.
In this format, "src" makes sense as a generic sha1_name, and _not_
necessarily limited to a ref-name.
IOW, there's really no reason to not allow
git-send-pack .. dest .. <sha1>:dst-ref
where "<sha1>" may be something else than a ref (but a ref obviously ends
up being one such thing).
For example, let's say that I've got stuff at the HEAD of my tree that I'm
not quite ready to push out yet, but I _do_ want to push out the parent of
the current head. I'd love to be able to just do
git-send-pack parent $(git-rev-parse HEAD^):master
and there's no real reason why that syntax shouldn't just work: it's
entirely logical to say "I want to push out the parent of my HEAD as
'master' on the other end", and that's _exactly_ what the above says.
So:
> - It is an error if <src> does not match exactly one of local
> refs.
I think "src" should just be seen as any random SHA1 name, and we should
use "get_sha()" to convert it to a SHA1.
In contrast, "dst" is obviously a real ref name, and as such:
> - It is an error if <dst> matches more than one remote refs.
makes sense.
That makes your next rule a bit iffy, though:
> - If <dst> does not match any remote refs, either
>
> - it has to start with "refs/"; <dst> is used as the
> destination literally in this case.
>
> - <src> == <dst> and the ref that matched the <src> must not
> exist in the set of remote refs; the ref matched <src>
> locally is used as the name of the destination.
since "src" from a local standpoint isn't really a ref-name at all.
But hey, your current patch looks fine already. It doesn't _quite_ do what
I had in mind, but it gets very very close.
Linus
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Junio C Hamano @ 2005-08-04 0:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508031641270.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> git-send-pack parent $(git-rev-parse HEAD^):master
>
> and there's no real reason why that syntax shouldn't just work: it's
> entirely logical to say "I want to push out the parent of my HEAD as
> 'master' on the other end", and that's _exactly_ what the above says.
Yes I think allowing get_sha()-able thing on the left hand side
makes things, well, interesting. I need to think about it a bit.
When I do something like your example, I create a temporary
lightweight tag and push it. Snapshots in JIT are just a bunch
of lightweight tags so..
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Linus Torvalds @ 2005-08-04 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bpq8t2a.fsf@assigned-by-dhcp.cox.net>
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> > git-send-pack parent $(git-rev-parse HEAD^):master
>
> When I do something like your example, I create a temporary
> lightweight tag and push it. Snapshots in JIT are just a bunch
> of lightweight tags so..
I like the scripting, and combining pipelines of commands kind of thing.
I agree that you can just make a temporary tag, but it's a bit like in any
scripting stuff - you could use a temp-file, but it's just cleaner if you
can keep temporary values in local variables (or in a local cmd pipeline
like the above).
Whenever you script somethign that creates a new tag or ref, you suddenly
have cleanup and uniqueness issues etc.
Linus
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Junio C Hamano @ 2005-08-04 1:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508031641270.3258@g5.osdl.org>
Well, I pushed it out, although I do agree that we should be
able to give anything get_sha()-able on the source side of the
push. Probably a revised version should have the following
semantics:
$ git-send-pack [--all] <remote> [<ref>...]
- When no <ref> is specified:
- with '--all', it is the same as specifying the full refs/*
path for all local refs;
- without '--all', it is the same as specifying the full
refs/* path for refs that exist on both ends;
- When one or more <ref>s are specified:
- a single token <ref> (i.e. no colon) must be a pattern that
tail-matches refs/* path for an existing local ref. It is
an error for the pattern to match no local ref, or more
than one local refs. The matching ref is pushed to the
remote end under the same name.
- <src>:<dst> can have different cases. <src> is first tried
as the tail-matching pattern for refs/* path.
- If more than one matches are found, it is an error.
- If one match is found, <dst> must either match no remote
ref and start with "refs/", or match exactly one remote
ref. That remote ref is updated with the sha1 value
obtained by the <src> sha1.
- If no match is found, it is given to get_extended_sha1();
it is an error if get_extended_sha1() does not find an
object name. If it succeeds, <dst> must either match
no remote ref and start with "refs/" or match exactly
one remote ref. That remote ref is updated with the sha1
value.
^ permalink raw reply
* gitweb: not all files listed in commit list
From: Olof Johansson @ 2005-08-04 1:49 UTC (permalink / raw)
To: git
Hi,
My apologies if this has already been found and reported; I'm not
tracking the list closely.
It seems that newly introduced files are not shown in gitweb.
For example, see the following commit:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fce0d5740322b98b863f9e609f5a9bd4c06703af
"13 files changed:", but only 11 listed. The two newly added files
(arch/ppc64/kernel/machine_kexec.c and include/asm-ppc64/kexec.h) are
not shown.
-Olof
^ permalink raw reply
* [Patch] Fix sparse warnings
From: Alecs King @ 2005-08-04 3:35 UTC (permalink / raw)
To: git
fix one 'should it be static?' warning and
two 'mixing declarations and code' warnings.
Signed-off-by: Alecs King <alecsk@gmail.com>
---
connect.c | 3 ++-
ssh-pull.c | 2 +-
tools/mailinfo.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/connect.c b/connect.c
--- a/connect.c
+++ b/connect.c
@@ -219,6 +219,7 @@ static struct ref *find_ref_by_name(stru
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all)
{
+ int len;
struct refspec *rs = parse_ref_spec(nr_refspec, refspec);
if (nr_refspec)
@@ -236,7 +237,7 @@ int match_refs(struct ref *src, struct r
if (!all)
continue;
/* Create a new one and link it */
- int len = strlen(src->name) + 1;
+ len = strlen(src->name) + 1;
dst_peer = xcalloc(1, sizeof(*dst_peer) + len);
memcpy(dst_peer->name, src->name, len);
memcpy(dst_peer->new_sha1, src->new_sha1, 20);
diff --git a/ssh-pull.c b/ssh-pull.c
--- a/ssh-pull.c
+++ b/ssh-pull.c
@@ -10,7 +10,7 @@ static int fd_out;
static unsigned char remote_version = 0;
static unsigned char local_version = 1;
-ssize_t force_write(int fd, void *buffer, size_t length)
+static ssize_t force_write(int fd, void *buffer, size_t length)
{
ssize_t ret = 0;
while (ret < length) {
diff --git a/tools/mailinfo.c b/tools/mailinfo.c
--- a/tools/mailinfo.c
+++ b/tools/mailinfo.c
@@ -152,13 +152,13 @@ static void cleanup_space(char *buf)
static void handle_rest(void)
{
+ FILE *out = cmitmsg;
char *sub = cleanup_subject(subject);
cleanup_space(name);
cleanup_space(date);
cleanup_space(email);
cleanup_space(sub);
printf("Author: %s\nEmail: %s\nSubject: %s\nDate: %s\n\n", name, email, sub, date);
- FILE *out = cmitmsg;
do {
if (!memcmp("diff -", line, 6) ||
--
Alecs King
^ permalink raw reply
* bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-04 4:53 UTC (permalink / raw)
To: Git Mailing List
I have been having lots of fun using 'git bisect' to find the commit
that broke S3 wake on my laptop. But in its last step it gives an
answer that cannot be right. I had not used git until now, so I may be
missing something obvious: Corrections will be gratefully received. I'm
using git from git-2005-08-03.tar.gz on i386 (TP 600X, Debian testing).
Before using git bisect, I had tested enough to know that 2.6.13-rc1 was
fine and 2.6.13-rc2-git1 was not (it would sleep but waking up would
hang). So I compiled all the 2.6.13-rc1-git* snapshots and found that
2.6.13-rc1-git7 was the last one that worked, and 2.6.13-rc2-git1 was
the first to fail (see <http://bugzilla.kernel.org/show_bug.cgi?id=4989>
if you are curious about the bug itself).
Time to use 'git bisect' to find where in between the S3 wake got
broken. I'll give all the commands I did so you can (hopefully!)
reproduce the problem.
I began by following the useful directions at
<http://linux.yyz.us/git-howto.html> to download the 2.6 repository:
repo=rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone $repo linux-2.6
cd linux-2.6
rsync -a --verbose --stats --progress $repo/ .git/
Then I binary searched, compiling and testing, until bisect told me I
was done. Here's the output of a script (run with #!/bin/bash -x) that
reproduces the problem in the clean archive made above.
======================================================================
+ git checkout
+ git bisect reset
+ git bisect start
+ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3 # 2.6.13-rc1-git7
+ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6 # 2.6.13-rc2-git1
Bisecting: 42 revisions left to test after this
+ cat .git/HEAD
b2f571026594884e7a2a3f8bc6ad5c92e0703330
+ git bisect good
Bisecting: 30 revisions left to test after this
+ cat .git/HEAD
450008b5a62bb09445ae05c4d01d510386c9435d
+ git bisect good
Bisecting: 15 revisions left to test after this
+ cat .git/HEAD
a9df3597fec5472d0840fbfdc2a3fac5268f7d08
+ git bisect bad
Bisecting: 8 revisions left to test after this
+ cat .git/HEAD
28e8c3ad9464de54a632f00ab3df88fa5f4652d1
+ git bisect bad
Bisecting: 4 revisions left to test after this
+ cat .git/HEAD
c774e93e2152d0be2612739418689e6e6400f4eb
+ git bisect bad
Bisecting: 2 revisions left to test after this
+ cat .git/HEAD
b4634484815e1879512a23e4f59eef648135c30a
+ git bisect bad
b4634484815e1879512a23e4f59eef648135c30a is first bad commit
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)
Author: Greg KH <greg@kroah.com>
Date: Wed Jul 6 08:51:03 2005 -0700
[PATCH] Fix bt87x.c build problem
Missing forward declaration
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
:040000 040000 5717e17e384b0b40e409966403e2b8dfdab615a9 4ba0c028e80bf81c5c782e9047bd484a1eeadca4 M sound
======================================================================
The answer makes no sense since my .config doesn't use the bt87x driver
(the TP600X uses a snd-cs46xx). To be sure, I checked the diff with
git diff 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737..b4634484815e1879512a23e4f59eef648135c30a
The commit changed only sound/pci/bt87x.c
I do believe this line at the end of the bisection:
b4634484815e1879512a23e4f59eef648135c30a is first bad commit
But
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)
cannot be right. Where did 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
come from? The last good commit was
450008b5a62bb09445ae05c4d01d510386c9435d
so shouldn't bisect (if there's really only 1 commit in left now) say
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 450008b5a62bb09445ae05c4d01d510386c9435d)
$ git diff 450008b5a62bb09445ae05c4d01d510386c9435d \
b4634484815e1879512a23e4f59eef648135c30a \
| grep 'diff --git' | awk '{print $3}'
produces this list of changed files (I'm sure there's an easier way):
a/arch/arm/kernel/armksyms.c
a/arch/arm/mach-ixp4xx/common-pci.c
a/arch/arm/mach-ixp4xx/coyote-setup.c
a/arch/arm/mach-ixp4xx/ixdp425-setup.c
a/arch/arm/mm/proc-v6.S
a/drivers/pci/pci-driver.c
a/include/asm-arm/arch-ixp4xx/io.h
a/sound/pci/bt87x.c
I suspect that bisect jumped the gun at the end, and that there are a
few more revisions to test. Maybe the revision tree structure gets a
bit complicated and breaks an implicit linearity assumption in bisect?
Probably 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is the commit just
before b4634484815e1879512a23e4f59eef648135c30a (the first one I know to
be bad), and I'm guessing that 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
is bad too.
The suspect change is probably to drivers/pci/pci-driver.c since all the
other changed files are the unused bt87x sound driver or are for the arm
architecture. Here is that diff:
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -17,13 +17,13 @@
* Dynamic device IDs are disabled for !CONFIG_HOTPLUG
*/
+#ifdef CONFIG_HOTPLUG
+
struct pci_dynid {
struct list_head node;
struct pci_device_id id;
};
-#ifdef CONFIG_HOTPLUG
-
/**
* store_new_id
*
But whether moving back the CONFIG_HOTPLUG fixes my S3 wake is another
story, one for the acpi-devel list (once I do the experiment).
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Junio C Hamano @ 2005-08-04 5:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508031641270.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In this format, "src" makes sense as a generic sha1_name, and _not_
> necessarily limited to a ref-name.
>
> IOW, there's really no reason to not allow
>
> git-send-pack .. dest .. <sha1>:dst-ref
>
> where "<sha1>" may be something else than a ref (but a ref obviously ends
> up being one such thing).
>
> For example, let's say that I've got stuff at the HEAD of my tree that I'm
> not quite ready to push out yet, but I _do_ want to push out the parent of
> the current head. I'd love to be able to just do
>
> git-send-pack parent $(git-rev-parse HEAD^):master
>
> and there's no real reason why that syntax shouldn't just work: it's
> entirely logical to say "I want to push out the parent of my HEAD as
> 'master' on the other end", and that's _exactly_ what the above says.
While I have not updated the send-pack <src>:<dst> syntax, I
added a horrible hack that some people may love to see. This
removes the need to use git-rev-parse from many commands.
This is a preview. I've run the standard test suite and it does
not seem to break anything, but I expect it will stay in "pu"
for a while.
------------
[PATCH] Update get_sha1() to grok extended format.
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 3 +
rev-parse.c | 188 +-------------------------------------------------
sha1_file.c | 39 ----------
sha1_name.c | 222 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 229 insertions(+), 223 deletions(-)
create mode 100644 sha1_name.c
99ef7de3e234347d2af1ab2129ce99c5876b591b
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -95,7 +95,8 @@ LIB_H=cache.h object.h blob.h tree.h com
pack.h pkt-line.h refs.h
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
- refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
+ refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o \
+ sha1_name.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -21,8 +21,6 @@ static int output_sq = 0;
#define REVERSED 1
static int show_type = NORMAL;
-static int get_extended_sha1(char *name, unsigned char *sha1);
-
/*
* Some arguments are relevant "revision" arguments,
* others are about output format or other details.
@@ -107,182 +105,6 @@ static void show_arg(char *arg)
show_norev(arg);
}
-static int get_parent(char *name, unsigned char *result, int idx)
-{
- unsigned char sha1[20];
- int ret = get_extended_sha1(name, sha1);
- struct commit *commit;
- struct commit_list *p;
-
- if (ret)
- return ret;
- commit = lookup_commit_reference(sha1);
- if (!commit)
- return -1;
- if (parse_commit(commit))
- return -1;
- if (!idx) {
- memcpy(result, commit->object.sha1, 20);
- return 0;
- }
- p = commit->parents;
- while (p) {
- if (!--idx) {
- memcpy(result, p->item->object.sha1, 20);
- return 0;
- }
- p = p->next;
- }
- return -1;
-}
-
-static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
-{
- static char dirname[PATH_MAX];
- char hex[40];
- DIR *dir;
- int found;
-
- snprintf(dirname, sizeof(dirname), "%s/%.2s", get_object_directory(), name);
- dir = opendir(dirname);
- sprintf(hex, "%.2s", name);
- found = 0;
- if (dir) {
- struct dirent *de;
- while ((de = readdir(dir)) != NULL) {
- if (strlen(de->d_name) != 38)
- continue;
- if (memcmp(de->d_name, name + 2, len-2))
- continue;
- memcpy(hex + 2, de->d_name, 38);
- if (++found > 1)
- break;
- }
- closedir(dir);
- }
- if (found == 1)
- return get_sha1_hex(hex, sha1) == 0;
- return 0;
-}
-
-static int match_sha(unsigned len, const unsigned char *a, const unsigned char *b)
-{
- do {
- if (*a != *b)
- return 0;
- a++;
- b++;
- len -= 2;
- } while (len > 1);
- if (len)
- if ((*a ^ *b) & 0xf0)
- return 0;
- return 1;
-}
-
-static int find_short_packed_object(int len, const unsigned char *match, unsigned char *sha1)
-{
- struct packed_git *p;
-
- prepare_packed_git();
- for (p = packed_git; p; p = p->next) {
- unsigned num = num_packed_objects(p);
- unsigned first = 0, last = num;
- while (first < last) {
- unsigned mid = (first + last) / 2;
- unsigned char now[20];
- int cmp;
-
- nth_packed_object_sha1(p, mid, now);
- cmp = memcmp(match, now, 20);
- if (!cmp) {
- first = mid;
- break;
- }
- if (cmp > 0) {
- first = mid+1;
- continue;
- }
- last = mid;
- }
- if (first < num) {
- unsigned char now[20], next[20];
- nth_packed_object_sha1(p, first, now);
- if (match_sha(len, match, now)) {
- if (nth_packed_object_sha1(p, first+1, next) || !match_sha(len, match, next)) {
- memcpy(sha1, now, 20);
- return 1;
- }
- }
- }
- }
- return 0;
-}
-
-static int get_short_sha1(char *name, unsigned char *sha1)
-{
- int i;
- char canonical[40];
- unsigned char res[20];
-
- memset(res, 0, 20);
- memset(canonical, 'x', 40);
- for (i = 0;;i++) {
- unsigned char c = name[i];
- unsigned char val;
- if (!c || i > 40)
- break;
- if (c >= '0' && c <= '9')
- val = c - '0';
- else if (c >= 'a' && c <= 'f')
- val = c - 'a' + 10;
- else if (c >= 'A' && c <='F') {
- val = c - 'A' + 10;
- c -= 'A' - 'a';
- }
- else
- return -1;
- canonical[i] = c;
- if (!(i & 1))
- val <<= 4;
- res[i >> 1] |= val;
- }
- if (i < 4)
- return -1;
- if (find_short_object_filename(i, canonical, sha1))
- return 0;
- if (find_short_packed_object(i, res, sha1))
- return 0;
- return -1;
-}
-
-/*
- * This is like "get_sha1()", except it allows "sha1 expressions",
- * notably "xyz^" for "parent of xyz"
- */
-static int get_extended_sha1(char *name, unsigned char *sha1)
-{
- int parent, ret;
- int len = strlen(name);
-
- parent = 1;
- if (len > 2 && name[len-1] >= '0' && name[len-1] <= '9') {
- parent = name[len-1] - '0';
- len--;
- }
- if (len > 1 && name[len-1] == '^') {
- name[len-1] = 0;
- ret = get_parent(name, sha1, parent);
- name[len-1] = '^';
- if (!ret)
- return 0;
- }
- ret = get_sha1(name, sha1);
- if (!ret)
- return 0;
- return get_short_sha1(name, sha1);
-}
-
static void show_default(void)
{
char *s = def;
@@ -291,7 +113,7 @@ static void show_default(void)
unsigned char sha1[20];
def = NULL;
- if (!get_extended_sha1(s, sha1)) {
+ if (!get_sha1(s, sha1)) {
show_rev(NORMAL, sha1);
return;
}
@@ -372,10 +194,10 @@ int main(int argc, char **argv)
unsigned char end[20];
char *n = dotdot+2;
*dotdot = 0;
- if (!get_extended_sha1(arg, sha1)) {
+ if (!get_sha1(arg, sha1)) {
if (!*n)
n = "HEAD";
- if (!get_extended_sha1(n, end)) {
+ if (!get_sha1(n, end)) {
if (no_revs)
continue;
def = NULL;
@@ -386,14 +208,14 @@ int main(int argc, char **argv)
}
*dotdot = '.';
}
- if (!get_extended_sha1(arg, sha1)) {
+ if (!get_sha1(arg, sha1)) {
if (no_revs)
continue;
def = NULL;
show_rev(NORMAL, sha1);
continue;
}
- if (*arg == '^' && !get_extended_sha1(arg+1, sha1)) {
+ if (*arg == '^' && !get_sha1(arg+1, sha1)) {
if (no_revs)
continue;
def = NULL;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -46,21 +46,6 @@ int get_sha1_hex(const char *hex, unsign
return 0;
}
-static int get_sha1_file(const char *path, unsigned char *result)
-{
- char buffer[60];
- int fd = open(path, O_RDONLY);
- int len;
-
- if (fd < 0)
- return -1;
- len = read(fd, buffer, sizeof(buffer));
- close(fd);
- if (len < 40)
- return -1;
- return get_sha1_hex(buffer, result);
-}
-
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
static void setup_git_env(void)
@@ -132,30 +117,6 @@ int safe_create_leading_directories(char
return 0;
}
-int get_sha1(const char *str, unsigned char *sha1)
-{
- static const char *prefix[] = {
- "",
- "refs",
- "refs/tags",
- "refs/heads",
- "refs/snap",
- NULL
- };
- const char **p;
-
- if (!get_sha1_hex(str, sha1))
- return 0;
-
- for (p = prefix; *p; p++) {
- char * pathname = git_path("%s/%s", *p, str);
- if (!get_sha1_file(pathname, sha1))
- return 0;
- }
-
- return -1;
-}
-
char * sha1_to_hex(const unsigned char *sha1)
{
static char buffer[50];
diff --git a/sha1_name.c b/sha1_name.c
new file mode 100644
--- /dev/null
+++ b/sha1_name.c
@@ -0,0 +1,222 @@
+#include "cache.h"
+#include "commit.h"
+
+static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
+{
+ static char dirname[PATH_MAX];
+ char hex[40];
+ DIR *dir;
+ int found;
+
+ snprintf(dirname, sizeof(dirname), "%s/%.2s", get_object_directory(), name);
+ dir = opendir(dirname);
+ sprintf(hex, "%.2s", name);
+ found = 0;
+ if (dir) {
+ struct dirent *de;
+ while ((de = readdir(dir)) != NULL) {
+ if (strlen(de->d_name) != 38)
+ continue;
+ if (memcmp(de->d_name, name + 2, len-2))
+ continue;
+ memcpy(hex + 2, de->d_name, 38);
+ if (++found > 1)
+ break;
+ }
+ closedir(dir);
+ }
+ if (found == 1)
+ return get_sha1_hex(hex, sha1) == 0;
+ return 0;
+}
+
+static int match_sha(unsigned len, const unsigned char *a, const unsigned char *b)
+{
+ do {
+ if (*a != *b)
+ return 0;
+ a++;
+ b++;
+ len -= 2;
+ } while (len > 1);
+ if (len)
+ if ((*a ^ *b) & 0xf0)
+ return 0;
+ return 1;
+}
+
+static int find_short_packed_object(int len, const unsigned char *match, unsigned char *sha1)
+{
+ struct packed_git *p;
+
+ prepare_packed_git();
+ for (p = packed_git; p; p = p->next) {
+ unsigned num = num_packed_objects(p);
+ unsigned first = 0, last = num;
+ while (first < last) {
+ unsigned mid = (first + last) / 2;
+ unsigned char now[20];
+ int cmp;
+
+ nth_packed_object_sha1(p, mid, now);
+ cmp = memcmp(match, now, 20);
+ if (!cmp) {
+ first = mid;
+ break;
+ }
+ if (cmp > 0) {
+ first = mid+1;
+ continue;
+ }
+ last = mid;
+ }
+ if (first < num) {
+ unsigned char now[20], next[20];
+ nth_packed_object_sha1(p, first, now);
+ if (match_sha(len, match, now)) {
+ if (nth_packed_object_sha1(p, first+1, next) || !match_sha(len, match, next)) {
+ memcpy(sha1, now, 20);
+ return 1;
+ }
+ }
+ }
+ }
+ return 0;
+}
+
+static int get_short_sha1(const char *name, unsigned char *sha1)
+{
+ int i;
+ char canonical[40];
+ unsigned char res[20];
+
+ memset(res, 0, 20);
+ memset(canonical, 'x', 40);
+ for (i = 0;;i++) {
+ unsigned char c = name[i];
+ unsigned char val;
+ if (!c || i > 40)
+ break;
+ if (c >= '0' && c <= '9')
+ val = c - '0';
+ else if (c >= 'a' && c <= 'f')
+ val = c - 'a' + 10;
+ else if (c >= 'A' && c <='F') {
+ val = c - 'A' + 10;
+ c -= 'A' - 'a';
+ }
+ else
+ return -1;
+ canonical[i] = c;
+ if (!(i & 1))
+ val <<= 4;
+ res[i >> 1] |= val;
+ }
+ if (i < 4)
+ return -1;
+ if (find_short_object_filename(i, canonical, sha1))
+ return 0;
+ if (find_short_packed_object(i, res, sha1))
+ return 0;
+ return -1;
+}
+
+static int get_sha1_file(const char *path, unsigned char *result)
+{
+ char buffer[60];
+ int fd = open(path, O_RDONLY);
+ int len;
+
+ if (fd < 0)
+ return -1;
+ len = read(fd, buffer, sizeof(buffer));
+ close(fd);
+ if (len < 40)
+ return -1;
+ return get_sha1_hex(buffer, result);
+}
+
+static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
+{
+ static const char *prefix[] = {
+ "",
+ "refs",
+ "refs/tags",
+ "refs/heads",
+ "refs/snap",
+ NULL
+ };
+ const char **p;
+
+ if (!get_sha1_hex(str, sha1))
+ return 0;
+
+ for (p = prefix; *p; p++) {
+ char *pathname = git_path("%s/%.*s", *p, len, str);
+ if (!get_sha1_file(pathname, sha1))
+ return 0;
+ }
+
+ return -1;
+}
+
+static int get_sha1_1(const char *name, int len, unsigned char *sha1);
+
+static int get_parent(const char *name, int len,
+ unsigned char *result, int idx)
+{
+ unsigned char sha1[20];
+ int ret = get_sha1_1(name, len, sha1);
+ struct commit *commit;
+ struct commit_list *p;
+
+ if (ret)
+ return ret;
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ return -1;
+ if (parse_commit(commit))
+ return -1;
+ if (!idx) {
+ memcpy(result, commit->object.sha1, 20);
+ return 0;
+ }
+ p = commit->parents;
+ while (p) {
+ if (!--idx) {
+ memcpy(result, p->item->object.sha1, 20);
+ return 0;
+ }
+ p = p->next;
+ }
+ return -1;
+}
+
+static int get_sha1_1(const char *name, int len, unsigned char *sha1)
+{
+ int parent, ret;
+
+ parent = 1;
+ if (len > 2 && name[len-1] >= '0' && name[len-1] <= '9') {
+ parent = name[len-1] - '0';
+ len--;
+ }
+ if (len > 1 && name[len-1] == '^') {
+ ret = get_parent(name, len-1, sha1, parent);
+ if (!ret)
+ return 0;
+ }
+ ret = get_sha1_basic(name, len, sha1);
+ if (!ret)
+ return 0;
+ return get_short_sha1(name, sha1);
+}
+
+/*
+ * This is like "get_sha1_basic()", except it allows "sha1 expressions",
+ * notably "xyz^" for "parent of xyz"
+ */
+int get_sha1(const char *name, unsigned char *sha1)
+{
+ return get_sha1_1(name, strlen(name), sha1);
+}
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Linus Torvalds @ 2005-08-04 5:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy87i46il.fsf@assigned-by-dhcp.cox.net>
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> While I have not updated the send-pack <src>:<dst> syntax, I
> added a horrible hack that some people may love to see. This
> removes the need to use git-rev-parse from many commands.
Yes, I think this makes sense. We had three different sha1 parsers:
get_sha1(), get_sha1_hex(), and get_extended_sha1().
None of the users of get_sha1() really have any reason to want the limited
form, so I think your patch does the right thing.
Now, for extra bonus points, maybe you should make "git-rev-list" also
understand the "rev..rev" format (which you can't do with just the
get_sha1() interface, since it expands into more).
Of course, most people don't tend to use git-rev-list directly, so maybe
that's not a biggie, and so git-rev-parse is fine.
Linus
^ permalink raw reply
* Re: bisect gives strange answer
From: Junio C Hamano @ 2005-08-04 6:57 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: git
In-Reply-To: <E1E0XjN-000102-Un@approximate.corpus.cam.ac.uk>
Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:
> + git bisect bad
> Bisecting: 2 revisions left to test after this
> + cat .git/HEAD
> b4634484815e1879512a23e4f59eef648135c30a
> + git bisect bad
> b4634484815e1879512a23e4f59eef648135c30a is first bad commit
> diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)
> The answer makes no sense since my .config doesn't use the bt87x driver
> (the TP600X uses a snd-cs46xx). To be sure, I checked the diff with
>
> git diff 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737..b4634484815e1879512a23e4f59eef648135c30a
>
> The commit changed only sound/pci/bt87x.c
>
> I do believe this line at the end of the bisection:
>
> b4634484815e1879512a23e4f59eef648135c30a is first bad commit
>...
> I suspect that bisect jumped the gun at the end, and that there are a
> few more revisions to test.
Thank you for a very useful reproduction recipe. I think this
is my bug. Could you try this please?
------------
diff --git a/git-bisect-script b/git-bisect-script
--- a/git-bisect-script
+++ b/git-bisect-script
@@ -107,8 +107,8 @@ bisect_next() {
rev=$(eval "git-rev-list --bisect $good $bad") || exit
nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
if [ "$nr" -le "1" ]; then
- echo "$bad is first bad commit"
- git-diff-tree --pretty $bad
+ echo "$rev is first bad commit"
+ git-diff-tree --pretty $rev
exit 0
fi
echo "Bisecting: $nr revisions left to test after this"
^ permalink raw reply
* Re: bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-04 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xzi42bm.fsf@assigned-by-dhcp.cox.net>
> Could you try this please?
Thanks, it now finishes with the diff that I expected:
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)
Author: Greg KH <gregkh@suse.de>
Date: Wed Jul 6 09:09:38 2005 -0700
[PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem
Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
in 2.6.13-rc2.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
:040000 040000 93e93c4d8e88d6e05e815261f96ab38376c92809 b9cbda6dd88aeca51031d36e00f396e7091fd54c M drivers
The full run is included below.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
+ git bisect reset
+ git bisect start
+ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3
+ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6
Bisecting: 42 revisions left to test after this
+ cat .git/HEAD
b2f571026594884e7a2a3f8bc6ad5c92e0703330
+ git bisect good
Bisecting: 30 revisions left to test after this
+ cat .git/HEAD
450008b5a62bb09445ae05c4d01d510386c9435d
+ git bisect good
Bisecting: 15 revisions left to test after this
+ cat .git/HEAD
a9df3597fec5472d0840fbfdc2a3fac5268f7d08
+ git bisect bad
Bisecting: 8 revisions left to test after this
+ cat .git/HEAD
28e8c3ad9464de54a632f00ab3df88fa5f4652d1
+ git bisect bad
Bisecting: 4 revisions left to test after this
+ cat .git/HEAD
c774e93e2152d0be2612739418689e6e6400f4eb
+ git bisect bad
Bisecting: 2 revisions left to test after this
+ cat .git/HEAD
b4634484815e1879512a23e4f59eef648135c30a
+ git bisect bad
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)
Author: Greg KH <gregkh@suse.de>
Date: Wed Jul 6 09:09:38 2005 -0700
[PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem
Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
in 2.6.13-rc2.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
:040000 040000 93e93c4d8e88d6e05e815261f96ab38376c92809 b9cbda6dd88aeca51031d36e00f396e7091fd54c M drivers
^ permalink raw reply
* Re: [PATCH] (preview) Renaming push.
From: Junio C Hamano @ 2005-08-04 8:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508032236470.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Now, for extra bonus points, maybe you should make "git-rev-list" also
> understand the "rev..rev" format (which you can't do with just the
> get_sha1() interface, since it expands into more).
Hmph. That makes sense.
What I set out to do when I started ripping extended_sha1 out of
rev-parse was actually something else.
Remember I was stupidly wondering why "git log master..gitk" did
not do what I wanted to?
The reason I started looking at git-rev-parse was because I
wanted to add "git log master...gitk" (three dots) which is
equivalent to "git log $(git-merge-base master gitk)..gitk".
That was what I wanted to have when I asked that stupid
question.
But unfortunately my GIT day this week is over, so the rest is
for the weekend.
^ permalink raw reply
* Re: bisect gives strange answer
From: Greg KH @ 2005-08-04 17:26 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: Junio C Hamano, git
In-Reply-To: <E1E0a4e-0000vu-69@approximate.corpus.cam.ac.uk>
On Thu, Aug 04, 2005 at 03:23:28AM -0400, Sanjoy Mahajan wrote:
> > Could you try this please?
>
> Thanks, it now finishes with the diff that I expected:
>
> 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
> diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)
> Author: Greg KH <gregkh@suse.de>
> Date: Wed Jul 6 09:09:38 2005 -0700
>
> [PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem
>
> Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
> in 2.6.13-rc2.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
By any chance, is this patch causing you problems?
Just curious :)
greg k-h
^ permalink raw reply
* Re: bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-04 17:41 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20050804172635.GA14144@kroah.com>
> By any chance, is this patch causing you problems?
No, sadly. But I had hopes! As I think about it more, there's no way
it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG
would not change anything (for those who don't know the patch, it is
appended below).
My latest theory is that I fed bisect incorrect good/bad data.
Perhaps If I had checked out and compiled those intermediate versions
from scratch, each version in a separate directory, then I would have
got different answers. Two possible reasons:
1. The kernel Makefiles ar do not understand every subtle dependency.
So they might get confused by updating to different tree states (as
the bisect progresses) because those updates change Makefiles and
include files. In other words, I should have done 'make clean' or
'make mrproper' before each kernel compile.
2. git-bisect-script doesn't use -f when it does 'git checkout', so
files that should be updated are not. Right now I'm in the middle
of recollecting the data with git-bisect-script using -f in all
uses of git checkout (unless that is a really silly idea).
-Sanjoy
git diff a18bcb7450840f07a772..3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -17,13 +17,13 @@
* Dynamic device IDs are disabled for !CONFIG_HOTPLUG
*/
-#ifdef CONFIG_HOTPLUG
-
struct pci_dynid {
struct list_head node;
struct pci_device_id id;
};
+#ifdef CONFIG_HOTPLUG
+
/**
* store_new_id
*
^ permalink raw reply
* Re: bisect gives strange answer
From: Dave Jones @ 2005-08-04 18:27 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: Greg KH, Junio C Hamano, git
In-Reply-To: <E1E0jiv-0003c4-00@skye.ra.phy.cam.ac.uk>
On Thu, Aug 04, 2005 at 06:41:41PM +0100, Sanjoy Mahajan wrote:
> > By any chance, is this patch causing you problems?
>
> No, sadly. But I had hopes! As I think about it more, there's no way
> it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG
> would not change anything (for those who don't know the patch, it is
> appended below).
>
> My latest theory is that I fed bisect incorrect good/bad data.
> Perhaps If I had checked out and compiled those intermediate versions
> from scratch, each version in a separate directory, then I would have
> got different answers. Two possible reasons:
Errrrm, if you don't compile/test those intermediate versions,
how do you know whether to tag it good/bad ?
Dave
^ permalink raw reply
* Re: bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-04 18:32 UTC (permalink / raw)
To: Dave Jones; +Cc: Greg KH, Junio C Hamano, git
In-Reply-To: <20050804182717.GA2241@redhat.com>
> Errrrm, if you don't compile/test those intermediate versions,
> how do you know whether to tag it good/bad ?
Sorry, I wrote this part carelessly: "If I had checked out and
compiled those intermediate versions from scratch..."
I meant to emphasize the 'from scratch'. I did check out and compile
the versions, but I didn't compile from scratch. i.e. I just took
whatever directory tree I got after
git bisect good
or
git bisect bad
and then did 'make -j 4'. Perhaps I should have done
make clean
<restore .config>
make -j 4
to be really sure that every file that needed recompilation got
recompiled.
-Sanjoy
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Johannes Schindelin @ 2005-08-04 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bprjzzg.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 Aug 2005, Junio C Hamano wrote:
> This may be controversial from the robustness standpoint, so I
> am placing it in the proposed update queue first. Discussions
> on the list very welcomed.
I'd vote against it: As of now, I can perfectly do
export PATH=$PATH:/whereever/my/git/is
git-init-db
which would not work with this patch. I don't mind the templating
mechanism per se, though. It should make life easier for new bees.
Let's just make sure git-init-db is usable without installing
anything.
Ciao,
Dscho
^ permalink raw reply
* Re: bisect gives strange answer
From: Junio C Hamano @ 2005-08-04 18:43 UTC (permalink / raw)
To: Dave Jones; +Cc: Sanjoy Mahajan, Greg KH, git
In-Reply-To: <20050804182717.GA2241@redhat.com>
Dave Jones <davej@redhat.com> writes:
> Errrrm, if you don't compile/test those intermediate versions,
> how do you know whether to tag it good/bad ?
I think Sanjoy is saying that they _were_ tested, and suspects
that bisect didn't leave the right versions of the files in the
work tree, so what was compiled and tested were not what bisect
wanted to get tested. This is theory #2 in Sanjoy's post:
>> 2. git-bisect-script doesn't use -f when it does 'git checkout', so
>> files that should be updated are not. Right now I'm in the middle
>> of recollecting the data with git-bisect-script using -f in all
>> uses of git checkout (unless that is a really silly idea).
I find this explanation quite plausible, in case it is all my
fault and I apologize for wasting kernel developers' time.
^ permalink raw reply
* Re: bisect gives strange answer
From: Sam Ravnborg @ 2005-08-04 19:28 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: Greg KH, Junio C Hamano, git
In-Reply-To: <E1E0jiv-0003c4-00@skye.ra.phy.cam.ac.uk>
>
> 1. The kernel Makefiles ar do not understand every subtle dependency.
> So they might get confused by updating to different tree states (as
> the bisect progresses) because those updates change Makefiles and
> include files. In other words, I should have done 'make clean' or
> 'make mrproper' before each kernel compile.
If you see any sort of evidence that this would hold true I really like
to know.
The current build system is only known to fail if a changed file gets a
timestamp that is not equal to 'now'. Some braindead SCM uses the
timestamp of the chekin.
There has been put a tremendous effort in tracking each and every subtle
dependeny - and if something is missing then it ought to be fixed.
Sam
^ permalink raw reply
* [PATCH] interactive merge in cg-Xmergefile for cogito-0.12.1
From: James Ketrenos @ 2005-08-04 19:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
I use the attached patch here and its helped me quite a bit. Thought
I'd send it out for others to use as well. Prior to 0.12 I could do
this in my own scripts after a cg-merge exited with conflicts. Resently
it seems 'git-ls-files --unmerged' will no longer list any files that
had conflicts during the merge.
So, this patch modifies cg-Xmergefile to interactively prompt you with
what to do in the event of a merge conflict. It is set up to work
reasonably well with kdiff3 as is.
If it or a variant gets sucked into cogito -- great. If there is
already a way to kick off a merge conflict resolution program while
cg-merge is running, please let me know.
Thanks,
James
[-- Attachment #2: cg-Xmergefile.diffstat --]
[-- Type: text/plain, Size: 122 bytes --]
cg-Xmergefile | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 46 insertions(+), 2 deletions(-)
[-- Attachment #3: cg-Xmergefile.patch --]
[-- Type: text/x-patch, Size: 1811 bytes --]
diff -Nup a/cg-Xmergefile b/cg-Xmergefile
--- a/cg-Xmergefile 2005-08-04 14:20:38.000000000 -0500
+++ b/cg-Xmergefile 2005-08-04 15:20:01.000000000 -0500
@@ -35,6 +35,49 @@ warning () {
}
+interactive_threeway() {
+ [ -z "$MERGE" ] && MERGE="kdiff3 -o"
+ dir=$(dirname $4)
+ [ ! -d $dir ] && mkdir -p $dir
+ cmd="$MERGE \"$4\" \"$4.base\" \"$4.parent\" \"$4.child\""
+ while true; do
+ echo "Do you wish to:"
+ echo -e "1. Invoke MERGE via:\n"\
+"$MERGE \"$4\" \"$4.base\" \"$4.parent\" \"$4.child\""
+ echo "2. restore from base"
+ echo "3. restore from parent"
+ echo "4. restore from child"
+ echo "5. commit changes and return"
+ echo "6. view file on disk"
+ echo "0. abort"
+ read -p "[1-6,0] : " reply <&1
+ case $reply in
+ 1) git-cat-file blob $1 > $4.base
+ git-cat-file blob $2 > $4.parent
+ git-cat-file blob $3 > $4.child
+ $MERGE "$4" "$4.base" "$4.parent" "$4.child"
+ ;;
+ 2) git-cat-file blob "$1" > "$4"
+ echo "Restored $4 from base"
+ ;;
+ 3) git-cat-file blob "$2" > "$4"
+ echo "Restored $4 from parent"
+ ;;
+ 4) git-cat-file blob "$3" > "$4"
+ echo "Restored $4 from child"
+ ;;
+ 5) git-update-cache -- $4 || return 1
+ return 0
+ ;;
+ 6) [ ! -e "$4" ] && git-checkout-cache -q -f -u -- "$4"
+ less "$4"
+ ;;
+ 0) return 1
+ ;;
+ esac
+ done
+}
+
case "${1:-.}${2:-.}${3:-.}" in
#
# Deleted in both or deleted in one and unchanged in the other
@@ -95,8 +138,7 @@ case "${1:-.}${2:-.}${3:-.}" in
if [ $ret -ne 0 ]; then
# The user already gets the warning from merge itself and
# from merge-cache too. This is too much.
- #error "Auto-merge failed"
- exit 1
+ interactive_threeway $1 $2 $3 $4 || exit 1
fi
exec git-update-cache -- "$4"
;;
@@ -106,3 +148,5 @@ case "${1:-.}${2:-.}${3:-.}" in
;;
esac
exit 1
+
+
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Junio C Hamano @ 2005-08-04 19:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508042038200.23886@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This may be controversial from the robustness standpoint, so I
>> am placing it in the proposed update queue first. Discussions
>> on the list very welcomed.
>
> I'd vote against it: As of now, I can perfectly do
>
> export PATH=$PATH:/whereever/my/git/is
> git-init-db
>
> which would not work with this patch.
I take it to mean that you do not mind building but would want
to try it out before installing.
Yes, that is similar to what I meant by "robustness". Maybe we
could do two things to make it palatable:
* Instead of $src/templates/Makefile installing in place, give
it a real 'build' target that creates $src/templates/blt/
hierarchy and build things there (I expect we would need some
templates that needs installation specific customization
later, and really want to avoid making $src/templates
something that is copied straight out). "make install" would
copy it out to the final destination.
* Make git-init-db create an absolute minimum $GIT_DIR
structure itself, if the template directory is not available,
possibly with a warning.
Then, your post-build pre-installation trial can go like this:
$ make
$ PATH=`pwd`:"$PATH"
$ GIT_TEMPLATE_DIRECTORY=`pwd`/templates/blt
$ export PATH GIT_TEMPLATE_DIRECTORY
$ cd /where/ever
$ git-init-db
^ permalink raw reply
* git: problems in read-only trees
From: Petr Baudis @ 2005-08-04 20:11 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050803074241.A2D1D3535F9@atlas.denx.de>
Dear diary, on Wed, Aug 03, 2005 at 09:42:41AM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> Hello,
>
> sometimes I have to work in trees for which I have only read
> permissions; cogito has problems then - for example:
>
> -> cg-diff
> fatal: unable to create new cachefile
> fatal: unable to create temp-file
>
> It would be nice if there was at least a way to specify some TMPDIR
> instead of the current directory in such a situation.
This is a bug in git-diff-* (producing the second error message; the first
error message means failed git-update-cache --refresh but that isn't
fatal). Any reason why prep_temp_blob() works in . instead of $TMPDIR?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git-local-pull?
From: Petr Baudis @ 2005-08-04 20:12 UTC (permalink / raw)
To: barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508031259430.23721@iabervon.org>
Dear diary, on Wed, Aug 03, 2005 at 07:11:00PM CEST, I got a letter
where barkalow@iabervon.org told me that...
> IIRC, git-local-pull still doesn't work for a packed source repository,
> because it doesn't include the possibility of copying a pack (or
> extracting an object) if the requested object is in a pack.
>
> I can probably fix it if anyone cares, but it's not something I use
> personally, so I don't know if it's worthwhile. It should probably be
> removed if we don't fix it, since it will fail on any popular repository
> at this point.
I want to use it in Cogito again, since copying everything obviously
sucks and I want to hardlink, so repacking is not a solution either.
Didn't you post some patches to fix this long time ago, actually?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Johannes Schindelin @ 2005-08-04 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll3hxykj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> This may be controversial from the robustness standpoint, so I
>>> am placing it in the proposed update queue first. Discussions
>>> on the list very welcomed.
>>
>> I'd vote against it: As of now, I can perfectly do
>>
>> export PATH=$PATH:/whereever/my/git/is
>> git-init-db
>>
>> which would not work with this patch.
>
> I take it to mean that you do not mind building but would want
> to try it out before installing.
I'd like to not being forced to install git. Scenario: I have an SSH
account on a remote machine. I am not root there, but I'd like to
synchronize my work with git. I can not install git.
> * Make git-init-db create an absolute minimum $GIT_DIR
> structure itself, if the template directory is not available,
> possibly with a warning.
This would be exactly what I'd like. Let git-init-db create
.git/objects/[0-9a-f]{2}/, .git/refs/heads/, .git/refs/tags and .git/HEAD.
Everything else is taken from the templates directory, if that exists. I
would not warn if it does not.
Ciao,
Dscho
^ 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