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 -
>
Catalin Marinas wrote:
Ingo Molnar <[EMAIL PROTECTED]> 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.)
AFAIK, cvsps uses t
Ingo Molnar <[EMAIL PROTECTED]> 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.)
AFAIK, cvsps uses the date/time to
On Sun, 2005-04-17 at 18:16 -0700, Linus Torvalds wrote:
> Alternatively, you can have just the rev-tree cache of them. That's what
> it was designed for (along with avoiding to have to read 60,000 commits).
Purely from a conceptual POV I'd be a little happier with the history
just ending with a p
On Mon, 18 Apr 2005, Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter
> where David Woodhouse <[EMAIL PROTECTED]> told me that...
> > On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > > Of course an entirely different thing are _trees_ associated w
Dear diary, on Mon, Apr 18, 2005 at 02:51:59AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> 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 commi
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 everyt
Dear diary, on Mon, Apr 18, 2005 at 02:45:22AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > > For the special case of removing history before 2.6.12-rc2 from the
> > > trees, I certainly think we can do it
On Mon, 2005-04-18 at 02:35 +0200, Petr Baudis wrote:
> > For the special case of removing history before 2.6.12-rc2 from the
> > trees, I certainly think we can do it by leaving out all the commits,
> > not just the trees. We can do that easily, but there's no way we can
> > _add_ that history ret
Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter
where David Woodhouse <[EMAIL PROTECTED]> told me that...
> On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > Of course an entirely different thing are _trees_ associated with those
> > commits. As long as you stay with a s
On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> I think this is bad, bad, bad. If you don't keep around all the
> _commits_, you get into all sorts of troubles - when merging, when doing
> git log, etc. And the commits themselves are probably actually pretty
> small portion of the thing. I
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
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
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 getti
On Sat, 16 Apr 2005, Mike Taht wrote:
> Junio C Hamano wrote:
> >>"MT" == Mike Taht <[EMAIL PROTECTED]> writes:
> >
> >
> > MT> alternatively, "git-archive-torrent" to create a list of files for a
> > MT> bittorrent feed
> >
> > That is certainly good for establishing the baseline, but
> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
CL> I bet 90% of the time people sync to the repository head first
CL> want to check out the last bits. And maybe reading some change
CL> log to see what is changed.
CL> So having all the commit object, the user will able to see
CL> what is
Junio C Hamano wrote:
"MT" == Mike Taht <[EMAIL PROTECTED]> writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between relat
* 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,
We can just have a baseline file contain all the commit objects.
Then have the git "download on demand". The problem with diff
package is that I it is harder to merge with more than one diff.
I bet 90% of the time people sync to the repository head first
want to check out the last bits. And maybe
On Sat, 2005-04-16 at 12:15 -0700, Linus Torvalds wrote:
>
> On Sat, 16 Apr 2005, Thomas Gleixner wrote:
> >
> > For the export stuff its terrible slow. :(
>
> What kind of _strange_ scripting architecture is so fast that there's a
> difference between "cat-file" and "ls-tree" and can handle 17,0
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> P.S.: It seems that Linus applied a patch to ls-tree which will make it
PB> read_sha1_file() on each item when ls-tree is recursive. Junio, why did
PB> you do it?
Sorry it was my misunderstanding, before I found out exactly how
S_ISDIR is
> "MT" == Mike Taht <[EMAIL PROTECTED]> writes:
MT> alternatively, "git-archive-torrent" to create a list of files for a
MT> bittorrent feed
That is certainly good for establishing the baseline, but you
still need to leverage the inherent delta-compressibility
between related blobs/trees
* 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
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
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
Dear diary, on Sat, Apr 16, 2005 at 09:50:21PM CEST, I got a letter
where Thomas Gleixner <[EMAIL PROTECTED]> told me that...
> 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 ob
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,
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
> "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 t
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 c
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 P
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.
* 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 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
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> What do people think? I'm not so much worried about the data itself: the
LT> git architecture is _so_ damn simple that now that the size estimate has
LT> been confirmed, that I don't think it would be a problem per se to put
LT> 3.2GB in
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 plac
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 course, but not necessarily putting it
> into git now. It would j
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
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
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 convert them to GIT.)
author names are abbreviated, e.
* 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' in
41 matches
Mail list logo
