On Tue, 19 Apr 2005, Chris Mason wrote:
>
> I'll finish off the patch once you ok the basics below. My current code
> works
> like this:
Chris, before you do anything further, let me re-consider.
Assuming that the real cost of write-tree is the compression (and I think
it is), I really susp
_BLUSH_
The 1/4 in the series was a buggy one I sent by mistake. Please
replace it with this fixed one. The other three are OK.
BTW, do you have a preferred patch-mail convention to mark the
cover paragraph like this to be excluded from the commit log,
like the three-dash one you mentioned t
This patch makes ls-tree accept either tree or commit.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
ls-tree.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Makefile: needs update
cache.h: needs update
sha1_file.c: needs update
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -74,7 +74,7
This patch makes diff-tree accept either tree or commit.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
diff-tree.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -160,18 +160,20 @@ static int diff_tree(void *tree1, unsign
This patch makes read-tree accept either tree or commit.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
read-tree.c |4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
Makefile: needs update
--- a/read-tree.c
+++ b/read-tree.c
@@ -29,11 +29,9 @@ static int read_tree(unsigned cha
Similar to the diff-cache command, we should accept commit ID
when tree ID is required but the end-user intent is unambiguous.
This patch lifts the tree-from-tree-or-commit logic from
diff-cache.c and moves it to sha1_file.c, which is a common
library source for the SHA1 storage part.
Signed-off-
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>> I'll immediately write a tool to diff the current working directory
>> against a tree object, and hopefully that will just make pasky happy with
>> this model too.
The model you have always had is that there are three things the
user
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 t
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 [EMA
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 v
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 GIT_OBJECT_DIRECTOR
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(-)
Signed-Off-
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 <[EMA
The first patch introduces the GIT_CACHE_DIRECTORY to the C plumbing.
Without this patch, the index file and its lock are always placed
in './.git'. Scripts wishing to run these commands from a different
working directory can use this support to override the cache directory.
The second patch ren
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
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
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
init-db.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
Signed-Off-By: Zach Welch <[EMAIL PROTECTED]>
Consolidate comments at top of main.
--- a/init-db.c
+++ b/init-db.c
@@ -5,6 +5,12 @@
*/
#include "cache.h"
+/*
+ * If you want to, you can share the DB area wit
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
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.6&action=show
Forget my earlier "aspatch" proposal, that's a lousy name.
How about "mkpatch"? Seems like a reasonable name for
a command that makes a patch. GNU Arch uses that command name.
CVS & Subversion basically do this as part of "diff"
(which is another possibility).
--- David A. Wheeler
-
To unsubscrib
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> Is there any other reason why git-pasky wants to have a work file?
Do you mean "why does a user wants to check things out in the
working directory and make changes, possibly run compile tests
before pushing the result to Linus?" ;-) I'
Just in case someone else is considering trying it, I've just written a
pair of programs to transfer a commit and everything it uses directly over
ssh (i.e., without rsync); it is also clever enough to reject anything
that either doesn't inflate or doesn't hash correctly. It also doesn't
transfer a
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" th
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
Thanks for your patience.
On Tue, 2005-04-19 at 16:32 -0700, Tupshin Harper wrote:
> >Give me a case where assuming it's a replace will do the wrong thing,
> >for C code, where it's a variable or function name.
> try this:
> initial patch creates hello.c
> #include
>
> int main(int argc, char *
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 on
On Tue, Apr 19, 2005 at 04:59:18PM -0700, Linus Torvalds wrote:
>
> However, it definitely wouldn't be useful for _me_. The whole thing that
> I'm after is to allow painless merging of distributed work. If I have to
> merge one patch at a time, I'd much rather see people send me patches
> directly
On Tuesday 19 April 2005 17:23, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > Regardless, putting it into the index somehow should be fastest, I'll see
> > what I can do.
>
> Start by putting it in at "read-tree" time, and adding the code to
> invalidate all parent directory i
I was reading this comment in gitcommit.sh and started
thinking...
# We bother with added/removed files here instead of updating
# the cache at the time of git(add|rm).sh, since we want to
# have the cache in a consistent state representing the tree
# as it was the last time we com
Hi,
ok it's starting to look like spam ;-)
I uploaded a new version of wit to http://www.absolutegiganten.org/wit
Wit is a web interface for git. Right now it includes: views of blob,
commit and tree objects, generating patches for the commits, downloading
of gz or bzip2 tarballs of trees.
It's
Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga
That which brings the highest happiness!!
-
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 Tue, 2005-04-19 15:43:54 -0700, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Apr 2005, Martin Schlemmer wrote:
> >
> > Correct me if I am wrong, but the right way to do this is to set the
> > hostname to just that - the hostname, and add 'domain foo.com'
> > to /etc/resolv.conf.
>
>
On Tue, 19 Apr 2005, David Lang wrote:
> >
> > If so, he should set up one repository per quilt patch.
>
> a tool to do this automaticaly is what I was trying to suggest (and asking
> if it would be useful)
Heh. It's certainly possible. Esepcially with the object sharing, you
could create a g
On Tuesday 19 April 2005 05:38 pm, Linus Torvalds wrote:
>
> On Tue, 19 Apr 2005, Steven Cole wrote:
> >
> > I wasn't complaining about the 4 minutes, just the lack of feedback
> > during the majority of that time. And most of it was after the last
> > patching file message.
>
> That should be
On Tue, 19 Apr 2005, Linus Torvalds wrote:
On Tue, 19 Apr 2005, David Lang wrote:
if you are useing quilt for locally developed patches I fully agree with
you, but I was thinking of the case where Andrew is receiving independant
patches from lots of people and storing them in quilt for testing, and
Petr Baudis <[EMAIL PROTECTED]> :
[...]
> Now you decided to do a little bit of parallel development and stick
> your patches not ready for 2.6.12 to a separate tree. That's fine, do
>
> git fork experimental ~/linux-2.6.experimental
>
> and get some coffee. (It takes about 8 minutes here,
Ray Lee wrote:
it allows regular expressions for the match and replace, which means
multiple unique tokens could change atomically. (Does anyone actually
*use* regexes? Sounds like a cannon that'd be hard to aim.)
Yes, and replace patches need to be used very carefully.
Regardless, I only care a
On Tue, 19 Apr 2005, Steven Cole wrote:
>
> I wasn't complaining about the 4 minutes, just the lack of feedback
> during the majority of that time. And most of it was after the last
> patching file message.
That should be exactly the thing that the new "read-tree -m" fixes.
Before, when you r
Ray Lee wrote:
I'm still not communicating well.
Give me a case where assuming it's a replace will do the wrong thing,
for C code, where it's a variable or function name.
Ray
-
I think you are communicating fine, but not fully understanding darcs.
try this:
initial patch creates hello.c
#include
i
On Tue, 19 Apr 2005, David A. Wheeler wrote:
> 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 see lots of reasons for doing a pull as a separate operation.
> One is disconnected operation; (...)
Dear diary, on Wed, Apr 20, 2005 at 01:04:48AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> Then, the flurry of patching file blah messages, followed by a rather
> pregnant pause after the last patching message.
>
> I wasn't complaining about the 4 minutes, just th
On Tue, 2005-04-19 at 16:00 -0700, Tupshin Harper wrote:
> 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 onl
Jon Seymour gmail.com> writes:
[...]
> It seems to me that file-orientation is here to stay and it would be
> really cool to layer some kind of virtual filesystem over the git
> repository so that different trees become transparently accessible via
> different branches of a file system, e.g.
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
On Tue, 2005-04-19 at 15:43 -0700, Linus Torvalds wrote:
>
> On Wed, 20 Apr 2005, Martin Schlemmer wrote:
> >
> > Correct me if I am wrong, but the right way to do this is to set the
> > hostname to just that - the hostname, and add 'domain foo.com'
> > to /etc/resolv.conf.
>
> I'll correct you
On Tue, 19 Apr 2005, David Lang wrote:
>
> if you are useing quilt for locally developed patches I fully agree with
> you, but I was thinking of the case where Andrew is receiving independant
> patches from lots of people and storing them in quilt for testing, and
> then sending them on to yo
On Wed, 20 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 12:17:12AM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
>
> > I can think of. Are you sure there isn't another path to 5b53d3?
>
> I'm not. Actually there well might be.
>
> I think
On Tue, 2005-04-19 at 19:03 -0400, Kevin Smith wrote:
> Pop quiz:
> Here is revision 1 of my file:
> abcde
>
> Here is revision 2:
> wow
> Now, did I do that with a darcs replace, or just by typing?
I'm still not communicating well.
Give me a case where assuming it's a replace will do t
Greg KH wrote:
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 before,
Dear diary, on Wed, Apr 20, 2005 at 12:38:17AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> Just say no to patches.
FYI, I've - per Junio's suggestion - made git merge's fast-forward to
apply show-diff output as a patch instead. This is roughly equal to
doing th
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 hav
Ray Lee wrote:
> On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
>
>>Notice that just by looking at my diffs, you can't tell that I used a
>>replace operation.
>
>
> Here's where we disagree. If you checkpoint your tree before the
> replace, and immediately after, the only differences in t
On Tue, 19 Apr 2005, Linus Torvalds wrote:
On Tue, 19 Apr 2005, David Lang wrote:
what if you turned the forest of quilt patches into a forest of git trees?
(essentially applying each patch against the baseline seperatly) would
this make sense or be useful?
It has a certain charm, but the fact is,
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> c
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 g
Hi all!
Quoting Linus Torvalds ([EMAIL PROTECTED]):
> And even the ones that use domainname tend to not have a fully qualified
> DNS domain there. You need to use dnsdomainname to get that, and I don't
> even know how to do it with standard libc.
I don't think getdomainname should be used at a
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 uniform
On Wed, 20 Apr 2005, Petr Baudis wrote:
>
> I will probably not buy git-export, though. (That is, it is merged, but
> I won't make git frontend for it.) My "git export" already does
> something different, but more importantly, "git patch" of mine already
> does effectively the same thing as you
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 repositories
On Tue, 19 Apr 2005, Daniel Jacobowitz wrote:
>
> Easiest might be to punt to hostname --fqdn, or an equivalent to its
> algorithm - which appears to be fetch the hostname from uname, do a DNS
> lookup on that, and a reverse DNS lookup on the result.
Hah. I'll just commit my patch, and for any
> "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,
On Wed, 20 Apr 2005, Martin Schlemmer wrote:
>
> Correct me if I am wrong, but the right way to do this is to set the
> hostname to just that - the hostname, and add 'domain foo.com'
> to /etc/resolv.conf.
I'll correct you.
The fact is, that's not what people do. Not me, not kernel.org, not _
(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].
> >>
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 s
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
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 operat
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
On Mon, Apr 18, 2005 at 12:43:23AM -0700, Andy Isaacson wrote:
>
> I'm not going to do the sums, but I would hazard a guess that it's more
> likely your PC suffered a cosmic-ray-induced memory fault - EACH OF THE
> FOUR TIMES YOU TESTED IT - causing it to report the same MD5, than that
> you actua
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 before, causing that patch).
>
> No, I think it's a bug in your dom
Dear diary, on Wed, Apr 20, 2005 at 12:19:01AM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
> 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 a
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 ch
On Tue, 19 Apr 2005, David Lang wrote:
>
> what if you turned the forest of quilt patches into a forest of git trees?
> (essentially applying each patch against the baseline seperatly) would
> this make sense or be useful?
It has a certain charm, but the fact is, it gets really messy to sort
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, 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 m
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 projec
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 don't think you
should do the domainname at all if the hostna
On Tue, Apr 19, 2005 at 01:20:47PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 19 Apr 2005, Greg KH wrote:
> >
> > Ok, if you want some practice with "real" merges, feel free to merge from
> > the following two trees whenever you are ready:
> > kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2
Hello,
I've hit a strange bug in merge-base I don't want to debug now. ;-)
I've been doing my regular git pull test from my main branch, but
suddenly git merge wanted to do a tree merge instead of fast-forward.
What went wrong?
The commits tree looks like:
36c764 -- 808162 -- .. -- 8
On Tue, 19 Apr 2005, Chris Mason wrote:
>
> Regardless, putting it into the index somehow should be fastest, I'll see
> what
> I can do.
Start by putting it in at "read-tree" time, and adding the code to
invalidate all parent directory indexes when somebody changes a file in
the index (ie "up
Hi,
I've uploaded a new wit to http://www.absolutegiganten.org/wit
Wit is a web interface for git. Right now it includes: views of blob,
commit and tree objects, generating patches for the commits, downloading
of gz or bzip2 tarballs of trees.
It's easy to setup and a simple stand alone server c
On Tuesday 19 April 2005 15:03, 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 whatev
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
David Greaves wrote:
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
I've been working on git.pl and getting help working nicely
things to try:
git.pl help
git.pl add
git.pl add --help
git.pl add --man
git.
Fix a stupid typo from the last mkdir refactorng patch.
init-db.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-Off-By: Zach Welch <[EMAIL PROTECTED]>
--- a/init-db.c 2005-04-19 13:06:11.0 -0700
+++ a/init-db.c 2005-04-19 13:06:16.0 -0700
@@ -11,7 +11,7 @@
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 Ros
On Tue, 19 Apr 2005, Greg KH wrote:
>
> Ok, if you want some practice with "real" merges, feel free to merge from
> the following two trees whenever you are ready:
> kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/
> for 11 aoe bugfix patches, and:
> kernel.org/pub/scm/linux/k
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).
O
Hello!
It shouldn't be necessary to patch Makefile to specify where scripts
should be installed. This patch introduces a variable bindir for that
purpose. The name of the variable was chosen for compatibility with
projects using Automake.
For example, to install scripts to /usr/local/bin use:
m
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 '
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? Shou
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
Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
where Steven Cole <[EMAIL PROTECTED]> told me that...
I've been working on git.pl and getting help working nicely
things to try:
git.pl help
git.pl add
git.pl add --help
git.pl add --man
git.pl help add
The main
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.
>
Fa
On Mon, Apr 18, 2005 at 09:39:38PM -0700, Greg KH wrote:
> Alright, let's try some small i2c and w1 patches...
>
> Could you merge with:
> kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
Nice, it looks like the merge of this tree, and my usb tree worked just
fine.
So, what does thi
* 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),
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 c
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, 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
On Tuesday 19 April 2005 13:36, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > I did a quick experiment with applying/commit 100 patches from the suse
> > kernel into a kernel git tree, which quilt can do in 2 seconds. git
> > needs 1m5s.
>
> Note that I don't think you want t
1 - 100 of 162 matches
Mail list logo
