On Fri, 2005-04-15 at 13:37 +, [EMAIL PROTECTED] wrote:
> > One option for optimising this, if we really need to, might be to track
> > the file back to its _first_ ancestor and use that as an identification.
> > The SCM could store that identifier in the blob itself, or we could
> > consider i
> One option for optimising this, if we really need to, might be to track
> the file back to its _first_ ancestor and use that as an identification.
> The SCM could store that identifier in the blob itself, or we could
> consider it an 'inode number' and store it in git's tree objects.
This sugges
Steven Cole wrote:
On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
Zach Welch pontificated:
I imagine quite a few folks expect something not entirely unlike an SCM
to emerge from these current efforts. Moreover, Petr's 'git' scripts
wrap your "filesystem" plumbing to that very e
On Thu, 2005-04-14 at 18:23 -0400, Daniel Barkalow wrote:
> I personally think renames are a minor thing that doesn't happen
> much. What actually happens, in my opinion, is that some chunk of a
> file is moved to a different, possibly new, file. If this is supported
> (as something that the SCM no
On Thu, 14 Apr 2005, David Woodhouse wrote:
> Opinions? Dissent? We'd probably need to escape the filenames in some
> way -- handwave over that for now.
I personally think renames are a minor thing that doesn't happen
much. What actually happens, in my opinion, is that some chunk of a file
is mov
Dear diary, on Thu, Apr 14, 2005 at 10:58:52PM CEST, I got a letter
where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that...
> Petr Baudis wrote:
>
> >>Cogito. "Git inside" can be the first slogan.
> >
> >What about tig?
>
> I like "Cogito"; it's a real name, plus it'd be a good use for the
>
Petr Baudis wrote:
Cogito. "Git inside" can be the first slogan.
What about tig?
I like "Cogito"; it's a real name, plus it'd be a good use for the
otherwise-pretty-useless two-letter combination "cg".
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
Dear diary, on Thu, Apr 14, 2005 at 10:42:16PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
> > Zach Welch pontificated:
> > > I imagine quite a few folks expect something not entirely unlike an SCM
On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
> Zach Welch pontificated:
> > I imagine quite a few folks expect something not entirely unlike an SCM
> > to emerge from these current efforts. Moreover, Petr's 'git' scripts
> > wrap your "filesystem" plumbing to that very end.
>
Zach Welch pontificated:
> I imagine quite a few folks expect something not entirely unlike an SCM
> to emerge from these current efforts. Moreover, Petr's 'git' scripts
> wrap your "filesystem" plumbing to that very end.
>
> To avoid confusion, I think it would be better to distinguish the two
>
Linus Torvalds wrote:
>
> On Thu, 14 Apr 2005, H. Peter Anvin wrote:
>
>> Although Linus is correct in that an SCM doesn't *have* to handle
>> this, it really feels like shooting for mediocracy to me. We might
>> as well design it right from the beginning.
>
>
> No. git is not an SCM. it's a
Linus Torvalds wrote:
On Thu, 14 Apr 2005, Ingo Molnar wrote:
there's no redundancy caused by this method: only renames (which are
rare) go through the rename_commit redirection. (to speed up the lookup
the rename_commit object could cache the offset of the two names within
their tree objects.)
On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:
> The thing i tried to avoid was to list long filenames in the commit
> (because of the tree hierarchy we'd need to do tree-absolute pathnames
> or something like that, and escape things, and do lookups - duplicating
> a VFS which is quite ba
On Thu, 2005-04-14 at 11:11 -0700, Linus Torvalds wrote:
> So, you really need to think of git as a filesystem. You can then
> implement an SCM _on_top_of_it_, which means that your second suggestion
> is not only acceptable, it really is the _only_ way to handle this in git:
>
> > So a commit i
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [...] Ie if you notice a rename, you first commit the rename (and you
> can _see_ it's a rename, since the object didn't change, and the sha1
> stayed the same, which in git-speak means that it is the same object,
> ie that _is_ a rename as far as
Linus Torvalds wrote:
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
Although Linus is correct in that an SCM doesn't *have* to handle this,
it really feels like shooting for mediocracy to me. We might as well
design it right from the beginning.
No. git is not an SCM. it's a filesystem designed to _
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
>
> Although Linus is correct in that an SCM doesn't *have* to handle this,
> it really feels like shooting for mediocracy to me. We might as well
> design it right from the beginning.
No. git is not an SCM. it's a filesystem designed to _host_ an S
On Thu, 14 Apr 2005, Ingo Molnar wrote:
>
> there's no redundancy caused by this method: only renames (which are
> rare) go through the rename_commit redirection. (to speed up the lookup
> the rename_commit object could cache the offset of the two names within
> their tree objects.)
Bzzt. Wr
David Woodhouse wrote:
Opinions? Dissent? We'd probably need to escape the filenames in some
way -- handwave over that for now.
For readability and simplicity I'd suggest using either URL-style %XX
escapes or octal \xxx escapes for anything bytes < 33, minus the escape
character.
Although Linus
* David Woodhouse <[EMAIL PROTECTED]> wrote:
> I've been looking at tracking file revisions. One proposed solution
> was to have a separate revision history for individual files, with a
> new kind of 'filecommit' object which parallels the existing 'commit',
> referencing a blob instead of a t
On Thu, 14 Apr 2005, David Woodhouse wrote:
>
> I've been looking at tracking file revisions. One proposed solution was
> to have a separate revision history for individual files, with a new
> kind of 'filecommit' object which parallels the existing 'commit',
> referencing a blob instead of a tre
I've been looking at tracking file revisions. One proposed solution was
to have a separate revision history for individual files, with a new
kind of 'filecommit' object which parallels the existing 'commit',
referencing a blob instead of a tree. Then trees would reference such
objects instead of re
22 matches
Mail list logo
