> No, '&' have a higher priority (weight?) than '&&'.
& has a higher precedence than &&
C Operator Precedence and Associativity
http://www.difranco.net/cop2220/op-prec.htm
and many others -- google for 'c operator precedence'
Where the bitops &, | and ^ bite you is that they are
lower prece
This adds merge-trees to the list of scripts to be installed in
the Makefile, and also adds merge-trees script itself.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
21e5e9f7d7dfa81c6519f0204d5a467236c7fdd5/merge-trees | 302 ++
Makefile
Recursive behaviour (-r) and NUL-terminated output (-z) are added to
ls-tree with this patch. They are necessary for merge-trees script to
deal with filenames with embedded newlines.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
ls-tree.c | 108 +
This adds NUL-terminated output (-z) to show-files. This is necessary
for merge-trees script to deal with filenames with embedded newlines.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
show-files.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
Index: show-files
This adds "--cacheinfo" option to update-cache. It is needed to
manipulate dircache without actually having such a blob in the working
directory. To pretend you have a file with mode-sha1 at path, say:
$ update-cache --cacheinfo mode sha1 path
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
I finally sync'ed up with Pasky 0.4. Reviewing the diffs
between Linus tree and Pasky tree for the core part you seem to
have picked up some good changes (especially the byteorder one),
so I decided to rebase my changes. So here it comes...
What follows are the 3 patches to the core part to supp
On Fri, 2005-04-15 at 00:35 +0200, Alex Riesen wrote:
> On 4/14/05, Martin Schlemmer <[EMAIL PROTECTED]> wrote:
> > + if (update_mode && changed & MODE_CHANGED)
> > + chmod(ce->name, ce->st_mode);
>
> it's "if ((update_mode && changed) & MODE_CHANGED)"
> Did you
Scott wrote:
> Anyway, maybe it's worth thinking a little about an SCM in which this is a
> feature, instead of (or in addition to) automatically assuming this is a
> bug we need to add infrastructure to work around.
Agreed.
To me, the main purpose in tracking renames is to obtain a deeper
hist
> I'd think the 8:00am-before-the-first-coffee checkins would be the
> most worrying :-)
For me, it was the Friday evening after beer bust checkin.
But my employer can't afford those anymore, so I'm safe.
--
I won't rest till it's the best ...
Programmer, Lin
Earlier, hpa wrote:
> The base64 version has 2^12 subdirectories instead of 2^8 (I just used 2
> characters as the hash key just like the hex version.)
Later, hpa wrote:
> Ultimately the question is: do we care about old (broken) filesystems?
I'd imagine we care a little - just not alot.
I'd th
>>In particular, if you ever find yourself wanting to graft together two
>>different commit histories, that almost certainly is what you'd want
to >>do. Somebody might have arrived at the exact same tree some other
way, >>starting with a 2.6.12 tar.ball or something, and I think we
should at >>leas
This adds '-r' (recursive) option and '-z' (NUL terminated)
option to ls-tree. I need it so that the merge-trees (formerly
known as git-merge.perl) script does not need to create any
temporary dircache while merging. It used to use show-files on
a temporary dircache to get the list of files in th
On Thu, Apr 14, 2005 at 05:58:25PM -0700, Junio C Hamano wrote:
>
> I do like, however, the idea of separating the step of doing any
> checkout/merge etc. and actually doing them. So the command set
> of parse-your-output needs to be defined. Based on what I have
> done so far, it would consist
Hi David
On Thu, 14 Apr 2005, David S. Miller wrote:
> On Fri, 15 Apr 2005 10:01:47 +1000
> Darren Williams <[EMAIL PROTECTED]> wrote:
>
> > Thanks to the team at [EMAIL PROTECTED] we now have a
> > no so complete Git archive at
> > http://www.gelato.unsw.edu.au/archives/git/
> >
> > If somebod
JH->Junio Hamano, LT->Linus Torvalds
JH>>I just have this fuzzy feeling that, when doing this merge:
A-1 --- A-2 --- A-3
/ \
Common Ancestor Merge Result
\ /
Linus Torvalds wrote:
On Thu, 14 Apr 2005, bert hubert wrote:
It is too easy to get into a O(N^2) situation. Git may be able to deal with
it but you may hurt yourself when making backups, or if you ever want to
share your tree (possibly with yourself) over the network.
Even something as simple as
Linus Torvalds wrote:
Even something as simple as "ls -l" has been known to have O(n**2)
behaviour for big directories.
For filesystems with linear directories, sure. For sane filesystems, it
should have O(n log n).
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git"
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>> I think the above would result in what SCM person would call
>> "merge upstream/sidestream changes into my working directory".
PB> And that's exactly what I'm doing now with git merge. ;-) In fact,
PB> ideally the whole change in my scripts
On Thu, 14 Apr 2005, bert hubert wrote:
>
> It is too easy to get into a O(N^2) situation. Git may be able to deal with
> it but you may hurt yourself when making backups, or if you ever want to
> share your tree (possibly with yourself) over the network.
Even something as simple as "ls -l" has
On Thu, 14 Apr 2005, Junio C Hamano wrote:
>
> You say "merge these two trees" above (I take it that you mean
> "merge these two trees, taking account of this tree as their
> common ancestor", so actually you are dealing with three trees),
Yes. We're definitely talking three trees.
> and I am t
On Fri, 15 Apr 2005 10:01:47 +1000
Darren Williams <[EMAIL PROTECTED]> wrote:
> Thanks to the team at [EMAIL PROTECTED] we now have a
> no so complete Git archive at
> http://www.gelato.unsw.edu.au/archives/git/
>
> If somebody could send me a complete Git mbox I will
> update the archive with it
Hi Martin
On Fri, 15 Apr 2005, Martin Schlemmer wrote:
> On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> > Currently the commit-id script is not install with
> > make install, this patches includes it in the SCRIPT
> > target. This patch is against git-pasky-0.4
> >
>
> Hmm, this is
Hi All
Thanks to the team at [EMAIL PROTECTED] we now have a
no so complete Git archive at
http://www.gelato.unsw.edu.au/archives/git/
If somebody could send me a complete Git mbox I will
update the archive with it.
- dsw
--
Darren Williams
[EM
BTW, I am not competing with Junio script. If that is the way
we all agree on. It is should be very easy for Junio to fix his
perl script. right?
Chris
On Thu, Apr 14, 2005 at 04:37:17PM -0400, Christopher Li wrote:
> Is that some thing you want to see? Maybe clean up the error printing.
>
>
>
>I'm trying to understand how it works and I'll appreciate if someone could
>help.
>1. git uses object abstraction for the different types and so
>everything is in one directory (objects). From what I've seen in the
>implementation, the different kind of objects are not of the same type
>(there a
Dear diary, on Fri, Apr 15, 2005 at 01:39:06AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> On Fri, 2005-04-15 at 01:15 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
> > where Martin Schlemmer <[EMAIL PROTECTED
Is that some thing you want to see? Maybe clean up the error printing.
Chris
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ merge.py2005-04-14 16:34:39.0 -0400
@@ -0,0 +1,76 @@
+#!/usr/bin/env python
+
+import re
+import sys
+import os
+from pprint import pprint
+
+def get_t
On Fri, Apr 15, 2005 at 01:31:59AM +0200, Petr Baudis wrote:
> > I am just trying to follow my understanding of what Linus
> > wanted. One of the guiding principle is to do as much things as
> > in dircache without ever checking things out or touching working
> > files unnecessarily.
>
> I'm just
On Fri, 2005-04-15 at 01:15 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Rather use checkout-cache to sync our tree, as should do the right thing
> > instead of diffing (cancel imply
Hi Junio,
I think if the merge tree belong to plumbing, you can do
even less in the merge.perl. You can just print out the
instruction for the upper level SCM what to to without
actually doing it yourself.
So you don't have to do touch anything in the tree.
That is the way I use in my previous py
Dear diary, on Fri, Apr 15, 2005 at 01:12:34AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> PB> What I would like your script to do is therefore just do the
> PB> merge in a given already prepared (includi
> "BS" == Barry Silverman <[EMAIL PROTECTED]> writes:
I have not thought about remote issues at all, other than the
distribution mechanism vaguely outlined in my previous mail (not
cc'ed to git list but I would not mind if you reproduced it here
if somebody asked), so I am not qualified to com
On Fri, 2005-04-15 at 01:09 +0200, Martin Schlemmer wrote:
> On Fri, 2005-04-15 at 01:00 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
> > where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > > On Fri, 2005-04-15 at 00:42 +0200, Petr Bau
If the mechanics of git still have you stumped, then here are a couple of
examples of using the really low level tools to do some basic operations.
In real life you would have higher level wrappers around these tools so
that you don't have to remember to update .git/HEAD with the new SHA1 after
you
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
Dear diary, on Thu, Apr 14, 2005 at 12:00:25AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> This splits read-cache.c into util.c, cache.c, and objects.c, based on
> what the code is used for; similarly, cache.h becomes util.h, cache.h, and
> objects.h. For simpli
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> What I would like your script to do is therefore just do the
PB> merge in a given already prepared (including built index)
PB> directory, with a passed base. The base should be determined
PB> by a separate tool (I already saw some patches);
On Fri, 2005-04-15 at 01:07 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Rather use checkout-cache to sync our tree, as should do the right thing
> > instead of diffing (cancel imply
On Fri, 2005-04-15 at 01:00 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> > > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CES
Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> Rather use checkout-cache to sync our tree, as should do the right thing
> instead of diffing (cancel imply just blow away everything).
>
> Signed-off-by: Martin Schlemm
Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> > where Martin Schlemmer <[EMAIL PROTECTED
On Fri, 2005-04-15 at 00:57 +0200, Martin Schlemmer wrote:
> Hi,
>
> gitcancel.sh do not handle mode changes:
>
>
> $ chmod -x Makefile
> $ git cancel
> patch: Only garbage was found in the patch input.
>
>
> Rather use checkout-cache to sync our tree, as should do the right thing
Dear diary, on Fri, Apr 15, 2005 at 12:57:25AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> Hi,
>
> gitcancel.sh do not handle mode changes:
>
>
> $ chmod -x Makefile
> $ git cancel
> patch: Only garbage was found in the patch input.
>
>
> Rath
On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > (PS, can you check the fact that your mail client keeps on adding a 'Re:
> > ' ...)
>
> Hmm. I guess my ancie
On Fri, 2005-04-15 at 00:35 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 12:37:25AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> > > Currently the commit-id script is not install
Hi,
gitcancel.sh do not handle mode changes:
$ chmod -x Makefile
$ git cancel
patch: Only garbage was found in the patch input.
Rather use checkout-cache to sync our tree, as should do the right thing
instead of diffing (cancel imply just blow away everything).
Signed-off-by: Mar
Hi,
I see the latest gitdiff-do does the right thing regarding modes, but we
still need to refresh the cache.
Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittr
Dear diary, on Fri, Apr 15, 2005 at 12:37:57AM CEST, I got a letter
where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> Hi, Petr!
>
> The attached patch against current git-pasky does following:
Hum. It does too much at once, that means I cannot apply it easily. :-(
> * README: spell checke
subscribe git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> (PS, can you check the fact that your mail client keeps on adding a 'Re:
> ' ...)
Hmm. I guess my ancient reply_regexp
"^((\\[|\\()([^B]|B([^u]|u([^g]|g([^ ]|AnTiMaTcH))
subscribe git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/14/05, Martin Schlemmer <[EMAIL PROTECTED]> wrote:
> + if (update_mode && changed & MODE_CHANGED)
> + chmod(ce->name, ce->st_mode);
it's "if ((update_mode && changed) & MODE_CHANGED)"
Did you really mean that?
-alex
-
To unsubscribe from this list: send th
Dear diary, on Fri, Apr 15, 2005 at 12:37:25AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> > Currently the commit-id script is not install with
> > make install, this patches includes it in the SCRIPT
On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> Currently the commit-id script is not install with
> make install, this patches includes it in the SCRIPT
> target. This patch is against git-pasky-0.4
>
Hmm, this is still not fixed ...
> Signed-off-by Darren Williams <[EMAIL PROTECTED
subscribe git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Perhaps our thinking is being clouded by 'how other SCMs do things' ---
do we *really* need extra rename metadata? As Linus pointed out, as long
as a commit is done immediately after a rename (ie before the renamed file
is changed) the tree object contains all the information one needs: you
can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Courtesy of Randy Dunlap, MARC now has full(?) archives for the git
list, actually stretching a bit back to the pre-git-list discussions on
linux-kernel, available at:
http://marc.theaimsgroup.com/?l=git
[ Apologies if this mail crisscrosses with a si
Hi,
note that in my git tree there is a git merge implementation which
does out-of-tree merges now. It is still very trivial, and basically
just does something along the lines of (symbolically written)
checkout-cache $(diff-tree)
git diff $base $mergedbranch | git apply
On Thu, Apr 14, 2005 at 11:12:35AM -0700, Junio C Hamano wrote:
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> At this moment in the script, we have run "read-tree" the
> ancestor so the dircache has the original. %tree0 and %tree1
> both did not touch the path ($_ here) so it is the
On Thu, Apr 14, 2005 at 12:25:40PM -0700, H. Peter Anvin wrote:
> >That may be true :-), but from the "front lines" I can report that
> >directories with > 32000 or > 65000 entries is *asking* for trouble. There
> >is a whole chain of systems that need to get things right for huge
> >directories to
On Thu, 2005-04-14 at 14:01 -0700, H. Peter Anvin wrote:
> Both of these are metadata; they may not be directly relevant to the
> filesystem, but are attributes relevant to the client thereof;
> effectively an xattr.
Right. That's perfectly acceptable -- and that's the reason why I think
it's al
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
>
David Woodhouse wrote:
On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
This is a very good point ... but this still has problems with the
"git is a filesystem, not a SCM" mantra. Timezone comments don't
belong in the git inode.
Yeah, but really I'd want to see other serious users of it before
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
On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
> This is a very good point ... but this still has problems with the
> "git is a filesystem, not a SCM" mantra. Timezone comments don't
> belong in the git inode.
Yeah, but really I'd want to see other serious users of it before I'd
accept that
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.
>
Dear diary, on Thu, Apr 14, 2005 at 10:23:26PM CEST, I got a letter
where Erik van Konijnenburg <[EMAIL PROTECTED]> told me that...
> On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> > Hmm. I actually don't like this naming. I think it's not too consistent,
> > is irregular, therefore
On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> Hmm. I actually don't like this naming. I think it's not too consistent,
> is irregular, therefore parsing it would be ugly. What I propose:
>
> 12c\tname <- legend
> <- original file
> D <- tree #1 removed file
> D
Dear diary, on Thu, Apr 14, 2005 at 09:59:04PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> LT> On Thu, 14 Apr 2005, Junio C Hamano wrote:
>
> >> Sorry, I have not seen what you have been doing since p
If you are merging from many distributed developers, than you would need to
replicate every one of their repositories into your own. Is this necessary?
I have been looking at Junio's code for merging, and it looks like it would
be (relatively) easy change to make it run live across two remote
repo
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Thu, 14 Apr 2005, Junio C Hamano wrote:
>> Sorry, I have not seen what you have been doing since pasky 0.3,
>> and I have not even started to understand the mental model of
>> the world your tool is building. That said, my gut feeli
Dear diary, on Thu, Apr 14, 2005 at 09:42:28PM CEST, I got a letter
where "Luck, Tony" <[EMAIL PROTECTED]> told me that...
> >I'd prefer not to lose the information. If someone has committed a
> >change at 2am, I like to know that it was 2am for _them_. It helps me
> >decide where to look first for
>I'd prefer not to lose the information. If someone has committed a
>change at 2am, I like to know that it was 2am for _them_. It helps me
>decide where to look first for the cause of problems. :)
I'd think the 8:00am-before-the-first-coffee checkins would be the
most worrying :-)
>It also helps
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
>
Dear diary, on Thu, Apr 14, 2005 at 08:12:35PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>
> PB> Bah, you outran me. ;-)
>
> Just being in a different timezone, I guess.
>
> PB> I'll change it to use the
bert hubert wrote:
That may be true :-), but from the "front lines" I can report that
directories with > 32000 or > 65000 entries is *asking* for trouble. There
is a whole chain of systems that need to get things right for huge
directories to work well, and it often is not that way.
Specifics, plea
On Thu, 2005-04-14 at 12:19 -0700, [EMAIL PROTECTED] wrote:
> With a UTC date, why would anyone care in which timezone the commit was
> made? Any pretty printing would most likely be prettiest if it is done
> relative to the timezone of the person looking at the commit record, not
> the person who
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
> OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
> what you're going to want to feed it. We store seconds since UTC epoch,
> we add the author's or committer's timezone as auxiliary data so that
> dates can be pretty-printed in the original timezone later if anyone
> cares.
W
On Thu, Apr 14, 2005 at 10:42:56AM -0700, Linus Torvalds wrote:
> > Eh?! n_link limits the number of *subdirectories* a directory can
> > contain, not the number of *entries*.
>
> Duh. I'm a git.
That may be true :-), but from the "front lines" I can report that
directories with > 32000 or > 65
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
I'm trying to understand how it works and I'll appreciate if someone could help.
1. git uses object abstraction for the different types and so
everything is in one directory (objects). From what I've seen in the
implementation, the different kind of objects are not of the same type
(there aren't a
* 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, Junio C Hamano wrote:
>
> Sorry, I have not seen what you have been doing since pasky 0.3,
> and I have not even started to understand the mental model of
> the world your tool is building. That said, my gut feeling is
> that telling this script about git-pasky's world mode
From: Tony Luck <[EMAIL PROTECTED]>
init-db calls getenv(DB_ENVIRONMENT) twice. Once should be enough.
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
init-db.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- init-db.c
+++ init-db.c 2005-04-14 11:01:52.0 -0700
@@ -7,
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
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> Bah, you outran me. ;-)
Just being in a different timezone, I guess.
PB> I'll change it to use the cool git-pasky stuff (commit-id etc) and its
PB> style of committing - that is, it will merely record the update-caches
PB> to be done upon
* 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
On Thu, 2005-04-14 at 02:12 -0700, Linus Torvalds wrote:
> I take that back. I'd be much happier with you doing and testing it,
> because now I'm crashing.
OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
what you're going to want to feed it. We store seconds since UTC epoch,
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
>
> Eh?! n_link limits the number of *subdirectories* a directory can
> contain, not the number of *entries*.
Duh. I'm a git.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL P
1 - 100 of 148 matches
Mail list logo
