On Fri, 15 Apr 2005, Linus Torvalds wrote:
>
> Actually, it turns out that I have a cunning plan.
Damn, my cunning plan is some good stuff.
Or maybe it is _so_ cunning that I just confuse even myself. But it looks
like it is actually working, and that it allows pretty much instantaenous
mer
Doesn't seem to make sense to use MADV_RANDOM on the cache file, but
maybe MADV_SEQUENTIAL on the rest...
--- /home/m/src/git-pasky-0.4/update-cache.c2005-04-15
12:24:26.0 -0700
+++ update-cache.c 2005-04-15 21:53:34.0 -0700
@@ -30,7 +30,7 @@
close(fd);
i
On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> I'd take the hint, but I would say the current Perl version
> would be far more usable than the C version I would come up with
> by the end of this weekend because:
Actually, it turns out that I have a cunning plan.
I'm full of cunning plans, in f
I wrote a quick and dirty patch to check out blobs into .git/blobs, and
hardlink them into the working directory; if you symlink .git/blobs
together for a number of trees, this should save a lot of space if you
have a lot of working directories. It also seems to speed up and save
space in "git fork
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> Just a heads-up - I'd really want to do the same thing to "merge-tree.c"
LT> too, but since you said that you were working on extending that to do
LT> recursion etc, I decided to hold off. So if you're working on it, maybe
LT> you can
On Fri, 15 Apr 2005, Linus Torvalds wrote:
> On Fri, 15 Apr 2005, Daniel Barkalow wrote:
> >
> > So you want to merge someone else's tree into your committed state, and
> > then merge the result with your working directory to get the working
> > directory you continue with, provided that the seco
On Sat, 16 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> where Petr Baudis <[EMAIL PROTECTED]> told me that...
> > git branch --- creates a branch from a given commit
> > (when passed empty commit, creates a branch
> >
On Sat, 16 Apr 2005, Petr Baudis wrote:
>
> I'm wondering, whether each tree should be fixed to a certain branch.
I'm wondering why you talk about "branches" at all.
No such thing should exist. There are no branches. There are just
repositories. You can track somebody elses repository, but yo
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
>
> So you want to merge someone else's tree into your committed state, and
> then merge the result with your working directory to get the working
> directory you continue with, provided that the second merge is trivial?
No, you don't even "merge" the
On Sat, 16 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> > I often want to take a base tree, which I keep tracking some remote head,
> > and make a local working tree that starts from
Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> git branch --- creates a branch from a given commit
> (when passed empty commit, creates a branch
> from the current commit a
On Fri, 15 Apr 2005, Linus Torvalds wrote:
>
> (This is also why we should write to a temp-file and then do an atomic
> "rename()").
Btw, before anybody asks: I do _not_ think that we should do fsync() etc.
We don't actually destroy any old state when we write a new object, so
even if the mac
On Fri, 15 Apr 2005, Morten Welinder wrote:
>
> This write will failing sooner or later when someone's disk fills up.
> That'll leave someone with a truncated file.
Yes. On the other hand, we could try to do this even better, ie make the
classic write loop that handles EAGAIN.
No POSIX filesy
On Fri, 15 Apr 2005, Linus Torvalds wrote:
> On Fri, 15 Apr 2005, Daniel Barkalow wrote:
> >
> > Is there some reason you don't commit before merging? All of the current
> > merge theory seems to want to merge two commits, using the information git
> > keeps about them.
>
> Note that the 3-way m
Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> I often want to take a base tree, which I keep tracking some remote head,
> and make a local working tree that starts from it. This makes "git ln -c
> " give you a tree th
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
>
> Is there some reason you don't commit before merging? All of the current
> merge theory seems to want to merge two commits, using the information git
> keeps about them.
Note that the 3-way merge would _only_ merge the committed state. The
thing
I often want to take a base tree, which I keep tracking some remote head,
and make a local working tree that starts from it. This makes "git ln -c
" give you a tree that you can just start working in and then diff
against the head you'd started from and send off.
Signed-Off-By: Daniel Barkalow <[E
On Fri, Apr 15, 2005 at 08:32:46AM -0700, Linus Torvalds wrote:
> In other words, I'm right. I'm always right, but sometimes I'm more right
> than other times. And dammit, when I say "files don't matter", I'm really
> really Right(tm).
>
You're right, of course (All Hail Linus!), if you can make
Linus,
this adds '-z' to merge-tree and changes its default line
termination to LF to make it consistent with your other recent
changes.
The patch is against
commit 028c5948257e763b3deb391e567b624eb7975ec2
tree 6b866e10b16183e630db8449c64899f6810d4270
Signed-off-by: Junio C Hamano
On Fri, 15 Apr 2005, Linus Torvalds wrote:
> I think I've explained my name tracking worries. When it comes to "how to
> merge", there's three issues:
>
> - we do commonly have merge clashes where both trees have applied the
>exact same patch. That should merge perfectly well using the 3-
On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> the merge-trees I sent you earlier was expecting the old
> diff-tree behaviour, and I did not realize that I need an
> explicit -z flag now.
You didn't need one - I just didn't want to merge your "ls-tree" change
without making things be consis
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
This write will failing sooner or later when someone's disk fills up.
That'll leave someone with
a truncated file.
Signed-off-by: Morten Welinder <[EMAIL PROTECTED]>
--- read-cache.c
+++ read-cache.c2005-04-15 20:32:52.87168 -0400
@@ -276,9 +276,13 @@
On Fri, 15 Apr 2005, Barry Silverman wrote:
>
> The issue I am trying to come to grips with in the current design, is
> that the git repository of a number of interrelated projects will soon
> become the logical OR of all blobs, commits, and trees in ALL the
> projects.
Nope. I'm actually again
On Sat, 16 Apr 2005, Petr Baudis wrote:
>
> But otherwise it is great news to me. Actually, in that case, is it
> worth renaming it to Cogito and using cg to invoke it? Wouldn't be that
> actually more confusing after it gets merged? IOW, should I stick to
> "git" or feel free to rename it to "c
Dear diary, on Sat, Apr 16, 2005 at 02:00:21AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> On Sat, 2005-04-16 at 01:48 +0200, Petr Baudis wrote:
> > Dear diary, on Thu, Apr 14, 2005 at 10:53:50AM CEST, I got a letter
> > where Martin Schlemmer <[EMAIL PROTECTED
On Sat, 2005-04-16 at 01:48 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 14, 2005 at 10:53:50AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
> >
> > Might not be that an big an issue as it should be freed on exit, but
> > might cause problems wit
On Wed, 13 Apr 2005 21:19:48 -0700, H. Peter Anvin wrote:
> Checking out the total kernel tree (time checkout-cache -a into an empty
> directory):
>
> Cache cold Cache hot
> stock 3:46.95 19.95
> base64 5:56.20 23.74
> flat2:44.13 15.68
>
> It seems t
On 4/15/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?
>
> No, '&' have a higher p
Dear diary, on Thu, Apr 14, 2005 at 10:53:50AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> Hi,
>
> Might not be that an big an issue as it should be freed on exit, but
> might cause problems with big trees.
>
>
>
> Plug memory leak in update-cache.c.
>
Linus,
the merge-trees I sent you earlier was expecting the old
diff-tree behaviour, and I did not realize that I need an
explicit -z flag now. Here is a fix.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
merge-trees |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
> "CSA" == C Scott Ananian <[EMAIL PROTECTED]> writes:
CSA> On Fri, 15 Apr 2005, Junio C Hamano wrote:
>> to yours is no problem for me. Currently I see your HEAD is at
>> 461aef08823a18a6c69d472499ef5257f8c7f6c8, so I will generate a
>> set of patches against it.
CSA> Have you considered us
The issue I am trying to come to grips with in the current design, is
that the git repository of a number of interrelated projects will soon
become the logical OR of all blobs, commits, and trees in ALL the
projects.
This will involve horrendous amounts of replication, as developers end
interchan
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> I can't see the conflicts between what I want and what Linus wants.
PB> After all, Linus says that I can use the directory cache in any way I
PB> please (well, the user can, but I'm speaking for him ;-). So I'm doing
PB> so, and with your t
Dear diary, on Fri, Apr 15, 2005 at 10:13:21PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> On Fri, 15 Apr 2005, Petr Baudis wrote:
> >
> > So, I assume that you don't want to merge my "SCM layer" (which is
> > perfectly fine by me). However, I also apply p
Linus,
This is the '-q' option for show-diff.c to squelch complaints for
missing files. It is handy if you want to run it in the merge
temporary directory after running merge-trees with its minimum
checkout mode, which is the default, because you would not find any
files other than the ones that
Linus,
what you have in 461aef08823a18a6c69d472499ef5257f8c7f6c8 is fine
by me for the essential support for merge-trees (sorry for the
confusing name, but this is a stop-gap Q&D script until I do the real
merge-tree.c conversion).
This patch contains the merge-trees script itself and Makefil
Dear diary, on Fri, Apr 15, 2005 at 10:58:10PM CEST, I got a letter
where "C. Scott Ananian" <[EMAIL PROTECTED]> told me that...
> On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> >to yours is no problem for me. Currently I see your HEAD is at
> >461aef08823a18a6c69d472499ef5257f8c7f6c8, so I will
On Fri, 15 Apr 2005, Junio C Hamano wrote:
to yours is no problem for me. Currently I see your HEAD is at
461aef08823a18a6c69d472499ef5257f8c7f6c8, so I will generate a
set of patches against it.
Have you considered using an s/key-like system to make these hashes more
human-readable? Using the S
On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> I was looking at merge-tree.c last night to add recursive
> behaviour (my favorite these days ;-) to it [*1*].
>
> But then I started thinking.
Always good.
> LT> ... For each entry in the directory it says either
> LT> select path
> LT> or
>
Dear diary, on Fri, Apr 15, 2005 at 12:22:26PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> After I re-read [*R1*], in which Linus talks about dircache,
> especially this section:
>
> - The "current directory cache" describes some baseline. In particular,
>n
On Fri, 2005-04-15 at 20:15 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 11:28:38AM CEST, I got a letter
> where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> > Hi,
> >
> > The egrep regex should not escape the '{' and '}', and also add a check
> > for ' \t' so that we
[ I'm cc'ing the git list even though Barry's question wasn't cc'd.
Because I think his question is interesting and astute per se, even
if I disagree with the proposal ]
On Fri, 15 Apr 2005, Barry Silverman wrote:
>
> If git is totally project based, and each commit represents total state
>
Hi.
The variable is '$patchfifo', not '$pathfifo'. Adding the missing 'c'
will remove the stray pipes that have been left in /tmp.
Art Haas
gitapply.sh: 47b9346d2679b1bf34220fe4502f15c7d0737b0c
--- gitapply.sh
+++ gitapply.sh 2005-04-15 15:11:03.0 -0500
@@ -74,4 +74,4 @@
done
' paddin
On Fri, 15 Apr 2005, Petr Baudis wrote:
>
> So, I assume that you don't want to merge my "SCM layer" (which is
> perfectly fine by me). However, I also apply plenty of patches
> concerning the "core git" - be it portability, leak fixes, argument
> parsing fixes and so on.
I'm actually perfectly
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> Hey, all the code I write is always perfect, of course ;)
And you are always right ;-) Liked that blast-from-the-past?
LT> That said, I'm having some trouble merging with your perfect code,
LT> especially since I decided that Russell'
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> In the meantime I wrote a very stupid "merge-tree" which
LT> does things slightly differently, but I really think your
LT> approach (aka my original approach) is actually a lot
LT> faster. I was just starting to worry that the ball didn'
Dear diary, on Fri, Apr 15, 2005 at 02:58:25AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
> >> I think the above would result in what SCM person would call
> >> "merge upstream/sidestream changes into my work
For for this email not threading properly, I have been lurking on the
mail list archives and just had to reply to this message.
I was planning to ask exactly this question, and Scott beat me to to. I
even wanted to call them "chunks" too. :-)
It's probably worthwhile for anyone discussing this su
These notions that one can always best answer questions by looking at
the content, and that "Individual files DO NOT EXIST" seem over stated,
to me.
Granted, overstated for a good reason. A couple sticks of dynamite are
needed to shake loose some old SCM thinking habits.
===
Ingo has a point wh
On Fri, 15 Apr 2005, C. Scott Ananian wrote:
>
> So I guess I'll have to implement this and find out, won't I? =)
The best way to shup somebody up is always to just do it, and say "hey, I
told you so". It's hard to argue with numbers.
Linus
-
To unsubscribe from this l
On Fri, Apr 15, 2005 at 02:45:55PM -0400, C. Scott Ananian wrote:
> > - we already have wasted space due to the low-level filesystem (as
> > opposed to "git") usually being block-based, which means that space
> > utilization for small objects tends to suck. So you really want to
> > prefer ob
Dear diary, on Fri, Apr 15, 2005 at 08:44:02PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> And I merged your "Add -z option to show-files", but you had based your
> other patches on Petr's tree which due to my other changes is not going to
> merge totally clean
On Fri, Apr 15, 2005 at 01:19:30PM -0400, C. Scott Ananian wrote:
> Why are blobs per-file? [After all, Linus insists that files are an
> illusion.] Why not just have 'chunks', and assemble *these*
> into blobs (read, 'files')? A good chunk size would fit evenly into some
> number of disk blo
On Fri, 15 Apr 2005, Linus Torvalds wrote:
The problem with chunking is:
- it complicates a lot of the routines. Things like "is this file
unchanged" suddenly become "is this file still the same set of chunks",
which is just a _lot_ more code and a lot more likely to have bugs.
The blob still h
On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> Linus, sorry for bothering you with a false alarm. The problem
> turns out to be introduced in pasky-0.4 and does not exist in
> your HEAD.
Hey, all the code I write is always perfect, of course ;)
That said, I'm having some trouble merging with
> intra file diffs: here are two versions of the same file.
Ah so. Linus faked me out.
I was _sure_ that by "file" he meant "file" -- as in a bucket of bits
with a unique identifying .
In that message, I guess by "file" he meant "a version controlled
file, consisting of a series of content ver
On Fri, 15 Apr 2005, C. Scott Ananian wrote:
>
> Why are blobs per-file? [After all, Linus insists that files are an
> illusion.] Why not just have 'chunks', and assemble *these*
> into blobs (read, 'files')? A good chunk size would fit evenly into some
> number of disk blocks (no wasted s
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
>> +static void _usage(void)
PB> This infriges the system namespaces. FWIW, I prefer to add the
PB> underscore at the end of the identifier if wanting to do stuff like
PB> this. Or just call it my_usage().
Thanks. My bad. Noted.
-
To uns
Dear diary, on Fri, Apr 15, 2005 at 11:28:38AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
> Hi,
>
> The egrep regex should not escape the '{' and '}', and also add a check
> for ' \t' so that we do not pickup stuff like '+', etc. Fix typo in
> assignment.
I've been reading the archives (a bad idea, I know). Here's a concrete
suggestion for GIT space-compression which is (I believe) consistent with
the philosophy of GIT.
Why are blobs per-file? [After all, Linus insists that files are an
illusion.] Why not just have 'chunks', and assemble *the
On Fri, 15 Apr 2005, C. Scott Ananian wrote:
>
> I think examining the rsync algorithms should convince you that finding
> common chunks can be fairly efficient.
Note that "efficient" really depends on how good a job you want to do, so
you can tune it to how much CPU you can afford to waste o
On Fri, 15 Apr 2005, David Woodhouse wrote:
given piece of content. Also because we actually have the developer's
attention at commit time, and we can get _real_ answers from the user
about what she was doing, instead of having to guess.
Yes, but it's still hard to get *accurate* information. And
On Fri, 15 Apr 2005, Paul Jackson wrote:
Um ah ... could you explain what you mean by inter and intra file diffs?
intra file diffs: here are two versions of the same file. what changed?
inter file diffs: here is a new file, and here are *all the files in the
current committed version*. Where di
Hello,
I've been thinking about it, and although it seemed Just Sensible
initially, I'm liking it less and less now that I'm actually doing
out-tree merges (git merge already supports it). What is the motivation
of doing things outside of your working directory?
The only one I can imagine i
Dear diary, on Fri, Apr 15, 2005 at 04:21:30AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> +static void _usage(void)
> +{
> + usage("ls-tree [-r] [-z] ");
> +}
(namespace-nazi-hat
This infriges the system namespaces. FWIW, I prefer to add the
underscore at
On Fri, 2005-04-15 at 08:32 -0700, Linus Torvalds wrote:
> - you're doing the work at the wrong point. Doing it _well_ is quite
>expensive. So if you do it at commit time, you cannot _afford_ to do it
>well, and you'll always fall back to doing an ass-backwards job that
>doesn't rea
Linus wrote:
> For example, just doing intra-file diffs is a lot _easier_ and less
> time-consuming than doing inter-file diffs.
Um ah ... could you explain what you mean by inter and intra file diffs?
Google found a three year old message by Andrew Morton, discussing
inter and intra file fragm
On Fri, 15 Apr 2005, David Woodhouse wrote:
>
> And when I'm looking for the change that broke something, I can almost
> always tell which file it's in and go looking in _that_ file.
Read my email about finding "what changed" that I sent out a minute ago.
I claim that my algorithm for finding
On Fri, 15 Apr 2005, David Woodhouse wrote:
>
> And you're right; it shouldn't have to be for renames only. There's no
> need for us to limit it to one "source" and one "destination"; the SCM
> can use it to track content as it sees fit.
Listen to yourself, and think about the problem for a sec
On Fri, 2005-04-15 at 07:53 -0700, Linus Torvalds wrote:
> Files DO NOT matter. Never have. It's an implementation limitation to
> think they do. You'll screw yourself up, and when somebody comes up with a
> half-way efficient way to generate inter-fiel diffs, your architecture is
> totally and
On Fri, 2005-04-15 at 16:53 +0200, Ingo Molnar wrote:
> but the specific scenario you described would require _Linus'_ tree to
> be in limbo for a long time, and have uncommitted half-done edits.
> I.e.:
>
>(A1B2)--(A2B2)--(A2'B3)
> / \ /\
>/\ / \
> (A1
* David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote:
> > do such cases occur frequently? In the kernel at least it's not too
> > typical.
>
> Isn't it? I thought it was a fairly accurate representation of the
> process "I make a whole bunch of c
On Fri, 15 Apr 2005, David Woodhouse wrote:
>
> I suspect that finding the common commit is actually a per-file thing;
> it's not just something you do for the _commit_ graph, then use for
> merging each file in the two branches you're trying to merge.
I disagree.
Conceptually, you should neve
On Thu, 14 Apr 2005, Paul Jackson wrote:
To me, rename is a special case of the more general case of a
big chunk of code (a portion of a file) that was in one place
either being moved or copied to another place.
I wonder if there might be someway to use the tools that biologists use
to analyze DNA
On Fri, Apr 15, 2005 at 02:03:08PM +0200, Johannes Schindelin wrote:
> I disagree. In order to be trusted, this thing has to catch the following
> scenario:
>
> Skywalker and Solo start from the same base. They commit quite a lot to
> their trees. In between, Skywalker commits a tree, where the fu
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
Darren Williams wrote:
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
gmane.org is already archiving this list.
-
To unsub
Hi,
On Fri, 15 Apr 2005, David Woodhouse wrote:
> On Thu, 2005-04-14 at 11:36 -0700, Linus Torvalds wrote:
> > And "merge these two trees" (which works on a _tree_ level)
> > or "find the common commit" (which works on a _commit_ level)
>
> I suspect that finding the common commit is actually a p
On Fri, 15 Apr 2005, Darren Williams wrote:
> 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.
Apparently gmane.o
In perusing the git code, I noticed some errors in argument parsing,
which the patch below fixes. The show-diff error (checking argv[1]
each time around the loop) probably doesn't actually cause any real
problem, but it could be confusing for a novice if "show-diff x"
produces an error but "show-d
> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
CL> Then do you emit the entry for it's parents directory?
In GIT object model, directory modes do not matter. It is not
designed to record directories, and running "update-cache --add
foo" when foo is a directory fails.
The data model of
After I re-read [*R1*], in which Linus talks about dircache,
especially this section:
- The "current directory cache" describes some baseline. In particular,
note the "some" part. It's not tied to any special baseline, and you
can change your baseline any way you please.
So it does NOT
On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote:
> do such cases occur frequently? In the kernel at least it's not too
> typical.
Isn't it? I thought it was a fairly accurate representation of the
process "I make a whole bunch of changes to files I maintain, pulling
from Linus while occasio
On Thu, 2005-04-14 at 17:42 -0700, Linus Torvalds wrote:
> I've not even been convinved that renames are worth it. Nobody has
> really given a good reason why.
>
> There are two reasons for renames I can think of:
>
> - space efficiency in delta-based trees.
> - "annotate".
Neither of those we
On Fri, Apr 15, 2005 at 12:43:47AM -0700, Junio C Hamano wrote:
> > "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
>
> CL> Is that SHA1 for tree or the file object?
>
> I am talking about a single file here.
>
Then do you emit the entry for it's parents directory?
e.g. /foo/bar get creat
* David Woodhouse <[EMAIL PROTECTED]> wrote:
> Consider a simple repository which contains two files A and B. We
> start off with the first version of each ('A1B1'), and the owner of
> each file takes a branch and modifies their own file. There is
> cross-pulling between the two, and then each
PS: forget the '1/2' in the topic, i did it slightly different which
required changes to gettrack.sh, etc, but to got getmerge.sh, and saw my
short sightedness.
On Fri, 2005-04-15 at 11:28 +0200, Martin Schlemmer wrote:
> Hi,
>
> The egrep regex should not escape the '{' and '}', and also add a c
Hi,
The egrep regex should not escape the '{' and '}', and also add a check
for ' \t' so that we do not pickup stuff like '+', etc. Fix typo in
assignment. Check if file exists in new tree before adding/removing
(might add support for this lowlevel to increase speed?). Fix typo in
line remo
On Thu, 2005-04-14 at 11:36 -0700, Linus Torvalds wrote:
> And "merge these two trees" (which works on a _tree_ level)
> or "find the common commit" (which works on a _commit_ level)
I suspect that finding the common commit is actually a per-file thing;
it's not just something you do for the _comm
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> 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
> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
>> - Result is this object $SHA1 with mode $mode at $path (takes
>> one of the trees); you can do update-cache --cacheinfo (if
>> you want to muck with dircache) or cat-file blob (if you want
>> to get the file) or both.
CL> Is that SHA1 fo
93 matches
Mail list logo
