* [ANNOUNCE] git-pasky-0.5
From: Petr Baudis @ 2005-04-18 22:25 UTC (permalink / raw)
To: git
Hello,
so here finally goes git-pasky-0.5, my set of scripts upon Linus
Torvald's git, which aims to provide a humanly usable interface, to a
degree similar to a SCM tool. You can get it at
http://pasky.or.cz/~pasky/dev/git/
See the READMEs etc for some introduction.
This contains plenty of changes, it's difficult to sum it up. It has
been reworked to better support the concept of branches; you can create
local branches which share the GIT object repository by git fork. There
is also git init which will yet you start a new GIT object repository
(possibly seeding it from some rsync URL), git status, better git log,
much cleaner concept of tracking (and consequently simpler yet better
git pull). Of course it contains the latest updates from Linus' branch
too.
There is also git merge, which does some merging, but note well that
it is vastly inferior to what we _can_ do (and what I will do now).
Expect 0.6 soon where git merge will actually make use of the merging
facilities. I released 0.5 basically only because I have been postponing
it so long that I really feel ashamed of myself. ;-)
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 22:33 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List, Peter Anvin
In-Reply-To: <20050418231652.C16789@flint.arm.linux.org.uk>
Dear diary, on Tue, Apr 19, 2005 at 12:16:52AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Ok, since the last one was soo successful, and I'm up for more
> punishment, here's another attempt. The diffstat is rather
> interesting in this one, claiming no changes. It should look
> like this:
>
> arch/arm/lib/bitops.h | 33 +++++++++++++++++++++++++++++++++
> 1 files changed, 33 insertions(+)
>
> However, it seems that git diff can't handle new files appearing
> yet.
Patches welcome. :^)
Actually it shouldn't be hard. Just for through add-queue/rm-queue and
diff it with /dev/null.
> The other interesting thing to note is that patches are generated
> for '-p0' rather than '-p1' application, which is contary to our
> historical requirements. This is going to confuse people - can
> we make it generate -p1 patches please?
This should be fixed with latest Junio's show-diff changes. I might
change it to be identical with gitdiff-do output later though, using
tree ID and "uncommitted" as the directories instead of 'a' and 'b'.
It will stay -p1 now, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Add + Status patches
From: Petr Baudis @ 2005-04-18 22:35 UTC (permalink / raw)
To: David Greaves; +Cc: Junio C Hamano, git
In-Reply-To: <42643224.60407@dgreaves.com>
Dear diary, on Tue, Apr 19, 2005 at 12:18:12AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Junio C Hamano wrote:
>
> >DG> It allows:
> >DG> find src -type f | git add -
> >
> >I am slow today, but have you considered using xargs?
> >
> >
> >
> yep thanks :)
> I know you _could_ do it with xargs - but you _could_ use the raw git
> commands too. This is a "be nice to the user" layer and I was
> 'surprised' that neither
> git add .
> nor
> git add -r .
> worked.
Actually, when I saw your patch, the xargs solution rushed through my
mind but I thought that '-' might be practical too. Thinking about it, I
couldn't come up with anything. So, what about instead making git add .
to work? ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* trivial fix to gitstatus.sh
From: Sebastian Kuzminsky @ 2005-04-18 22:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This is against git-pasky-0.5, just a little typo.
gitstatus.sh: d5d0f82aca3f668655469cefb08a4d06049f2580
--- gitstatus.sh
+++ gitstatus.sh 2005-04-18 16:31:26.000000000 -0600
@@ -12,7 +12,7 @@
} | sort -z -k 2 | xargs -0 sh -c '
while [ "$1" ]; do
tag=${1% *};
- filename=${1r* };
+ filename=${1#* };
case "$filename" in
*.[ao] | tags | ,,merge*) ;;
*) echo "$tag $filename";;
--
Sebastian
^ permalink raw reply
* Re: [PATCH 1/1] add, rm + status patches
From: Petr Baudis @ 2005-04-18 22:41 UTC (permalink / raw)
To: David Greaves; +Cc: git
In-Reply-To: <4264321F.2050107@dgreaves.com>
Dear diary, on Tue, Apr 19, 2005 at 12:18:07AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Petr Baudis wrote:
>
> > Thanks. Could you please send the patches signed off and either with
> > content-disposition: inline or in the mail body?
> Is this OK.
> Thunderbird isn't the best for attaching patches.
Yes. The patch you inserted is useless, whitespaces are mangled away.
> > I think it would be cleaner to do the testing for the dash in the for
> > loop, so that I can do git add foo bar -. Also, don't forget to
> > update git add's documentation at the top. For the usage string, I'd
> > probably prefer (-|FILE)...
> >
> > thanks,
>
> Here you are:
> * git add and git rm now take (-|FILE)...
> * noted some bugs to be fixed
> * introduced de-dupe code into add and rm
> * git status reports added/removed files (although there are extra entries)
> * README, git and command docs updated
>
> I realise as I write this that I should have split these patches up - I
> will do so next time.
Well, I didn't ask you to split the patch the first time since it was
quite trivial for me to do, but this is too much. ;-)
> Has a decision been reached to _not_ code the cogito part of the git
> suite in perl?
>
> I ask because the code in git status is getting pretty ugly.
> I'd be happy to help with a preliminary port to perl.
I'm fine with Perl. I chose shell for the very initial implementation since
it actually was simplest, but now, I wouldn't have anything against Perl
if it makes is simpler. (And as long as your Perl is nice. I'm harsh
reviewer. ;-)
> Index: gitadd.sh
> ===================================================================
> --- c0aff9b98c4242ab8965c428241df1d8f7a1d4bb/gitadd.sh (mode:100755
> sha1:3ed93ea0fcb995673ba9ee1982e0e7abdbe35982)
> +++ cd5cd7a9272ce1966aca3bfce15f703e33cafc04/gitadd.sh (mode:100755
> sha1:a3e83ac52abd5a9cdc6abd560f95b2f19646fd99)
> \ No newline at end of file
Note this. Something is wrong with your text editor, too.
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Mansfield @ 2005-04-18 22:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Ingo Molnar, git
In-Reply-To: <tnx4qe49z4h.fsf@arm.com>
Catalin Marinas wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
>
>>i've converted the Linux kernel CVS tree into 'flat patchset' format,
>>which gave a series of 28237 separate patches. (Each patch represents a
>>changeset, in the order they were applied. I've used the cvsps
>>utility.)
>
>
> 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 -
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
>
> I read that the old history won't be merged into the new repository
> but, if you are interested, I have a script that can do this based on
> the "(Logical change ...)" string in the file commit logs and it is
> quite fast at generating the patches.
>
Hmmm. I read that message just now. Is it a matter of 'perfection'
that is the issue here, or actual correctness when applying the patches
in order?
(perhaps this has now been fixed).
David
^ permalink raw reply
* (unknown),
From: Matt W. @ 2005-04-18 22:45 UTC (permalink / raw)
To: git
majordomo@vger.kernel.org
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 22:48 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418225356.B16789@flint.arm.linux.org.uk>
Dear diary, on Mon, Apr 18, 2005 at 11:53:57PM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Maybe Petr can improve the error handling, and incorporate it (or at
> least some of it) into git-pasky
This does not need to touch git pull at all now; all the relevant logic
can change in git merge (and git commit), and I'm hacking that now. It
should be rather easy, I think.
I think I won't make git merge commit automatically - I think the user
should get a chance to do a git diff on what is getting merged to check
if everything is all right.
What is actually a little annoying is having to cd ,,merge and then
back, though. I don't know, but the current pull-merge script does not
bother with the temporary merge directory neither, even though Linus
wanted it. Linus, do you still do? ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-18 22:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418224852.GM5554@pasky.ji.cz>
On Tue, Apr 19, 2005 at 12:48:52AM +0200, Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 11:53:57PM CEST, I got a letter
> where Russell King <rmk@arm.linux.org.uk> told me that...
> > Maybe Petr can improve the error handling, and incorporate it (or at
> > least some of it) into git-pasky
>
> This does not need to touch git pull at all now; all the relevant logic
> can change in git merge (and git commit), and I'm hacking that now. It
> should be rather easy, I think.
>
> I think I won't make git merge commit automatically - I think the user
> should get a chance to do a git diff on what is getting merged to check
> if everything is all right.
>
> What is actually a little annoying is having to cd ,,merge and then
> back, though. I don't know, but the current pull-merge script does not
> bother with the temporary merge directory neither, even though Linus
> wanted it. Linus, do you still do? ;-)
In the case I highlighted, we don't want to end up having to require
user intervention. This is a common case here, and was one which was
entirely scripted with BK.
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
The net result is that my workflow consisted entirely of:
1. commit whatever into working tree
2. test
3. send linus a pull request
4. repeat next day
The tree resynchronisation happened completely and entirely in the
background with no user intervention required at all.
With your suggested requirement for user intervention whenever there's
a merge, it means that this just isn't possible - you could automate
the pulls, but you need to ensure that you'd visited each and every
unmerged tree before the next day, or you don't script it at all and
do the whole thing manually.
Hey, I'm lazy, and that means that just won't get done, and my trees
will end up being horrendously out of date all the time. But isn't
this precisely what we have computers and scripts for?
--
Russell King
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-18 23:10 UTC (permalink / raw)
To: Greg KH; +Cc: Russell King, David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <20050418220541.GB19744@kroah.com>
On Mon, 18 Apr 2005, Greg KH wrote:
>
> Hm, have you pushed all of the recent changes public?
Oops. Obviously not. Will fix.
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 23:09 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418235951.D16789@flint.arm.linux.org.uk>
Dear diary, on Tue, Apr 19, 2005 at 12:59:52AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> In the case I highlighted, we don't want to end up having to require
> user intervention. This is a common case here, and was one which was
> entirely scripted with BK.
Well, you can script that
cd ,,merge && echo 'Merge with Linus' | git ci && cd ..
too. ;-)
But it seems like a good idea to just proceed with commit in case of no
conflicts (and possibly have a switch which will tell git merge to just
merge, not commit).
> 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
>
> The net result is that my workflow consisted entirely of:
>
> 1. commit whatever into working tree
> 2. test
> 3. send linus a pull request
> 4. repeat next day
>
> The tree resynchronisation happened completely and entirely in the
> background with no user intervention required at all.
And in the case of conflicts...?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: James Bottomley @ 2005-04-18 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, SCSI Mailing List
In-Reply-To: <Pine.LNX.4.58.0504181429570.15725@ppc970.osdl.org>
On Mon, 2005-04-18 at 14:39 -0700, Linus Torvalds wrote:
> > Linus, the rc-fixes repo is ready for applying ... it's the same one I
> > announced on linux-scsi and lkml a while ago just with the git date
> > information updated to be correct (the misc one should wait until after
> > 2.6.12 is final).
>
> Ok. Can you verify? I did a "git diff" between your old head and my new
> head, and it did not show any SCSI files (only the expected arm etc stuff
> that you didn't have in your), so it all _looks_ good. But hey, just to
> make sure that I didn't do anything stupid..
Actually, the verify fails, according to bitkeeper.
It looks like the merge tree has contamination from the scsi-misc-2.6
tree ... possibly because the hosting system got the merged objects when
I pushed.
Could you strip it back and I'll check out the repos on www.parisc-
linux.org?
Thanks,
James
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-18 23:16 UTC (permalink / raw)
To: Greg KH; +Cc: Russell King, David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <20050418221407.GA20290@kroah.com>
On Mon, 18 Apr 2005, Greg KH wrote:
>
> Anyway, I try it this way and get:
You should update to the newest version anyway..
> $ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch
>
> Applying USB: visor Tapwave Zodiac support patch
>
> fatal: preparing to update file 'drivers/usb/serial/visor.c' not uptodate in cache
>
> What did I forget to do?
The most common reason is that the scripts _really_ want the index to
match your current tree exactly. Run "update-cache --refresh". And if you
have any uncommitted information, make sure to commit it first.
(Not _strictly_ true - you can leave edited files in your directory, and
just hope the patch never touches them. The thing you should _not_ do is
to do an "update-cache xxxx.c" to commit any changes to the 'index',
because then the patch applicator will actually commit that one too).
Linus
^ permalink raw reply
* [PATCH] trivial fix for init-db
From: Aaron Straus @ 2005-04-18 23:14 UTC (permalink / raw)
To: git
This makes init-db work for common object database.
Signed-Off-By: Aaron Straus <aaron@merfinllc.com>
init-db.c: aa00fbb1b95624f6c30090a17354c9c08a6ac596
--- a/init-db.c
+++ b/init-db.c
@@ -24,7 +24,7 @@ int main(int argc, char **argv)
sha1_dir = getenv(DB_ENVIRONMENT);
if (sha1_dir) {
struct stat st;
- if (!stat(sha1_dir, &st) < 0 && S_ISDIR(st.st_mode))
+ if (!stat(sha1_dir, &st) && S_ISDIR(st.st_mode))
return 0;
fprintf(stderr, "DB_ENVIRONMENT set to bad directory %s: ", sha1_dir);
}
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: Junio C Hamano @ 2005-04-18 23:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.58.0504181429570.15725@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Merged. Here's the command line history:
LT> ~/git/git-pull-script \
LT> rsync://www.parisc-linux.org/~jejb/scsi-rc-fixes-2.6.git
Maybe it is just me, but I have this setup:
$ /bin/ls -lF .git
total 20
-rw-rw-r-- 1 junio src 41 Apr 18 16:03 HEAD
-rw-rw-r-- 1 junio junio 41 Apr 18 15:07 MERGE_HEAD
-rw------- 1 junio src 2720 Apr 18 16:03 index
lrwxrwxrwx 1 junio src 18 Apr 18 15:55 objects -> ../../.git/objects/
My point being that .git/objects is a symbolic link and shares
object database with somewhere else.
However the "Getting object database" part trashed this symlink
when I tried to pull from my other repo locally. I am wondering
it the following might be a better alternative. A possible
downside in this approach is that you would not pull .git/heads
and .git/tags (i.e. Pesky stuff) from the remote anymore. Is it
a problem (I am also CC'ing Petr to hear his opinion on this).
If not, please apply.
[PATCH] Do not let rsync obliterate .git/object symbolic link.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-pull-script: e27215d3978635558c63859495d97f8114b4ece3
--- a/git-pull-script
+++ b/git-pull-script
@@ -6,7 +6,7 @@
merge_repo=$1
echo "Getting object database"
-rsync -avz --ignore-existing $merge_repo/ .git/
+rsync -avz --ignore-existing $merge_repo/objects/. .git/objects/.
echo "Getting remote head"
rsync -avz $merge_repo/HEAD .git/MERGE_HEAD
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Greg KH @ 2005-04-18 23:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Russell King, David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504181613490.15725@ppc970.osdl.org>
On Mon, Apr 18, 2005 at 04:16:45PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 18 Apr 2005, Greg KH wrote:
> >
> > Anyway, I try it this way and get:
>
> You should update to the newest version anyway..
>
> > $ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch
> >
> > Applying USB: visor Tapwave Zodiac support patch
> >
> > fatal: preparing to update file 'drivers/usb/serial/visor.c' not uptodate in cache
> >
> > What did I forget to do?
>
> The most common reason is that the scripts _really_ want the index to
> match your current tree exactly. Run "update-cache --refresh". And if you
> have any uncommitted information, make sure to commit it first.
Ah, that was the step I was missing, thanks, it's working now.
greg k-h
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-18 23:29 UTC (permalink / raw)
To: Russell King; +Cc: Petr Baudis, Git Mailing List, Peter Anvin
In-Reply-To: <20050418231652.C16789@flint.arm.linux.org.uk>
On Mon, 18 Apr 2005, Russell King wrote:
>
> Ok, since the last one was soo successful, and I'm up for more
> punishment, here's another attempt. The diffstat is rather
> interesting in this one, claiming no changes. It should look
> like this:
>
> arch/arm/lib/bitops.h | 33 +++++++++++++++++++++++++++++++++
> 1 files changed, 33 insertions(+)
>
> However, it seems that git diff can't handle new files appearing
> yet.
It should definitely be able to do that.
Do a "git log | less" to look up the trees involved, and do a "git diff
<parent-tree> <child-tree>" to see the output. If you don't see your new
file, then either you have an old "git diff" that doesn't like the new
tools (and you need to add a "-z" flag to diff-tree), or you didn't
check in the new file successfully ;)
You can also always do "tree-diff -r old-tree new-tree" which will show
you the tree-level changes. That's the low-level plumbing stuff: it
doesn't show you the actual file contents, just how the tree changed.
> The other interesting thing to note is that patches are generated
> for '-p0' rather than '-p1' application, which is contary to our
> historical requirements. This is going to confuse people - can
> we make it generate -p1 patches please?
That should already be the case now after the latest diffs from Junio.
> Linus - assuming I un-messed-up my tree properly (it appears to
> be correct and fsck-cache $(commit-id) is happy) please merge
> this.
Looks ok, which seems to mean that your scripts are buggered since they
didn't pick up the new file.
Merge pushed out.
Linus
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: Petr Baudis @ 2005-04-18 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzrvsm8j.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Apr 19, 2005 at 01:23:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> However the "Getting object database" part trashed this symlink
> when I tried to pull from my other repo locally. I am wondering
> it the following might be a better alternative. A possible
> downside in this approach is that you would not pull .git/heads
> and .git/tags (i.e. Pesky stuff) from the remote anymore. Is it
> a problem (I am also CC'ing Petr to hear his opinion on this).
Getting tags is probably nice. You should definitively not get
.git/heads, though. Those are your private stuff mostly, and the HEAD
you "export" is .git/HEAD.
I'm thinking about this yet, since it might be useful to be able to
export multiple branches without needing to set up multiple rsync
URLs... you still don't want the heads/ directory en block, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-18 23:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Russell King, Git Mailing List
In-Reply-To: <20050418224852.GM5554@pasky.ji.cz>
On Tue, 19 Apr 2005, Petr Baudis wrote:
>
> What is actually a little annoying is having to cd ,,merge and then
> back, though. I don't know, but the current pull-merge script does not
> bother with the temporary merge directory neither, even though Linus
> wanted it. Linus, do you still do? ;-)
No, now that the merge is done entirely in the index file, I don't care
any more. The index file _is_ the temporary directory as far as I'm
concerned.
Linus
^ permalink raw reply
* [PATCH 7/6] show-diff: Remove stale comments
From: Junio C Hamano @ 2005-04-18 23:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Patch 1/6 in the series has already cleaned the interface to
call sq_expand(), but the comment before that function still
carries the stale interface warning. Remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 3 ---
1 files changed, 3 deletions(-)
show-diff.c: b592fb131fc3949e1197bed461b8eb143f8e73ff
--- a/show-diff.c
+++ b/show-diff.c
@@ -34,9 +34,6 @@ static void prepare_diff_cmd(void)
* name ==> name ==> 'name'
* a b ==> a b ==> 'a b'
* a'b ==> a'\''b ==> 'a'\''b'
- *
- * NOTE! The returned memory belongs to this function so
- * do not free it.
*/
static char *sq_expand(char *src)
{
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: linux @ 2005-04-18 21:04 UTC (permalink / raw)
To: torvalds; +Cc: darcs-devel, git
> Hell no.
>
> The commit _does_ specify the patch uniquely and exactly, so I really
> don't see the point. You can always get the patch by just doing a
>
> git diff $parent_tree $thistree
>
> so putting the patch in the comment is not an option.
Er... no.
One of darcs' big points is that it has at least two fundamentally
different *kinds* of patches. One is the classic diff(1) style.
The other is "replace very instace of identifier `foo` with identifier`bar`".
Note that merging such a patch with another that adds a new instance
of "foo" has a quite different effect from a similar diff-style patch.
Even though both have identical effects on the tree to which they were
initially merged.
And darcs is specifically intended to support additional kinds of patches.
Again, all in order that the patch can work better when applied to
trees *other* that the one it was originally developed against.
Anyway, the point is that, in the darcs world, it is NOT possible to
reconstruct a patch from the before and after trees.
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 23:53 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List, Peter Anvin
In-Reply-To: <20050418231652.C16789@flint.arm.linux.org.uk>
Dear diary, on Tue, Apr 19, 2005 at 12:16:52AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> However, it seems that git diff can't handle new files appearing
> yet.
Fixed. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: Linus Torvalds @ 2005-04-19 0:03 UTC (permalink / raw)
To: James Bottomley; +Cc: git, SCSI Mailing List
In-Reply-To: <1113866092.4998.92.camel@mulgrave>
On Mon, 18 Apr 2005, James Bottomley wrote:
>
> It looks like the merge tree has contamination from the scsi-misc-2.6
> tree ... possibly because the hosting system got the merged objects when
> I pushed.
Nope, the way I merge, if I get a few objects it shouldn't matter at all.
I'll just look at your HEAD, and merge with the objects that represents.
Afterwards, if I have extra objects, I'll see them with fsck-cache.
> Could you strip it back and I'll check out the repos on www.parisc-
> linux.org?
Git does work like BK in the way that you cannot remove history when you
have distributed it. Once it's there, it's there.
The patches from you I have in my tree are:
scsi: add DID_REQUEUE to the error handling
zfcp: add point-2-point support
[PATCH] Convert i2o to compat_ioctl
[PATCH] kill old EH constants
[PATCH] scsi: remove meaningless scsi_cmnd->serial_number_at_timeout field
[PATCH] scsi: remove unused scsi_cmnd->internal_timeout field
[PATCH] remove outdated print_* functions
[PATCH] consolidate timeout defintions in scsi.h
or at least that's what they claim in their changelogs.
Oh, and here's the diffstat that matches "scsi":
drivers/block/scsi_ioctl.c | 5 -
drivers/s390/scsi/zfcp_aux.c | 4 -
drivers/s390/scsi/zfcp_def.h | 5 +
drivers/s390/scsi/zfcp_erp.c | 20 +++++
drivers/s390/scsi/zfcp_fsf.c | 38 ++++++++--
drivers/s390/scsi/zfcp_fsf.h | 6 +
drivers/s390/scsi/zfcp_sysfs_adapter.c | 6 +
drivers/scsi/53c7xx.c | 23 +++---
drivers/scsi/BusLogic.c | 7 -
drivers/scsi/NCR5380.c | 9 +-
drivers/scsi/advansys.c | 7 -
drivers/scsi/aha152x.c | 17 ++--
drivers/scsi/arm/acornscsi.c | 9 +-
drivers/scsi/arm/fas216.c | 9 +-
drivers/scsi/arm/scsi.h | 2
drivers/scsi/atari_NCR5380.c | 9 +-
drivers/scsi/constants.c | 2
drivers/scsi/ips.c | 7 -
drivers/scsi/ncr53c8xx.c | 14 ---
drivers/scsi/pci2000.c | 4 -
drivers/scsi/qla2xxx/qla_dbg.c | 6 -
drivers/scsi/scsi.c | 5 -
drivers/scsi/scsi.h | 43 -----------
drivers/scsi/scsi_error.c | 11 ---
drivers/scsi/scsi_ioctl.c | 5 -
drivers/scsi/scsi_lib.c | 2
drivers/scsi/scsi_obsolete.h | 106 -----------------------------
drivers/scsi/scsi_priv.h | 5 -
drivers/scsi/seagate.c | 5 -
drivers/scsi/sg.c | 3
drivers/scsi/sun3_NCR5380.c | 9 +-
drivers/scsi/sym53c8xx_2/sym_glue.c | 6 -
drivers/scsi/ultrastor.c | 4 -
so it doesn't look like there's a _lot_ wrong. Send in a patch to revert
anything that needs reverting..
Linus
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Ray Lee @ 2005-04-19 0:07 UTC (permalink / raw)
To: linux; +Cc: git, darcs-devel, torvalds
In-Reply-To: <20050418210436.23935.qmail@science.horizon.com>
On Mon, 2005-04-18 at 21:04 +0000, linux@horizon.com wrote:
> The other is "replace very instace of identifier `foo` with identifier`bar`".
That could be derived, however, by a particularly smart parser [1].
Alternately, that itself could be embedded in the comment for patches
sourced from darcs. Of course, that means patches from others are less
commutable than from other darcs users, but that's the price you'd pay
for relying on the user to explicitly note a token rename.
[1] An example: http://minnie.tuhs.org/Programs/Ctcompare/index.html
As for "darcs mv", that can be derived from the before/after pictures of
the trees.
> And darcs is specifically intended to support additional kinds of patches.
Anything missing out of what I listed above? (darcs has adddir and
addfile, IIRC, but those are trivially discovered via inspection of the
trees as well, I think.)
> Anyway, the point is that, in the darcs world, it is NOT possible to
> reconstruct a patch from the before and after trees.
Not yet, and maybe not ever, but I think we can certainly get closer to
discovering what the coder was thinking during a changeset.
Ray
^ permalink raw reply
* Re: yet another gitting started
From: Alex Riesen @ 2005-04-19 0:10 UTC (permalink / raw)
To: randy_dunlap; +Cc: git
In-Reply-To: <20050417195512.061e617a.rdunlap@xenotime.net>
On 4/18/05, randy_dunlap <rdunlap@xenotime.net> wrote:
> Here's the beginnings of yet another git usage/howto/tutorial.
>
> It can grow or die... I'll gladly take patches for it,
> or Pasky et al can merge more git plumbing and toilet usages
> into it, with or without me.
>
> http://www.xenotime.net/linux/doc/git-usage-howto
Thanks! Helped me to start :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox