* Cogito RFE: cg-commit -q
From: H. Peter Anvin @ 2005-10-13 17:45 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis
I would find it very useful if cg-commit had a "-q" option, meaning
"silently skip this commit if there is nothing to commit." There are
some automatic release scripts that I have which enforces consistency
before release, but if the repository is already correctly set up for
release, there is nothing to do.
This is the opposite of -f, which would create a commit object pointing
to the same tree.
-hpa
^ permalink raw reply
* Re: [PATCH] Sparse fixes for http-fetch
From: H. Peter Anvin @ 2005-10-13 17:51 UTC (permalink / raw)
To: Peter Hagervall; +Cc: junkio, git
In-Reply-To: <20051013174203.GA6860@peppar.cs.umu.se>
Peter Hagervall wrote:
> This patch cleans out all sparse warnings from http-fetch.c
>
> I'm a bit uncomfortable with adding extra #ifdefs to avoid either
> 'mixing declaration with code' or 'unused variable' warnings, but I
> figured that since those functions are already littered with #ifdefs I
> might just get away with it. Comments?
>
For the first, you can use extra brackets to create blocks in which
declarations can happen; for the latter, you can (void)var; to specify
that a certain variable may be legitimately unused under some circumstances.
-hpa
^ permalink raw reply
* Re: [PATCH] Sparse fixes for http-fetch
From: Junio C Hamano @ 2005-10-13 18:16 UTC (permalink / raw)
To: Peter Hagervall; +Cc: git
In-Reply-To: <20051013174203.GA6860@peppar.cs.umu.se>
Peter Hagervall <hager@cs.umu.se> writes:
> I'm a bit uncomfortable with adding extra #ifdefs to avoid either
> 'mixing declaration with code' or 'unused variable' warnings, but I
> figured that since those functions are already littered with #ifdefs I
> might just get away with it. Comments?
How about something like this on top of what you posted? There
still is one in main(), but...
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
git diff
diff --git a/http-fetch.c b/http-fetch.c
index 26f8130..d549471 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -27,6 +27,8 @@ static int data_received;
#ifdef USE_CURL_MULTI
static int max_requests = DEFAULT_MAX_REQUESTS;
static CURLM *curlm;
+static void process_curl_messages();
+static void process_request_queue();
#endif
static CURL *curl_default;
static struct curl_slist *pragma_header;
@@ -154,11 +156,6 @@ static size_t fwrite_sha1_file(void *ptr
return size;
}
-#ifdef USE_CURL_MULTI
-void process_curl_messages();
-void process_request_queue();
-#endif
-
static struct active_request_slot *get_active_slot(void)
{
struct active_request_slot *slot = active_queue_head;
@@ -443,7 +440,7 @@ static void release_request(struct trans
}
#ifdef USE_CURL_MULTI
-void process_curl_messages(void)
+static void process_curl_messages(void)
{
int num_messages;
struct active_request_slot *slot;
@@ -495,7 +492,7 @@ void process_curl_messages(void)
}
}
-void process_request_queue(void)
+static void process_request_queue(void)
{
struct transfer_request *request = request_queue_head;
int num_transfers;
@@ -904,9 +901,6 @@ static int fetch_object(struct alt_base
char *hex = sha1_to_hex(sha1);
int ret;
struct transfer_request *request = request_queue_head;
-#ifdef USE_CURL_MULTI
- int num_transfers;
-#endif
while (request != NULL && memcmp(request->sha1, sha1, 20))
request = request->next;
@@ -920,6 +914,7 @@ static int fetch_object(struct alt_base
#ifdef USE_CURL_MULTI
while (request->state == WAITING) {
+ int num_transfers;
curl_multi_perform(curlm, &num_transfers);
if (num_transfers < active_requests) {
process_curl_messages();
Compilation finished at Thu Oct 13 11:14:23
^ permalink raw reply related
* auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-10-13 18:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
I know we tried this once earlier, and it caused problems, but that was
when pack-files were new, and not everybody could handle them. These days,
if you can't handle pack-files, kernel.org is already pretty useless,
because all the major packages use them anyway, because people have
packed their repositories by hand.
So I'm suggesting we try to do an automatic repack every once in a while.
In my suggestion, there would be two levels of repacking: "incremental"
and "full", and both of them would count the number of files before they
run, so that you'd only do it when it seems worthwhile.
This is a _really_ simple heuristic:
- incremental repacking run every day:
#
# Check if we have more than a couple of hundred
# unpacked objects - approximated by whether we
# have any "00" directory with more than one
#
# This means that we don't repack projects that
# that don't have a lot of work going on.
#
# Note: with really new versions of git, the "00"
# directory may not exist if it has been pruned
# away, so handle that gracefully.
#
export GIT_DIR=${1:-.}
objs=$(find "$GIT_DIR/objects/00" -type f 2> /dev/null | wc -l)
if [ "$obj" -gt 0 ]; then
git repack &&
git prune-packed
fi
- "full repack" every week if the number of packs has grown to be bigger
than say 10 (ie even a very active projects will never have a full
repack more than every other week)
#
# Check if we have lots of packs, where "lots" is defined as 10.
#
# Note: with something that was generated with an old version
# of git, the "pack" directory may not exist, so handle that
# gracefully.
#
export GIT_DIR=${1:-.}
packs=$(find "$GIT_DIR/objects/pack" -name '*.idx' 2> /dev/null | wc -l)
if [ "$packs" -gt 10 ]; then
git repack -a -d &&
git prune-packed
fi
- do a full repack of everything once to start with.
export GIT_DIR=${1:-.}
git repack -a -d &&
git prune-packed
the above three trivial scripts just take a single argument, which becomes
the GIT_DIR (and if no argument exists, it would default to ".")
Is there any reason not to do this? Right now mirroring is slow, and
webgit is also getting to be very slow sometimes. I bet we'd be _much_
better off with this kind of setup.
NOTE! The above is the "stupid" approach, which totally ignores alternate
directories, and isn't able to take advantage of the fact that many
projects could share objects. But it's simple, and it's efficient (eg it
won't spend time on things like the large historic archives which don't
change, but that would be expensive to repack if you didn't check for the
need).
So we could try to come up with a better approach eventually, which would
automatically notice alternate directories and not repack stuff that
exists there, but I'm pretty sure that the above would already help a
_lot_, and while pack-files have been been around forever, the
"alternates" support is still pretty new, so the above is also the "safer"
thing to do.
We'd only do the automatic thing on stuff under /pub/scm, of course: not
stuff in peoples home directories etc..
Peter?
Linus
^ permalink raw reply
* Regression: Multi-head syntax
From: Johannes Schindelin @ 2005-10-13 20:28 UTC (permalink / raw)
To: git
Hi,
with 221e743c.. [git-fetch --tags: deal with tags with spaces in them.] my
usual git-fetch no longer works. My .git/remotes/junio used to look like
this:
-- snip --
URL: rsync://rsync.kernel.org/pub/scm/git/git.git
Pull: master:junio todo:todo +pu:pu
-- snap --
but this makes a new head "junio todo:todo +pu:pu". Now I have to write
the remote like this to work correctly:
-- snip --
URL: rsync://rsync.kernel.org/pub/scm/git/git.git
Pull: master:junio
Pull: todo:todo
Pull: +pu:pu
-- snap --
Is this intended?
Ciao,
Dscho
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-10-13 21:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: H. Peter Anvin, users, Git Mailing List, Junio C Hamano
In-Reply-To: <434EC07C.30505@pobox.com>
On Thu, 13 Oct 2005, Jeff Garzik wrote:
>
> Right now, things go through an expand-contract cycle:
>
> * people base repos off of Marcelo or Linus's git repo, including using those
> pack files (saves download bandwidth, disk space through hardlinks).
>
> * as 3rd parties and Marcelo/Linus merge stuff, .git/objects/* grows with
> individual files.
>
> * once a month/release/whatever, Linus packs his repo, allowing all the repos
> following his to use those pack files, pruning a ton of objects off of
> kernel.org.
>
> I have real users of my git repos who can't just download a 100MB pack file in
> an hour, it takes them many hours.
Argh.
Ok, I'm going to follow this up with three small patches that add a "-l"
flag to "git repack", which does only a "local repack" (ie it will pack
only objects that are _not_ in packs in alternate object directories).
That will hopefully mean that this usage case is supported too.
Linus
^ permalink raw reply
* [PATCH 1/3] Keep track of whether a pack is local or not
From: Linus Torvalds @ 2005-10-13 21:26 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If we want to re-pack just local packfiles, we need to know whether a
particular object is local or not.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/cache.h b/cache.h
index 1a7e047..3286582 100644
--- a/cache.h
+++ b/cache.h
@@ -313,6 +313,7 @@ extern struct packed_git {
void *pack_base;
unsigned int pack_last_used;
unsigned int pack_use_cnt;
+ int pack_local;
unsigned char sha1[20];
char pack_name[0]; /* something like ".git/objects/pack/xxxxx.pack" */
} *packed_git;
@@ -352,7 +353,7 @@ extern struct packed_git *find_sha1_pack
extern int use_packed_git(struct packed_git *);
extern void unuse_packed_git(struct packed_git *);
-extern struct packed_git *add_packed_git(char *, int);
+extern struct packed_git *add_packed_git(char *, int, int);
extern int num_packed_objects(const struct packed_git *p);
extern int nth_packed_object_sha1(const struct packed_git *, int, unsigned char*);
extern int find_pack_entry_one(const unsigned char *, struct pack_entry *, struct packed_git *);
diff --git a/sha1_file.c b/sha1_file.c
index f059004..e456799 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -416,7 +416,7 @@ int use_packed_git(struct packed_git *p)
return 0;
}
-struct packed_git *add_packed_git(char *path, int path_len)
+struct packed_git *add_packed_git(char *path, int path_len, int local)
{
struct stat st;
struct packed_git *p;
@@ -444,6 +444,7 @@ struct packed_git *add_packed_git(char *
p->pack_base = NULL;
p->pack_last_used = 0;
p->pack_use_cnt = 0;
+ p->pack_local = local;
return p;
}
@@ -484,7 +485,7 @@ void install_packed_git(struct packed_gi
packed_git = pack;
}
-static void prepare_packed_git_one(char *objdir)
+static void prepare_packed_git_one(char *objdir, int local)
{
char path[PATH_MAX];
int len;
@@ -506,7 +507,7 @@ static void prepare_packed_git_one(char
/* we have .idx. Is it a file we can map? */
strcpy(path + len, de->d_name);
- p = add_packed_git(path, len + namelen);
+ p = add_packed_git(path, len + namelen, local);
if (!p)
continue;
p->next = packed_git;
@@ -522,11 +523,11 @@ void prepare_packed_git(void)
if (run_once)
return;
- prepare_packed_git_one(get_object_directory());
+ prepare_packed_git_one(get_object_directory(), 1);
prepare_alt_odb();
for (alt = alt_odb_list; alt; alt = alt->next) {
alt->name[0] = 0;
- prepare_packed_git_one(alt->base);
+ prepare_packed_git_one(alt->base, 0);
}
run_once = 1;
}
diff --git a/verify-pack.c b/verify-pack.c
index 80b60a6..c99db9d 100644
--- a/verify-pack.c
+++ b/verify-pack.c
@@ -15,12 +15,12 @@ static int verify_one_pack(char *arg, in
len--;
}
/* Should name foo.idx now */
- if ((g = add_packed_git(arg, len)))
+ if ((g = add_packed_git(arg, len, 1)))
break;
/* No? did you name just foo? */
strcpy(arg + len, ".idx");
len += 4;
- if ((g = add_packed_git(arg, len)))
+ if ((g = add_packed_git(arg, len, 1)))
break;
return error("packfile %s not found.", arg);
}
^ permalink raw reply related
* [PATCH 2/3] Add support for "local" packing
From: Linus Torvalds @ 2005-10-13 21:26 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This adds the "--local" flag to git-pack-objects, which acts like
"--incremental", except that instead of ignoring all packed objects, it
only ignores objects that are packed and in an alternate object tree.
As a result, it effectively only does a local re-pack: any remote-packed
objects will stay in the alternate object directories.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/pack-objects.c b/pack-objects.c
index ef55cab..8a1ee74 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -5,7 +5,7 @@
#include "pack.h"
#include "csum-file.h"
-static const char pack_usage[] = "git-pack-objects [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
+static const char pack_usage[] = "git-pack-objects [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
struct object_entry {
unsigned char sha1[20];
@@ -20,6 +20,7 @@ struct object_entry {
static unsigned char object_list_sha1[20];
static int non_empty = 0;
+static int local = 0;
static int incremental = 0;
static struct object_entry **sorted_by_sha, **sorted_by_type;
static struct object_entry *objects = NULL;
@@ -195,8 +196,20 @@ static int add_object_entry(unsigned cha
unsigned int idx = nr_objects;
struct object_entry *entry;
- if (incremental && has_sha1_pack(sha1))
- return 0;
+ if (incremental || local) {
+ struct packed_git *p;
+
+ for (p = packed_git; p; p = p->next) {
+ struct pack_entry e;
+
+ if (find_pack_entry_one(sha1, &e, p)) {
+ if (incremental)
+ return 0;
+ if (local && !p->pack_local)
+ return 0;
+ }
+ }
+ }
if (idx >= nr_alloc) {
unsigned int needed = (idx + 1024) * 3 / 2;
@@ -404,6 +417,10 @@ int main(int argc, char **argv)
non_empty = 1;
continue;
}
+ if (!strcmp("--local", arg)) {
+ local = 1;
+ continue;
+ }
if (!strcmp("--incremental", arg)) {
incremental = 1;
continue;
@@ -436,6 +453,7 @@ int main(int argc, char **argv)
if (pack_to_stdout != !base_name)
usage(pack_usage);
+ prepare_packed_git();
while (fgets(line, sizeof(line), stdin) != NULL) {
unsigned int hash;
char *p;
^ permalink raw reply related
* [PATCH 3/3] Add "-l" flag for repacking only local packs
From: Linus Torvalds @ 2005-10-13 21:30 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This uses the new "--local" flag to git-pack-objects. It currently only
makes a difference together with "-a", since a normal incremental repack
won't pack any packed objects at all (whether local or remote).
Eventually, it might end up skipping any objects that aren't local to
the current object directory, but for now it only knows to skip packed
objects.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Ok, that was the last of it. I tested it out by doing a
git clone -l -s git newgit
cd newgit
.. do a dummy commit ..
git repack -a -d -l
and then
cd ../git
git repack -a -d
cd ../newgit
git repack -a -d -l
and verified that the repacks in "newgit" all seemed to do the right thing
(ie they only repacked objects that weren't packed in the original git,
and repacking the original git archive caused the repack in the new one to
shrink considerably).
This means that my suggested automatic repacking should work fine with
alternate object directories too, except my second script (the periodic
full repack) would needs to be updated to use the new "-l" flag.
diff --git a/git-repack.sh b/git-repack.sh
index b395d0e..49547a7 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -5,13 +5,14 @@
. git-sh-setup || die "Not a git archive"
-no_update_info= all_into_one= remove_redundant=
+no_update_info= all_into_one= remove_redundant= local=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
-a) all_into_one=t ;;
-d) remove_redandant=t ;;
+ -l) local=t ;;
*) break ;;
esac
shift
@@ -37,6 +38,9 @@ case ",$all_into_one," in
find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
+if [ "$local" ]; then
+ pack_objects="$pack_objects --local"
+fi
name=$(git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
^ permalink raw reply related
* Re: Regression: Multi-head syntax
From: Junio C Hamano @ 2005-10-13 22:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510132225120.1028@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> with 221e743c.. [git-fetch --tags: deal with tags with spaces in them.] my
> usual git-fetch no longer works. My .git/remotes/junio used to look like
> this:
>
> -- snip --
> URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> Pull: master:junio todo:todo +pu:pu
> -- snap --
>
> but this makes a new head "junio todo:todo +pu:pu". Now I have to write
> the remote like this to work correctly:
>
> -- snip --
> URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> Pull: master:junio
> Pull: todo:todo
> Pull: +pu:pu
> -- snap --
>
> Is this intended?
Unintended regression whose solution is not quite decided. My
current thinking is to disallow refnames that:
* have a path component that begins with a ".", or
* have two consecutive dots "..", or
* have ASCII control character, "~", "^", ":" or SP, anywhere, or
* end with a "/".
and there are series of commits to enforce the above (except two
dots) in the proposed updates branch.
The first one does not have much technical reason for it, but is
just easier on eye, and we do not have to worry about /./ or
/../ if we have that rule. The second one is so that
"ref1..ref2" notation that means "^ref1 ref2" in some tools
would be unambiguous.
SP and TAB are because of the shell splicing tokens at IFS, LF
is because of remote/ file format, and forbidding the rest of
the control characters are "not strictly necessariy but why not
while we are at it?" "~" and "^" are "follow-the-parent"
postfix operators, and ":" separates a src:dst pair in a
refspec.
There is a thread on this:
http://marc.theaimsgroup.com/?l=git&m=112901070817153&w=2
It appears to me that the list does not have many objections to
the above restriction, so that change can goes in now after
double-dot fixes, and perhaps after fixing cvs/arch import to
munge the tag/branch names appropriately, we can revert the
IFS="$LF" change in git-fetch that is giving you this trouble,
This is slightly offtopic, but could you switch to http
transport? Rsync has been deprecated for quite some time.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Paul Eggert @ 2005-10-14 0:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <Pine.LNX.4.64.0510121411550.15297@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So I repeat:
> - escape as little as possible
> - make the _viewer_ decide how to view it.
Under my most recent proposal, the only bytes one must escape are ",
\, and LF. Doesn't that satisfy these two main criteria?
> If GNU emacs does locale translations rather than just do a binary
> transfer of the data, then that's a sign that GNU emacs is being
> really stupid.
Perhaps so, but it has a lot of company. I have even worse problems
with Mozilla Thunderbird. And as we observed, Pine also has problems
sending properly-formatted email containing arbitrary binary data.
I suspect the vast majority of email clients will screw up in
relatively common cases involving unusual characters in file names.
Using attachments avoids many of the problems, but lots of patches are
emailed inline and I'd rather not force people to use attachments to
send diffs.
> I find that email is very robust - it's basically 8-bit clean. No
> character encoding, no crap. Just a byte stream. It really _is_ the most
> reliable format.
Hmm. To test that theory, I just now sent plain-text email to myself,
containing a carriage-return (CR) byte in the middle of a line.
The CR byte was transliterated into a LF. Ooops.
This was the very first (and only) test I tried, which isn't a good
sign for reliability. If you're curious, I tracked the problem down
to Exim, a popular mail transfer agent that is running on my personal
Debian GNU/Linux (stable) box. As to why Exim munges email, please see
<http://www.exim.org/exim-html-4.40/doc/html/spec_44.html#SECT44.1>.
(And I didn't know about the Exim glitch before trying my test.
I'm normally a Sendmail man myself.)
More generally, I suspect inline patches with weird bytes will suffer
greatly from encoding and recoding by mail agents.
> What matters is not what it looks like, but what it _saves_ as. If
> you save the email message, it should come out as the same reliable
> 8-bit byte stream
Unfortunately this isn't true for Emacs, and I suspect other mailers
will have similar problems. For example, with Emacs I can easily save
either the exact byte-for-byte message body that my mail transfer
agent gave me; or I can have Emacs decode the message into its
constituent characters, reencode the result as UTF-8, and put that
into a file. In neither case, though, am I saving the original byte
stream that you presented to your mail user agent. Even if I save the
byte-for-byte message body, it is often in quoted-printable format so
I'll have to decode strings like "=EF" to recover the original bytes.
This is doable, yes, but it's inconvenient in practice, at least with
the mail user agents I'm familiar with. And even if I do it, I don't
necessarily have the same byte stream you gave your mail user agent; I
merely have the byte stream that your MUA gave to your MTA, and these
may not be the same thing (they certainly aren't always the same thing
with Emacs).
The simplest fix for git may be to say "Don't use inline patches; use
attachments if you must email anything with strange characters in it."
That's fine. But I prefer a format that also allows GNU diff, if it
chooses, to generate output that resists common inline-email botches.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Paul Eggert @ 2005-10-14 0:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <Pine.LNX.4.64.0510121355280.15297@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I find that email is very robust - it's basically 8-bit clean. No
> character encoding, no crap. Just a byte stream. It really _is_ the most
> reliable format.
I found another amusing bit of info that tends to undercut this claim.
This discussion thread is archived at
<http://marc.theaimsgroup.com/?t=112877773400002&r=1&w=2&n=22>.
But there's an item missing from the archive: my message with
Message-ID <87vf02qy79.fsf@penguin.cs.ucla.edu>. This is the message
with the joke "Aach! Those Finns! Always on the trailing edge of
technology!".
All my other messages are achived. What was special about this
one? Surely there's not a joke filter at theaimsgroup.com!
I nosed around through the archive and here's my guess as to what
happened. My message's email header contained this:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
and my guess is that the web archiver can't handle that format.
This is just a guess. I can't confirm it because (among other things)
the web archiver won't give me all the bytes of the messages that it
archives. Even its "Download message RAW" doesn't do that: it omits
the header. But I have a strong suspicion. Let's put it this way: I
think mine was the only message in the thread that said
"charset=utf-8".
If my guess is right, the archiver dropped my email on the floor
simply because it contained UTF-8. This is not a good sign for
putting UTF-8 into email, or for relying on email to transmit byte
streams.
^ permalink raw reply
* Cogito: Merge failure when new remote has been added locally
From: Horst von Brand @ 2005-10-14 1:06 UTC (permalink / raw)
To: git
I've set up an example project to play around with cogito/git. To simulate
patches flowing back and forth I set up several repositories, which I edit
independently. In this I run into trouble with a reasonable scenario:
A creates a project, and publishes it
B gets A's version, updates his version, and ships a patch (which creates
stack.h) to A
A merges in B's changes, and fixes a typo in stack.h
B tries to update from A via cg-update, the merge fails because there is a
local stack.h (which is different than the remote one). The resulting
message is less than helpful.
A script showing the problem follows:
mkdir tst1
cd tst1
echo "Initial" | cg-init
cd ..
cg-clone tst1 tst2
cd tst2
echo 'Hello!' > greet
cg-add greet
cg-commit -m "Add greet"
cd ../tst1
echo 'Hi there!' > greet
cg-add greet
cg-commit -m "Add greet"
cd ../tst2
cg-update
This gives:
MERGE ERROR: : Not handling case -> ->
Conflicts during merge. Do cg-commit after resolving them.
And there is nothing marked to fix by hand. cg-diff returns an empty
difference in greet.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Linus Torvalds @ 2005-10-14 5:20 UTC (permalink / raw)
To: Paul Eggert
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <87irw1q7eu.fsf@penguin.cs.ucla.edu>
On Thu, 13 Oct 2005, Paul Eggert wrote:
>
> Perhaps so, but it has a lot of company. I have even worse problems
> with Mozilla Thunderbird. And as we observed, Pine also has problems
> sending properly-formatted email containing arbitrary binary data.
No, pine does it right. Exactly because it sends _arbitraty_ binary data.
The fact that I turned the terminal into utf-8 mode in order to generate
the bytes (that end up being a garbage string in latin1) is not pine's
fault.
The point being that because the transport was 8-bit clean, I could do
that. I could mix a latin1-encoding with a UTF-8 encoding, and the other
side could see the mixed setting. Now, the other side had no way of
knowing that I mixed things (unless it was a smart human and could read
and understand what I wrote), so any email client would have trouble
showing it.
But it got _transferred_ right, and you could have saved the email, and
turned the terminal into latin1 or utf-8 mode, and done a "cat" both ways,
and you'd have seen both versions.
> I suspect the vast majority of email clients will screw up in
> relatively common cases involving unusual characters in file names.
Not if they just save it.
Oh, sure, they can't _display_ it, since they don't know what it is, but
when they save it, they'd _better_ save it bit-for-bit.
Which is the right thing to do. Then you apply it with "patch", and you
get the right answer.
> Using attachments avoids many of the problems, but lots of patches are
> emailed inline and I'd rather not force people to use attachments to
> send diffs.
inline or attachment should not matter to any sane email client. If it
does, then the email client isn't sane.
The point is, when you save it, it _has_ to be saved bit-for-bit.
The only difference between a binary attachment and a text thing is that
an email client will _try_ to show the text thing to you as text. It has
no other meaning.
And trying is better than not trying. Attachments are _inferior_ to inline
for that reason.
> > I find that email is very robust - it's basically 8-bit clean. No
> > character encoding, no crap. Just a byte stream. It really _is_ the most
> > reliable format.
>
> Hmm. To test that theory, I just now sent plain-text email to myself,
> containing a carriage-return (CR) byte in the middle of a line.
>
> The CR byte was transliterated into a LF. Ooops.
I'm not surprised, since CR/LF is special for a lot of (sad) reasons. Oh,
well.
I agree that it makes sense to escape \r, and obviously you _have_ to
escape \n. In general, escaping pretty much everything in the 0-31 range
is likely the right approach, since those are never printable anyway.
That, btw, is probably true of the patch contents too, not just the
filename. The exception being \t (and in patch contents, \n is obviously
part of the stream).
> More generally, I suspect inline patches with weird bytes will suffer
> greatly from encoding and recoding by mail agents.
I've had pretty good luck. We do have 8-bit stuff occasionally, but it
almost always makes it through.
Spaces and tabs are much worse (yes, they're more common too). That's
clearly just crap mailers.
> Unfortunately this isn't true for Emacs, and I suspect other mailers
> will have similar problems. For example, with Emacs I can easily save
> either the exact byte-for-byte message body that my mail transfer
> agent gave me; or I can have Emacs decode the message into its
> constituent characters, reencode the result as UTF-8, and put that
> into a file.
Well, as long as there's a choice.
> In neither case, though, am I saving the original byte
> stream that you presented to your mail user agent. Even if I save the
> byte-for-byte message body, it is often in quoted-printable format so
> I'll have to decode strings like "=EF" to recover the original bytes.
You have a broken mail client. Now, I'm not a big fan of QP (I think it
was making a stupid excuse for bad transport), but QP is a _mail_ level
quoting protocol, and the same way a MUA uses QP to encode, the MUA should
have de-coded the QP. It shouldn't leave it to somebody else.
I think GNU emacs is a horrible mistake ("do everything - badly"), but you
may be able to fix it by letting your mail transport agent do the un-QP
for you. A lot of them do, which makes it easier to then use weak MUA's.
Anyway, it sounds like GNU emacs made the wrong choices (hey, I'm not
surprised). It should have decoded QP, not the character set. There are
lots of tools that do charset conversions, that's not very email-specific.
Linus
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Linus Torvalds @ 2005-10-14 5:43 UTC (permalink / raw)
To: Paul Eggert
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <87ek6ork3y.fsf@penguin.cs.ucla.edu>
On Thu, 13 Oct 2005, Paul Eggert wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > I find that email is very robust - it's basically 8-bit clean. No
> > character encoding, no crap. Just a byte stream. It really _is_ the most
> > reliable format.
>
> I found another amusing bit of info that tends to undercut this claim.
No, I think you found that email as a _transfer_ is mostly 8-bit clean
(finally! Oh - has qmail gotten fixed?).
But the end-points aren't. They do strange things with encodings,
sometimes. They see an encoding they don't know what to do with, and they
just freak out.
Linus
^ permalink raw reply
* Peeling the onion
From: Junio C Hamano @ 2005-10-14 6:03 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Martin Langhoff, Tom Prince, Linus Torvalds
In-Reply-To: <7virwlumyo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>>> we could send phony entries like this:
>>>
>>> b92c9c07fe2d0d89c4f692573583c4753b5355d2 deref/tags/junio-gpg-pub
>>> a3eb250f996bf5e12376ec88622c4ccaabf20ea8 deref/tags/v0.99
>>> 78d9d414123ad6f4f522ffecbcd9e4a7562948fd deref/tags/v0.99.1
>>
>> Yes, it would work,..
>> in general, it's just a really ugly special case, I think.
>
> I think we could do this instead, to make it less ugly.
>
> ...
>
> The alternative would be what Pasky outlined in his message --
> bypassing git transport layer to fetch single object by hand,
> repeatedly dereferencing it until he gets a non-tag. I think
> that is unnecessary misery for him.
I did not hear much from the people involved since this message,
but I have a bit less ugly solution along the lines outlined
above, in the proposed updates branch. Incidentally this would
also simplify Martin's git-findtags, especially if we do not
worry about its '-t' option.
I'll be sending 3-patch series; the first two are preparatory
but what may be useful for Pasky and Martin is in the third
one.
[PATCH] Ignore funny refname sent from remote.
[PATCH] Introduce notation "ref^{type}".
[PATCH] Show peeled onion from upload-pack and server-info.
^ permalink raw reply
* [PATCH] Introduce notation "ref^{type}".
From: Junio C Hamano @ 2005-10-14 6:03 UTC (permalink / raw)
To: git
Existing "tagname^0" notation means "dereference tag zero or more
times until you cannot dereference it anymore, and make sure it is a
commit -- otherwise barf". But tags do not necessarily reference
commit objects.
This commit introduces a bit more generalized notation, "ref^{type}".
Existing "ref^0" is a shorthand for "ref^{commit}". If the type
is empty, it just dereferences tags until it hits a non-tag object.
With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob
object name -- there is no need to manually read the tag object and
find out the object name anymore.
"git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the
tree object name of the HEAD commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is another preparation, which is not strictly needed but
for notational consistency. The next one is the gem in the
series -- upload-pack starts sending extra information on
refs it has using this notation, so that client side can find
out what each tag on the remote side refers to without first
getting them.
sha1_name.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 83 insertions(+), 0 deletions(-)
applies-to: 8edf2fed07b27673ab24e1bb40a0887f757d60b0
24552507a1fd71c707199bca0a225f2715a6759b
diff --git a/sha1_name.c b/sha1_name.c
index 4e9a052..75c688e 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1,5 +1,8 @@
#include "cache.h"
+#include "tag.h"
#include "commit.h"
+#include "tree.h"
+#include "blob.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -274,6 +277,82 @@ static int get_nth_ancestor(const char *
return 0;
}
+static int peel_onion(const char *name, int len, unsigned char *sha1)
+{
+ unsigned char outer[20];
+ const char *sp;
+ const char *type_string = NULL;
+ struct object *o;
+
+ /*
+ * "ref^{type}" dereferences ref repeatedly until you cannot
+ * dereference anymore, or you get an object of given type,
+ * whichever comes first. "ref^{}" means just dereference
+ * tags until you get a non-tag. "ref^0" is a shorthand for
+ * "ref^{commit}". "commit^{tree}" could be used to find the
+ * top-level tree of the given commit.
+ */
+ if (len < 4 || name[len-1] != '}')
+ return -1;
+
+ for (sp = name + len - 1; name <= sp; sp--) {
+ int ch = *sp;
+ if (ch == '{' && name < sp && sp[-1] == '^')
+ break;
+ }
+ if (sp <= name)
+ return -1;
+
+ sp++; /* beginning of type name, or closing brace for empty */
+ if (!strncmp(commit_type, sp, 6) && sp[6] == '}')
+ type_string = commit_type;
+ else if (!strncmp(tree_type, sp, 4) && sp[4] == '}')
+ type_string = tree_type;
+ else if (!strncmp(blob_type, sp, 4) && sp[4] == '}')
+ type_string = blob_type;
+ else if (sp[0] == '}')
+ type_string = NULL;
+ else
+ return -1;
+
+ if (get_sha1_1(name, sp - name - 2, outer))
+ return -1;
+
+ o = parse_object(outer);
+ if (!o)
+ return -1;
+ if (!type_string) {
+ o = deref_tag(o);
+ memcpy(sha1, o->sha1, 20);
+ }
+ else {
+ /* At this point, the syntax look correct, so
+ * if we do not get the needed object, we should
+ * barf.
+ */
+
+ while (1) {
+ if (!o)
+ return -1;
+ if (o->type == type_string) {
+ memcpy(sha1, o->sha1, 20);
+ return 0;
+ }
+ if (o->type == tag_type)
+ o = ((struct tag*) o)->tagged;
+ else if (o->type == commit_type)
+ o = &(((struct commit *) o)->tree->object);
+ else
+ return error("%.*s: expected %s type, but the object dereferences to %s type",
+ len, name, type_string,
+ o->type);
+ if (!o->parsed)
+ parse_object(o->sha1);
+ }
+ }
+ return 0;
+}
+
static int get_sha1_1(const char *name, int len, unsigned char *sha1)
{
int parent, ret;
@@ -315,6 +394,10 @@ static int get_sha1_1(const char *name,
return get_nth_ancestor(name, len1, sha1, parent);
}
+ ret = peel_onion(name, len, sha1);
+ if (!ret)
+ return 0;
+
ret = get_sha1_basic(name, len, sha1);
if (!ret)
return 0;
---
@@GIT_VERSION@@
^ permalink raw reply related
* [PATCH] Ignore funny refname sent from remote
From: Junio C Hamano @ 2005-10-14 6:03 UTC (permalink / raw)
To: git
This allows the remote side (most notably, upload-pack) to show
additional information without affecting the downloader. Peek-remote
does not ignore them -- this is to make it useful for Pasky's
automatic tag following.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is a preparation for the next one, which starts sending
out extra "refs" from upload-pack. Normal client side should
not get affected by those extra info.
cache.h | 2 +-
clone-pack.c | 2 +-
connect.c | 8 +++++++-
fetch-pack.c | 2 +-
peek-remote.c | 2 +-
send-pack.c | 2 +-
6 files changed, 12 insertions(+), 6 deletions(-)
applies-to: c0f2aa6e25a9291830ddd86acfc569fd33077ec6
60b2e010ba8dd4c24fe6ef7bfc1ee3185ac2cf52
diff --git a/cache.h b/cache.h
index 3286582..8aa63cc 100644
--- a/cache.h
+++ b/cache.h
@@ -339,7 +339,7 @@ extern int path_match(const char *path,
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all);
extern int get_ack(int fd, unsigned char *result_sha1);
-extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match);
+extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, int ignore_funny);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
extern struct packed_git *parse_pack_index_file(const unsigned char *sha1,
diff --git a/clone-pack.c b/clone-pack.c
index 0ea7e7f..f9b263a 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -287,7 +287,7 @@ static int clone_pack(int fd[2], int nr_
struct ref *refs;
int status;
- get_remote_heads(fd[0], &refs, nr_match, match);
+ get_remote_heads(fd[0], &refs, nr_match, match, 1);
if (!refs) {
packet_flush(fd[1]);
die("no matching remote head");
diff --git a/connect.c b/connect.c
index b157cf1..b6732f6 100644
--- a/connect.c
+++ b/connect.c
@@ -10,7 +10,8 @@
/*
* Read all the refs from the other end
*/
-struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match)
+struct ref **get_remote_heads(int in, struct ref **list,
+ int nr_match, char **match, int ignore_funny)
{
*list = NULL;
for (;;) {
@@ -29,6 +30,11 @@ struct ref **get_remote_heads(int in, st
if (len < 42 || get_sha1_hex(buffer, old_sha1) || buffer[40] != ' ')
die("protocol error: expected sha/ref, got '%s'", buffer);
name = buffer + 41;
+
+ if (ignore_funny && 45 < len && !memcmp(name, "refs/", 5) &&
+ check_ref_format(name + 5))
+ continue;
+
if (nr_match && !path_match(name, nr_match, match))
continue;
ref = xcalloc(1, sizeof(*ref) + len - 40);
diff --git a/fetch-pack.c b/fetch-pack.c
index 582f967..953c0cf 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -81,7 +81,7 @@ static int fetch_pack(int fd[2], int nr_
int status;
pid_t pid;
- get_remote_heads(fd[0], &ref, nr_match, match);
+ get_remote_heads(fd[0], &ref, nr_match, match, 1);
if (!ref) {
packet_flush(fd[1]);
die("no matching remote head");
diff --git a/peek-remote.c b/peek-remote.c
index 4b1d0d5..ee49bf3 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -11,7 +11,7 @@ static int peek_remote(int fd[2])
{
struct ref *ref;
- get_remote_heads(fd[0], &ref, 0, NULL);
+ get_remote_heads(fd[0], &ref, 0, NULL, 0);
packet_flush(fd[1]);
while (ref) {
diff --git a/send-pack.c b/send-pack.c
index 55d8ff7..9f9a6e7 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -181,7 +181,7 @@ static int send_pack(int in, int out, in
int new_refs;
/* No funny business with the matcher */
- remote_tail = get_remote_heads(in, &remote_refs, 0, NULL);
+ remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
get_local_heads();
/* match them up */
---
@@GIT_VERSION@@
^ permalink raw reply related
* [PATCH] Show peeled onion from upload-pack and server-info.
From: Junio C Hamano @ 2005-10-14 6:03 UTC (permalink / raw)
To: git
This updates git-ls-remote to show SHA1 names of objects that are
referred by tags, in the "ref^{}" notation.
This would make git-findtags (without -t flag) almost trivial.
git-peek-remote . |
sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p'
Also Pasky could do:
git-ls-remote --tags $remote |
sed -ne 's:\( refs/tags/.*\)^{}$:\1:p'
to find out what object each of the remote tags refers to, and
if he has one locally, run "git-fetch $remote tag $tagname" to
automatically catch up with the upstream tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch.sh | 1 +
server-info.c | 7 +++++++
upload-pack.c | 8 ++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
applies-to: e03d0f32f8566817f50156b0c91972620b0f48fa
d6cc99156c5877a8d43df75b9f55a055f4d35e02
diff --git a/git-fetch.sh b/git-fetch.sh
index 7c05880..0cb1596 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -176,6 +176,7 @@ if test "$tags"
then
taglist=$(git-ls-remote --tags "$remote" |
sed -e '
+ /\^{}$/d
s/^[^ ]* //
s/.*/&:&/')
if test "$#" -gt 1
diff --git a/server-info.c b/server-info.c
index 3c08a28..ba53591 100644
--- a/server-info.c
+++ b/server-info.c
@@ -9,7 +9,14 @@ static FILE *info_ref_fp;
static int add_info_ref(const char *path, const unsigned char *sha1)
{
+ struct object *o = parse_object(sha1);
+
fprintf(info_ref_fp, "%s %s\n", sha1_to_hex(sha1), path);
+ if (o->type == tag_type) {
+ o = deref_tag(o);
+ fprintf(info_ref_fp, "%s %s^{}\n",
+ sha1_to_hex(o->sha1), path);
+ }
return 0;
}
diff --git a/upload-pack.c b/upload-pack.c
index 83f5a35..21b4b8b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1,6 +1,8 @@
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
+#include "tag.h"
+#include "object.h"
static const char upload_pack_usage[] = "git-upload-pack <dir>";
@@ -165,7 +167,13 @@ static int receive_needs(void)
static int send_ref(const char *refname, const unsigned char *sha1)
{
+ struct object *o = parse_object(sha1);
+
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
+ if (o->type == tag_type) {
+ o = deref_tag(o);
+ packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname);
+ }
return 0;
}
---
@@GIT_VERSION@@
^ permalink raw reply related
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Junio C Hamano @ 2005-10-14 6:59 UTC (permalink / raw)
To: Paul Eggert; +Cc: Linus Torvalds, git
In-Reply-To: <87vf02qy79.fsf@penguin.cs.ucla.edu>
Paul Eggert <eggert@CS.UCLA.EDU> writes:
> Here is the proposed format. Each file name is a string of bytes, in
> one of the following two formats:
>
> A. A nonempty sequence of ASCII graphic characters (i.e., bytes in
> the range '!' == '\041' through '~' == '\177'). The first byte
> cannot be '!' == '\041' or '"' == '\042'. Leading '"' is used for
> (B) below, and leading '!' is reserved for future extensions.
>
> B. A nonempty C-language character string literal, with the following
> restrictions and modifications:
>
> B1. No multibyte character processing is done. Members of the
> string literal are treated as bytes, not characters. Null
> bytes are not allowed, and '"' == '\042', '\\' == '\134' and
> '\n' == '\012' are allowed only if properly escaped as shown
> below; but all other bytes are allowed.
>
> B2. No trigraph processing is done (e.g., ??/ stands for three
> bytes, not one).
>
> B3. No line-splicing is done (i.e., backslash-newline is not allowed).
>
> B4. Only the following escape sequences are allowed.
>
> \" \\ \a \b \f \n \r \t \v
> \XYZ (where X, Y, and Z are octal digits, X <= 3, and
> at least one of the digits is nonzero)
Just to let you know, I am slowly converting apply.c to accept
this format, and also diff.c to produce this. I did not
personally like the missing double quotes around what I did
anyway, although it was easier to code.
^ permalink raw reply
* Re: Peeling the onion
From: Junio C Hamano @ 2005-10-14 8:40 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90510140048r30c7ec36n35f77a1ac52c4691@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I personally don't care much for the -t option, at the moment. I do
> think that tree identity is in some contexts more important than
> commit identity, so there will be instances where you really want to
> have a canonical way to "drill down" to the tree.
I do not know how useful it would be, but the onion peeler can
be told to dereference commit to tree.
$ ./git-cat-file -s 'v0.99.8^{tree}'
6875
$ ./git-cat-file -s 'v0.99.8^{commit}'
435
$ ./git-cat-file -t 'v0.99.8^{tree}'
tree
$ ./git-cat-file -t 'v0.99.8^{commit}'
commit
$ ./git-rev-parse v0.99.8 \
v0.99.8^0 v0.99.8^{commit} \
v0.99.8^{commit}^{tree} v0.99.8^{tree}
b041895af323bdef10cc9a718bda468ba3622bc0
91dd674e30ba0298e89c9be2657024805170c2ac
91dd674e30ba0298e89c9be2657024805170c2ac
bfd844a69bfd582d107622c27b89e9b959e89fd8
bfd844a69bfd582d107622c27b89e9b959e89fd8
^ permalink raw reply
* Fwd: debian packaging
From: Aneesh Kumar @ 2005-10-14 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <cc723f590510140218s76c9fca2me4ec39b03c77245f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
---------- Forwarded message ----------
From: Aneesh Kumar <aneesh.kumar@gmail.com>
Date: Oct 14, 2005 2:48 PM
Subject: debian packaging
To: junkio@cox.net
Make it build with stable testing and unstable.
-aneesh
[-- Attachment #2: git.diff --]
[-- Type: text/plain, Size: 542 bytes --]
diff --git a/debian/control b/debian/control
index 5d75c32..2ae4ee9 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: git-core
Section: devel
Priority: optional
Maintainer: Junio C Hamano <junkio@cox.net>
-Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc (>= 6.0.3), xmlto, debhelper (>= 4.0.0), bc
+Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev|libcurl3-gnutls-dev|libcurl3-openssl-dev, asciidoc (>= 6.0.3), xmlto, debhelper (>= 4.0.0), bc
Standards-Version: 3.6.1
Package: git-core
^ permalink raw reply related
* Re: maybe breakage with latest git-pull and http protocol
From: Randal L. Schwartz @ 2005-10-14 10:58 UTC (permalink / raw)
To: git
In-Reply-To: <867jciz18w.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I updated git to d06b689a933f6d2130f8afdf1ac0ddb83eeb59ab,
Randal> then compiled and installed.
Randal> When I went to "git-pull" on my cogito archive (which I had edited
Randal> to use HTTP instead of RSYNC), I got into trouble. Unfortunately,
Randal> I changed it to rsync to force cogito into a sane state before
Randal> I realized that this would be a good bug report. :)
Randal> This is perhaps just a heads-up that the recent git-pull might be
Randal> broken with respect to http updates.
Even after updating git this morning, git-pull still seems to be broken
with respect to http://www.kernel.org/.
Is http pulling broken for good now? Or is someone looking at this?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* cygwin: t3200-branch.sh fails with "List form of pipe open not implemented at -e line 22."
From: Alex Riesen @ 2005-10-14 12:46 UTC (permalink / raw)
To: git
Now, how broken is that:
The message comes from one of the hooks, which are executed even
though they never meant to, because cygwin apparently uses file
content or name to detect executability (on FAT).
I just remove the hooks from repositories atm.
^ permalink raw reply
* failing test with cogito
From: Ivo Alxneit @ 2005-10-14 13:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
hi
i use
cogito
commit 19e07806612d8cea5c8e343709d567fb796e2bb3
git
commit d06b689a933f6d2130f8afdf1ac0ddb83eeb59ab
and the following tests fail for cogito (all tests pass in git)
*** t9200-merge.sh ***
* FAIL 17: merging branch2 to branch1 (automatic)
(cd branch1 && cg-merge </dev/null)
* FAIL 18: checking for correct merged content
(cmp branch1/brm expect)
* FAIL 23: checking for correct conflict content
(cmp brm-cleaned-up expect)
*** t9202-merge-on-dirty.sh ***
* FAIL 19: checking if we still have our local change
(cd branch1 && cg-status -w | grep -q "^M foo" && cmp foo foo-)
* FAIL 36: merging branch2 to branch1 (automatic)
(cd branch1 && cg-merge </dev/null)
* FAIL 37: checking if the working copy was touched by the merge
(cd branch1 && ! cmp brm brm-)
* FAIL 38: checking if we still have our local change
(cd branch1 && cg-status -w | grep -q "^M bar" && cmp bar bar-)
* FAIL 47: confirming that we have no uncommitted modifications
(cd branch1 && [ -z "$(git-diff-index -r $(cg-object-id -t))" ])
* FAIL 50: checking if the merge caused a conflict
(cd branch1 && grep "<<<" brm)
--
Dr. Ivo Alxneit
Laboratory for Solar Technology phone: +41 56 310 4092
Paul Scherrer Institute fax: +41 56 310 2688
CH-5232 Villigen http://solar.web.psi.ch
Switzerland gnupg key: 0x515E30C7
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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