On Tue, Apr 19, 2005 at 01:09:42AM +0200, Petr Baudis wrote:
Essentially, with BK, at 7am localtime each morning, I'd:
- update my baseline linux 2.6 tree
- for each working tree which may be pulled from
- if the baseline is a superset
- update working tree from baseline
KS == Kevin Smith [EMAIL PROTECTED] writes:
KS what's so special about files ? where the author suggests that
KS existing SCM systems are so blinded by the tradition of file
KS orientation that they can't see that there might be alternatives.
Correct: file orientation is eventually a
Dear diary, on Tue, Apr 19, 2005 at 07:43:07AM CEST, I got a letter
where bert hubert [EMAIL PROTECTED] told me that...
On Tue, Apr 19, 2005 at 05:51:07AM +0200, Petr Baudis wrote:
http://pasky.or.cz/~pasky/dev/git
I pulled the tar.bz2 and did make:
gcc -g -O3 -Wall -o merge-cache
Aye, that will require some metadata on the git side (the hack,
suggested by Linus, of using git hashes to notice moves won't work).
So, why won't it work?
Because two files can legitimately have identical contents without
being ``the same'' file from the VC system's point of view.
In
Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
My automatic pull this morning produced the following messages, which
seem to indicate that something's up with git pull now.
git-pasky-0.4
On Tue, Apr 19, 2005 at 10:23:41AM +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
where Russell King [EMAIL PROTECTED] told me that...
My automatic pull this morning produced the following messages, which
seem to indicate that something's up
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 -
Hi all,
I'm working on an OO perl alternative to Petr's git scripts, which I'm
currently calling yogi (your other git interface). While I'm not
ready to release that just yet, I wanted to start floating some patches to
the core plumbing to support the respective packages' potentially
divergent
init-db calls getenv(DB_ENVIRONMENT) twice. Once should be enough.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
init-db.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
This patch factors the init-db directory creation into a new function,
which is then reused in the next patch.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
This patch give init-db the ability for the index directory to be
overridden by the INDEX_FILE_DIRECTORY environment variable.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv
Move redundant mkdir call logic into helper function.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
[PATCH 2/8] init-db.c: [RESEND] make init-db work with common
This patch give read-tree the ability for the index directory to be
overridden by the INDEX_FILE_DIRECTORY environment variable.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv
David A. Wheeler wrote:
I propose changing pull to ONLY download, and update to pull AND merge.
Why? It seems oddly inconsistent that pull sometimes merges
in changes, but at other times it doesn't.
true
I propose that there be two subcommands, pull and update
(now that update isn't a reserved
On Mon, Apr 18, 2005 at 08:38:25AM -0700, Linus Torvalds wrote:
On Mon, 18 Apr 2005, David Roundy wrote:
In particular, it would make life (that is, life interacting back
and forth with git) easier if we were to embed darcs patches in their
entirety in the git comment block.
Hell
Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter
where David Greaves [EMAIL PROTECTED] told me
On Tue, Apr 19, 2005 at 02:55:05AM +0200, Juliusz Chroboczek wrote:
[Using git as a backend for Darcs.]
...
1. remove the assumption that patch IDs have a fixed format. Patch
IDs should be opaque blobs of binary data that Darcs only compares
for equality.
I'm not really comfortable
On Mon, Apr 18, 2005 at 06:42:11PM -0700, Ray Lee wrote:
On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
You could guess, but that's not good enough for darcs to be able to
reliably commute the patches later.
Who said anything about guessing? If a user replaces all instances of
foo
[Removing Linus from CC, keeping the Git list -- or should we remove it?]
I'm not clear why it would be necesary, and it takes the only immutable
piece of information regarding a patch, and makes it variable.
Er... I'm not suggesting to make it variable, just to make it an
opaque blob of bytes
Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter
where Juliusz Chroboczek [EMAIL PROTECTED] told me that...
The problem is that there is no sequence of alien versions that one can
differentiate. Git has a branched history, with each version that follows
a merge having
Dear all,
please don't bother me with ``read the source dude'' or similar answers to this
post. If it's tone or contents just piss You off, ignore it.
I read a little about git lately, and tried to get it running the
last two days. I found the following things lacking:
1) There is no clear
On Sat, Apr 16, 2005 at 07:37:02PM +0200, Martin Uecker wrote:
On Sat, Apr 16, 2005 at 11:11:00AM -0400, C. Scott Ananian wrote:
The rsync approach does not use fixed chunk boundaries; this is necessary
to ensure good storage reuse for the expected case (ie; inserting a single
line at
Is there a way to check out a tree without changing the mtime of any
files that you have already checked out and which are the same as the
version you are checking out? It seems that checkout-cache -a doesn't
overwrite any existing files, and checkout-cache -f -a overwrites all
files and gives
* David Woodhouse [EMAIL PROTECTED] wrote:
On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote:
Is there a way to check out a tree without changing the mtime of any
files that you have already checked out and which are the same as the
version you are checking out? It seems that
I disagree. This already forces you to have two branches (one to pull
from to get the data, mirroring the remote branch, one for your real
work) uselessly and needlessly.
...
These naming issues may appear silly but I think they matter big time
for usability, intuitiveness, and learning
On Tue, 2005-04-19 at 12:50 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the style of a man page.
I
On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter
where Kay Sievers [EMAIL PROTECTED] told me that...
I'm hacking on a simple web interface, cause I missed the bkweb too much.
It can't do much more than browse through
On Tue, 19 Apr 2005, Tupshin Harper wrote:
I suspect that any use of wildcards in a new format would be impossible
for darcs since it wouldn't allow darcs to construct dependencies,
though I'll leave it to david to respond to that.
Note that git _does_ very efficiently (and I mean
On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote:
On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter
where Kay Sievers [EMAIL PROTECTED] told me that...
I'm hacking on a simple web interface, cause I missed
Dear diary, on Tue, Apr 19, 2005 at 02:36:32PM CEST, I got a letter
where Klaus Robert Suetterlin [EMAIL PROTECTED] told me that...
1) There is no clear (e.g. by name) distinction between ``git as done
by Linus'', which is a kind of content addressable database with added
semantics, and ``git
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
is there any 'export commit as patch' support in git-pasky? I didnt find
any such command (maybe it got added meanwhile), so i'm using the 'ge'
hack below.
e.g. i
Greg KH greg at kroah.com writes:
[...]
Looks good, care to post the updated version?
http://ehlo.org/~kay/
What about a git repo of gitweb?
gitweb2.pl is nice with the browse function. BTW, but there's a '1' artefact
right after the browse link in action=show_tree :-)
Kay, your script is
On Tue, 19 Apr 2005, Petr Baudis wrote:
I'd actually prefer, if:
(i) checkout-cache simply wouldn't touch files whose stat matches with
what is in the cache; it updates the cache with the stat informations
of touched files
Run update-cache --refresh _before_ doing the checkout-cache,
On Tue, Apr 19, 2005 at 07:32:42PM +0200, Kay Sievers wrote:
On Tue, Apr 19, 2005 at 09:52:48AM -0700, Greg KH wrote:
On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote:
On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
Example:
..snip a perfect-looking example..
-
Speaking of 'git diff', I ran that before applying the following patch,
and got a diff starting thusly:
---
On Tue, 19 Apr 2005, Linus Torvalds wrote:
The real expense right now of a merge is that we always forget all the
stat information when we do a merge (since it does a read-tree). I have a
cunning way to fix that, though, which is to make read-tree -m read in
the old index state like it
On Tue, 19 Apr 2005, Petr Baudis wrote:
I disagree. This already forces you to have two branches (one to pull
from to get the data, mirroring the remote branch, one for your real
work) uselessly and needlessly.
If you pull in a non-tracked tree, it certainly won't apply the
changes, so you
On Tue, Apr 19, 2005 at 10:36:06AM -0700, Linus Torvalds wrote:
In fact, git has all the same issues that BK had, and for the same
fundamental reason: if you do distributed work, you have to always
append stuff, and that means that you can never re-order anything after
the fact.
You can,
* Petr Baudis [EMAIL PROTECTED] wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
is there any 'export commit as patch' support in git-pasky? I didnt find
any such command (maybe it got added meanwhile), so i'm
On Tue, 19 Apr 2005, Chris Mason wrote:
Very true, you can't replace quilt with git without ruining both of them.
But
it would be nice to take a quilt tree and turn it into a git tree for merging
purposes, or to make use of whatever visualization tools might exist someday.
Fair
On Tue, Apr 19, 2005 at 07:03:20PM +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
is there any 'export commit as patch' support in git-pasky? I didnt find
any such command (maybe it got added
On Tue, 19 Apr 2005, Greg KH wrote:
Nice, it looks like the merge of this tree, and my usb tree worked just
fine.
Yup, it all seems to work out.
So, what does this now mean? Is your kernel.org git tree now going to
be the real kernel tree that you will be working off of now? Should
we
Dear diary, on Tue, Apr 19, 2005 at 08:56:07PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
and please fix gitXnormid.sh to simply echo nothing and return with a -1
exit value when a nonsensical ID is passed to it. Right now the output
is quite ugly if you do 'ge
On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote:
I'm still working out some performance issues with merges (the actual
merge operation itself is very fast, but I've been trying to make the
subsequent update the working directory tree to the right thing be much
better).
Ok, if
Hello!
This patch improves option handling for gitdiff.sh. Now -p doesn't
need to precede -r, although all options still have to be placed
before the file names. Also, the patch introduces a minimal usage info
for the script.
The patch is against current git-pasky.
Signed-off-by: Pavel Roskin
Steven Cole wrote:
Speaking of I think, the name cogito was suggested for the
SCM layer, but IIRC Linus suggested staying with just plain git. Petr
suggested tig, perhaps because it looks at git from another point of view.
I haven't read _all_ the mails - I thought cogito was kinda selected and
On Monday 18 April 2005 10:05 pm, Kevin Smith wrote:
The big feature of a darcs replace patch is that it works forward and
backward in time. Let me try to come up with an example that can help
explain it. Hopefully I'll get it right. Let's start with a file like
this that exists in a project
On Tue, 19 Apr 2005, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Chris Mason wrote:
Very true, you can't replace quilt with git without ruining both of them.
But
it would be nice to take a quilt tree and turn it into a git tree for merging
purposes, or to make use of whatever visualization tools
Linus Torvalds wrote:
On Tue, 19 Apr 2005, Greg KH wrote:
Nice, it looks like the merge of this tree, and my usb tree worked just
fine.
Yup, it all seems to work out.
[many files patched]
patching file mm/mmap.c
patching file net/bridge/br_sysfs_if.c
patching file scripts/ver_linux
On Tue, 2005-04-19 at 15:00 -0700, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Greg KH wrote:
It looks like your domain name isn't set up properly for your box (which
is why it worked for you, but not me before, causing that patch).
No, I think it's a bug in your domainname changes. I
On Tue, Apr 19, 2005 at 06:27:38PM -0400, Daniel Jacobowitz wrote:
On Tue, Apr 19, 2005 at 03:00:04PM -0700, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Greg KH wrote:
It looks like your domain name isn't set up properly for your box (which
is why it worked for you, but not me
On Tue, 19 Apr 2005, Steven Cole wrote:
But perhaps a progress bar right about here might be
a good thing for the terminally impatient.
real3m54.909s
user0m14.835s
sys 0m10.587s
4 minutes might be long enough to cause some folks to lose hope.
Well, the real operations
Dear diary, on Tue, Apr 19, 2005 at 10:20:47PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
Pasky? Can you check my latest git stuff, notably read-tree.c and the
changes to git-pull-script?
I've made git merge to use read-tree -m, HTH.
I will probably not buy
Daniel Barkalow wrote:
See, I don't think you ever want to just pull. You want to
pull-and-do-something, but the something could be any operation...
In a _logical_ sense that's true; I'd only want to pull data if I intended
to (possibly) do something with it. But as a _practical_ matter,
I can
(Sorry for the delayed reply -- I'm living on tape delay for a bit.)
On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
The other is replace very instace of identifier `foo` with
identifier`bar`.
That could be derived, however, by a particularly smart parser [1].
No, it can't.
On Tue, 19 Apr 2005, Linus Torvalds wrote:
(*) Actually, I think it's the compression that ends up being the most
expensive part.
You're also using the equivalent of '-9', too -- and *that's slow*.
Changing to Z_NORMAL_COMPRESSION would probably help a lot
(but would break all existing
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB I'm wondering if doing
PB if [ $(show-diff) ]; then
PB git diff | git apply
PB else
PB checkout-cache -f -a
PB fi
PB would actually buy us some time; or, how common is it for people to have
PB no local changes whatsoever, and whether
On Tue, 19 Apr 2005, David Meybohm wrote:
But doesn't this require assuming the distribution of MD5 is uniform,
and don't the papers finding collisions in less show it's not? So, your
birthday-argument for calculating the probability wouldn't apply, because
it rests on the assumption MD5 is
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
is there any 'export commit as patch' support in git-pasky?
Nice idea. I will add it, probably as 'git patch'.
Eek!
It's a nice idea, and it'd be
Ray Lee wrote:
Here's where we disagree. If you checkpoint your tree before the
replace, and immediately after, the only differences in the
source-controlled files would be due to the replace.
This is assuming that you only have one replace and no other operations
recorded in the patch. If you
Dear diary, on Wed, Apr 20, 2005 at 12:45:02AM CEST, I got a letter
where Junio C Hamano [EMAIL PROTECTED] told me that...
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB I'm wondering if doing
PB if [ $(show-diff) ]; then
PB git diff | git apply
PB else
PB checkout-cache -f -a
PB
On Tuesday 19 April 2005 04:38 pm, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Steven Cole wrote:
But perhaps a progress bar right about here might be
a good thing for the terminally impatient.
real3m54.909s
user0m14.835s
sys 0m10.587s
4 minutes might be long
On Tue, 19 Apr 2005, Chris Mason wrote:
5) right before exiting, write-tree updates the index if it made any changes.
This part won't work. It needs to do the proper locking, which means that
it needs to create index.lock _before_ it reads the index file, and
write everything to that one
On Tue, 2005-04-19 at 10:22 +0200, Juliusz Chroboczek wrote:
Aye, that will require some metadata on the git side (the hack,
suggested by Linus, of using git hashes to notice moves won't work).
So, why won't it work?
Because two files can legitimately have identical contents without
On Tue, 19 Apr 2005, Junio C Hamano wrote:
Let's for a moment forget what git-pasky currently does, which
is not to touch .git/index until the user says Ok, let's
commit.
I think git-pasky is wrong.
It's true that we want to often (almost always) diff against the last
released thing,
On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
Hi,
ok it's starting to look like spam ;-)
I uploaded a new version of wit to http://www.absolutegiganten.org/wit
Why not work together with Kay's tool:
http://ehlo.org/~kay/gitweb.pl?project=linux-2.6action=show_log
Linus,
I see you pulled the first two patches of my last series into your tree,
so I know I had your attention briefly. I wanted to see what I can do to
help the rest of the changes get in, so
I realized last night as I was going to bed that the third patch might
not be accepted because it
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
init-db.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Normalize init-db environment variable handling, allowing the creation
of object directories
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
[PATCH 2/3] init-db.c: normalize env var handling.
init-db.c | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Factor mkdir
On Tue, 19 Apr 2005, Linus Torvalds wrote:
That is indeed the whole point of the index file. In my world-view, the
index file does _everything_. It's the staging area (work file), it's
the merging area (merge directory) and it's the cache file (stat
cache).
I'll immediately write a tool
cache.h|3 +++
init-db.c |9 +++--
read-cache.c | 15 +--
read-tree.c| 35 ++-
update-cache.c | 33 -
5 files changed, 73 insertions(+), 22 deletions(-)
Signed-Off-By: Zach Welch
This patch applies on top of:
[PATCH 1/3] add GIT_CACHE_DIRECTORY support
cache.h |4 ++--
fsck-cache.c |2 +-
init-db.c|4 ++--
ls-tree.c|4 ++--
read-cache.c |4 ++--
sha1_file.c |2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
This patch applies on top of:
[PATCH 1/3] add GIT_CACHE_DIRECTORY support
[PATCH 2/3] rename object directory symbols
cache.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Rename SHA1_FILE_DIRECTORY to
On Tue, 19 Apr 2005, Zach Welch wrote:
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
init-db.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Normalize init-db environment variable
Linus Torvalds wrote:
For future reference, this is in the wrong order.
I feel even more abashed for my earlier scripting faux pas. Would you
like me to resend them to you off-list?
Cheers,
Zach
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL
On Tue, 19 Apr 2005, Zach Welch wrote:
I feel even more abashed for my earlier scripting faux pas. Would you
like me to resend them to you off-list?
No, I edited them and applied them (the first series, I'll have to think
about the second one).
It's only when there are tens of patches
77 matches
Mail list logo
