* Re: How should I handle binary file with GIT
From: Randal L. Schwartz @ 2006-04-05 15:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0604051131010.2550@localhost.localdomain>
>>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>> IIRC bsdiff is used by Firefox to distribute binary software updates.
>> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
>> supposedly offers worse compression (bigger diffs).
Nicolas> We already have our own delta code for pack storage.
I think the issue is related to being able to cherry-pick and merge
when binaries are involved. I've been worried about that myself.
How well are binaries supported these days for all the operations
we're taking for granted? When is a "diff" expected to be a real
"diff" and not just "binary files differ"?
--
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
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 15:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e10mn9$cjs$1@sea.gmane.org>
On Wed, 5 Apr 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > It _might_ make sense to adopt a well-defined binary patch
> > format (or if there is no prior art, introduce our own) and
> > support that format with both git-diff-* brothers and git-apply,
> > but that would be a bit longer term project.
>
> bsdiff? http://www.daemonology.net/bsdiff/
> EDelta? http://www.diku.dk/~jacobg/edelta/
> Xdelta? http://xdelta.blogspot.com/
>
> IIRC bsdiff is used by Firefox to distribute binary software updates.
> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
> supposedly offers worse compression (bigger diffs).
We already have our own delta code for pack storage.
Nicolas
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Jakub Narebski @ 2006-04-05 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bgs4exz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It _might_ make sense to adopt a well-defined binary patch
> format (or if there is no prior art, introduce our own) and
> support that format with both git-diff-* brothers and git-apply,
> but that would be a bit longer term project.
bsdiff? http://www.daemonology.net/bsdiff/
EDelta? http://www.diku.dk/~jacobg/edelta/
Xdelta? http://xdelta.blogspot.com/
IIRC bsdiff is used by Firefox to distribute binary software updates.
Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
supposedly offers worse compression (bigger diffs).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] Avoid a crash if realloc returns a different pointer.
From: Mike McCormack @ 2006-04-05 14:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 80 bytes --]
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Attachment #2: 235cf581a853777fdb6886806ddbfcd9f782eb98.diff --]
[-- Type: text/x-patch, Size: 369 bytes --]
235cf581a853777fdb6886806ddbfcd9f782eb98
diff --git a/imap-send.c b/imap-send.c
index f3cb79b..d04259a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1202,6 +1202,7 @@ read_message( FILE *f, msg_data_t *msg )
p = xrealloc(msg->data, len+1);
if (!p)
break;
+ msg->data = p;
}
r = fread( &msg->data[msg->len], 1, len - msg->len, f );
if (r <= 0)
^ permalink raw reply related
* [PATCH] Avoid a divide by zero if there's no messages to send.
From: Mike McCormack @ 2006-04-05 14:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 86 bytes --]
---
imap-send.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
[-- Attachment #2: 8f910a131c905720e9640ddecfd8f85927ddc660.diff --]
[-- Type: text/x-patch, Size: 643 bytes --]
8f910a131c905720e9640ddecfd8f85927ddc660
diff --git a/imap-send.c b/imap-send.c
index d04259a..52e2400 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1333,6 +1333,12 @@ main(int argc, char **argv)
return 1;
}
+ total = count_messages( &all_msgs );
+ if (!total) {
+ fprintf(stderr,"no messages to send\n");
+ return 1;
+ }
+
/* write it to the imap server */
ctx = imap_open_store( &server );
if (!ctx) {
@@ -1340,7 +1346,6 @@ main(int argc, char **argv)
return 1;
}
- total = count_messages( &all_msgs );
fprintf( stderr, "sending %d message%s\n", total, (total!=1)?"s":"" );
ctx->name = imap_folder;
while (1) {
^ permalink raw reply related
* [PATCH] Fix compile with expat, but an old curl version
From: Johannes Schindelin @ 2006-04-05 14:22 UTC (permalink / raw)
To: git, junkio
With an old curl version, git-http-push is not compiled. But git-http-fetch
still needs to be linked with expat if NO_EXPAT is not defined.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
57918780ecdff0c767a22b7589ff1025de6cb40f
diff --git a/Makefile b/Makefile
index 3596445..557d322 100644
--- a/Makefile
+++ b/Makefile
@@ -333,9 +333,11 @@ ifndef NO_CURL
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
- EXPAT_LIBEXPAT = -lexpat
PROGRAMS += git-http-push$X
endif
+ endif
+ ifndef NO_EXPAT
+ EXPAT_LIBEXPAT = -lexpat
endif
endif
--
1.3.0.rc2.g4a16-dirty
^ permalink raw reply related
* Re: Cygwin can't handle huge packfiles?
From: Johannes Schindelin @ 2006-04-05 14:14 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604050624h13ebd8deg241ae98cef1f5a74@mail.gmail.com>
Hi,
On Wed, 5 Apr 2006, Kees-Jan Dijkzeul wrote:
> On 4/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
> [...]
> > That's not hugely fundamental, but I didn't expect people to hit it this
> > quickly. What kind of project has a 1.5GB pack-file _already_? I hope it's
> > fifteen years of history (so that we'll have another fifteen years before
> > we'll have to worry about 4GB pack-files ;)
>
> I'm trying to get Git to manage my companies source tree. We're
> writing software for digital TV sets. Anyway, the archive is about 5Gb
> in size and contains binaries, zip files, excel sheets meeting minutes
> and whatnot. So it doesn't compress very well. The 1.5Gb pack file
> hardly contains any history at all (five commits or so). On the flip
> side, for now I'll be the only one adding to the archive, so at least
> it will not grow that fast ;-)
>
> Anyway, to reconstitute the tree, I need very nearly the entire pack,
> so limiting the pack size won't do much good, as git will still try to
> allocate a total of 1.5Gb memory (which, unfortunately, isn't there
> :-)
>
> Inspired by a patch of Alex Riesen (thanks, Alex), I tried to use the
> regular mmap for mapping pack files, only to discover that I compile
> without defining "NO_MMAP", so I've been using the stock mmap all
> along. So now I'm thinking that the cygwin mmap also does a
> malloc-and-read, just like git does with NO_MMAP. So I'll continue to
> investigate in that direction.
I think cygwin's mmap() is based on the Win32 API equivalent, which could
mean that it *is* memory mapped, but in a special area (which is smaller
than 1.5 gigabyte). In this case, it would make sense to limit the pack
size, thereby having several packs, and mmap() them as they are needed.
Hth,
Dscho
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: moreau francis @ 2006-04-05 13:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604050906590.2550@localhost.localdomain>
--- Nicolas Pitre <nico@cam.org> a écrit :
> On Wed, 5 Apr 2006, moreau francis wrote:
> >
> > well maybe it's just stupid, but why not simply transforming binary files
> into
> > ascii files (maybe by using uuencode) before using git-diff-* brothers and
> > git-apply ?
>
> Imagine if the only difference between two versions of the same file is
> a single byte inserted at the very beginning. The uuencode would then
> be totally different between the two files.
>
ok uuencode was just a bad example for encoding...
Francis
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 13:25 UTC (permalink / raw)
To: moreau francis; +Cc: Junio C Hamano, git
In-Reply-To: <20060405122113.60376.qmail@web25801.mail.ukl.yahoo.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 723 bytes --]
On Wed, 5 Apr 2006, moreau francis wrote:
>
> --- Junio C Hamano <junkio@cox.net> a écrit :
>
> > It _might_ make sense to adopt a well-defined binary patch
> > format (or if there is no prior art, introduce our own) and
> > support that format with both git-diff-* brothers and git-apply,
> > but that would be a bit longer term project.
> >
>
> well maybe it's just stupid, but why not simply transforming binary files into
> ascii files (maybe by using uuencode) before using git-diff-* brothers and
> git-apply ?
Imagine if the only difference between two versions of the same file is
a single byte inserted at the very beginning. The uuencode would then
be totally different between the two files.
Nicolas
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Kees-Jan Dijkzeul @ 2006-04-05 13:24 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604030734440.3781@g5.osdl.org>
On 4/3/06, Linus Torvalds <torvalds@osdl.org> wrote:
[...]
> That's not hugely fundamental, but I didn't expect people to hit it this
> quickly. What kind of project has a 1.5GB pack-file _already_? I hope it's
> fifteen years of history (so that we'll have another fifteen years before
> we'll have to worry about 4GB pack-files ;)
I'm trying to get Git to manage my companies source tree. We're
writing software for digital TV sets. Anyway, the archive is about 5Gb
in size and contains binaries, zip files, excel sheets meeting minutes
and whatnot. So it doesn't compress very well. The 1.5Gb pack file
hardly contains any history at all (five commits or so). On the flip
side, for now I'll be the only one adding to the archive, so at least
it will not grow that fast ;-)
Anyway, to reconstitute the tree, I need very nearly the entire pack,
so limiting the pack size won't do much good, as git will still try to
allocate a total of 1.5Gb memory (which, unfortunately, isn't there
:-)
Inspired by a patch of Alex Riesen (thanks, Alex), I tried to use the
regular mmap for mapping pack files, only to discover that I compile
without defining "NO_MMAP", so I've been using the stock mmap all
along. So now I'm thinking that the cygwin mmap also does a
malloc-and-read, just like git does with NO_MMAP. So I'll continue to
investigate in that direction.
To be continued...
Groetjes,
Kees-Jan
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: moreau francis @ 2006-04-05 13:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgs4exz.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> a écrit :
> If I were doing that today, I would be doing almost exactly the
> above sequence, or:
>
> $ git am patch
> $ git add <new images>
> $ git commit -a --amend
>
BTW, what does "--amend" option do ? It doesn't seem to be documented anywhere.
Francis
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: moreau francis, git
In-Reply-To: <7v3bgs4exz.fsf@assigned-by-dhcp.cox.net>
On Wed, 5 Apr 2006, Junio C Hamano wrote:
> It _might_ make sense to adopt a well-defined binary patch
> format (or if there is no prior art, introduce our own) and
> support that format with both git-diff-* brothers and git-apply,
> but that would be a bit longer term project.
What about simply using diff-delta and encoding its output with base64?
Nicolas
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Radoslaw Szkodzinski @ 2006-04-05 12:23 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Daniel Drake, Junio C Hamano, git
In-Reply-To: <20060404180130.GF14967@reactrix.com>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
Nick Hengeveld wrote:
> On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:
>
>> Ah, should have known. I am behind a (lame) transparent proxy on port 80.
>>
>> I opened that file in my web browser and it showed the old heads. After
>> a force-refresh (ctrl+F5, which sends some additionally http headers to
>> refresh the page from the real server), the old heads disappeared, and
>> git now clones successfully.
>>
>> git-http-fetch should probably send those extra headers too. I'll try to
>> find some time to look at this next week.
>
> git-http-fetch uses the "Pragma: no-cache" header when requesting
> objects that shouldn't be cached. Is this the additional header you're
> referring to?
>
As per HTTP 1.1, it should also send:
Cache-Control: no-cache
Pragma: no-cache is the deprecated extension.
It's safe to send both.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: moreau francis @ 2006-04-05 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgs4exz.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> a écrit :
> It _might_ make sense to adopt a well-defined binary patch
> format (or if there is no prior art, introduce our own) and
> support that format with both git-diff-* brothers and git-apply,
> but that would be a bit longer term project.
>
well maybe it's just stupid, but why not simply transforming binary files into
ascii files (maybe by using uuencode) before using git-diff-* brothers and
git-apply ?
Francis
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
^ permalink raw reply
* [PATCH] diff_flush(): leakfix.
From: Junio C Hamano @ 2006-04-05 9:45 UTC (permalink / raw)
To: git
We were leaking filepairs when output-format was set to
NO_OUTPUT.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is somewhat embarrassing that the original breakage was
in a commit on Aug 21, 2005 and the bug stayed there forever
in git timescale.
diff.c | 44 +++++++++++++++++++++++++-------------------
1 files changed, 25 insertions(+), 19 deletions(-)
a12d2890e4d1ada6f9302dea10d151b819e0c0d0
diff --git a/diff.c b/diff.c
index e496905..fe4664c 100644
--- a/diff.c
+++ b/diff.c
@@ -1280,28 +1280,34 @@ void diff_flush(struct diff_options *opt
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
- if ((diff_output_format == DIFF_FORMAT_NO_OUTPUT) ||
- (p->status == DIFF_STATUS_UNKNOWN))
- continue;
- if (p->status == 0)
- die("internal error in diff-resolve-rename-copy");
- switch (diff_output_format) {
- case DIFF_FORMAT_PATCH:
- diff_flush_patch(p, options);
- break;
- case DIFF_FORMAT_RAW:
- case DIFF_FORMAT_NAME_STATUS:
- diff_flush_raw(p, line_termination,
- inter_name_termination,
- options);
+
+ switch (p->status) {
+ case DIFF_STATUS_UNKNOWN:
break;
- case DIFF_FORMAT_NAME:
- diff_flush_name(p,
- inter_name_termination,
- line_termination);
+ case 0:
+ die("internal error in diff-resolve-rename-copy");
break;
+ default:
+ switch (diff_output_format) {
+ case DIFF_FORMAT_PATCH:
+ diff_flush_patch(p, options);
+ break;
+ case DIFF_FORMAT_RAW:
+ case DIFF_FORMAT_NAME_STATUS:
+ diff_flush_raw(p, line_termination,
+ inter_name_termination,
+ options);
+ break;
+ case DIFF_FORMAT_NAME:
+ diff_flush_name(p,
+ inter_name_termination,
+ line_termination);
+ break;
+ case DIFF_FORMAT_NO_OUTPUT:
+ break;
+ }
}
- diff_free_filepair(q->queue[i]);
+ diff_free_filepair(p);
}
free(q->queue);
q->queue = NULL;
--
1.3.0.rc2.g110c
^ permalink raw reply related
* Re: How should I handle binary file with GIT
From: Junio C Hamano @ 2006-04-05 8:14 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060405073022.13054.qmail@web25806.mail.ukl.yahoo.com>
moreau francis <francis_moreau2000@yahoo.fr> writes:
> For now they only send me the text updates through patch and attach new images
> with the patch email. Then I do:
>
> $ git am < text_only_patch
> $ git reset --soft HEAD^
> $ git add <new images>
> $ git commit -a -C ORIG_HEAD
>
> Now my question: is it the best way to achieve this process ?
If I were doing that today, I would be doing almost exactly the
above sequence, or:
$ git am patch
$ git add <new images>
$ git commit -a --amend
It _might_ make sense to adopt a well-defined binary patch
format (or if there is no prior art, introduce our own) and
support that format with both git-diff-* brothers and git-apply,
but that would be a bit longer term project.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-05 7:59 UTC (permalink / raw)
To: git
In-Reply-To: <4433723E.1080705@vilain.net>
Sam Vilain wrote:
> Jakub Narebski wrote:
>>Third, would using *directory* with for a N-HEAD (containing all the
>>subheads, subprojects, chains, branches, fibers, whatever) instead of an
>>ordinary file for HEAD be a good idea? For hydra if we want it to be
>>easily interweaved with ordinary commit I think we would also need the
>>link for bottom, hydra shoulder, hydra tail i.e. common commit being
>>starting point for all the chains, or subprojects (for subprojects it can
>>be empty tree commit).
>
> This was similar to the original suggestion, of heads that have multiple
> heads, or hydra. I think the basic rejection for this is that nothing is
> then tracking the progression of the merged tree - unless you keep a
> "cherry picked" tree for the combined work. And of course it is a
> backwards incompatible change.
I thought about keeping N-HEAD and HEAD and updating them simultaneously.
With extra fields in commit (however they would be named) use them, without
extra fields use ordinary branches, creating histories like in your example
in first post in the thread.
I.e. when doing [hydra] commit, add commit to ordinary history (recording
the time sequence of changes inside branch) advancing HEAD, and add commit
to appropriate chain/subhead/fiber in the N-HEAD and "advance N-HEAD". This
would make change backwards compatibile.
The problem would be to keep N-HEAD and HEAD to get out of sync, e.g. when
somebody updates only HEAD with an older git... well, we can always advance
N-HEAD to HEAD using commits from the time they were in sync to the current
head state.
--
Jakub Narebski
ShadeHawk on #git
Warsaw, Poland
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-05 7:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e0vqjk$5dr$1@sea.gmane.org>
Jakub Narebski wrote:
>First, hydras or n-head was invented to avoid capping and recapping, and
>just advance it as a normal head (and to remember what are
>subprojects/patch dependency chains/whatever to choose).
>
>Second, we could generalize those extra commit references in commit
>structure (be they "bind", "prior" or "previous", or "depends-on") and have
>
>
Note that these are all quite different types of references. "Bind"
implies an unmerged tree to be woven in on checkout, "prior and
"previous" a historical relationship, and "depends-on" the previous
commit that the change that this commit supplies was based on.
So, I think "parent" already means "depends-on" closely enough.
>commit/merge pluggable helper manage them. And merge strategy may make use
>of them.
>
>Third, would using *directory* with for a N-HEAD (containing all the
>subheads, subprojects, chains, branches, fibers, whatever) instead of an
>ordinary file for HEAD be a good idea? For hydra if we want it to be easily
>interweaved with ordinary commit I think we would also need the link for
>bottom, hydra shoulder, hydra tail i.e. common commit being starting point
>for all the chains, or subprojects (for subprojects it can be empty tree
>commit).
>
>
This was similar to the original suggestion, of heads that have multiple
heads, or hydra. I think the basic rejection for this is that nothing is
then tracking the progression of the merged tree - unless you keep a
"cherry picked" tree for the combined work. And of course it is a
backwards incompatible change.
Sam.
^ permalink raw reply
* How should I handle binary file with GIT
From: moreau francis @ 2006-04-05 7:30 UTC (permalink / raw)
To: git
Hi,
I'd like to use git to keep track of a documentation repository. This repo is
mainly composed by text file and the documenation is generated by asciidoc.
People who are using my repo and updating some docs which may include new
images can't send their whole work through patches.
For now they only send me the text updates through patch and attach new images
with the patch email. Then I do:
$ git am < text_only_patch
$ git reset --soft HEAD^
$ git add <new images>
$ git commit -a -C ORIG_HEAD
Now my question: is it the best way to achieve this process ?
thanks for you answers
Francis
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-05 7:11 UTC (permalink / raw)
To: git
In-Reply-To: <443364F5.2040504@vilain.net>
First, hydras or n-head was invented to avoid capping and recapping, and
just advance it as a normal head (and to remember what are
subprojects/patch dependency chains/whatever to choose).
Second, we could generalize those extra commit references in commit
structure (be they "bind", "prior" or "previous", or "depends-on") and have
commit/merge pluggable helper manage them. And merge strategy may make use
of them.
Third, would using *directory* with for a N-HEAD (containing all the
subheads, subprojects, chains, branches, fibers, whatever) instead of an
ordinary file for HEAD be a good idea? For hydra if we want it to be easily
interweaved with ordinary commit I think we would also need the link for
bottom, hydra shoulder, hydra tail i.e. common commit being starting point
for all the chains, or subprojects (for subprojects it can be empty tree
commit).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Andrew Morton @ 2006-04-05 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virpo4jxf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > But there was a second problem. Once the parsing had misbehaved, Len
> > managed to create a commit which was six months in the future:
> >
> > commit 8313524a0d466f451a62709aaedf988d8257b21c
> > Author: Bob Moore <robert.moore@intel.com>
> > Date: Tue Oct 3 00:00:00 2006 -0400
> >
> > ACPI: ACPICA 20060310
> >
> > Will your fix prevent that from happening? If not, perhaps some basic
> > sanity checking might be appropriate.
>
> You _might_ get an e-mail to fix kernel problems from yourself
> in the future, in which case you would want to commit with
> future author date, like this ;-).
>
> People would often deal with dates in the past (way in the past
> when talking about importing foreign SCM history), but probably
> it would never make sense to do dates way into the future. I'll
> think about it.
>
Well it doesn't have to be fatal, of course. Some "do you really want to
do this [y/n]?" prompt, with a command option to override it. Or simply
print a big warning.
Whatever.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-05 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd596ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>A "bind commit" proposal was made to support subprojects living
>in their own subdirectories. The picture to describe the commit
>ancestry chain would be almost the same as the above picture,
>except that it did not uncap and recap, but would have built its
>own ancestry chain.
>
>
I had considered that this would make directory subprojects possible,
but didn't want to draw attention to it.
Actually I'm now of the thinking that the problem is that we are using
'parent' for two things;
1. the merge bases for this merge, if a merge
(or the base for this change for a patch)
2. the historical precedent(s) for this commit.
In the single line of history case these are always the same. For an
actual merge they are also the same. However, when you are superceding a
merge with a newer merge, or mucking with history they are different.
So, I think all we need to make this all work smashingly well is to have
a new field called "prior" or perhaps "previous".
As well as being mostly backwards compatible and supporting grouping
your commits into topics in a single checkout, this would also have the
side effect of:
- directly supporting stgit / pg style patchset evolution, without
needing to use seperate branches for each release of your patchset. This
would not replace the need for stgit etc to wind the head - while
revising a patchset you really don't want the system to record
intermediate changes, just the ones you want to publish
- supporting tree subprojects (as it is a more specific use case)
- rewriting history! Without losing the old commits. Unless you wanted
to - say, for archiving old commits by rebasing the whole project off a
new revision.
It also does not suffer from the 'problem' in Andreas' "dual head
commit" approach that one commit will thenceforth be known by two commit
IDs.
>It had two different kinds of commit relationships: parenthood
>and directory structure binding. The component subprojects
>lived in their own subdirectories (so if you are maintaining an
>embedded Linux along with matching toolchain, you would have linux/
>subdirectory that has the kernel hierarchy, gcc/, libc/, ...),
>and commit objects had "bind commit-sha1 subdirectory-name"
>lines to express how the components are bundled together. A
>commit object would have looked like this:
>
> tree fc9957b0052df6a8248420395bc9febd66194252
> parent 052df6a8248420395bc9febd66194252fc9957b0
> bind f6a8248420395bc9febd66194252fc9957b0052d linux/
> bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
> author A U Thor <author@example.com> 1144111304 -0700
>
>The "parent" line is the commit ancestry as usual, and each
>"bind" line names a commit object of component project and where
>in the directory hierarchy the tree for that commit object would
>be checked out. The "tree" line records the result of grafting
>the subprojects together. So, for example, ls-tree -d fc9957
>linux in the above example would have shown the tree object
>f6a824^{tree}.
>
>
While the approach I outlined supports this in a way, it is subtly
different.
Firstly, the above approach makes it a hard requirement that the
independent series of commits are in seperate paths, you mention a fix
for this -
>The structure forbid you from binding two separate projects at
>the same directory in order to enforce clean separation of
>subprojects, but if you allow multiple commits to be bound at
>the root level, that could be used as a hydra cap.
>
>
- but this means you are not storing the 'merged' tree in the commit,
which I think is a mistake. While we've been talking mostly about
dealing with managing changes simple enough to merge plainly for
simplicity of operations, this would *force* it to be so because you
need to allow anyone to check it out.
On the other hand - these bind commits enables tracking a sub-project in
a sub-directory whilst retaining the same commit IDs, to make tracking
easier.
Even this works using "prior", too - though you'd have to use surrogate
commits that link to the sub-project commit and wrapper tree object.
How does that sound?
Sam.
^ permalink raw reply
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Junio C Hamano @ 2006-04-05 6:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060404231606.219a4cc5.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> But there was a second problem. Once the parsing had misbehaved, Len
> managed to create a commit which was six months in the future:
>
> commit 8313524a0d466f451a62709aaedf988d8257b21c
> Author: Bob Moore <robert.moore@intel.com>
> Date: Tue Oct 3 00:00:00 2006 -0400
>
> ACPI: ACPICA 20060310
>
> Will your fix prevent that from happening? If not, perhaps some basic
> sanity checking might be appropriate.
You _might_ get an e-mail to fix kernel problems from yourself
in the future, in which case you would want to commit with
future author date, like this ;-).
People would often deal with dates in the past (way in the past
when talking about importing foreign SCM history), but probably
it would never make sense to do dates way into the future. I'll
think about it.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Jakub Narebski @ 2006-04-05 6:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060405060048.6694.65940.stgit@dv.roinet.com>
Pavel Roskin wrote:
> +SYNOPSIS
> +--------
> +[verse]
> +'git-clean' [-d | -D] [-n] [-q] [-x]
Shouldn't it be
> +'git-clean' [-d] [-n] [-q] [-x | -X]
like in below?
> +USAGE="[-d] [-n] [-q] [-x | -X]"
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Andrew Morton @ 2006-04-05 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, len.brown
In-Reply-To: <7vodzg4l5n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> The comment associated with the date parsing code for three
> numbers separated with slashes or dashes implied we wanted to
> interpret using this order:
>
> yyyy-mm-dd
> yyyy-dd-mm
> mm-dd-yy
> dd-mm-yy
>
> However, the actual code had the last two wrong, and making it
> prefer dd-mm-yy format over mm-dd-yy.
But there was a second problem. Once the parsing had misbehaved, Len
managed to create a commit which was six months in the future:
commit 8313524a0d466f451a62709aaedf988d8257b21c
Author: Bob Moore <robert.moore@intel.com>
Date: Tue Oct 3 00:00:00 2006 -0400
ACPI: ACPICA 20060310
Will your fix prevent that from happening? If not, perhaps some basic
sanity checking might be appropriate.
^ 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