* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Morten Welinder @ 2005-05-07 20:22 UTC (permalink / raw)
To: Martin Waitz; +Cc: GIT, Junio C Hamano
In-Reply-To: <20050507172429.GJ3562@admingilde.org>
On 5/7/05, Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
>
> On Sat, May 07, 2005 at 11:05:43AM +0200, Thomas Glanzmann wrote:
> > * Junio C Hamano <junkio@cox.net> [050507 10:54]:
> > > A quick question. Which construct in this bashism?
> > > Not using backtick but saying $(command)?
> >
> > Exactly:
>
> huh? which broken shell does not understand $()?
Solaris' /bin/sh
I thought everything we were relying on bash anyway. It'll take it.
Morten
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Pavel Machek @ 2005-05-07 19:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20050506175835.65b9c9c1.akpm@osdl.org>
Hi!
> > This adds short intro to git aimed at kernel hackers.
> >
>
> OK, but I'm hoping that shortly we'll have something more complete than
> this, and your patch might not be a suitable starting point for that.
> (Large hint-dropping sounds).
Okay.. Should I add Documentation/git, and put this as intro.txt into
it?
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-07 19:51 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <7vbr7nbl89.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> Perhaps I'm just missing something in your code,...
JCH> Thankfully I think Linus had rejected this part in the series.
JCH> I'll fix it up.
Here is the fixed one. The previous one was ugly and
inconvenient to use (thanks for noticing, Sean).
I'll keep it in the git-jc repository until Linus returns.
------------
Author: Junio C Hamano <junkio@cox.net>
Date: Sat May 7 00:38:04 2005 -0700
Introduce SHA1_FILE_DIRECTORIES to support multiple object databases.
SHA1_FILE_DIRECTORIES environment variable is a colon separated paths
used when looking for SHA1 files not found in the usual place for
reading. Creating a new SHA1 file does not use this alternate object
database location mechanism. This is useful to archive older, rarely
used objects into separate directories.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- a/cache.h
+++ b/cache.h
@@ -101,6 +101,7 @@ unsigned int active_nr, active_alloc, ac
#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
+#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
#define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
--- a/fsck-cache.c
+++ b/fsck-cache.c
@@ -306,7 +306,7 @@ int main(int argc, char **argv)
usage("fsck-cache [--tags] [[--unreachable] [--cache] <head-sha1>*]");
}
- sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+ sha1_dir = get_object_directory();
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", sha1_dir, i);
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -100,18 +100,34 @@ char * sha1_to_hex(const unsigned char *
return buffer;
}
+static void fill_sha1_path(char *pathbuf, const unsigned char *sha1)
+{
+ int i;
+ for (i = 0; i < 20; i++) {
+ static char hex[] = "0123456789abcdef";
+ unsigned int val = sha1[i];
+ char *pos = pathbuf + i*2 + (i > 0);
+ *pos++ = hex[val >> 4];
+ *pos = hex[val & 0xf];
+ }
+}
+
/*
* NOTE! This returns a statically allocated buffer, so you have to be
* careful about using it. Do a "strdup()" if you need to save the
* filename.
+ *
+ * Also note that this returns the location for creating. Reading
+ * SHA1 file can happen from any alternate directory listed in the
+ * SHA1_FILE_DIRECTORIES environment variable if it is not found in
+ * the primary object database.
*/
char *sha1_file_name(const unsigned char *sha1)
{
- int i;
static char *name, *base;
if (!base) {
- char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+ char *sha1_file_directory = get_object_directory();
int len = strlen(sha1_file_directory);
base = xmalloc(len + 60);
memcpy(base, sha1_file_directory, len);
@@ -120,16 +136,74 @@ char *sha1_file_name(const unsigned char
base[len+3] = '/';
name = base + len + 1;
}
- for (i = 0; i < 20; i++) {
- static char hex[] = "0123456789abcdef";
- unsigned int val = sha1[i];
- char *pos = name + i*2 + (i > 0);
- *pos++ = hex[val >> 4];
- *pos = hex[val & 0xf];
- }
+ fill_sha1_path(name, sha1);
return base;
}
+static struct alternate_object_database
+{
+ char *base;
+ char *name;
+} *alt_odb;
+
+static void prepare_alt_odb(void)
+{
+ int pass, totlen, i;
+ void *buf;
+ const char *cp, *last;
+ char *op = 0;
+ const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
+
+ for (totlen = pass = 0; pass < 2; pass++) {
+ last = alt;
+ i = 0;
+ do {
+ cp = strchr(last, ':') ? : last + strlen(last);
+ if (last != cp) {
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = cp - last;
+ int entlen = pfxlen + 43;
+ if (pass == 0)
+ totlen += entlen;
+ else {
+ alt_odb[i].base = op;
+ alt_odb[i].name = op + pfxlen + 1;
+ memcpy(op, last, pfxlen);
+ op[pfxlen] = op[pfxlen + 3] = '/';
+ op[entlen-1] = 0;
+ op += entlen;
+ }
+ i++;
+ }
+ while (*cp && *cp == ':')
+ cp++;
+ last = cp;
+ } while (*cp);
+ if (pass)
+ break;
+ alt_odb = buf = xmalloc(sizeof(*alt_odb) * (i + 1) + totlen);
+ alt_odb[i].base = alt_odb[i].name = 0;
+ op = (char*)(&alt_odb[i+1]);
+ }
+}
+
+static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
+{
+ int i;
+ char *name = sha1_file_name(sha1);
+
+ if (!stat(name, st))
+ return name;
+ if (!alt_odb)
+ prepare_alt_odb();
+ for (i = 0; (name = alt_odb[i].name) != NULL; i++) {
+ fill_sha1_path(name, sha1);
+ if (!stat(alt_odb[i].base, st))
+ return alt_odb[i].base;
+ }
+ return NULL;
+}
+
int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
{
char header[100];
@@ -145,10 +219,15 @@ int check_sha1_signature(unsigned char *
void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
{
- char *filename = sha1_file_name(sha1);
struct stat st;
void *map;
int fd;
+ char *filename = find_sha1_file(sha1, &st);
+
+ if (!filename) {
+ error("cannot map sha1 file %s", sha1_to_hex(sha1));
+ return NULL;
+ }
fd = open(filename, O_RDONLY | sha1_file_open_flag);
if (fd < 0) {
@@ -167,10 +246,6 @@ void *map_sha1_file(const unsigned char
/* If it failed once, it will probably fail again. Stop using O_NOATIME */
sha1_file_open_flag = 0;
}
- if (fstat(fd, &st) < 0) {
- close(fd);
- return NULL;
- }
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (-1 == (int)(long)map)
@@ -315,6 +390,7 @@ int write_sha1_file(char *buf, unsigned
}
snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX", get_object_directory());
+
fd = mkstemp(tmpfile);
if (fd < 0) {
fprintf(stderr, "unable to create temporary sha1 filename %s: %s", tmpfile, strerror(errno));
@@ -442,12 +518,8 @@ int write_sha1_from_fd(const unsigned ch
int has_sha1_file(const unsigned char *sha1)
{
- char *filename = sha1_file_name(sha1);
struct stat st;
-
- if (!stat(filename, &st))
- return 1;
- return 0;
+ return !!find_sha1_file(sha1, &st);
}
int index_fd(unsigned char *sha1, int fd, struct stat *st)
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-07 19:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git, junkio
In-Reply-To: <20050507152849.GD9495@pasky.ji.cz>
I'll keep this in git-jc repository until Linus returns. Pasky
and Kay could you give it a try?
-- test case --
$ ls -a
./ ../
$ git-init-db
defaulting to local storage area
$ date >path
$ git-update-cache --add path
$ rm path
$ mkdir path
$ date >path/file
$ git-update-cache --add path/file
$ git-ls-files --stage
100644 1738f2536b1201218c41153941da065cc26174c9 0 path
100644 620c72f1c1de15f56ff9d63d6d7cdc69e828f1e3 0 path/file
$ git-ls-tree $(git-write-tree) ;# using old one
100644 blob 1738f2536b1201218c41153941da065cc26174c9 path
040000 tree ec116937f223e3df95aeac9f076902ae1618ae98 path
$ ../git-write-tree ;# using new one
You have both path and path/file
fatal: write-tree: not able to write tree
$ exit
----------------------------------------------------------------
Notice index that has path and path/file and refuse to write such a tree.
Kay Sievers noticed that you can have both path and path/file in
the cache and write-tree happily creates a tree object from such
a state. Since a merge can result in such situation and the
user should be able to see the situation by looking at the
cache, rather than forbidding add_cache_entry() to create such
conflicts, fix it by making write-tree refuse to write such an
nonsensical tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
write-tree.c | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
--- a/write-tree.c
+++ b/write-tree.c
@@ -84,7 +84,7 @@ static int write_tree(struct cache_entry
int main(int argc, char **argv)
{
- int i, unmerged;
+ int i, funny;
int entries = read_cache();
unsigned char sha1[20];
@@ -92,18 +92,45 @@ int main(int argc, char **argv)
die("write-tree: no cache contents to write");
/* Verify that the tree is merged */
- unmerged = 0;
+ funny = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = active_cache[i];
if (ntohs(ce->ce_flags) & ~CE_NAMEMASK) {
- if (++unmerged > 10) {
+ if (10 < ++funny) {
fprintf(stderr, "...\n");
break;
}
fprintf(stderr, "%s: unmerged (%s)\n", ce->name, sha1_to_hex(ce->sha1));
}
}
- if (unmerged)
+ if (funny)
+ die("write-tree: not able to write tree");
+
+ /* Also verify that the cache does not have path and path/file
+ * at the same time. At this point we know the cache has only
+ * stage 0 entries.
+ */
+ funny = 0;
+ for (i = 0; i < entries - 1; i++) {
+ /* path/file always comes after path because of the way
+ * the cache is sorted. Also path can appear only once,
+ * which means conflicting one would immediately follow.
+ */
+ const char *this_name = active_cache[i]->name;
+ const char *next_name = active_cache[i+1]->name;
+ int this_len = strlen(this_name);
+ if (this_len < strlen(next_name) &&
+ strncmp(this_name, next_name, this_len) == 0 &&
+ next_name[this_len] == '/') {
+ if (10 < ++funny) {
+ fprintf(stderr, "...\n");
+ break;
+ }
+ fprintf(stderr, "You have both %s and %s\n",
+ this_name, next_name);
+ }
+ }
+ if (funny)
die("write-tree: not able to write tree");
/* Ok, write it out */
^ permalink raw reply
* Re: [PATCH] git-tar-tree: Lift path length limit
From: Junio C Hamano @ 2005-05-07 18:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Rene Scharfe, Linus Torvalds, git
In-Reply-To: <20050507120935.GB9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Dear diary, on Sat, May 07, 2005 at 02:57:06AM CEST, I got a letter
PB> where Rene Scharfe <rene.scharfe@lsrfire.ath.cx> told me that...
>> On Sat, May 07, 2005 at 02:25:27AM +0200, Rene Scharfe wrote:
>> > Last minute patch?
>>
>> This leaks memory. D'oh!
>>
>> Petr, would you add the (hopefully) fixed version below to your tree now
>> that Linus is on vacation? (Patch applies to tip of GIT tree.)
PB> It appears to me that the patch currently in the git tree is this
PB> (correct) one?
Yes it was merged before Linus left the machine last night.
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-07 18:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git, junkio
In-Reply-To: <20050507152849.GD9495@pasky.ji.cz>
I'll have a look later but as I recall the code (I'm writing
this without looking at the specific code, just your patch
hunk), the flag comparison there is not about blob vs tree modes
but for "stages"; it must answer that two entries with the same
name but in different merge stages are different.
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Junio C Hamano @ 2005-05-07 18:38 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050507101530.GH23680@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Hello,
>> You can nest $() which is valuable, unlike backtics.
TG> we're aware of this. But the specific script works perfectly fine
TG> without nested simple-command redirection. So what is your point?
If that is the case then I think the patch you posted to force
bash is backwards. How about changing it to use backticks?
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Martin Waitz @ 2005-05-07 17:24 UTC (permalink / raw)
To: GIT, Junio C Hamano
In-Reply-To: <20050507090543.GG23680@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
hoi :)
On Sat, May 07, 2005 at 11:05:43AM +0200, Thomas Glanzmann wrote:
> * Junio C Hamano <junkio@cox.net> [050507 10:54]:
> > A quick question. Which construct in this bashism?
> > Not using backtick but saying $(command)?
>
> Exactly:
huh? which broken shell does not understand $()?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Broken adding of cache entries
From: Petr Baudis @ 2005-05-07 15:28 UTC (permalink / raw)
To: Kay Sievers; +Cc: git, junkio
In-Reply-To: <1115431767.32065.182.camel@localhost.localdomain>
Dear diary, on Sat, May 07, 2005 at 04:09:27AM CEST, I got a letter
where Kay Sievers <kay.sievers@vrfy.org> told me that...
..snip..
> Look what funny thing you can do:
> kay@mam:~/public_html/pub/scm/funny-tree$ git-ls-tree HEAD
> 100644 blob b1a17ba136936531b72571844a773fe938b85ad4 entry
> 040000 tree eba6ba02f18176500019755ad58c0bdfead16c47 entry
>
> Add a file to the cache, replace it with a directory, add that to the
> cache and then write the tree and you have two entries with the same
> name. :)
Duh. Well, what could be the reasonwhy cache_name_compare() cares about
flags at all? Can you _ever_ have two same-named entries? Junio, what do
you think about something like this?
Index: read-cache.c
===================================================================
--- e47e2a558a85b33e0652233f78aa1ca8a959685b/read-cache.c (mode:100644)
+++ uncommitted/read-cache.c (mode:100644)
@@ -68,10 +68,6 @@
return -1;
if (len1 > len2)
return 1;
- if (flags1 < flags2)
- return -1;
- if (flags1 > flags2)
- return 1;
return 0;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-07 12:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505050846530.2328@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Thu, 2005-05-05 at 09:40 -0700, Linus Torvalds wrote:
> Btw, if you want to, you could simplify and optimize things heavily by
> doign some very specific git internal mucking around, and using the new
> "-m" flag I added to "git-diff-cache".
OK, this is in place now. I also made sure it was going to treat a real
'2.6.12' release as newer than '2.6.12-rcX'. The selection of the tags
and the output of the log are still chronological, which is of course
wrong -- but it'll do for now.
As an added bonus I've also fixed the script to refrain from creating a
-git1 snapshot even when there have been no commits since the last
release. And deleted 2.6.12-rc4-git1.
--
dwmw2
[-- Attachment #2: git-snapshot.sh --]
[-- Type: application/x-shellscript, Size: 2499 bytes --]
^ permalink raw reply
* Re: [PATCH] git-tar-tree: Lift path length limit
From: Petr Baudis @ 2005-05-07 12:09 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Linus Torvalds, git
In-Reply-To: <20050507005706.GA6093@lsrfire.ath.cx>
Dear diary, on Sat, May 07, 2005 at 02:57:06AM CEST, I got a letter
where Rene Scharfe <rene.scharfe@lsrfire.ath.cx> told me that...
> On Sat, May 07, 2005 at 02:25:27AM +0200, Rene Scharfe wrote:
> > Last minute patch?
>
> This leaks memory. D'oh!
>
> Petr, would you add the (hopefully) fixed version below to your tree now
> that Linus is on vacation? (Patch applies to tip of GIT tree.)
It appears to me that the patch currently in the git tree is this
(correct) one?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Petr Baudis @ 2005-05-07 11:36 UTC (permalink / raw)
To: David Greaves; +Cc: Andrew Morton, Pavel Machek, git
In-Reply-To: <427C7E38.3010301@dgreaves.com>
Dear diary, on Sat, May 07, 2005 at 10:37:12AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Andrew Morton wrote:
>
> >Pavel Machek <pavel@ucw.cz> wrote:
> >
> >
> >>This adds short intro to git aimed at kernel hackers.
> >>
> >>
> >>
> >
> >OK, but I'm hoping that shortly we'll have something more complete than
> >this, and your patch might not be a suitable starting point for that.
> >(Large hint-dropping sounds).
> >
> >
> What are you looking for.
>
> For man-page-a-like, have you seen Documentation/core-git.txt in Linus'
> repository?
>
> I'll be working more on that this weekend.
Are you planning to split it to individual files at some point?
(That's what I'd like to do with Documentation/cogito/, speaking of
manpageness...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Thomas Glanzmann @ 2005-05-07 10:15 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050507100348.GA16461@outpost.ds9a.nl>
Hello,
> You can nest $() which is valuable, unlike backtics.
we're aware of this. But the specific script works perfectly fine
without nested simple-command redirection. So what is your point?
Thomas
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: bert hubert @ 2005-05-07 10:03 UTC (permalink / raw)
To: GIT, Junio C Hamano
In-Reply-To: <20050507090543.GG23680@cip.informatik.uni-erlangen.de>
On Sat, May 07, 2005 at 11:05:43AM +0200, Thomas Glanzmann wrote:
> * Junio C Hamano <junkio@cox.net> [050507 10:54]:
> > A quick question. Which construct in this bashism?
> > Not using backtick but saying $(command)?
You can nest $() which is valuable, unlike backtics.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Thomas Glanzmann @ 2005-05-07 9:05 UTC (permalink / raw)
To: GIT; +Cc: Junio C Hamano
In-Reply-To: <7v3bszbeoo.fsf@assigned-by-dhcp.cox.net>
Hello,
* Junio C Hamano <junkio@cox.net> [050507 10:54]:
> A quick question. Which construct in this bashism?
> Not using backtick but saying $(command)?
Exactly:
(faui04a) [~/work/git/git-solaris] git pull
head => 46dd99f970d283dc0de440c06fca8f4586b70548
remote => e7d3dd248f50501f98b29c917e70bddcf3ea925a
base => 74c7cfa875448c71a18d21a0cc7c973afe759fa5
Documentation/core-git.txt: unmerged (8bd893197e6e769b6e03ca1206e355214e16d56a)
local-pull.c: unmerged (4f52bca48c390e8113b3695a53ce62e0c23278a8)
local-pull.c: unmerged (a8af725467cde6653160511e468a1fda4e004503)
local-pull.c: unmerged (1eec8927dbfa3af934651b25ded738d192706286)
sha1_file.c: unmerged (e6ce455ae90bd430f2128f454bdb6e0575412486)
sha1_file.c: unmerged (7887b6481ae5c9368a24bf053f79dbbc1f039300)
sha1_file.c: unmerged (f1c1c70d784aa0587cd4c7143c3d464fd8e5ddc6)
fatal: write-tree: not able to write tree
This is it:
/home/cip/adm/sithglan/work/git/bin/git-SunOS/bin/git-merge-one-file-script: syntax error at line 55: `orig=$' unexpected
fatal: merge program failed
git-merge-cache failed: child exit value: 1 at /home/cip/adm/sithglan/work/git/yagf/git line 1015.
The attached patch at the end of this eMail fixes it for me *without*
touching /bin/sh in the bang:
(faui04a) [~/work/git/git-solaris] git pull
head => 46dd99f970d283dc0de440c06fca8f4586b70548
remote => e7d3dd248f50501f98b29c917e70bddcf3ea925a
base => 74c7cfa875448c71a18d21a0cc7c973afe759fa5
Documentation/core-git.txt: unmerged (8bd893197e6e769b6e03ca1206e355214e16d56a)
local-pull.c: unmerged (4f52bca48c390e8113b3695a53ce62e0c23278a8)
local-pull.c: unmerged (a8af725467cde6653160511e468a1fda4e004503)
local-pull.c: unmerged (1eec8927dbfa3af934651b25ded738d192706286)
sha1_file.c: unmerged (e6ce455ae90bd430f2128f454bdb6e0575412486)
sha1_file.c: unmerged (7887b6481ae5c9368a24bf053f79dbbc1f039300)
sha1_file.c: unmerged (f1c1c70d784aa0587cd4c7143c3d464fd8e5ddc6)
fatal: write-tree: not able to write tree
Threewaydiff invloved.
[PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -52,9 +52,9 @@
#
"$1$2$3")
echo "Auto-merging $4."
- orig=$(git-unpack-file $1)
- src1=$(git-unpack-file $2)
- src2=$(git-unpack-file $3)
+ orig=`git-unpack-file $1`
+ src1=`git-unpack-file $2`
+ src2=`git-unpack-file $3`
merge "$src2" "$orig" "$src1"
ret=$?
if [ "$6" != "$7" ]; then
@@ -64,7 +64,7 @@
echo "ERROR: Leaving conflict merge in $src2."
exit 1
fi
- sha1=$(git-write-blob "$src2") || {
+ sha1=`git-write-blob "$src2"` || {
echo "ERROR: Leaving conflict merge in $src2."
}
exec git-update-cache --add --cacheinfo "$6" $sha1 "$4" ;;
^ permalink raw reply
* Re: How do I...
From: David Woodhouse @ 2005-05-07 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Frank Sorenson, git
In-Reply-To: <Pine.LNX.4.58.0505061652240.2233@ppc970.osdl.org>
On Fri, 2005-05-06 at 16:54 -0700, Linus Torvalds wrote:
> But trying to be clever while building this up is just crazy talk. When
> diff-tree prints out the changes, it has no way of knowing what the
> context around it was - it doesn't know about merges far away, and it
> _shouldn't_ know.
Isn't that what I suggested? Start with full history, mark the
'interesting' commits which touch the file(s) in question, then prune.
--
dwmw2
^ permalink raw reply
* Re: [PATCH]: git-merge-one-file-script use /usr/bin/env to call bash
From: Junio C Hamano @ 2005-05-07 8:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050507084549.GF23680@cip.informatik.uni-erlangen.de>
A quick question. Which construct in this bashism?
Not using backtick but saying $(command)?
^ permalink raw reply
* Re: [patch] add simple git documentation
From: David Greaves @ 2005-05-07 8:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, git
In-Reply-To: <20050506175835.65b9c9c1.akpm@osdl.org>
Andrew Morton wrote:
>Pavel Machek <pavel@ucw.cz> wrote:
>
>
>>This adds short intro to git aimed at kernel hackers.
>>
>>
>>
>
>OK, but I'm hoping that shortly we'll have something more complete than
>this, and your patch might not be a suitable starting point for that.
>(Large hint-dropping sounds).
>
>
What are you looking for.
For man-page-a-like, have you seen Documentation/core-git.txt in Linus'
repository?
I'll be working more on that this weekend.
David
--
^ permalink raw reply
* [PATCH] make INSTALL binary in Makefile configurable via make variable
From: Thomas Glanzmann @ 2005-05-07 8:41 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds
[PATCH] make INSTALL binary in Makefile configurable via make variable
On Solaris machines gnu install called ginstall
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/Makefile
+++ b/Makefile
@@ -11,6 +11,7 @@
CC=gcc
AR=ar
+INSTALL=install
SCRIPTS=git-apply-patch-script git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script
@@ -26,7 +27,7 @@
all: $(PROG)
install: $(PROG) $(SCRIPTS)
- install $(PROG) $(SCRIPTS) $(HOME)/bin/
+ $(INSTALL) $(PROG) $(SCRIPTS) $(HOME)/bin/
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH]: git-merge-one-file-script use /usr/bin/env to call bash
From: Thomas Glanzmann @ 2005-05-07 8:45 UTC (permalink / raw)
To: Linus Torvalds, GIT
[PATCH]: git-merge-one-file-script use /usr/bin/env to call bash
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/usr/bin/env bash
#
# This is the git merge script, called with
#
^ permalink raw reply
* [PATCH] Add #include <limits.h> so that git compiles under Solaris
From: Thomas Glanzmann @ 2005-05-07 8:41 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds
[PATCH] Add #include <limits.h> so that git compiles under Solaris
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/diff-tree-helper.c
+++ b/diff-tree-helper.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2005 Junio C Hamano
*/
+#include <limits.h>
#include "cache.h"
#include "strbuf.h"
#include "diff.h"
--- a/diff.c
+++ b/diff.c
@@ -4,6 +4,7 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
+#include <limits.h>
#include "cache.h"
#include "diff.h"
--- a/local-pull.c
+++ b/local-pull.c
@@ -5,6 +5,7 @@
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
+#include <limits.h>
#include "cache.h"
#include "commit.h"
#include <errno.h>
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -7,6 +7,7 @@
* creation etc.
*/
#include <stdarg.h>
+#include <limits.h>
#include "cache.h"
const char *sha1_file_directory = NULL;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-07 6:31 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <2721.10.10.10.24.1115425962.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> Perhaps I'm just missing something in your code,...
Yes you are. You have spotted a very inconvenient inconsistency
in the interface to the code.
Only on the very first time when it tries to constructs the
alternate directory list, and if there is no alternate list, it
just returns the name without stat(), which forces the callers
to do stat() themselves all the time. I think I should make it
always stat, since the reading side needs do it anyway.
Thankfully I think Linus had rejected this part in the series.
I'll fix it up.
^ permalink raw reply
* Updated versions of previously posted patches
From: Jonas Fonseca @ 2005-05-07 3:38 UTC (permalink / raw)
To: pasky; +Cc: git
Hi pasky,
I have updated the patches I have previously posted here. They are
available at http://www.nitro.dk/~jonas/cogito/ and carry the following
changes:
- 0--move-date-to-Xlib.patch
Move date conversion from cg-log to cg-Xlib so it can be used in the
next patch.
- 1--human-readable-mkpatch-dates.patch:
Show the author and commit date in a human readable format.
- 2--show-changed-files-in-log-output.patch
Add an -f switch to cg-log controlling whether to list which files
were changed. The output looks like the following:
<commit header>
* file1, file2, ..., fileN:
<log message>
It doesn't do anything fancy like wrapping long lines and can be quite
costly to do for big logs.
- 3--add-mkpatch-short-version.patch
Add an -s option to cg-mkpatch which specifies whether to print a
short version of the patch without a patch header with meta info such
as author and committer.
This was proposed by you after YOSHIFUJI Hideaki pointed out that the
diffstat is not always useful. However, I don't know if this is
anywhere near how you intended it to be. Anyway, it prepares for the
next patch.
- 4--show-diffstat-for-mkpatch.patch
Show diffstat as part of the patch header if diffstat is available on
the system.
I didn't test this since diffstat unfortunately wasn't available on
the system I updated the patches on.
--
Jonas Fonseca
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: Marcelo Tosatti @ 2005-05-06 21:51 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <427BE699.60802@zytor.com>
On Fri, May 06, 2005 at 02:50:17PM -0700, H. Peter Anvin wrote:
> David Woodhouse wrote:
> >On Thu, 2005-05-05 at 17:28 -0700, H. Peter Anvin wrote:
> >
> >>Could you add that to 2.4 as well, too?
> >
> >Is there a 2.4 git tree?
> >
>
> I thought so, but now I can't find it. Marcelo?
Not yet. I should be able to put a "beta" version
next week.
David, can I bug you to add nightly snapshotting
as soon as the v2.4 git tree is created ?
I hope there aren't many further changes in v2.4.x...
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Andrew Morton @ 2005-05-07 0:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: git
In-Reply-To: <20050505102600.GA16387@elf.ucw.cz>
Pavel Machek <pavel@ucw.cz> wrote:
>
> This adds short intro to git aimed at kernel hackers.
>
OK, but I'm hoping that shortly we'll have something more complete than
this, and your patch might not be a suitable starting point for that.
(Large hint-dropping sounds).
>
> ---
> commit addb0833bdadda14495d66749e6cb95b6a9445d7
> tree 7e66cb899004fbec0fadae5c9265d0731d3a26f3
> parent 1f9ca1262e6b27dde44d456a87c456d15f0a9b80
> author <pavel@amd.(none)> 1115288688 +0200
> committer <pavel@amd.(none)> 1115288688 +0200
>
> Index: Documentation/git.txt
> ===================================================================
> --- /dev/null (tree:de65e7579ed050d324357e3040b37c561676ab7d)
> +++ 7e66cb899004fbec0fadae5c9265d0731d3a26f3/Documentation/git.txt (mode:100644 sha1:353d5ae7f46eeb79c058be611cb429622167f784)
> @@ -0,0 +1,41 @@
> + Kernel hacker's guide to git
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + 2005 Pavel Machek <pavel@suse.cz>
> +
> +You can get cogito at http://www.kernel.org/pub/software/scm/cogito/
> +. Compile it, and place it somewhere in $PATH. Then you can get kernel
> +by running
> +
> +mkdir clean-cg; cd clean-cg
> +cg-init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> +
> +... Do cg-update origin to pickup latest changes from Linus. You can
> +do cg-diff to see what changes you done in your local tree. cg-cancel
> +will kill any such changes, and cg-commit will make them permanent.
> +
> +To get diff between your working tree and "next tree up", do cg-diff
> +-r origin: . If you want to get the same diff but separated
> +patch-by-patch, do cg-mkpatch origin: . If you want to pull changes
> +from the "up" tree to your working tree, do cg-update origin.
> +
> +
> +How to set up your trees so that you can cooperate with Linus
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +What I did:
> +
> +Created clean-cg. Initialized straight from Linus (as above). Then I
> +created "nice" tree, good for Linus to pull from
> +
> +mkdir /data/l/linux-good; cd /data/l/linux-good
> +cg-init /data/l/clean-cg
> +
> +and then my working tree, based on linux-good
> +
> +mkdir /data/l/linux-cg; cd /data/l/linux-cg
> +cg-init /data/l/linux-good
> +
> +. I do my work in linux-cg. If someone sends me nice patch I should
> +pass up, I apply it to linux-good with nice message and do
> +
> +cd /data/l/linux-cg; cg-update origin
>
> --
> Boycott Kodak -- for their patent abuse against Java.
^ 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