* Re: sizeof(struct ...)
From: Andy Whitcroft @ 2006-11-23 16:19 UTC (permalink / raw)
To: René Scharfe; +Cc: Erik Mouw, Gerrit Pape, git
In-Reply-To: <4565C8F4.6000606@lsrfire.ath.cx>
René Scharfe wrote:
> Erik Mouw schrieb:
>> On Thu, Nov 23, 2006 at 04:45:09PM +0100, René Scharfe wrote:
>>> Is there really a compiler that inserts padding between arrays of
>>> unsigned chars?
>> Yes, that compiler is called "gcc".
>>
>> #include <stdio.h>
>>
>> struct foo {
>> unsigned char a[3];
>> unsigned char b[3];
>> };
>>
>> int main(void)
>> {
>> printf("%d\n", sizeof(struct foo));
>> return 0;
>> }
>>
>> On i386 that prints 6, on ARM it prints 8.
>
> Does it add 1 byte after a and and 1 after b or two after b?
> I suspect it's the latter case -- otherwise Gerrit's patch,
> which started this thread, wouldn't help solve his problem.
> Or the pad sizing follows complicated rules that I do not
> understand at the moment.
>
> Time to look for an ARM emulator, it seems.
Perhaps we can look and see what a portable application like gzip or
bzip2 do in this situation. They must have the same problem.
^ permalink raw reply
* Re: git crash when cg-fetch:ing dash
From: Sean @ 2006-11-23 16:18 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: René Scharfe, git
In-Reply-To: <200611231554.kANFsv9h005228@laptop13.inf.utfsm.cl>
On Thu, 23 Nov 2006 12:54:57 -0300
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> > Horst H. von Brand schrieb:
> > > I did:
> > > git clone http://gondor.apana.org.au/~herbert/dash/dash.git
> > > and got:
> > > error: Unable to start request
> > > error: Could not interpret heads/master as something to pull
> >
> > It works for me with both the version of git that came with Ubuntu 6.10
> > (1.4.1) and a self-compiled git 1.4.4.g5942. :-?
>
> Here it's git-1.4.4 (self-built from Junio's SRPM, on Fedora rawhide i686).
Works fine here with 1.4.3.3.g869c.
Horst, this is the second recent example of something not working in your
environment that works for others. Is it possible you have an old stray
version of git installed in your ~/bin or something? By the way, did you
ever resolve that other issue?
^ permalink raw reply
* Re: sizeof(struct ...)
From: René Scharfe @ 2006-11-23 16:14 UTC (permalink / raw)
To: Erik Mouw; +Cc: Andy Whitcroft, Gerrit Pape, git
In-Reply-To: <20061123155431.GD6581@harddisk-recovery.com>
Erik Mouw schrieb:
> On Thu, Nov 23, 2006 at 04:45:09PM +0100, René Scharfe wrote:
>> Is there really a compiler that inserts padding between arrays of
>> unsigned chars?
>
> Yes, that compiler is called "gcc".
>
> #include <stdio.h>
>
> struct foo {
> unsigned char a[3];
> unsigned char b[3];
> };
>
> int main(void)
> {
> printf("%d\n", sizeof(struct foo));
> return 0;
> }
>
> On i386 that prints 6, on ARM it prints 8.
Does it add 1 byte after a and and 1 after b or two after b?
I suspect it's the latter case -- otherwise Gerrit's patch,
which started this thread, wouldn't help solve his problem.
Or the pad sizing follows complicated rules that I do not
understand at the moment.
Time to look for an ARM emulator, it seems.
Thanks,
^ permalink raw reply
* "stgit clean" has problems with removed generated files
From: Yann Dirson @ 2006-11-23 16:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
I recently encountered a problem with "stgit clean", but it really is a
generic issue, which can also impact other subcommands.
In a kernel tree, the precise problem I had is due to generated files
committed by error in an upstream branch (a BSP from a well-known
vendor, indeed ;). The first patch in my stgir stack does some cleanup
by removing them from git control (so that "make dep" does not cause
them to change every so often).
Now when I want to run "stg clean" for applied patches, stgit first
wants to pop the whole stack, including that patch, which triggers the
following error:
fatal: Untracked working tree file 'include/asm-arm/constants.h' would be overwritten by merge. stg clean: git-read-tree failed (local changes maybe?)
Obviously, removing all such files by hand allows to run "stg clean", as
does (floating and) popping that patch and deleting it, or running "stg clean
--unappplied". The 1st approach is intrusive, and forces the user to
rerun "make dep", which is not very friendy; the 2nd one is too error-prone for
an operation that ought to be risk-less (delete has no --undo). The 3rd option
is probably the best, but is surely not so intuitive.
The root issue seems to be that stgit has problem with such generated
files, ie., files that were removed from version-control, but can still
legitimately exist in the tree. Dealing with them could possibly be
done (eg. allowing to back them up, and restore them when pushing the
annoying patch), but is not a trivial issue (eg. we still need to guard
the user against real conflicts).
At least we could put a notice about this case in the doc, so users
don't get too surprised.
I could think of several (non-exclusive) possibilities to deal with the
precise problem I got, which should allow.
First, when cleaning patches, we could first look up which patches are
to be removed, and only pop the necessary ones.
Second, we could generalize the "clean" subcommand to accept arbitrary
ranges, not only the "applied" and "unapplied" ones. A special case
would be "stg clean that-patch", which would be a secure version of "stg
delete".
BTW, maybe it would those make sense to allowthose special ranges in
most places a range is valid.
Best regards,
--
^ permalink raw reply
* Re: git crash when cg-fetch:ing dash
From: Horst H. von Brand @ 2006-11-23 15:54 UTC (permalink / raw)
To: René Scharfe; +Cc: Horst H. von Brand, git
In-Reply-To: <45656B3C.4090601@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Horst H. von Brand schrieb:
> > I did:
> > git clone http://gondor.apana.org.au/~herbert/dash/dash.git
> > and got:
> > error: Unable to start request
> > error: Could not interpret heads/master as something to pull
>
> It works for me with both the version of git that came with Ubuntu 6.10
> (1.4.1) and a self-compiled git 1.4.4.g5942. :-?
Here it's git-1.4.4 (self-built from Junio's SRPM, on Fedora rawhide i686).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: sizeof(struct ...)
From: Erik Mouw @ 2006-11-23 15:54 UTC (permalink / raw)
To: Ren? Scharfe; +Cc: Andy Whitcroft, Gerrit Pape, git
In-Reply-To: <4565C205.8050300@lsrfire.ath.cx>
On Thu, Nov 23, 2006 at 04:45:09PM +0100, Ren? Scharfe wrote:
> Andy Whitcroft schrieb:
> > You see packing attributes applied to similar things in the kernel.
> > Perhaps they are relevant here?
> > Is there not some kind of attribute thing we can apply to this structure
> > to prevent the padding? You see that in the kernel from time to time.
> >
> > struct foo {
> > } __attribute__((packed));
>
> Yes, that would be nice, but unfortunately __attribute__ is no standard
> C.
There is no standard C way to pack structures. Some compilers use
#pragma's, gcc uses __attribute__((packed)).
> Is there really a compiler that inserts padding between arrays of
> unsigned chars?
Yes, that compiler is called "gcc".
#include <stdio.h>
struct foo {
unsigned char a[3];
unsigned char b[3];
};
int main(void)
{
printf("%d\n", sizeof(struct foo));
return 0;
}
On i386 that prints 6, on ARM it prints 8.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
^ permalink raw reply
* Re: sizeof(struct ...)
From: René Scharfe @ 2006-11-23 15:45 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Gerrit Pape, git
In-Reply-To: <4565A866.8020201@shadowen.org>
Andy Whitcroft schrieb:
> This structure represents an on-disk/on-the-wire thing, should we not be
> specifying it in some architecture neutral way? You are going to get
> the length right in the case of tail padding but not in the face of any
> other padding internally.
>
> You see packing attributes applied to similar things in the kernel.
> Perhaps they are relevant here?
> Is there not some kind of attribute thing we can apply to this structure
> to prevent the padding? You see that in the kernel from time to time.
>
> struct foo {
> } __attribute__((packed));
Yes, that would be nice, but unfortunately __attribute__ is no standard
C. Is there really a compiler that inserts padding between arrays of
unsigned chars?
Thanks,
^ permalink raw reply
* Re: StGit metadata grabbing with git clone
From: Otavio Salvador @ 2006-11-23 14:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxslgawic2.fsf@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> Otavio Salvador <otavio@debian.org> wrote:
>> I'm a happy user of stgit together with git to maintain a patch queue
>> while I or the company team is working on patches that will be send
>> for merging. Both works great but we're having troubles when we try to
>> clone a stgit repository.
>>
>> When I clone the repository it grab the source but it loses the
>> metadata. I would like to grab those too. Does anybody has a solution
>> or a trick how I can do that?
>
> Most of the StGIT metadata can be generated by "uncommit" (the reason
> I still keep a lot of this metadata like author etc. is for
> speed). However, I'm not sure how well this would work since you can
> nor synchronise the patches afterwards. StGIT works well for sharing
> patches via e-mail but you might want to consider topic branches
> instead of patches (though StGIT seems more convenient).
>
> Another idea is to export the patches (stg export) to a common place
> and import them in the other tree (stg import --series --replace). I
> could also add a --sync option to "import", instead of --replace,
> which would perform a three-way merge with the coresponding local
> patches so that it grabs any additional changes in both repositories
> or branches (similar to "pick --fold", option which I added for the
> same reason).
>
> Yet another idea is a "stg import" command for remote repositories or
> branches which would bring in the StGIT metadata.
>
> At the bottom of the TODO list is something that would solve this,
> only that I've never found the time to think about it properly. I work
> on several branches (and even separate trees) and share patches
> between them. It would be nice to be able to synchronise the changes
> to these patches.
That would be a really nice feature. Besides, would be nice to have a
way to plug something on clone and push git methods so you might send
all those metadata without much hassle.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
^ permalink raw reply
* Re: sizeof(struct ...)
From: Andy Whitcroft @ 2006-11-23 13:55 UTC (permalink / raw)
To: René Scharfe; +Cc: Gerrit Pape, git
In-Reply-To: <4565A46C.6090805@lsrfire.ath.cx>
René Scharfe wrote:
> Oh no, whitespace damage! The major downside of getting a new
> machine is that Thunderbird needs to be beaten into submission
> again. :-( Here's the patch a second time, hopefully intact.
>
> René
>
This structure represents an on-disk/on-the-wire thing, should we not be
specifying it in some architecture neutral way? You are going to get
the length right in the case of tail padding but not in the face of any
other padding internally.
You see packing attributes applied to similar things in the kernel.
Perhaps they are relevant here?
Is there not some kind of attribute thing we can apply to this structure
to prevent the padding? You see that in the kernel from time to time.
struct foo {
} __attribute__((packed));
-apw
>
> archive-zip.c | 24 ++++++++++++++++++------
> 1 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/archive-zip.c b/archive-zip.c
> index ae5572a..4caaec4 100644
> --- a/archive-zip.c
> +++ b/archive-zip.c
> @@ -35,6 +35,7 @@ struct zip_local_header {
> unsigned char size[4];
> unsigned char filename_length[2];
> unsigned char extra_length[2];
> + unsigned char _end[0];
> };
>
> struct zip_dir_header {
> @@ -55,6 +56,7 @@ struct zip_dir_header {
> unsigned char attr1[2];
> unsigned char attr2[4];
> unsigned char offset[4];
> + unsigned char _end[0];
> };
>
> struct zip_dir_trailer {
> @@ -66,8 +68,18 @@ struct zip_dir_trailer {
> unsigned char size[4];
> unsigned char offset[4];
> unsigned char comment_length[2];
> + unsigned char _end[0];
> };
>
> +/*
> + * On ARM, padding is added at the end of the struct, so a simple
> + * sizeof(struct ...) reports two bytes more than the payload size
> + * we're interested in.
> + */
> +#define ZIP_LOCAL_HEADER_SIZE offsetof(struct zip_local_header, _end)
> +#define ZIP_DIR_HEADER_SIZE offsetof(struct zip_dir_header, _end)
> +#define ZIP_DIR_TRAILER_SIZE offsetof(struct zip_dir_trailer, _end)
> +
> static void copy_le16(unsigned char *dest, unsigned int n)
> {
> dest[0] = 0xff & n;
> @@ -211,7 +223,7 @@ static int write_zip_entry(const unsigne
> }
>
> /* make sure we have enough free space in the dictionary */
> - direntsize = sizeof(struct zip_dir_header) + pathlen;
> + direntsize = ZIP_DIR_HEADER_SIZE + pathlen;
> while (zip_dir_size < zip_dir_offset + direntsize) {
> zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
> zip_dir = xrealloc(zip_dir, zip_dir_size);
> @@ -234,8 +246,8 @@ static int write_zip_entry(const unsigne
> copy_le16(dirent.attr1, 0);
> copy_le32(dirent.attr2, attr2);
> copy_le32(dirent.offset, zip_offset);
> - memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
> - zip_dir_offset += sizeof(struct zip_dir_header);
> + memcpy(zip_dir + zip_dir_offset, &dirent, ZIP_DIR_HEADER_SIZE);
> + zip_dir_offset += ZIP_DIR_HEADER_SIZE;
> memcpy(zip_dir + zip_dir_offset, path, pathlen);
> zip_dir_offset += pathlen;
> zip_dir_entries++;
> @@ -251,8 +263,8 @@ static int write_zip_entry(const unsigne
> copy_le32(header.size, uncompressed_size);
> copy_le16(header.filename_length, pathlen);
> copy_le16(header.extra_length, 0);
> - write_or_die(1, &header, sizeof(struct zip_local_header));
> - zip_offset += sizeof(struct zip_local_header);
> + write_or_die(1, &header, ZIP_LOCAL_HEADER_SIZE);
> + zip_offset += ZIP_LOCAL_HEADER_SIZE;
> write_or_die(1, path, pathlen);
> zip_offset += pathlen;
> if (compressed_size > 0) {
> @@ -282,7 +294,7 @@ static void write_zip_trailer(const unsi
> copy_le16(trailer.comment_length, sha1 ? 40 : 0);
>
> write_or_die(1, zip_dir, zip_dir_offset);
> - write_or_die(1, &trailer, sizeof(struct zip_dir_trailer));
> + write_or_die(1, &trailer, ZIP_DIR_TRAILER_SIZE);
> if (sha1)
> write_or_die(1, sha1_to_hex(sha1), 40);
> }
> -
> 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: sizeof(struct ...)
From: René Scharfe @ 2006-11-23 13:38 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <45659781.5050005@lsrfire.ath.cx>
Oh no, whitespace damage! The major downside of getting a new
machine is that Thunderbird needs to be beaten into submission
again. :-( Here's the patch a second time, hopefully intact.
René
archive-zip.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index ae5572a..4caaec4 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -35,6 +35,7 @@ struct zip_local_header {
unsigned char size[4];
unsigned char filename_length[2];
unsigned char extra_length[2];
+ unsigned char _end[0];
};
struct zip_dir_header {
@@ -55,6 +56,7 @@ struct zip_dir_header {
unsigned char attr1[2];
unsigned char attr2[4];
unsigned char offset[4];
+ unsigned char _end[0];
};
struct zip_dir_trailer {
@@ -66,8 +68,18 @@ struct zip_dir_trailer {
unsigned char size[4];
unsigned char offset[4];
unsigned char comment_length[2];
+ unsigned char _end[0];
};
+/*
+ * On ARM, padding is added at the end of the struct, so a simple
+ * sizeof(struct ...) reports two bytes more than the payload size
+ * we're interested in.
+ */
+#define ZIP_LOCAL_HEADER_SIZE offsetof(struct zip_local_header, _end)
+#define ZIP_DIR_HEADER_SIZE offsetof(struct zip_dir_header, _end)
+#define ZIP_DIR_TRAILER_SIZE offsetof(struct zip_dir_trailer, _end)
+
static void copy_le16(unsigned char *dest, unsigned int n)
{
dest[0] = 0xff & n;
@@ -211,7 +223,7 @@ static int write_zip_entry(const unsigne
}
/* make sure we have enough free space in the dictionary */
- direntsize = sizeof(struct zip_dir_header) + pathlen;
+ direntsize = ZIP_DIR_HEADER_SIZE + pathlen;
while (zip_dir_size < zip_dir_offset + direntsize) {
zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
zip_dir = xrealloc(zip_dir, zip_dir_size);
@@ -234,8 +246,8 @@ static int write_zip_entry(const unsigne
copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
- memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
- zip_dir_offset += sizeof(struct zip_dir_header);
+ memcpy(zip_dir + zip_dir_offset, &dirent, ZIP_DIR_HEADER_SIZE);
+ zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
zip_dir_offset += pathlen;
zip_dir_entries++;
@@ -251,8 +263,8 @@ static int write_zip_entry(const unsigne
copy_le32(header.size, uncompressed_size);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, 0);
- write_or_die(1, &header, sizeof(struct zip_local_header));
- zip_offset += sizeof(struct zip_local_header);
+ write_or_die(1, &header, ZIP_LOCAL_HEADER_SIZE);
+ zip_offset += ZIP_LOCAL_HEADER_SIZE;
write_or_die(1, path, pathlen);
zip_offset += pathlen;
if (compressed_size > 0) {
@@ -282,7 +294,7 @@ static void write_zip_trailer(const unsi
copy_le16(trailer.comment_length, sha1 ? 40 : 0);
write_or_die(1, zip_dir, zip_dir_offset);
- write_or_die(1, &trailer, sizeof(struct zip_dir_trailer));
+ write_or_die(1, &trailer, ZIP_DIR_TRAILER_SIZE);
if (sha1)
write_or_die(1, sha1_to_hex(sha1), 40);
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Horst H. von Brand @ 2006-11-23 2:52 UTC (permalink / raw)
To: hanwen; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <455CFCBD.8040901@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
[...]
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.
>
> - clone but not a put-clone,
Lost me there.
> - pull = merge + fetch, but no command for merge + throw
throw + merge (at the remote end, that is)?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: sizeof(struct ...)
From: René Scharfe @ 2006-11-23 12:43 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20061123101609.1711.qmail@8b73034525b1a6.315fe32.mid.smarden.org>
Gerrit Pape schrieb:
> Hi, I don't think we can rely on sizeof(struct ...) to be the exact size
> of the struct as defined. As the selftests show, archive-zip doesn't
> work correctly on Debian/arm
>
> http://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1%3A1.4.4-1&arch=arm&stamp=1164122355&file=log
>
> It's because sizeof(struct zip_local_header) is 32, zip_dir_header 48,
> and zip_dir_trailer 24, breaking the zip files. Compiling with
> -fpack-struct seemed to break other things, so I for now I ended up with
> this (not so nice) workaround.
Hm, yes, this use sizeof() is not strictly correct. But I'd very much
like to keep being lazy and let the compiler to do the summing. How
about this patch instead? Does it work for you, Gerrit?
Thanks,
René
archive-zip.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index ae5572a..4caaec4 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -35,6 +35,7 @@ struct zip_local_header {
unsigned char size[4];
unsigned char filename_length[2];
unsigned char extra_length[2];
+ unsigned char _end[0];
};
struct zip_dir_header {
@@ -55,6 +56,7 @@ struct zip_dir_header {
unsigned char attr1[2];
unsigned char attr2[4];
unsigned char offset[4];
+ unsigned char _end[0];
};
struct zip_dir_trailer {
@@ -66,8 +68,18 @@ struct zip_dir_trailer {
unsigned char size[4];
unsigned char offset[4];
unsigned char comment_length[2];
+ unsigned char _end[0];
};
+/*
+ * On ARM, padding is added at the end of the struct, so a simple
+ * sizeof(struct ...) reports two bytes more than the payload size
+ * we're interested in.
+ */
+#define ZIP_LOCAL_HEADER_SIZE offsetof(struct zip_local_header, _end)
+#define ZIP_DIR_HEADER_SIZE offsetof(struct zip_dir_header, _end)
+#define ZIP_DIR_TRAILER_SIZE offsetof(struct zip_dir_trailer, _end)
+
static void copy_le16(unsigned char *dest, unsigned int n)
{
dest[0] = 0xff & n;
@@ -211,7 +223,7 @@ static int write_zip_entry(const unsigne
}
/* make sure we have enough free space in the dictionary */
- direntsize = sizeof(struct zip_dir_header) + pathlen;
+ direntsize = ZIP_DIR_HEADER_SIZE + pathlen;
while (zip_dir_size < zip_dir_offset + direntsize) {
zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
zip_dir = xrealloc(zip_dir, zip_dir_size);
@@ -234,8 +246,8 @@ static int write_zip_entry(const unsigne
copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
- memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
- zip_dir_offset += sizeof(struct zip_dir_header);
+ memcpy(zip_dir + zip_dir_offset, &dirent, ZIP_DIR_HEADER_SIZE);
+ zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
zip_dir_offset += pathlen;
zip_dir_entries++;
@@ -251,8 +263,8 @@ static int write_zip_entry(const unsigne
copy_le32(header.size, uncompressed_size);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, 0);
- write_or_die(1, &header, sizeof(struct zip_local_header));
- zip_offset += sizeof(struct zip_local_header);
+ write_or_die(1, &header, ZIP_LOCAL_HEADER_SIZE);
+ zip_offset += ZIP_LOCAL_HEADER_SIZE;
write_or_die(1, path, pathlen);
zip_offset += pathlen;
if (compressed_size > 0) {
@@ -282,7 +294,7 @@ static void write_zip_trailer(const unsi
copy_le16(trailer.comment_length, sha1 ? 40 : 0);
write_or_die(1, zip_dir, zip_dir_offset);
- write_or_die(1, &trailer, sizeof(struct zip_dir_trailer));
+ write_or_die(1, &trailer, ZIP_DIR_TRAILER_SIZE);
if (sha1)
write_or_die(1, sha1_to_hex(sha1), 40);
^ permalink raw reply related
* Re: Advice on converting to git from versioning-by-directory
From: Andy Parkins @ 2006-11-23 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <20061123100757.GB32620@coredump.intra.peff.net>
On Thursday 2006 November 23 10:07, Jeff King wrote:
> If I understand you correctly, you want to take four branches, each with
> data in version1/, version2/, etc, and make it look like they all had
> data in the project root throughout history. Is that right?
Yes. In essence I want to move the spatial dimension (directories) into git's
time dimension (branches).
> If so, cogito's cg-admin-rewritehist can probably do what you want (I
> also posted a script a while back to do this exact thing, and I can dig
> it up if you want).
I will have a look at cg-admin-rewritehist. After Andy pointed out that they
were just like traditional svn branches, I'm having good luck using multiple
runs of git-svn to track each directory as if it were a separate branch.
Thank you for the offer of a script, but don't go to any trouble to find it
just yet. I think I have it licked now.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: StGit metadata grabbing with git clone
From: Catalin Marinas @ 2006-11-23 10:47 UTC (permalink / raw)
To: Otavio Salvador; +Cc: git
In-Reply-To: <87ac2jwutu.fsf@neumann.lab.ossystems.com.br>
Otavio Salvador <otavio@debian.org> wrote:
> I'm a happy user of stgit together with git to maintain a patch queue
> while I or the company team is working on patches that will be send
> for merging. Both works great but we're having troubles when we try to
> clone a stgit repository.
>
> When I clone the repository it grab the source but it loses the
> metadata. I would like to grab those too. Does anybody has a solution
> or a trick how I can do that?
Most of the StGIT metadata can be generated by "uncommit" (the reason
I still keep a lot of this metadata like author etc. is for
speed). However, I'm not sure how well this would work since you can
nor synchronise the patches afterwards. StGIT works well for sharing
patches via e-mail but you might want to consider topic branches
instead of patches (though StGIT seems more convenient).
Another idea is to export the patches (stg export) to a common place
and import them in the other tree (stg import --series --replace). I
could also add a --sync option to "import", instead of --replace,
which would perform a three-way merge with the coresponding local
patches so that it grabs any additional changes in both repositories
or branches (similar to "pick --fold", option which I added for the
same reason).
Yet another idea is a "stg import" command for remote repositories or
branches which would bring in the StGIT metadata.
At the bottom of the TODO list is something that would solve this,
only that I've never found the time to think about it properly. I work
on several branches (and even separate trees) and share patches
between them. It would be nice to be able to synchronise the changes
to these patches.
--
^ permalink raw reply
* sizeof(struct ...)
From: Gerrit Pape @ 2006-11-23 10:16 UTC (permalink / raw)
To: git
Hi, I don't think we can rely on sizeof(struct ...) to be the exact size
of the struct as defined. As the selftests show, archive-zip doesn't
work correctly on Debian/arm
http://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1%3A1.4.4-1&arch=arm&stamp=1164122355&file=log
It's because sizeof(struct zip_local_header) is 32, zip_dir_header 48,
and zip_dir_trailer 24, breaking the zip files. Compiling with
-fpack-struct seemed to break other things, so I for now I ended up with
this (not so nice) workaround.
Regards, Gerrit.
diff --git a/archive-zip.c b/archive-zip.c
index ae5572a..4fcda44 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -211,7 +211,7 @@ static int write_zip_entry(const unsigne
}
/* make sure we have enough free space in the dictionary */
- direntsize = sizeof(struct zip_dir_header) + pathlen;
+ direntsize = 46 + pathlen;
while (zip_dir_size < zip_dir_offset + direntsize) {
zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
zip_dir = xrealloc(zip_dir, zip_dir_size);
@@ -234,8 +234,8 @@ static int write_zip_entry(const unsigne
copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
- memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
- zip_dir_offset += sizeof(struct zip_dir_header);
+ memcpy(zip_dir + zip_dir_offset, &dirent, 46);
+ zip_dir_offset += 46;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
zip_dir_offset += pathlen;
zip_dir_entries++;
@@ -251,8 +251,8 @@ static int write_zip_entry(const unsigne
copy_le32(header.size, uncompressed_size);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, 0);
- write_or_die(1, &header, sizeof(struct zip_local_header));
- zip_offset += sizeof(struct zip_local_header);
+ write_or_die(1, &header, 30);
+ zip_offset += 30;
write_or_die(1, path, pathlen);
zip_offset += pathlen;
if (compressed_size > 0) {
@@ -282,7 +282,7 @@ static void write_zip_trailer(const unsi
copy_le16(trailer.comment_length, sha1 ? 40 : 0);
write_or_die(1, zip_dir, zip_dir_offset);
- write_or_die(1, &trailer, sizeof(struct zip_dir_trailer));
+ write_or_die(1, &trailer, 22);
if (sha1)
write_or_die(1, sha1_to_hex(sha1), 40);
^ permalink raw reply related
* Re: Advice on converting to git from versioning-by-directory
From: Andy Parkins @ 2006-11-23 10:09 UTC (permalink / raw)
To: git
In-Reply-To: <456570BE.5040702@shadowen.org>
On Thursday 2006 November 23 09:58, Andy Whitcroft wrote:
> Ok, why is this so different from any normal SVN repository?
> Yes your branches are in the 'wrong' place. But they behave as you'd
> expect don't they? Each one has linear history from its appearance,
What an absolutely excellent idea. It's so obvious now you say it, but all
the best ideas are.
> No idea if thats any use...
It's of enormous use. Thank you very much.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Advice on converting to git from versioning-by-directory
From: Jeff King @ 2006-11-23 10:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611230916.46415.andyparkins@gmail.com>
On Thu, Nov 23, 2006 at 09:16:44AM +0000, Andy Parkins wrote:
> What should I do? I've thought of a number of things:
> * Recreate the whole lot by hand, the repository isn't huge and I could
> manually apply each commit as a patch in the correct place. It would be a
> bit time-consuming but would mean I'd have what I wanted
If I understand you correctly, you want to take four branches, each with
data in version1/, version2/, etc, and make it look like they all had
data in the project root throughout history. Is that right?
If so, cogito's cg-admin-rewritehist can probably do what you want (I
also posted a script a while back to do this exact thing, and I can dig
it up if you want).
^ permalink raw reply
* [PATCH] Increase length of function name buffer
From: Andy Parkins @ 2006-11-23 10:05 UTC (permalink / raw)
To: git
In xemit.c:xdl_emit_diff() a buffer for showing the function name as
commentary is allocated; this buffer was 40 characters. This is a bit
small; particularly for C++ function names where there is often an
identical prefix (like void LongNamespace::LongClassName) on multiple
functions, which makes the context the same everywhere. In other words
the context is useless. This patch increases that buffer to 80
characters - which may still not be enough, but is better
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
xdiff/xemit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 07995ec..e291dc7 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -118,7 +118,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
long s1, s2, e1, e2, lctx;
xdchange_t *xch, *xche;
- char funcbuf[40];
+ char funcbuf[80];
long funclen = 0;
if (xecfg->flags & XDL_EMIT_COMMON)
--
1.4.3.GIT-dirty
^ permalink raw reply related
* Re: rebase fails but not sure why
From: Jeff King @ 2006-11-23 9:59 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611230026.58936.alan@chandlerfamily.org.uk>
On Thu, Nov 23, 2006 at 12:26:58AM +0000, Alan Chandler wrote:
> I have now got to a point where the following error occurs during a rebase.
>
> fatal: empty ident <alan@chandlerfamily.org.uk> not allowed
> Commit failed, please do not call "git commit"
> directly, but instead do one of the following:
It should be pulling that identity from the old commit (using git-commit
-C). Do you have a commit object with a blank author or committer name
(which shouldn't have been allowed in the first place, but you never
know)? Try running git-log on the range of commits being rebased.
^ permalink raw reply
* Re: Advice on converting to git from versioning-by-directory
From: Andy Whitcroft @ 2006-11-23 9:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611230916.46415.andyparkins@gmail.com>
Andy Parkins wrote:
> Hello,
>
> This is an overly long email, please don't waste your time unless you're
> interested in git-based puzzles. I'm only really trying to solve the problem
> for fun. (This is what I do for fun now? Oh dear).
>
> I'm in the process of converting a colleague to using git for his project.
> Previously it was stored in subversion - but was only really used as a backup
> system, history is entirely linear and there are no merges and no branches.
> Branching was effectively done by copying directories. So the history went
> like this:
>
> * version1/ created and worked on with regular commits
> * version2/ created as a copy of version 1
> * version2/ worked on with regular commits
> * occasional commits in version1/
> * version3/ created as a copy of version2/ and worked on
> * version4/ created as a copy of version2/ and worked on
>
> I simply converted the subversion repository to git and then used a bit of
> rebase and cherry-pick work to put each commit in a particular directory in
> its correct branch.
>
> * -- * -- * -- * -- * version1
> \
> * -- * -- * version2
> |\
> | * -- * version3
> \
> * -- * version4
>
> This is pretty good. It's certainly a huge improvement over what there was.
> However, it's still not quite what I want. The problem is that I haven't
> done any directory reorganising so now this is a mixed version-by-directory
> and version-by-branch repository. For example the version4 branch, because
> it came from version2, which came from version1 contains directories
> version1/, version2/ and version4/.
>
> This makes merging changes impossible, a bug fix in version1, when pulled into
> version4 simply goes in version4's version1/ directory - obviously not what
> would be wanted.
>
> Phew; still with me? Obviously what I would like is to remove each
> subdirectory, and have all the branching done using git. However, I'd like
> to keep the history so far for each branch.
>
> What should I do? I've thought of a number of things:
> * Recreate the whole lot by hand, the repository isn't huge and I could
> manually apply each commit as a patch in the correct place. It would be a
> bit time-consuming but would mean I'd have what I wanted
> * Keep the current history and move and remove files out of each branch to
> make it look like I want it now, and allow history to be a bit of a mess.
> * As I make each branch reorganise it early on, _then_ apply the history of
> each branch to the right branch.
>
> I'm tempted to go with recreate by hand, as that has the fewest compromises.
> Before I did that though I thought I'd ask you clever chaps to see if you had
> any amazing ideas :-)
Ok, why is this so different from any normal SVN repository?
Yes your branches are in the 'wrong' place. But they behave as you'd
expect don't they? Each one has linear history from its appearance,
each is made from another branch. I am supprised that you can't use
some mild variation on the svnimport to get it in. I thought you could
move the branch directory etc.
On the assumption that its too differnt to make it work which is
entirely possible. It feels like you could use the tree identity to
figure out which tree each is a copy of, where identity is something
like this:
identity() {
(
cd "$1" && \
find . -type f -print | xargs md5sum | md5sum -
)
}
I would then start with the svn repo checked out as 'svn' and an empty
git repo as 'git', it might go something like the following completly
untested fragment below:
let rev=0
let max=NNN
export GIT_DIR=`pwd/git/.git`
while [ "$rev" -lt "$max" ]; do
# Get the next svn revision ...
svn update -r $rev
# For each 'directory' version ...
for vd in *; do
if git branch | grep "$vd"; then
# We have this branch, so move to it ...
( cd git; git checkout "$vd")
else
# New one, find out where it came from ...
id=`identity "$vd"`
for from in *; do
if [ "$from" != "$vd" ]; then
if [ "$id" = `identity "$from" ]; then
git checkout -v "$vd" "$from"
break
fi
fi
done
fi
rm -rf git/*
cp -rp "$vd" git
( cd git; git add .; git commit -a -m "svn commit message" )
done
done
Obviously it needs some error handling if we can't find the 'copy
source', likely we would need to checkin an empty commit under the first
version name, and its not doing the svn commit message etc.
No idea if thats any use...
-apw
^ permalink raw reply
* [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Peter Baumann @ 2006-11-23 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <7v64d8y4tu.fsf@assigned-by-dhcp.cox.net>
This allows one to see the root commit as a diff in commands like git-log,
git-show and git-whatchanged. It also modifies git-diff-tree to act as --root
was specified on the commandline. The default is set to true.
Signed-off-by: Peter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de>
---
I'm not sure if making core.showroot acting on git-diff-tree is the
right thing to do. Please check first bevore applying.
Documentation/config.txt | 6 ++++++
builtin-diff-tree.c | 1 +
builtin-log.c | 3 +++
cache.h | 1 +
config.c | 5 +++++
environment.c | 1 +
6 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9d3c71c..7e600ca 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -110,6 +110,12 @@ core.legacyheaders::
database directly (where the "http://" and "rsync://" protocols
count as direct access).
+core.showroot::
+ If true, the initial commit will be shown as a big creation event.
+ This is equivalent to a diff against an empty tree.
+ Tools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which
+ normally hide the root commit will now show it. True by default.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index 24cb2d7..d58b7ca 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -72,6 +72,7 @@ int cmd_diff_tree(int argc, const char *
nr_sha1 = 0;
opt->abbrev = 0;
opt->diff = 1;
+ opt->show_root_diff = show_root_diff;
argc = setup_revisions(argc, argv, opt, NULL);
while (--argc > 0) {
diff --git a/builtin-log.c b/builtin-log.c
index fedb013..9541c7d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -53,6 +53,7 @@ int cmd_whatchanged(int argc, const char
rev.diff = 1;
rev.diffopt.recursive = 1;
rev.simplify_history = 0;
+ rev.show_root_diff = show_root_diff;
cmd_log_init(argc, argv, prefix, &rev);
if (!rev.diffopt.output_format)
rev.diffopt.output_format = DIFF_FORMAT_RAW;
@@ -72,6 +73,7 @@ int cmd_show(int argc, const char **argv
rev.always_show_header = 1;
rev.ignore_merges = 0;
rev.no_walk = 1;
+ rev.show_root_diff = show_root_diff;
cmd_log_init(argc, argv, prefix, &rev);
return cmd_log_walk(&rev);
}
@@ -83,6 +85,7 @@ int cmd_log(int argc, const char **argv,
git_config(git_diff_ui_config);
init_revisions(&rev, prefix);
rev.always_show_header = 1;
+ rev.show_root_diff = show_root_diff;
cmd_log_init(argc, argv, prefix, &rev);
return cmd_log_walk(&rev);
}
diff --git a/cache.h b/cache.h
index f2ec5c8..feff2bd 100644
--- a/cache.h
+++ b/cache.h
@@ -191,6 +191,7 @@ extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
extern int zlib_compression_level;
+extern int show_root_diff;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index 3cae390..dd720b5 100644
--- a/config.c
+++ b/config.c
@@ -319,6 +319,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.showroot")) {
+ show_root_diff = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 84d870c..71099f4 100644
--- a/environment.c
+++ b/environment.c
@@ -24,6 +24,7 @@ const char *apply_default_whitespace;
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
int pager_in_use;
int pager_use_color = 1;
+int show_root_diff = 1;
static const char *git_dir;
static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
--
1.4.3.3
^ permalink raw reply related
* Re: git crash when cg-fetch:ing dash
From: René Scharfe @ 2006-11-23 9:34 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200611230247.kAN2lbLU006457@laptop13.inf.utfsm.cl>
Horst H. von Brand schrieb:
> I did:
>
> git clone http://gondor.apana.org.au/~herbert/dash/dash.git
>
> and got:
>
> error: Unable to start request
> error: Could not interpret heads/master as something to pull
It works for me with both the version of git that came with Ubuntu 6.10
(1.4.1) and a self-compiled git 1.4.4.g5942. :-?
^ permalink raw reply
* Re: git-show --stat on first commit
From: Andy Parkins @ 2006-11-23 9:25 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <ejvlv9$781$1@sea.gmane.org>
On Tuesday 2006 November 21 20:03, Jakub Narebski wrote:
> We don't show patch for merges by default in git-show, so I don't
> see why we would want to show root commit diff in git-show by default:
> those two are very similar.
$ git init-db
$ date > file1
$ git add file1; git commit -a -m "file1 added"
$ date > file2
$ git add file2; git commit -a -m "file2 added"
$ git show --stat HEAD
$ git show --stat HEAD^
I can understand while people get confused. Two patches, both add a file.
git-show on one of them shows a stat; on the other it doesn't.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Advice on converting to git from versioning-by-directory
From: Andy Parkins @ 2006-11-23 9:16 UTC (permalink / raw)
To: git
Hello,
This is an overly long email, please don't waste your time unless you're
interested in git-based puzzles. I'm only really trying to solve the problem
for fun. (This is what I do for fun now? Oh dear).
I'm in the process of converting a colleague to using git for his project.
Previously it was stored in subversion - but was only really used as a backup
system, history is entirely linear and there are no merges and no branches.
Branching was effectively done by copying directories. So the history went
like this:
* version1/ created and worked on with regular commits
* version2/ created as a copy of version 1
* version2/ worked on with regular commits
* occasional commits in version1/
* version3/ created as a copy of version2/ and worked on
* version4/ created as a copy of version2/ and worked on
I simply converted the subversion repository to git and then used a bit of
rebase and cherry-pick work to put each commit in a particular directory in
its correct branch.
* -- * -- * -- * -- * version1
\
* -- * -- * version2
|\
| * -- * version3
\
* -- * version4
This is pretty good. It's certainly a huge improvement over what there was.
However, it's still not quite what I want. The problem is that I haven't
done any directory reorganising so now this is a mixed version-by-directory
and version-by-branch repository. For example the version4 branch, because
it came from version2, which came from version1 contains directories
version1/, version2/ and version4/.
This makes merging changes impossible, a bug fix in version1, when pulled into
version4 simply goes in version4's version1/ directory - obviously not what
would be wanted.
Phew; still with me? Obviously what I would like is to remove each
subdirectory, and have all the branching done using git. However, I'd like
to keep the history so far for each branch.
What should I do? I've thought of a number of things:
* Recreate the whole lot by hand, the repository isn't huge and I could
manually apply each commit as a patch in the correct place. It would be a
bit time-consuming but would mean I'd have what I wanted
* Keep the current history and move and remove files out of each branch to
make it look like I want it now, and allow history to be a bit of a mess.
* As I make each branch reorganise it early on, _then_ apply the history of
each branch to the right branch.
I'm tempted to go with recreate by hand, as that has the fewest compromises.
Before I did that though I thought I'd ask you clever chaps to see if you had
any amazing ideas :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Johannes Sixt @ 2006-11-23 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611212116340.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> I started playing with MinGW, and got it to compile and run, with some
> features lacking. See
>
> Message-ID: <Pine.LNX.4.63.0609021724110.28360@wbgn013.biozentrum.uni-wuerzburg.de>
>
> for details. From TFM
>
> : The two biggest obstacles are fork() and the network stuff (I do not
> : plan on supporting Git.pm there). To overcome the absence of fork() I
> : wanted to use the subprocess stuff in MinGW's port of GNU make.
I'd like to do something about it. Is your work accessible in some way?
At the moment I'm limping along with CVS on Windows, which really is the
wrong tool for my current task (CVS I mean, not Windows ;)
-- Hannes
^ 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