David Mansfield [EMAIL PROTECTED] wrote:
Catalin Marinas wrote:
AFAIK, cvsps uses the date/time to create the changesets. There is a
problem with the BKCVS export since some files in the same commit can
have a different time (by an hour). I posted a mail some time ago
about this -
Dear diary, on Mon, Apr 18, 2005 at 01:31:36AM CEST, I got a letter
where David Woodhouse [EMAIL PROTECTED] told me that...
Note that any given copy of a tree doesn't _need_ to keep all the
history back the beginning of time. It's OK if the oldest commit object
in your tree actually refers back
On Mon, 2005-04-18 at 02:50 +0200, Petr Baudis wrote:
I think I will make git-pasky's default behaviour (when we get
http-pull, that is) to keep the complete commit history but only trees
you need/want; togglable to both sides.
I think the default behaviour should probably be to fetch
* Ingo Molnar [EMAIL PROTECTED] wrote:
the patches contain all the existing metadata, dates, log messages and
revision history. (What i think is missing is the BK tree merge
information, but i'm not sure we want/need to convert them to GIT.)
author names are abbreviated, e.g. 'viro'
Ingo Molnar [EMAIL PROTECTED] :
[...]
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
127 weeks of bk-commit mail for the 2.6 branch alone since october 2002
provides more
On Sat, 16 Apr 2005, Ingo Molnar wrote:
i've converted the Linux kernel CVS tree into 'flat patchset' format,
which gave a series of 28237 separate patches. (Each patch represents a
changeset, in the order they were applied. I've used the cvsps utility.)
the history data starts at
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
So I'd _almost_ suggest just starting from a clean slate after all.
Keeping the old history around, of course, but not necessarily putting it
into git now. It would just force everybody who is getting used to git in
the first place
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
scripting.
Converting the ASCII - binary for the
* A script git-archive-tar is used to create a base tarball
that roughly corresponds to linux-*.tar.gz. This works as
follows:
$ git-archive-tar C [B1 B2...]
This reads the named commit C, grabs the associated tree
(i.e. its sub-tree objects and the blob they refer to), and
Dear diary, on Sat, Apr 16, 2005 at 08:32:32PM CEST, I got a letter
where Petr Baudis [EMAIL PROTECTED] told me that...
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The
On Sat, 2005-04-16 at 20:32 +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
where Thomas Gleixner [EMAIL PROTECTED] told me that...
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
scripting.
Converting the ASCII - binary for the sha1sum comparision should not
take much longer than the binary - ASCII
JCH == Junio C Hamano [EMAIL PROTECTED] writes:
JCH I have been cooking this idea before I dove into the merge stuff
JCH and did not have time to implement it myself (Hint Hint), but I
JCH think something along the following lines would work nicely:
It should be fairly obvious from the context
On Sat, 2005-04-16 at 11:44 -0700, Linus Torvalds wrote:
That level of abstraction (we never look directly at the objects) is
what allows us to change the object structure later. For example, we
already changed the commit date thing once, and the tree object has
obviously evolved a bit,
On Sat, Apr 16, 2005 at 07:43:27PM +0200, Petr Baudis wrote:
Dear diary, on Sat, Apr 16, 2005 at 07:04:31PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
So I'd _almost_ suggest just starting from a clean slate after all.
Keeping the old history around, of
On Sat, 2005-04-16 10:04:31 -0700, Linus Torvalds [EMAIL PROTECTED]
wrote in message [EMAIL PROTECTED]:
What do people think? I'm not so much worried about the data itself: the
git architecture is _so_ damn simple that now that the size estimate has
been confirmed, that I don't think it would
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
For the export stuff its terrible slow. :(
I don't really see your point.
If you already know what the tree is like you say, you don't care about
the tree object. And if you don't know what the tree is, what _are_ you
doing?
In other words, show
* David Mansfield [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
the patches contain all the existing metadata, dates, log messages and
revision history. (What i think is missing is the BK tree merge
information, but i'm not sure we want/need to
* Linus Torvalds [EMAIL PROTECTED] wrote:
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
Hey, that's great. I got the CVS repo too, and I was looking at it,
but the
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
So I'd _almost_ suggest just starting from a clean slate after all.
Keeping the old history around, of course, but not necessarily putting it
into git now. It would just force everybody who is
20 matches
Mail list logo
