[PATCH] Add -k kill keyword expansion option to git-cvsimport
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
Should improve our chances of detecting merges and reduce imported
repository size.
Signed-off: Martin Langhoff <[EMAIL PROTECTED]>
---
Documentation/git-cvsimport-script.txt |7 ++-
git-cvsimport-script | 12 +++-
2 files changed, 13 insertions(+), 6 deletions(-)
68d02ed3485e389315f33ab6387c0f1fc028b255
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-cvsimport-script' [ -o ] [ -h ] [ -v ]
[ -d ] [ -p ]
- [ -C ] [ -i ] [ ]
+ [ -C ] [ -i ] [ -k ] [ ]
DESCRIPTION
@@ -34,6 +34,11 @@ OPTIONS
ensures the working directory and cache remain untouched and will
not create them if they do not exist.
+-k::
+ Kill keywords: will extract files with -ko from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
-o ::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
sub usage() {
print STDERR <{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
- # $self->{'socketo'}->write("Argument -ko\n") or return undef;
- # -ko: Linus' version doesn't use it
+ # -ko: Linus' version doesn't use it - defaults to off
+ if ($opt_k) {
+ $self->{'socketo'}->write("Argument -ko\n") or return undef;
+ }
$self->{'socketo'}->write("Argument -r\n") or return undef;
$self->{'socketo'}->write("Argument $rev\n") or return undef;
$self->{'socketo'}->write("Argument --\n") or return undef;
-
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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
Martin Langhoff <[EMAIL PROTECTED]> writes: > [PATCH] Add -k kill keyword expansion option to git-cvsimport > > Early versions of git-cvsimport defaulted to using preexisting keyword > expansion settings. This change preserves compatibility with existing cvs > imports and allows new repository migrations to kill keyword expansion. > > Should improve our chances of detecting merges and reduce imported > repository size. The discussion between you and Linus since you brought this up has kept me wondering if -ko is the only thing people may want to do, or sometimes -kk or even -kb or -kv make sense for some others, in which case instead of a -k option that does not allow anything but -ko, making it take an optional single letter o/k/b/v might might more sense. A single -k defaulting to -ko is fine by me if you did so, because I think that is the most useful and usual mode of operation while converting to GIT repository. Thoughts? - 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
Re: Git 1.0 Synopis (Draft v4)
Ryan Anderson <[EMAIL PROTECTED]> writes: > I guess this means, "I dunno, either place works for me." I was hoping it means to "Oh, come to think of it, maybe I should send this to [EMAIL PROTECTED]" ;-). I agree with you that this may be a lot more suitable for people _before_ they get the git sources, which is to say it may make more sense not to include in core-git tarball but is made into a patch to Pasky's introduction website. - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
On 8/15/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > The discussion between you and Linus since you brought this up > has kept me wondering if -ko is the only thing people may want > to do, or sometimes -kk or even -kb or -kv make sense for some The git-cvsimport script requests the full file at a given revision straight from the cvs server daemon it has instantiated. So I suspect we are mixing up cvs client flags with protocol flags. Hmm, reading up on it ( http://www.elegosoft.com/cvs/cvsclient.html#SEC9 ) the flags are carried through, and it sounds like it's pretty broken. Still, it clearly leaves handling of newlines to the client. The difference between -kb and -ko (we are using -ko ATM) is the newline handling if you are using standard cvs clients. With git-cvsimport, we are doing the unix thing, which happens to be right thing to do. Perhaps repos created with early versions of CVSNT are broken in this regard, but tough. I think -kv is just the wrong thing to do if you are migrating to git. Anyway, this script has so far followed cvs's own default... which is -kv, and I am generally unwilling to break backwards compatibility. Though we could make it default to 'on' and provide '-K' for those masochistic enough to want it. People with repos where cvswrappers was set to mark files as -kb or -ko are safe from all this pain and tears. cheers, martin - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
Martin Langhoff <[EMAIL PROTECTED]> writes: > I think -kv is just the wrong thing to do if you are migrating to git. > Anyway, this script has so far followed cvs's own default... which is > -kv, and I am generally unwilling to break backwards compatibility. Isn't cvs default -kkv? - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
On 8/15/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > Isn't cvs default -kkv? You're right, default is -kkv (expand keyword/value every time) and not -kv (expand keyword/value only if previously unexpanded). There's something else in the -kb / -ko distinction according to the protocol description I linked before. Using -kb changes the way the file is sent, and this may well break our protocol handling, which is currently quite happy to deal with the file as a series of lines. OTOH I am not sure if it breaks when dealing with true binary stuff like images, compressed data, etc. cheers, martin - 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
Re: Git 1.0 Synopis (Draft v4)
On Mon, Aug 15, 2005 at 12:17:46AM -0700, Junio C Hamano wrote: > Ryan Anderson <[EMAIL PROTECTED]> writes: > > > I guess this means, "I dunno, either place works for me." > > I was hoping it means to "Oh, come to think of it, maybe I > should send this to [EMAIL PROTECTED]" ;-). I was waiting until you said, "Ok, 1.00 tomorrow morning" > I agree with you that this may be a lot more suitable for people > _before_ they get the git sources, which is to say it may make > more sense not to include in core-git tarball but is made into a > patch to Pasky's introduction website. Good point. It's already there (now that I found the site.) -- Ryan Anderson sometimes Pug Majere - 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
Re: symlinked directories in refs are now unreachable
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote: > Matt Draisey <[EMAIL PROTECTED]> writes: > > > The behaviour of the symlinked in ref directories has changed from > > earlier versions of git. They used to be taken into account in > > git-fsck-cache --unreachable. > > > > Can the previous behaviour be reinstated? > > I would not have much problem accepting a patch for that; it > would make things safer when a symlink points to a real file > that is outside .git/refs/ that holds a pointer to a valid > object. > > Having said that, I would first like to know why you have a > symlink there, and the real file pointed by it outside .git/refs > hierarchy. The core GIT tools do not create such symlinks, so > either you are creating one by hand, or your Porcelain is > creating one for you for whatever reason. It is my own home-grown Porcelain that creates the symlinks. I've thrown together a python programme to track a nested collection of projects. My own programming efforts rarely exceed two or three files per project, and don't justify there own .git/objects repository. Still, a few projects do benefit from having their own commit history, while the rest are tracked as one big outermost superproject of unrelated stuff. > I would like to know > a use case or two to illustrate why there are symlinks pointing > at real files outside .git/refs/ hierarchy, and how that > arrangement is useful. Whether or not its useful?? Hmmm. Debatable. I've only written a commit tool. All the other git and cogito tools I invoke from the outermost directory like so $git-cat-file commit per/Minesweeper/master Symlinking still works here as expected. The per directory is just there so I don't stomp on the outermost namespace, the Minesweeper is a symlink to the nested project's refs directory. Symlinking seems the natural way to do this as they only need updating when I move subdirectories around. P.S. $echo new-id > .git/per/Minesweeper/master is safe here --- this is the actual behaviour I want. - 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
Re: symlinked directories in refs are now unreachable
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote: > Matt Draisey <[EMAIL PROTECTED]> writes: > > > The behaviour of the symlinked in ref directories has changed from > > earlier versions of git. They used to be taken into account in > > git-fsck-cache --unreachable. > > > > Can the previous behaviour be reinstated? > > I would not have much problem accepting a patch for that; it > would make things safer when a symlink points to a real file > that is outside .git/refs/ that holds a pointer to a valid > object. > > Having said that, I would first like to know why you have a > symlink there, and the real file pointed by it outside .git/refs > hierarchy. The core GIT tools do not create such symlinks, so > either you are creating one by hand, or your Porcelain is > creating one for you for whatever reason. It is my own home-grown Porcelain that creates the symlinks. I've thrown together a python programme to track a nested collection of projects. My own programming efforts rarely exceed two or three files per project, and don't justify there own .git/objects repository. Still, a few projects do benefit from having their own commit history, while the rest are tracked as one big outermost superproject of unrelated stuff. > I would like to know > a use case or two to illustrate why there are symlinks pointing > at real files outside .git/refs/ hierarchy, and how that > arrangement is useful. Whether or not its useful?? Hmmm. Debatable. I've only written a commit tool. All the other git and cogito tools I invoke from the outermost directory like so $git-cat-file commit per/Minesweeper/master Symlinking still works here as expected. The per directory is just there so I don't stomp on the outermost namespace, the Minesweeper is a symlink to the nested project's refs directory. Symlinking seems the natural way to do this as they only need updating when I move subdirectories around. P.S. $echo new-id > .git/per/Minesweeper/master is safe here --- this is the actual behaviour I want. - 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
Re: Switching heads and head vs branch after CVS import
On Sun, Aug 14, 2005 at 07:49:26PM -0700, Linus Torvalds wrote: > On Mon, 15 Aug 2005, Martin Langhoff wrote: > > Except for the keyword expansion. surely there's a way to tell cvsps > > to not do it. Why would we ever want it? > > Ahh. I don't think we should blame cvsps, I think cvsimport should use the > "-ko" flag to disable keyword expansion or whatever the magic flag is. > > Sven, Matthias, opinions? I've never used CVS keyword expansion, and > always felt it was pointless, but hey.. > I don't have any strong opinion on that, but I do think that by default a cvsimport should give you the same file contents that a "cvs import" would. Martin's patch seems to be going in the right direction. skimo - 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
[PATCH] Add documentation for git repack and git-prune-packed.
Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> --- Documentation/git-pack-objects.txt |4 +++ Documentation/git-prune-packed.txt | 42 +++ Documentation/git-repack-script.txt | 41 ++ 3 files changed, 87 insertions(+), 0 deletions(-) create mode 100644 Documentation/git-prune-packed.txt create mode 100644 Documentation/git-repack-script.txt a5842d0ec3abe8316d7a965f43299ce4852dfa04 diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -74,6 +74,10 @@ Documentation - Documentation by Junio C Hamano +See-Also + +git-repack-script(1) git-prune-packed(1) + GIT --- Part of the link:git.html[git] suite diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt new file mode 100644 --- /dev/null +++ b/Documentation/git-prune-packed.txt @@ -0,0 +1,42 @@ +git-prune-packed(1) += +v0.1, August 2005 + +NAME + +git-prune-packed - Program used to remove the extra object files that are now +residing in a pack file. + + +SYNOPSIS + +'git-prune-packed' + +DESCRIPTION +--- +This program search the GIT_OBJECT_DIR for all objects that currently exist in +a pack file as well as the independent object directories. + +All such extra objects are removed. + +A pack is a collection of objects, individually compressed, with delta +compression applied, stored in a single file, with an associated index file. + +Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc. + +Author +-- +Written by Linus Torvalds <[EMAIL PROTECTED]> + +Documentation +-- +Documentation by Ryan Anderson <[EMAIL PROTECTED]> + +See-Also + +git-pack-objects(1) git-repack-script(1) + +GIT +--- +Part of the link:git.html[git] suite + diff --git a/Documentation/git-repack-script.txt b/Documentation/git-repack-script.txt new file mode 100644 --- /dev/null +++ b/Documentation/git-repack-script.txt @@ -0,0 +1,41 @@ + +git-repack-script(1) += +v0.1, August 2005 + +NAME + +git-repack-script - Script used to pack a repository from a collection of +objects into pack files. + + +SYNOPSIS + +'git-repack-script' + +DESCRIPTION +--- +This script is used to combine all objects that do not currently reside in a +"pack", into a pack. + +A pack is a collection of objects, individually compressed, with delta +compression applied, stored in a single file, with an associated index file. + +Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc. + +Author +-- +Written by Linus Torvalds <[EMAIL PROTECTED]> + +Documentation +-- +Documentation by Ryan Anderson <[EMAIL PROTECTED]> + +See-Also + +git-pack-objects(1) git-prune-packed(1) + +GIT +--- +Part of the link:git.html[git] suite + - 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
Re: Git 1.0 Synopis (Draft v4)
Ryan Anderson <[EMAIL PROTECTED]> writes: > I was waiting until you said, "Ok, 1.00 tomorrow morning" Makes sense. There would be some weeks until that happens I am afraid. - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
Martin Langhoff <[EMAIL PROTECTED]> writes: >> ..., in which case instead of a -k option that does not allow >> anything but -ko, making it take an optional single letter >> o/k/b/v might might more sense. A single -k defaulting to -ko >> is fine by me if you did so, because I think that is the most >> useful and usual mode of operation while converting to GIT >> repository. > Anyway, this script has so far followed cvs's own default... which is > -kv, and I am generally unwilling to break backwards compatibility. I realize what I wrote was prone to be misunderstood. What I meant about "single -k defaulting to -ko" was this: cvsimport without -k => cvs default cvsimport -k == cvsimport -ko => use cvs -ko cvsimoprt -kv => use cvs -kv - 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
[PATCH] Add some simple howtos, culled from the mailing list.
I think these are useful, and I think putting them in a new "howto" directory might help some users until we get to the point of splitting up the tutorial to be easier to read. Given the authorship, I think it's safe to put these in the repository. Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> --- Documentation/howto/make-dist.txt | 47 ++ Documentation/howto/rebase-and-edit.txt| 78 ++ .../howto/rebase-from-internal-branch.txt | 163 +++ 3 files changed, 288 insertions(+), 0 deletions(-) create mode 100644 Documentation/howto/make-dist.txt create mode 100644 Documentation/howto/rebase-and-edit.txt create mode 100644 Documentation/howto/rebase-from-internal-branch.txt 5276bcd9892bd712b648761f4b1eeaf6f972594b diff --git a/Documentation/howto/make-dist.txt b/Documentation/howto/make-dist.txt new file mode 100644 --- /dev/null +++ b/Documentation/howto/make-dist.txt @@ -0,0 +1,47 @@ +Date: Fri, 12 Aug 2005 22:39:48 -0700 (PDT) +From: Linus Torvalds <[EMAIL PROTECTED]> +To: Dave Jones <[EMAIL PROTECTED]> +cc: git@vger.kernel.org +Subject: Re: Fwd: Re: git checkout -f branch doesn't remove extra files + +On Sat, 13 Aug 2005, Dave Jones wrote: +> +> > Git actually has a _lot_ of nifty tools. I didn't realize that people +> > didn't know about such basic stuff as "git-tar-tree" and "git-ls-files". +> +> Maybe its because things are moving so fast :) Or maybe I just wasn't +> paying attention on that day. (I even read the git changes via RSS, +> so I should have no excuse). + +Well, git-tar-tree has been there since late April - it's actually one of +those really early commands. I'm pretty sure the RSS feed came later ;) + +I use it all the time in doing releases, it's a lot faster than creating a +tar tree by reading the filesystem (even if you don't have to check things +out). A hidden pearl. + +This is my crappy "release-script": + +[EMAIL PROTECTED] ~]$ cat bin/release-script +#!/bin/sh +stable="$1" +last="$2" +new="$3" +echo "# git-tag-script v$new" +echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz" +echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz" +echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new" +echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog" +echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new" + +and when I want to do a new kernel release I literally first tag it, and +then do + +release-script 2.6.12 2.6.13-rc6 2.6.13-rc7 + +and check that things look sane, and then just cut-and-paste the commands. + +Yeah, it's stupid. + +Linus + diff --git a/Documentation/howto/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt new file mode 100644 --- /dev/null +++ b/Documentation/howto/rebase-and-edit.txt @@ -0,0 +1,78 @@ +Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT) +From: Linus Torvalds <[EMAIL PROTECTED]> +To:Steve French <[EMAIL PROTECTED]> +cc:git@vger.kernel.org +Subject: Re: sending changesets from the middle of a git tree + +On Sat, 13 Aug 2005, Linus Torvalds wrote: + +> That's correct. Same things apply: you can move a patch over, and create a +> new one with a modified comment, but basically the _old_ commit will be +> immutable. + +Let me clarify. + +You can entirely _drop_ old branches, so commits may be immutable, but +nothing forces you to keep them. Of course, when you drop a commit, you'll +always end up dropping all the commits that depended on it, and if you +actually got somebody else to pull that commit you can't drop it from +_their_ repository, but undoing things is not impossible. + +For example, let's say that you've made a mess of things: you've committed +three commits "old->a->b->c", and you notice that "a" was broken, but you +want to save "b" and "c". What you can do is + + # Create a branch "broken" that is the current code + # for reference + git branch broken + + # Reset the main branch to three parents back: this + # effectively undoes the three top commits + git reset HEAD^^^ + git checkout -f + + # Check the result visually to make sure you know what's + # going on + gitk --all + + # Re-apply the two top ones from "broken" + # + # First "parent of broken" (aka b): + git-diff-tree -p broken^ | git-apply --index + git commit --reedit=broken^ + + # Then "top of broken" (aka c): + git-diff-tree -p broken | git-apply --index + git commit --reedit=broken + +and you've now re-applied (and possibly edited the comments) the two +commits b/c, and commit "a" is basically gone (it still exists in the +"broken" branch, of course). + +Finally, check out the end result again: + + # Look at the new commit history + gitk --all + +to see that every
Re: Switching heads and head vs branch after CVS import
In message <[EMAIL PROTECTED]> you wrote: > > One thing that "git cvsimport" does not know to do is to show when a > branch was merged back into the HEAD. That would be a very interesting > thing to see, but I don't think there's any way to get that information > out of CVS (so you'd have to basically make an educated guess by looking > at the changes). > > So in a cvsimport, you'll never see a merge back to the head, even if one > technically took place. I asked this question before without receiving any reply: Assume I know exactly where the merge back happenend - is there any way to tell git about it, so I don't see all these dangling heads any more? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] "The number of Unix installations has grown to 10, with more expected."- The Unix Programmer's Manual, 2nd Edition, June, 1972 - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
Martin Langhoff <[EMAIL PROTECTED]> writes: > Do you want just -kv or you'd like to handle all the modes? No, I do not. I was just wondering if we are limiting options for people who want to convert their own CVS repositories by always using either -kkv or -ko and nothing else. Your simply saying "I do not think so, -ko is what makes the most sense, and any other option does not make any sense, but we used to do -kkv so let's leave that as the default and have a -k option that does -ko" is enough for me. It is getting late for me so I'll merge it and push it out tomorrow when I find time; it will be my day-job day. - 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
Re: sending changesets from the middle of a git tree
Junio C Hamano <[EMAIL PROTECTED]> wrote: > Petr Baudis <[EMAIL PROTECTED]> writes: > >> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter >> where Junio C Hamano <[EMAIL PROTECTED]> told me that... >>> Linus Torvalds <[EMAIL PROTECTED]> writes: >>> >>> > Junio, maybe you want to talk about how you move patches from your "pu" >>> > branch to the real branches. >>> >> Actually, wouldn't this be also precisely for what StGIT is intended to? > > Exactly my feeling. I was sort of waiting for Catalin to speak > up. With its basing philosophical ancestry on quilt, this is > the kind of task StGIT is designed to do. Have been on holiday and couldn't reply. I will follow up. -- Catalin - 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
Re: symlinked directories in refs are now unreachable
On Mon, 2005-08-15 at 00:41 -0700, Junio C Hamano wrote: > Matt Draisey <[EMAIL PROTECTED]> writes: > > > ... My own programming efforts rarely exceed two or three files > > per project, and don't justify there own .git/objects repository. > > Still, a few projects do benefit from having their own commit history, > > I am afraid I am not quite getting it. > > You are interested in many projects that have outside upstream, > and you typically modify only small portion of each of them, > which is quite a typical behaviour for individual developers. > For some reason you want to keep those repository "clean" > without your own commit objects or changed objects only > reachable from your commits. Is it what is happening here? No, all the projects are my own. I am not a developer at all, merely a hobbyist. Upstream projects don't fit into this scheme. > > I've only written a commit tool. All the other git and cogito tools I > > invoke from the outermost directory like so > > > > $git-cat-file commit per/Minesweeper/master > > > > Symlinking still works here as expected. The per directory is just > > there so I don't stomp on the outermost namespace, the Minesweeper is a > > symlink to the nested project's refs directory. > > Hmm. So you have two GIT managed trees, $D/matt and $D/Minesweeper, > and a symlink between them like this. Is that what is happening here? > > $D/matt/.git/refs/heads/per/Minesweeper -> $D/Minesweeper/.git/refs/heads > No, they are nested $D/.git/refs/heads/per/Minesweeper -> $D/Minesweeper/.git/refs/heads The outermost repository merely aggregates a bunch of small unrelated projects that are not yet ready for an independent existence. The idea is to put everything under revision control in the hope that eventually something useful falls out. My commit tool walks up the chain towards root until it finds the objects directory and does the appropriate thing. > Of course 'git-cat-file commit per/Minesweeper/master' would > work in "$D/matt" directory. How do the set of paths recorded > in the index file used in these repositories relate to each > other? Is $D/matt/ tracking the same set of files as the other > repository tracks? Is it meant to be a superset? Subset? More > or less independent "private additions"? > > There must be some advantage to this arrangement than the more > typical arrangement I've seen people do, which is to have two > branches in Minesweeper (that is the upstream, right?) > repository, one "origin" and the other "master". Upstream > changes you fetch and pull into "origin" branch while you commit > your changes to "master" branch. I just do not yet see what > that advantage is, and I strongly suspect because I misread your > description and misunderstood the two repository arrangement you > have and how they are used. > > By the way, did you want to take this discussion private or was > it by accident you did not CC: the list? > No, I didn't want to take it private. I just don't know how my email programme works. I also just discovered that Evolution's Forward As > Redirect is really a bounce and not a forward at all (it doesn't change the to: address) - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
On 8/15/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > I was just wondering if we are limiting options for people who > want to convert their own CVS repositories by always using > either -kkv or -ko and nothing else. I think the other modes are relevant in different scenarios. -kv is only meaningful as file mode over the life of the file in the repo. -kk is only meaningful when calling cvs update with -j -j parameters or cvs diff, and is effectively a synonim of -ko. In the position we are, getting file/revisions out of a repo, there are 2 possible files we can get: the one that you'll get with -kkv and the one you'll get with -ko/-kb. -kb/-ko should give us exactly the same file, modulo bugs. I suspect that in practice -kb is more reliable when it comes to binary files. But to support that the _files() method will need to handle a slightly different protocol mode on the socket, and I rather not mess with it unless I can prove its broken. Talking with cvs servers on the socket is not my idea of fun, and there's all sorts of version-specific oddities. cheers, martin - 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
Re: Switching heads and head vs branch after CVS import
Hi, Linus Torvalds wrote:
>> There may be some surprises in here! gitk --all shows at least one
>> branch opening and merging back into origin, and it has figured it out
>> correctly
>
> Oh, wow. The new cvsimport is obviously being a hell of a lot smarter
> than my original one was. Goodie.
Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)
> Sven, Matthias, opinions? I've never used CVS keyword expansion, and
> always felt it was pointless, but hey..
I have intentionally kept keyword expansion on when I wrote the code,
because matching up the files from CVS with files gathered from tarballs,
Debian repositories, and what-not, becomes a whole lot easier that way.
For me, that's a major use case, esp. with CVS getting confused about its
tags (as people haphazardly copy whole subtrees from one CVS repository
into a different one).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I hope you will find the courage to keep on living
despite the existence of this feature.
-- Richard Stallman
-
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
Re: sending changesets from the middle of a git tree
There are other ways to do these, explained in this thread. I will
only show the StGIT way, just choose which one suits you better.
Steve French <[EMAIL PROTECTED]> wrote:
> 1) There is no way to send a particular changeset from the "middle"
> of a set from one tree to another, without exporting it as a patch
> or rebuilding a new git tree. I have two changesets that, after
> testing last week, I now consider more important to send upstream
> than the few earlier and later changesets.
With StGIT, you create a new patch ('stg new '), modify and
commit the changes with 'stg refresh'. All the modifications to a
patch are stored as a single GIT commit. If you manage a (contributor)
tree with StGIT, you shouldn't commit changes directly with GIT but
use the StGIT commands instead. You end up with a stack of changesets
on top of the main tree.
You can send the changesets upstream with the 'stg mail' command or
export them with 'stg export'.
> If I export those two changesets as patches, and send them
> on. presumably I lose the changset comments etc. and then when the
> upstream tree is merged back, it might look a little odd in the
> changeset history.
Pulling the latest changes from the main tree will keep your changes
on top, much like git cherry/rebase, but StGIT does a diff3 merge
instead of simply generating and applying patch. This has the
advantage of detecting when a patch (changeset) was not fully merged
or was modifed. If the upstream merge was complete, StGIT shows your
patch as empty (since your patch no longer needs to change the
tree). Otherwise, you can either have some changes in the patch or
even be notified of a conflict (patch modified before being merged).
> 2) There is no way to update the comment field of a changeset after
> it goes in (e.g. to add a bugzilla bug number for a bug that was
> opened just after the fix went in).
'stg refresh --edit' lets you modify the patch text. Since the GIT
commits are immutable, a new commit is generated but the parent of the
new commit is the same as the parent of the old commit (making this
commit unaccessible). Being able to create your own DAG structure with
GIT is what made StGIT possible.
> 3) There is no way to do a test commit of an individual changeset
> against a specified tree (to make sure it would still merge cleanly,
> automatically).
With StGIT you can pop all the patches from the stack and only push
the one you want to test (the push/pop operations also allow patch
reordering). Note that the push operation is done with a three-way
merge and, if successful, the patch might have a sligthly different
form (different offsets for example, or even chunks removed if they
are already in the tree).
If the push fails, it means that it doesn't apply cleanly because it
depends on changes made by other patches in your series. You can undo
the push operation with 'stg push --undo'.
--
Catalin
-
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
[PATCH] cvsgit fixes: spaces in filenames and CVS server dialog woes
Problems found while importing dasher's CVS:
* Allow spaces in filenames.
* cvsps may create unnamed branches with revisions that don't really
exist, which causes the CVS server to return something we haven't
hitherto expected.
* Report deleted files when being verbose.
* Also, report the commit date.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -294,6 +293,12 @@ sub _line {
return $res;
} elsif($line =~ s/^E //) {
# print STDERR "S: $line\n";
+ } elsif($line =~ /^Remove-entry /i) {
+ $line = $self->readline(); # filename
+ $line = $self->readline(); # OK
+ chomp $line;
+ die "Unknown: $line" if $line ne "ok";
+ return -1;
} else {
die "Unknown: $line\n";
}
@@ -561,7 +566,7 @@ my $commit = sub {
or die "Error writing to git-commit-tree: $!\n";
$pw->close();
- print "Committed patch $patchset ($branch)\n" if $opt_v;
+ print "Committed patch $patchset ($branch ".strftime("%Y-%m-%d
%H:%M:%S",gmtime($date)).")\n" if $opt_v;
chomp(my $cid = <$pr>);
length($cid) == 40
or die "Cannot get commit id ($cid): $!\n";
@@ -675,26 +680,32 @@ while() {
$state = 9;
} elsif($state == 8) {
$logmsg .= "$_\n";
- } elsif($state == 9 and
/^\s+(\S+):(INITIAL|\d+(?:\.\d+)+)->(\d+(?:\.\d+)+)\s*$/) {
+ } elsif($state == 9 and
/^\s+(.+?):(INITIAL|\d+(?:\.\d+)+)->(\d+(?:\.\d+)+)\s*$/) {
# VERSION:1.96->1.96.2.1
my $init = ($2 eq "INITIAL");
my $fn = $1;
my $rev = $3;
$fn =~ s#^/+##;
my ($tmpname, $size) = $cvs->file($fn,$rev);
- print "".($init ? "New" : "Update")." $fn: $size bytes.\n" if
$opt_v;
- open my $F, '-|', "git-hash-object -w $tmpname"
- or die "Cannot create object: $!\n";
- my $sha = <$F>;
- chomp $sha;
- close $F;
+ if($size == -1) {
+ push(@old,$fn);
+ print "Drop $fn\n" if $opt_v;
+ } else {
+ print "".($init ? "New" : "Update")." $fn: $size
bytes\n" if $opt_v;
+ open my $F, '-|', "git-hash-object -w $tmpname"
+ or die "Cannot create object: $!\n";
+ my $sha = <$F>;
+ chomp $sha;
+ close $F;
+ my $mode = pmode($cvs->{'mode'});
+ push(@new,[$mode, $sha, $fn]); # may be resurrected!
+ }
unlink($tmpname);
- my $mode = pmode($cvs->{'mode'});
- push(@new,[$mode, $sha, $fn]); # may be resurrected!
- } elsif($state == 9 and
/^\s+(\S+):\d(?:\.\d+)+->(\d(?:\.\d+)+)\(DEAD\)\s*$/) {
+ } elsif($state == 9 and
/^\s+(.+?):\d(?:\.\d+)+->(\d(?:\.\d+)+)\(DEAD\)\s*$/) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
+ print "Delete $fn\n" if $opt_v;
} elsif($state == 9 and /^\s*$/) {
$state = 10;
} elsif(($state == 9 or $state == 10) and /^-+$/) {
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Let he who takes the plunge remember to return it by Tuesday.
-
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
Re: [ANNOUNCE] qgit-0.9
> You just need to add -I/usr/include/qt3/ in the appropriate place in the > scons control file, IIRC. I figured out that it wanted qt3-mt, installed it, and fiddled with the SConfiguration file. Still no dice, perhaps because I have a qt4 build environment? $ QTDIR=/usr/ make scons -Q Retrieved `src/annotate.o' from cache /usr//bin/uic -o src/commitbase.h src/commitbase.ui /usr//bin/uic -impl commitbase.h -o src/uic_commitbase.cc src/commitbase.ui /usr//bin/moc -o src/moc_commitbase.cc src/commitbase.h uic: File generated with too old version of Qt Designer File 'src/commitbase.ui' is not valid scons: *** [src/commitbase.h] Error 1 make: *** [all] Error 2 this is with qgit 0.91. Hmmm. Removed all traces of qt4. Hmmm, and hmm some more and it's built. Nice! I actually like it quite a bit. So, notes for the build instructions: under debian, you want to apt-get install qt3-dev-tools libqt3-mt-dev Make sure there's_no_ qt4 build environment, edit SConstruct and have the env.Append line look like: env.Append( CPPFLAGS = ['-DQT_THREAD_SUPPORT', '-D_REENTRANT', '-I/usr/include/qt3'] ) And then make it, saying: QTDIR=/usr make cheers, martin - 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
Re: Switching heads and head vs branch after CVS import
On 8/15/05, Matthias Urlichs <[EMAIL PROTECTED]> wrote: > Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his > from, but it wasn't me. ;-) Just wishful thinking, and a viewing things on a remote box over a slow x11-over-ssh connection. When I think about it, it doesn't seem possible either, so I better stop dreaming. > > Sven, Matthias, opinions? I've never used CVS keyword expansion, and > > always felt it was pointless, but hey.. > > I have intentionally kept keyword expansion on when I wrote the code, > because matching up the files from CVS with files gathered from tarballs, > Debian repositories, and what-not, becomes a whole lot easier that way. Makes sense in that context. On the other hand, if you are you're migrating a project from cvs to git, getting rid of the noise is good. And the resulting git repo will actually let you do trivial merges of old commits after you've switched -- otherwise every file-level merge will conflict, as it does in cvs when you don't use -kk. cheers, martin - 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
[PATCH] Audit rev-parse users.
Make sure that we say --verify when we want to get a single SHA1
name. Also when we say --verify, --revs-only is redundant.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-rebase-script |2 +-
git-reset-script |4 ++--
git-tag-script|2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
fb1dea6f0298f4b47ae6a3dc08a1bc2398ef8053
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -28,7 +28,7 @@ case "$#" in
esac
git-read-tree -m -u $ours $upstream &&
-echo "$upstream" >"$GIT_DIR/HEAD" || exit
+git-rev-parse --verify "$upstream^0" >"$GIT_DIR/HEAD" || exit
tmp=.rebase-tmp$$
fail=$tmp-fail
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -1,7 +1,7 @@
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
-rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
-rev=$(git-rev-parse --revs-only --verify $rev^0) || exit
+rev=$(git-rev-parse --verify --default HEAD "$@") || exit
+rev=$(git-rev-parse --verify $rev^0) || exit
git-read-tree --reset "$rev" && {
if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
then
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -47,7 +47,7 @@ if [ -e "$GIT_DIR/refs/tags/$name" -a -z
fi
shift
-object=$(git-rev-parse --verify --revs-only --default HEAD "$@") || exit 1
+object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-
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
[PATCH] Add git-show-branches-script
Often I find myself wanting to do quick branches check when I am not in the windowing environment and cannot run gitk. This stupid script shows commits leading to the heads of interesting branches with indication which ones belong to which branches, so that fork point is somewhat discernible without using gitk. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- Documentation/git-show-branches-script.txt | 69 Documentation/git.txt |2 + Makefile |1 git-show-branches-script | 53 ++ 4 files changed, 125 insertions(+), 0 deletions(-) create mode 100644 Documentation/git-show-branches-script.txt create mode 100755 git-show-branches-script 8d67319c6e28035abdb848b9b2f31a8c5711bd49 diff --git a/Documentation/git-show-branches-script.txt b/Documentation/git-show-branches-script.txt new file mode 100644 --- /dev/null +++ b/Documentation/git-show-branches-script.txt @@ -0,0 +1,69 @@ +git-show-branches-script(1) +=== +v0.99.4, Aug 2005 + +NAME + +git-show-branches-script - Show branches and their commits. + +SYNOPSIS + +'git show-branches ...' + +DESCRIPTION +--- +Shows the head commits from the named (or all refs under +$GIT_DIR/refs/heads), and displays concise list of commit logs +to show their relationship semi-visually. + +OPTIONS +--- +:: + Name of the reference under $GIT_DIR/refs/heads/. + + +OUTPUT +-- +Given N , the first N lines are the one-line +description from their commit message. The branch head that is +pointed at by $GIT_DIR/HEAD is prefixed with an asterisk '*' +character while other heads are prefixed with a '!' character. + +Following these N lines, one-line log for each commit is +displayed, indented N places. If a commit is on the I-th +branch, the I-th indentation character shows a '+' sign; +otherwise it shows a space. + +The following example shows three branches, "pu", "master" and +"rc": + + * [pu] Add cheap local clone '-s' flag to git-clone-script +! [master] Documentation updates. + ! [rc] Merge master into rc + + Add cheap local clone '-s' flag to git-clone-script + + Alternate object pool mechanism updates. + + Audit rev-parse users. + ++ Documentation updates. + + Merge master into rc + +++ [PATCH] plug memory leak in diff.c::diff_free_filepair() + +These three branches all forked from a common commit, "[PATCH] +plug memory leak...", and "rc" has one commit ahead of it. The +"master" branch has one different commit that is also shared by +"pu" branch, and "pu" branch has three more commits on top of +"master" branch. + + +Author +-- +Written by Junio C Hamano <[EMAIL PROTECTED]> + + +Documentation +-- +Documentation by Junio C Hamano. + + +GIT +--- +Part of the link:git.html[git] suite diff --git a/Documentation/git.txt b/Documentation/git.txt --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -188,6 +188,8 @@ link:git-pull-script.html[git-pull-scrip link:git-commit-script.html[git-commit-script]:: Record changes to the repository. +link:git-show-branches-script.html[git-show-branches-script]:: + Show branches and their commits. Ancilliary Commands --- diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -71,6 +71,7 @@ SCRIPTS=git git-apply-patch-script git-m SCRIPTS += git-count-objects-script # SCRIPTS += git-send-email-script SCRIPTS += git-revert-script +SCRIPTS += git-show-branches-script PROG= git-update-cache git-diff-files git-init-db git-write-tree \ git-read-tree git-commit-tree git-cat-file git-fsck-cache \ diff --git a/git-show-branches-script b/git-show-branches-script new file mode 100755 --- /dev/null +++ b/git-show-branches-script @@ -0,0 +1,53 @@ +#!/bin/sh +# +# Show refs and their recent commits. +# + +. git-sh-setup-script || die "Not a git repository" + +headref=`readlink $GIT_DIR/HEAD` +case "$#" in +0) + set x `cd $GIT_DIR/refs && + find heads -type f -print | + sed -e 's|heads/||' | + sort` + shift ;; +esac + +hh= in= +for ref +do + case "/$headref" in + */"$ref") H='*' ;; + *) H='!' ;; + esac + h=`git-rev-parse --verify "$ref^0"` || exit + l=`git-log-script --max-count=1 --pretty=oneline "$h" | + sed -e 's/^[^ ]* //'` + hh="$hh $h" + echo "$in$H [$ref] $l" + in="$in " +done +set x $hh +shift + +git-rev-list --pretty=oneline "$@" | +while read v l +do + in='' + for h + do + b=`git-merge-base $h $v` + case "$b" in + $v) in="$in+" ;; + *) in="$in " ;; + esac + done + + echo "$in $l" + case "$in" in + *' '*) ;; + *) break ;; + esac +done - To unsubscribe from this list: s
Re: [ANNOUNCE] qgit-0.9
Martin Langhoff wrote: >I figured out that it wanted qt3-mt, installed it, and fiddled with >the SConfiguration file. Still no dice, perhaps because I have a qt4 >build environment? I have qt 3 3.3.4 installed and I never dared to hope qgit can compile with qt4, being a so huge compatibility break. Now I am sure of it ;-) >I actually like it quite a bit. So, notes for the build instructions: >under debian, you want to > > apt-get install qt3-dev-tools libqt3-mt-dev > >Make sure there's_no_ qt4 build environment, edit SConstruct and have >the env.Append line look like: > > env.Append( CPPFLAGS = ['-DQT_THREAD_SUPPORT', '-D_REENTRANT', >'-I/usr/include/qt3'] ) > With this modification qgit compiles also on no Debian platform, so I have applied it to my tree too. Thanks ;-) >And then make it, saying: > > QTDIR=/usr make > Peraphs it is possible to teach SConstruct to understand also this last line? So Debian users don't need to tweak anything. >cheers, > >martin >- Thanks Marco Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - 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
Re: Switching heads and head vs branch after CVS import
Hi, Wolfgang Denk wrote:
> Assume I know exactly where the merge back happenend - is there any
> way to tell git about it, so I don't see all these dangling heads any
> more?
Two ways:
- you can enhance cvs2git to do it at the appropriate time. Good luck.
- after the fact, and after finding the relevant heads manually, you can
use .git/info/grafts to fake it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
As crazy as hauling timber into the woods.
-- Quintus Horatius Flaccus (Horace)
-
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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
On 8/15/05, Martin Langhoff <[EMAIL PROTECTED]> wrote: > I think the other modes are relevant in different scenarios. -kv is > only meaningful as file mode over the life of the file in the repo. > -kk is only meaningful when calling cvs update with -j -j parameters > or cvs diff, and is effectively a synonim of -ko. > > In the position we are, getting file/revisions out of a repo, there > are 2 possible files we can get: the one that you'll get with -kkv and > the one you'll get with -ko/-kb. -kb/-ko should give us exactly the > same file, modulo bugs. After a few more trial runs, it ends up being that -kb and -ko drop the ball in some instances, and the most reliable flag to send is -kk. Don't ask me how or why. So this patch is obsolete too. martin - 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
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
After exploration of the different -k modes in the cvs protocol, we use -kk
which kills keyword expansion wherever possible. Against the protocol
spec, -ko and -kb will sometimes expand keywords.
Should improve our chances of detecting merges and reduce imported
repository size.
Signed-off: Martin Langhoff <[EMAIL PROTECTED]>
---
Documentation/git-cvsimport-script.txt |7 ++-
git-cvsimport-script | 12 +++-
2 files changed, 13 insertions(+), 6 deletions(-)
b30d52a3327183d371416661fc2c7d168791b3bd
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-cvsimport-script' [ -o ] [ -h ] [ -v ]
[ -d ] [ -p ]
- [ -C ] [ -i ] [ ]
+ [ -C ] [ -i ] [ -k ] [ ]
DESCRIPTION
@@ -34,6 +34,11 @@ OPTIONS
ensures the working directory and cache remain untouched and will
not create them if they do not exist.
+-k::
+ Kill keywords: will extract files with -kk from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
-o ::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
sub usage() {
print STDERR <{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
- # $self->{'socketo'}->write("Argument -ko\n") or return undef;
- # -ko: Linus' version doesn't use it
+ # -kk: Linus' version doesn't use it - defaults to off
+ if ($opt_k) {
+ $self->{'socketo'}->write("Argument -kk\n") or return undef;
+ }
$self->{'socketo'}->write("Argument -r\n") or return undef;
$self->{'socketo'}->write("Argument $rev\n") or return undef;
$self->{'socketo'}->write("Argument --\n") or return undef;
-
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
Re: Switching heads and head vs branch after CVS import
On Mon, Aug 15, 2005 at 12:38:53PM +0200, Matthias Urlichs wrote: > Hi, Wolfgang Denk wrote: > > > Assume I know exactly where the merge back happenend - is there any > > way to tell git about it, so I don't see all these dangling heads any > > more? > > Two ways: > - you can enhance cvs2git to do it at the appropriate time. Good luck. > - after the fact, and after finding the relevant heads manually, you can > use .git/info/grafts to fake it. - Create the merge commit manually and then rebase the rest of the branch on top of that commit. Maybe you could enhance git-rebase to rebase on top of more than one head, performing the merge for you. skimo - 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
[PATCH] Just run Ispell through git.txt
[PATCH] Just run Ispell through git.txt Signed-off-by: Yasushi SHOJI <[EMAIL PROTECTED]> --- Documentation/git.txt | 16 1 files changed, 8 insertions(+), 8 deletions(-) 7752fb658ce21b5156547593df01a3a4584ebf80 diff --git a/Documentation/git.txt b/Documentation/git.txt --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -38,7 +38,7 @@ In addition, git itself comes with a spa commands. They are usable but are not meant to compete with real Porcelains. -There are also some ancilliary programs that can be viewed as useful +There are also some ancillary programs that can be viewed as useful aids for using the core commands but which are unlikely to be used by SCMs layered over git. @@ -122,8 +122,8 @@ The interrogate commands may create file touch the working file set - but in general they don't -Synching repositories -~ +Syncing repositories + link:git-clone-script.html[git-clone-script]:: Clones a repository into the current repository (user interface) @@ -189,8 +189,8 @@ link:git-commit-script.html[git-commit-s Record changes to the repository. -Ancilliary Commands +Ancillary Commands +-- Manipulators: link:git-apply-patch-script.html[git-apply-patch-script]:: @@ -212,7 +212,7 @@ link:git-tag-script.html[git-tag-script] An example script to create a tag object signed with GPG -Interogators: +Interrogators: link:git-diff-helper.html[git-diff-helper]:: Generates patch format output for git-diff-* @@ -252,7 +252,7 @@ Identifier Terminology Symbolic Identifiers -Any git comand accepting any can also use the following +Any git command accepting any can also use the following symbolic notation: HEAD:: @@ -323,7 +323,7 @@ git so take care if using Cogito etc 'GIT_ALTERNATE_OBJECT_DIRECTORIES':: Due to the immutable nature of git objects, old objects can be archived into shared, read-only directories. This variable - specifies a ":" seperated list of git object directories which + specifies a ":" separated list of git object directories which can be used to search for git objects. New objects will not be written to these directories. - 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
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Over the week-end, I was thinking about the thread "Re: How is working on arbitrary remote heads supposed to work in Cogito". I wanted to weigh in an opinion that I've developed on it but thought it deserved a new thread. Somewhere in the thread something was mentioned about maintaining : pairs in the git repository when pushes and pulls are performed. I think the argument was actually against keeping this information and ultimately against allowing pushes to a branch of a different name. I wanted to weigh in with why it would be a good idea to make note of this information. The only thing that would be required of the plumbing is to specify how this information is kept and if a push or pull is performed directly with git then make note of the push/pull relationship. Everything else would be up to the porcelains. So, I envision a simple directed graph where nodes represent the branches (wether local or remote) and the edges represent push or pull relationships between branches. Git already stores the nodes. The edges, in theory, would spring into existence when a push or pull is performed between two branches for the first time. This graph will be extremely useful for manageing flow in a project. It could enable something as simple as a script that would walk the edges and tell which ones have fallen behind. It would also be possible to easily pull up a visual representation of the graph (with graphviz, maybe). This sort of thing might prove to be a valuable orientation tool for the developer or project manager. It could also enable some very powerful project flow management --- in a porcelain of course --- that would manage flow from an engineer's own sand-box through software engineering 'gates' such as integration, quality assurance, product maintenance and the documentation and sign-offs required to pass through each of these gates. It could also be used to aid in documenting and managing the, already existent, linux tree development flow in whatever way suits. This is a big return on investment. Little would be required of the plumbing to maintain these 'edges', just add to them when it performs a push/pull on an edge that hasn't already been recorded. Any changes or deletions could be handled by the user or by some porcelain. I think it is important, though, to specify how this information should be stored to maintain compatibility between porcelains while (hopefully) allowing for some degree of flexibility. I don't yet know where this line should be drawn. Carl On Sat, Aug 13, 2005 at 12:48:32AM -0700, Junio C Hamano wrote: > Carl Baldwin <[EMAIL PROTECTED]> writes: > > > On Fri, Jul 29, 2005 at 08:10:51AM +, Petr Baudis wrote: > >> Exactly. I want much more freedom in pushing, the only requirement being > >> that "the to-be-replaced remote head is ancestor of the to-be-pushed > >> local head". I think (am I wrong?) git-send-pack localhead:remotehead > >> would work just fine for me, the only thing I need is the support for > >> different local and remote head names. > > > > Sorry to join the game so late. I've only read this thread now. > > Just in case you have not noticed, the push in 0.99.4 and > onwards does exactly that. Please see git-push-script.txt in > the Documentation/ directory --- oops, there is no such thing. > > Please see git-send-pack.txt instead, and if you feel like it, I > would appreciate a patch to add the missing documentation for > git-push-script ;-). > > What's not supported well yet is the opposite --- downloading > multiple refs and dealing with them. > > Johannes Schindelin calls this "reverse push", and I think that > is really a good name to describe what it does. It takes a > remote repository and possibly multiple refs, downloads the > objects to complete the named remote references, and updates the > local refs only if the remote refs are fast forward children of > the local refs being replaced, just like "push" fast forwards > the remote refs using the local refs. In other words, given > and repository, the following should do the same > thing: > > On repository machine, with GIT_DIR being the repository: > $ git push :... > > On repository machine, with GIT_DIR being the repository: > $ git pull :... > > Johannes posted a script on the list a couple of days ago, which > should work well, except that it was written before the > git-fetch-pack command was updated to natively download from > multiple refs, so it does not know how to fetch multiple refs at > a one go. > > -jc > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from
Making note, in the repository, of push/pull relationships
(Sorry for the repost. The other one was an accident.) Over the week-end, I was thinking about the thread "Re: How is working on arbitrary remote heads supposed to work in Cogito". I wanted to weigh in an opinion that I've developed on it but thought it deserved a new thread. Somewhere in the thread something was mentioned about maintaining : pairs in the git repository when pushes and pulls are performed. I think the argument was actually against keeping this information and ultimately against allowing pushes to a branch of a different name. I wanted to weigh in with why it would be a good idea to make note of this information. The only thing that would be required of the plumbing is to specify how this information is kept and if a push or pull is performed directly with git then make note of the push/pull relationship. Everything else would be up to the porcelains. So, I envision a simple directed graph where nodes represent the branches (wether local or remote) and the edges represent push or pull relationships between branches. Git already stores the nodes. The edges, in theory, would spring into existence when a push or pull is performed between two branches for the first time. This graph will be extremely useful for manageing flow in a project. It could enable something as simple as a script that would walk the edges and tell which ones have fallen behind. It would also be possible to easily pull up a visual representation of the graph (with graphviz, maybe). This sort of thing might prove to be a valuable orientation tool for the developer or project manager. It could also enable some very powerful project flow management --- in a porcelain of course --- that would manage flow from an engineer's own sand-box through software engineering 'gates' such as integration, quality assurance, product maintenance and the documentation and sign-offs required to pass through each of these gates. It could also be used to aid in documenting and managing the, already existent, linux tree development flow in whatever way suits. This is a big return on investment. Little would be required of the plumbing to maintain these 'edges', just add to them when it performs a push/pull on an edge that hasn't already been recorded. Any changes or deletions could be handled by the user or by some porcelain. I think it is important, though, to specify how this information should be stored to maintain compatibility between porcelains while (hopefully) allowing for some degree of flexibility. I don't yet know where this line should be drawn. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
Re: Switching heads and head vs branch after CVS import
On Mon, 15 Aug 2005, Wolfgang Denk wrote:
>
> I asked this question before without receiving any reply:
>
> Assume I know exactly where the merge back happenend - is there any
> way to tell git about it, so I don't see all these dangling heads any
> more?
You'd have to teach cvsimport about it. Basically, in cvsimport, you have
...
my @par = ();
@par = ("-p",$parent) if $parent;
which sets the parent. Right now the parent is _always_ just the previous
head of the branch we're committing to (I'm no good with perl, but I think
Martin was wrong - there's no code to handle the case of a merge: once we
branch off, "git cvsimport" will not currently ever create a
merge-commit).
But if you have some heuristic for figuring out that it's a merge, and
know the other branch is, you could add more parents by just adding
another ("-p", $merge_parent) to the parameters to git-commit-tree.
The problem is literally how to figure out that it's a merge. You can
probably make a guess from the commit message together with possibly
looking at the diff.
The good news is that if you guess wrong, and you claim a merge where none
exists, it doesn't really do any real damage. It might make th history
look strange, and it might make subsequent git merges harder if the branch
is actually still live and you want to continue development within git.
But even that is debatable (if the eventual git merge isn't trivial,
you're likely to have to merge by hand anyway - and it's going to be as
hard as a CVS merge would have been, because quite frankly, you've got the
same information CVS had..).
Linus
-
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
Re: Cloning speed comparison
On Sat, 13 Aug 2005, Petr Baudis wrote: > Hello, > > I've wondered how slow the protocols other than rsync are, and the > (well, a bit dubious; especially wrt. caching on the remote side) > results are: > > git clone-pack:ssh 25s > git rsync 27s > git http-pull 47s > git dumb-http 54s > git ssh-pull660s > > cogito clone-pack:ssh 35s (!) > cogito rsync 140s > cogito ssh-pull480s > cogito http-pull extrapolated to about an hour! I should be able to get http-pull down to the neighborhood of (current) ssh-pull; http-pull is that slow (when the source repository isn't packed) because it's entirely sequential, rather than overlapping requests like ssh-pull now does. I should also be able to get ssh-pull down to the area of clone-pack, but that's lower-priority, since there's clone-pack. (I've written an untested patch for local-pull, which I'll be testing, cleaning, and submitting tonight, assuming my newly-arrived monitor actually works) > PS: > With the latest git version as of time of writing this: > $ time cg-clone git+ssh://[EMAIL PROTECTED]/home/pasky/WWW/dev/git/.g > cogito > ... > progress: 5759 objects, 10292457 bytes > $ time cg-clone http://localhost/~pasky/dev/git/.g cogito > ... > progress: 8681 objects, 14881571 bytes I've noticed that ssh connections don't actually disconnect at the end with recent versions of ssh sometimes. In my experience, this occasionally happens with git, but always happens with scp, suggesting that it's an ssh bug of some sort; I've also only noticed this with openssh 3.9_p1 with some of Gentoo's -r2 patches. -Daniel *This .sig left intentionally blank* - 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
[PATCH] Fixed two bugs in git-cvsimport-script.
The git-cvsimport-script had a copule of small bugs that prevented me
from importing a big CVS repository.
The first was that it didn't handle removed files with a multi-digit
primary revision number.
The second was that it was asking the CVS server for "F" messages,
although they were not handled.
I also updated the documentation for that script to correspond to
actual flags.
Signed-off-by: David Kågedal <[EMAIL PROTECTED]>
---
Documentation/git-cvsimport-script.txt |9 -
git-cvsimport-script |4 ++--
2 files changed, 10 insertions(+), 3 deletions(-)
50452f9c0c2df1f04d83a26266ba704b13861632
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -29,6 +29,10 @@ OPTIONS
currently, only the :local:, :ext: and :pserver: access methods
are supported.
+-C ::
+The GIT repository to import to. If the directory doesn't
+exist, it will be created. Default is the current directory.
+
-i::
Import-only: don't perform a checkout after importing. This option
ensures the working directory and cache remain untouched and will
@@ -44,7 +48,7 @@ OPTIONS
-p ::
Additional options for cvsps.
- The options '-x' and '-A' are implicit and should not be used here.
+ The options '-u' and '-A' are implicit and should not be used here.
If you need to pass multiple options, separate them with a comma.
@@ -57,6 +61,9 @@ OPTIONS
-h::
Print a short usage message and exit.
+-z ::
+Pass the timestamp fuzz factor to cvsps.
+
OUTPUT
--
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -190,7 +190,7 @@ sub conn {
$self->{'socketo'}->write("Root $repo\n");
# Trial and error says that this probably is the minimum set
- $self->{'socketo'}->write("Valid-responses ok error Valid-requests Mode
M Mbinary E F Checked-in Created Updated Merged Removed\n");
+ $self->{'socketo'}->write("Valid-responses ok error Valid-requests Mode
M Mbinary E Checked-in Created Updated Merged Removed\n");
$self->{'socketo'}->write("valid-requests\n");
$self->{'socketo'}->flush();
@@ -691,7 +691,7 @@ while() {
unlink($tmpname);
my $mode = pmode($cvs->{'mode'});
push(@new,[$mode, $sha, $fn]); # may be resurrected!
- } elsif($state == 9 and
/^\s+(\S+):\d(?:\.\d+)+->(\d(?:\.\d+)+)\(DEAD\)\s*$/) {
+ } elsif($state == 9 and
/^\s+(\S+):\d+(?:\.\d+)+->(\d+(?:\.\d+)+)\(DEAD\)\s*$/) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
--
David Kågedal
-
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
Re: gitweb - option to disable rename detection
On Tue, 16 Aug 2005, Yasushi SHOJI wrote: > > It seems to me that git-diff-tree needs huge memory if you try to diff > on big change with rename detection enabled. > > This isn't problem for sane project but if you create a repo with only > major releases imports, git-diff-tree run by git_commit() eats system > memory and die ;P Instead of disabling it entirely, how about just having some limit on it? The basic rename detection works very well for "normal" changes as you point out, but it very fundamentally is O(n^2) in number of files created and deleted, so we could instead just limit it and say "if we have tons of new/deleted files, disable it in the interest of CPU/memory usage". Linus - 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
Re: Git 1.0 Synopis (Draft v4)
On Mon, 15 Aug 2005, Junio C Hamano wrote: > Ryan Anderson <[EMAIL PROTECTED]> writes: > > > I was waiting until you said, "Ok, 1.00 tomorrow morning" > > Makes sense. There would be some weeks until that happens I am > afraid. It might be worth putting the list of things left to do before 1.0 in the tree (since they clearly covary), and it would be useful to know what you're thinking of as preventing the release at any particular stage. -Daniel *This .sig left intentionally blank* - 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
Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
Linus Torvalds wrote: > I'll happily help anybody who wants to try to write some nice > documentation (answer questions etc), but I'm just not very good at doing > it myself. Here's something that I've been putting together on how I'm using GIT as a Linux subsystem maintainer. I suspect that I'm a bit slap-happy with the "git checkout" commands in the examples below, and perhaps missing some of the _true-git_ ways of doing things. -Tony Linux subsystem maintenance using GIT - My requirements here are to be able to create two public trees: 1) A "test" tree into which patches are initially placed so that they can get some exposure when integrated with other ongoing development. This tree is available to Andrew for pulling into -mm whenever he wants. 2) A "release" tree into which tested patches are moved for final sanity checking, and as a vehicle to send them upstream to Linus (by sending him a "please pull" request.) Note that the period of time that each patch spends in the "test" tree is dependent on the complexity of the change. Since GIT does not support cherry picking, it is not practical to simply apply all patches to the test tree and then pull to the release tree as that would leave trivial patches blocked in the test tree waiting for complex changes to accumulate enough test time to graduate. Back in the BitKeeper days I achieved this my creating small forests of temporary trees, one tree for each logical grouping of patches, and then pulling changes from these trees first to the test tree, and then to the release tree. At first I replicated this in GIT, but then I realised that I could so this far more efficiently using branches inside a single GIT repository. So here is the step-by-step guide how this all works for me. First create your work tree by cloning Linus's public tree: $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work Change directory into the cloned tree you just created $ cd work Make a GIT branch named "linus", and rename the "origin" branch as linus too: $ git checkout -b linus $ mv .git/branches/origin .git/branches/linus The "linus" branch will be used to track the upstream kernel. To update it, you simply run: $ git checkout linus && git pull linus you can do this frequently (as long as you don't have any uncommited work in your tree). If you need to keep track of other public trees, you can add branches for them too: $ git checkout -b another linus $ echo URL-for-another-public-tree > .git/branches/another Now create the branches in which you are going to work, these start out at the current tip of the linus branch. $ git checkout -b test linus $ git checkout -b release linus These can be easily kept up to date by merging from the "linus" branch: $ git checkout test && git resolve test linus "Auto-update from upstream" $ git checkout release && git resolve release linus "Auto-update from upstream" Set up so that you can push upstream to your public tree: $ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin and then push each of the test and release branches using: $ git push origin test and $ git push origin release Now to apply some patches from the community. Think of a short snappy name for a branch to hold this patch (or related group of patches), and create a new branch from the current tip of the linus branch: $ git checkout -b speed-up-spinlocks linus Now you apply the patch(es), run some tests, and commit the change(s). If the patch is a multi-part series, then you should apply each as a separate commit to this branch. $ ... patch ... test ... commit [ ... patch ... test ... commit ]* When you are happy with the state of this change, you can pull it into the "test" branch in preparation to make it public: $ git checkout test && git resolve test speed-up-spinlocks "Pull speed-up-spinlock changes" It is unlikely that you would have any conflicts here ... but you might if you spent a while on this step and had also pulled new versions from upstream. Some time later when enough time has passed and testing done, you can pull the same branch into the "release" tree ready to go upstream. This is where you see the value of keeping each patch (or patch series) in its own branch. It means that the patches can be moved into the "release" tree in any order. $ git checkout release && git resolve release speed-up-spinlocks "Pull speed-up-spinlock changes" After a while, you will have a number of branches, and despite the well chosen names you picked for each of them, you may forget what they are for, or what status they are in. To get a reminder of what changes are in a specific branch, use: $ git-whatchanged branchname ^linus | git-shortlog To see whether it has already been merged into the test or release branches use: $ git-rev-list branchname ^test or $ git-rev-list branchname ^release [
Re: Switching heads and head vs branch after CVS import
On 8/16/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > The good news is that if you guess wrong, and you claim a merge where none > exists, it doesn't really do any real damage. I had figured out what part of the code I wanted to hack, but was concerned that marking things that were merges in cvs-speak but not in git-speak would leave me with broken import and problems going forward. If I find the time, I'll add some sort of pattern-match parameters to be tried against the commitmsg to extract likely head/branch names where we are merging from. My problem right now is that the only cvs repo with interesting branches and merges I have is huge, and takes an hour to import. That puts a damper on things, unfortunately. cheers, martin - 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
Re: Switching heads and head vs branch after CVS import
In message <[EMAIL PROTECTED]> you wrote: > > If I find the time, I'll add some sort of pattern-match parameters to > be tried against the commitmsg to extract likely head/branch names > where we are merging from. My problem right now is that the only cvs > repo with interesting branches and merges I have is huge, and takes an > hour to import. That puts a damper on things, unfortunately. In a first step, and to try things out, it might be sufficient if one could feed in this information manually, like by providing a list of PatchSet ID's which are known to be merges ? At least in my case where the number of branches and merges is small this would be completely satisfactory. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 - 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
Re: Cloning speed comparison
Daniel Barkalow <[EMAIL PROTECTED]> writes: > I should be able to get http-pull down to the neighborhood of > (current) ssh-pull; http-pull is that slow (when the source repository > isn't packed) because it's entirely sequential, rather than overlapping > requests like ssh-pull now does. I like those prefetch() and process() code in pull.c very much. I have been wondering if increasing parallelism more by prefetching beyond the immediate parents of the current commit, in "if (get_history)" part of process_commit(). Maybe it is not worth it because doing a commit, its associated tree(s) and its parents would already give us enough parallelism already. > (I've written an untested patch for local-pull, which I'll be testing, > cleaning, and submitting tonight, assuming my newly-arrived monitor > actually works) That is a great news. Thank you for doing this; looking forward to see it, but no rush. Enjoy your new monitor. - 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
[PATCH] Add git-branches-script
For people whose workflow involves switching back and forth between a lot of branches, it can be really helpful to be able to quickly tell which branch you are on and which ones are available. This patch introduces a small script that when invoked as `git branches' prints a list of available branches with a star in front of the one you are on: $ cd linux-2.6/ $ git checkout -b ppc64-cleanups $ git checkout -b ppc64-new-devel $ git checkout -b ppc64-all-merge $ git branches master * ppc64-all-merge ppc64-cleanups ppc64-new-devel Signed-off-by: Amos Waterland <[EMAIL PROTECTED]> --- git-branches-script |8 1 files changed, 8 insertions(+), 0 deletions(-) create mode 100755 git-branches-script 12ab86f36137c4ffd1fb9b878479b9befe4cf2d4 diff --git a/git-branches-script b/git-branches-script new file mode 100755 --- /dev/null +++ b/git-branches-script @@ -0,0 +1,8 @@ +#!/bin/sh + +. git-sh-setup-script || die "Not a git archive" + +current=$(basename $(readlink $GIT_DIR/HEAD)) + +cd $GIT_DIR/refs/heads && +ls | sed -e "s/^/ /" -e "s/ $current/* $current/" - 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
Re: gitweb - option to disable rename detection
At Mon, 15 Aug 2005 11:53:20 -0700 (PDT),
Linus Torvalds wrote:
>
> On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
> >
> > It seems to me that git-diff-tree needs huge memory if you try to diff
> > on big change with rename detection enabled.
> >
> > This isn't problem for sane project but if you create a repo with only
> > major releases imports, git-diff-tree run by git_commit() eats system
> > memory and die ;P
>
> Instead of disabling it entirely, how about just having some limit on it?
ah, that's a good idea. here is a quick and dirty patch.
--
yashi
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -40,6 +40,9 @@ my $home_text = "indextext.html";
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# max number of changes to use rename detection on git-diff-tree
+my $rename_detection_threshold = 1000;
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1587,7 +1590,18 @@ sub git_commit {
$root = " --root";
$parent = "";
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or
die_error(undef, "Open failed.");
+ my $nr_files;
+ my $opts = "";
+ my $disabled_notice;
+ open my $fd, "-|", "$gitbin/git-diff-tree -r $root $parent $hash" or
die_error(undef, "Open failed.");
+ $nr_files++ while <$fd>;
+ close $fd or die_error(undef, "Counting diff-tree failed.");
+ if ($nr_files < $rename_detection_threshold) {
+ $opts .= " -M";
+ } else {
+ $disabled_notice = "(Rename detection disabled)";
+ }
+ open my $fd, "-|", "$gitbin/git-diff-tree -r $opts $root $parent $hash"
or die_error(undef, "Open failed.");
@difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
git_header_html();
@@ -1671,7 +1685,7 @@ sub git_commit {
print "\n";
print "\n";
if ($#difftree > 10) {
- print(($#difftree + 1) . " files changed:\n");
+ print(($#difftree + 1) . " files changed" . $disabled_notice .
":\n");
}
print "\n";
print "\n";
-
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
Mergeback patch - (was: Switching heads and head vs branch after CVS import)
Just a work-in-progress sample. I've done a pretty successful import
of a small tree with this patch. It is showing the merges /almost/ in
the right place. The almost is due to bad cvs practices, and not this
code.
Definitely doable, though it'll never be "nice" -- CVS doesn't have
the right data for this. I want to make the regexes configurable, and
have a more decent way of extracting the parent sha. B
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -542,6 +542,24 @@ my $commit = sub {
my @par = ();
@par = ("-p",$parent) if $parent;
+
+ # detect additional branches
+ my @rx = ( qr/Merged from (\w+)/i , qr/merge of (\w+)/i );
+ foreach my $rx (@rx) {
+ if ($logmsg =~ $rx) {
+ my $parent = $1;
+ if ($parent eq 'HEAD') { $parent = 'origin'};
+ if ( -e "$git_dir/refs/heads/$parent") {
+ warn "grabbing $parent";
+ $parent = `cat $git_dir/refs/heads/$parent`;
+ chomp $parent;
+ warn "grabbed $parent";
+ push @par, '-p', $parent;
+ }
+ }
+ }
+ # %seen_branches
+
exec("env",
"GIT_AUTHOR_NAME=$author",
"GIT_AUTHOR_EMAIL=$author",
-
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
Re: [PATCH] Add --signoff and --verify option to git commit.
On Saturday 13 August 2005 11:08, Junio C Hamano wrote: > Also add --verify to make sure the lines you introduced are > clean, which is more useful in commit but not very much in > format-patch as it was originally implemented, because finding > botches at format-patch time is too late. I think that verification of/commenting on commits at/before commit time is a perfect place for another hook script (or collection of verification scripts). People probably want to check a new commit on identation/coding style on a per-project manner. The hook also should be able to give warnings/hints by adding text to the commit message (e.g. "please do not use 'fgetc'" / "doublecheck quoting in system()", ...) without rejecting the commit as a whole. It could even be allowed to edit the code before commit. These verification scripts should be used per default, and git-commit should have an option to force bypassing verification. If I get some time, I can come up with a patch. Josef - 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
Re: Cloning speed comparison
On Mon, 15 Aug 2005, Junio C Hamano wrote: > Daniel Barkalow <[EMAIL PROTECTED]> writes: > > > I should be able to get http-pull down to the neighborhood of > > (current) ssh-pull; http-pull is that slow (when the source repository > > isn't packed) because it's entirely sequential, rather than overlapping > > requests like ssh-pull now does. > > I like those prefetch() and process() code in pull.c very much. > > I have been wondering if increasing parallelism more by > prefetching beyond the immediate parents of the current commit, > in "if (get_history)" part of process_commit(). Maybe it is not > worth it because doing a commit, its associated tree(s) and its > parents would already give us enough parallelism already. It is actually already maxing out the parallelism; it has a FIFO of objects which it needs, and calls prefetch() when it enqueues an object and fetch() when it dequeues it. It only cares about the dependancies for this purpose, not the types. -Daniel *This .sig left intentionally blank* - 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
Re: Switching heads and head vs branch after CVS import
On Tue, 16 Aug 2005, Martin Langhoff wrote: > > If I find the time, I'll add some sort of pattern-match parameters to > be tried against the commitmsg to extract likely head/branch names > where we are merging from. My problem right now is that the only cvs > repo with interesting branches and merges I have is huge, and takes an > hour to import. That puts a damper on things, unfortunately. I was seriously considering just breaking the "remote cvs" support entirely (you can always just use cvsup or something to download it to make it local), and just taking the RCS parsing code from GNU rcs/cvs and making a C language CVS importer. That would speed things up by an order of magnitude or more, as far as I can tell. Linus - 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
Re: Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
Hi, On Mon, 15 Aug 2005, [EMAIL PROTECTED] wrote: > Linus Torvalds wrote: > > I'll happily help anybody who wants to try to write some nice > > documentation (answer questions etc), but I'm just not very good at doing > > it myself. > > Here's something that I've been putting together on how I'm using > GIT as a Linux subsystem maintainer. This is perfect material for the newly introduced howto/ directory! How about Documentation/howto/how-tony-luck-does-it.txt :-) Ciao, Dscho - 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
Re: gitweb - option to disable rename detection
On Tue, 16 Aug 2005, Yasushi SHOJI wrote: > > > Instead of disabling it entirely, how about just having some limit on it? > > ah, that's a good idea. here is a quick and dirty patch. This makes it somewhat more expensive - I was thinking about disabling it in git-diff-tree, since the rename logic already knows how many new/deleted files there are. Linus - 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
Re: Making note, in the repository, of push/pull relationships
Hi, On Mon, 15 Aug 2005, Carl Baldwin wrote: > Somewhere in the thread something was mentioned about maintaining > : pairs in the git repository when pushes > and pulls are performed. I think the argument was actually against > keeping this information and ultimately against allowing pushes to a > branch of a different name. I think the loudest voice was mine :-) Actually, I was not against *keeping* the information, but against *pulling* in such strange ways. If "cross-pulling" is allowed, I am all for keeping track of that. In the meantime, I did not think about the issue at all :-) However, as is often the case in an open discussion, I think I was wrong after all. There may be cases you want that, and in the end, nobody forces me to use that feature. Anyway, Junio decided to enhance the fetch mechanism to support the cross-pulling (and also multi-pulling). Ciao, Dscho - 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
Re: Switching heads and head vs branch after CVS import
Hi, On Mon, 15 Aug 2005, Linus Torvalds wrote: > I was seriously considering just breaking the "remote cvs" support > entirely (you can always just use cvsup or something to download it to > make it local), and just taking the RCS parsing code from GNU rcs/cvs and > making a C language CVS importer. That would speed things up by an order > of magnitude or more, as far as I can tell. That may be true for many "cvs import" tasks, but not _at all_ for "cvs update" tasks. I, for one, keep track of _lots_ of CVS projects via git-cvsimport. I would hate it if I could no longer do that. Ciao, Dscho - 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
Re: Some tutorial text
Johannes Schindelin <[EMAIL PROTECTED]> writes: >> Here's something that I've been putting together on how I'm using >> GIT as a Linux subsystem maintainer. > > This is perfect material for the newly introduced howto/ directory! How > about Documentation/howto/how-tony-luck-does-it.txt :-) I already have done that pushed it out. Tony is clearly a winner with this one. - 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
Re: git reveals a bug in (some versions) BSD diff
Hi, On Sat, 13 Aug 2005, Brad Roberts wrote: > I'm seeing this on a standard os/x 10.3.9 install which seems to have an > old, but still GNU based, diff. > > $ which diff > /usr/bin/diff > > $ diff --version > diff - GNU diffutils version 2.7 That is exactly the same as with 10.2.8. > [...] > * FAIL 9: apply diff between 2 and 3 > git-apply * FAIL 12: apply diff between 3 and 2 > git-apply http://vger.kernel.org/majordomo-info.html
Screwed up AUTHOR field for two commits.
The topmost couple of commits in the "master" branch made from your patches are incorrectly attributed to me. What happened was that I stumbled upon a merge conflict during git-rebase, and ended up hand committing these two without carrying the authorship information forward from the original commits. This usually does not happen because I always use JIT tools for rebasing, but this time I was trying to stay within the set of core GIT barebone Porcelain. I apologize for the screwup. - 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
Re: [PATCH] Add SubmittingPatches
Hi, On Sat, 13 Aug 2005, Junio C Hamano wrote: > +Note that your maintainer does not subscribe to the git mailing > +list (he reads it via mail-to-news gateway). Wow. I didn't even read a newsgroup in decades... BTW, I don't know how many people still use pine, but for those poor souls it may be good to mention that the quell-flowed-text is needed for recent versions. Ciao, Dscho - 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
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Hi, On Sat, 13 Aug 2005, Junio C Hamano wrote: > Johannes posted a script on the list a couple of days ago, which > should work well, except that it was written before the > git-fetch-pack command was updated to natively download from > multiple refs, so it does not know how to fetch multiple refs at > a one go. Actually, my script usually only calls fetch once. It checks if the commit object is already local before trying to fetch it, and it turns out that a single fetch is often (always?) sufficient to slurp the other commits, too. I did not have time to find out if that is a true bug in git. Ciao, Dscho - 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
Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
Martin Langhoff <[EMAIL PROTECTED]> writes: > So this patch is obsolete too. I take it to mean that it should be dropped and replaced with the one you sent today with -kk change. However, the -kk change one is a corrupted patch and does not apply. Your MUA ate leading whitespaces, perhaps. I have already slurped in other two patches to cvsimport in the proposed updates branch, so could you kindly proofread them (I am no expert on cvs networking protocol issues) and rebase the -kk patch, and send it without whitespace corruption this time around please? -jc - 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
Re: [PATCH] Add --signoff and --verify option to git commit.
Josef Weidendorfer <[EMAIL PROTECTED]> writes: > These verification scripts should be used per default, and git-commit should > have an option to force bypassing verification. I agree that it would be a good place to do a hook. Also it may not be a bad idea, if you volunteer to come up with a patch, to look at an earlier thread that talks about commit message templates and think about how these things should mesh together. Bypassing can already be done by not giving '-v', so I do not think you need to make things more complicated than necessary. You can first try with a '-v', examine what it complains about, fix only what are applicable to your change, try with '-v' again to make sure the only complaints are from false positives, and then you commit without '-v', bypassing the check. - 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
Re: Making note, in the repository, of push/pull relationships
Carl Baldwin <[EMAIL PROTECTED]> writes:
> Somewhere in the thread something was mentioned about maintaining
> : pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
> branch of a different name.
If you are referring to what I said about the user having some
control over both ends hence it should be possible to arrange to
use the same name on both ends to reduce mental burden, Pasky
and others convinced me otherwise during later discussions, and
the current core knows how to do renaming pushes.
One proposal which has not been pursued yet, due to lack of time
on my end if anything else, is to have a set of files that is an
extension of current $GIT_DIR/branches/* file (which can record
the URL and optionally one filename under refs/heads/ over there
to mean "which branch to pull from by default"). Instead, the
proposal introduces $GIT_DIR/remotes/* files, whose contents
would look like this:
$ cat .git/remotes/ko
URL: master.kernel.org:/pub/scm/git/git.git/
Push: master pu rc
Pull: master:ko-master pu:ko-pu rc:ko-rc
The expected workflow with the above example "remotes" file is
for me to be able to do this:
(1) fetch from master.kernel.org (that is the source of the
mirroring for everybody to see on {www,rsync}.kernel.org)
before starting my day. The current "git fetch" does not
do this, but make it:
$ git fetch ko
to mean "fetch from those three branches on the 'Pull:'
line, fast-forward local ko-master, ko-pu and ko-rc with
these heads".
Then I can see where my private heads and publicly visibile
ones stand to make sure things are in good order. E.g. I
can do "git show-branches ko ko-master rc rc-master".
(2) after doing work in my private repository, push to
master.kernel.org with:
$ git push ko
This does not happen to involve renaming push, because both
ends are owned and controlled by me, but you could put
renaming refspec on "Push:" line in the .git/remotes line
to make it rename.
Note that I am _not_ expecting for "git push/pull/fetch"
commands to dynamically update .git/remotes/ file whenever it
gets a new set of heads and renaming refspecs on the command
line. Explicit refspecs on the command line will just override
what is recorded in .git/remotes/* files instead. So:
$ git push ko pu:refs/heads/testing
would not push usual "master pu rc" but create a new "testing"
branch there, starting at the commit which is the head commit of
the local "pu" branch. This is a one-shot override, so next
time around, "git push ko" will do the usual three heads that is
recorded in the .git/remotes/ko file.
-
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
[PATCH] Make git-format-patch's signoff option more consistent
Since git-commit-script has a "--signoff" option, use that in
git-format-patch-script, too (and since partial option names are
supported,"--sign" is still valid).
Also, if the message already contains the S-O-B line, silently ignore the
"--signoff" request.
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
git-format-patch-script | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
36d8f8116e677848da231e3d33da379bd4546505
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -6,7 +6,7 @@
. git-sh-setup-script || die "Not a git archive."
usage () {
-echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--sign] [-...] upstream [ our-head ]
+echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--signoff] [-...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -46,7 +46,7 @@ do
date=t author=t mbox=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
--s|--s|--si|--sig|--sign)
+-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
--output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\
@@ -179,9 +179,12 @@ Date: '"$ad"
test "$signoff" = "t" && {
offsigner=`git-var GIT_COMMITTER_IDENT | sed -e 's/>.*/>/'`
- echo
- echo "Signed-off-by: $offsigner"
- echo
+ line="Signed-off-by: $offsigner"
+ grep -q "^$line\$" $commsg || {
+ echo
+ echo "$line"
+ echo
+ }
}
echo '---'
-
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
Re: [PATCH] Add SubmittingPatches
Johannes Schindelin <[EMAIL PROTECTED]> writes: > BTW, I don't know how many people still use pine, but for those poor souls > it may be good to mention that the quell-flowed-text is needed for recent > versions. Contributions from pine users are very much appreciated. Among the patches I either receive or pick up from the list, 15-20% have WS corruption one way or another, which is starting to annoy me. What annoys me more are MIME quoted printable, though, but that is partly my fault. I haven't counted what percentage of those WS corrupted ones are from Pine, so please do not take the above 15-20% number to have anything to do with Pine. - 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
Re: [PATCH] Add SubmittingPatches
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
>
> BTW, I don't know how many people still use pine, but for those poor souls
> it may be good to mention that the quell-flowed-text is needed for recent
> versions.
And 4.58 needs at least this
Linus
---
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from
e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close.
diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;
-
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
Re: [PATCH] Add SubmittingPatches
Linus Torvalds <[EMAIL PROTECTED]> writes: > And 4.58 needs at least this > diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from > e886a61f76edf5410573e92e38ce22974f9c40f1) > Author: Linus Torvalds <[EMAIL PROTECTED]> > Date: Mon Aug 15 17:23:51 2005 -0700 > > Fix pine whitespace-corruption bug > > There's no excuse for unconditionally removing whitespace from > the pico buffers on close. Wow. This is a _terrible_ one. Isn't pico code also supposed to be a standalone editor of some sort? I wonder how anybody could tolerate this kind of "dictatorship ;-)". At least the changelog entry seems to say that 4.60 removed this "feature". - 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
Re: [PATCH] Add SubmittingPatches
Hi, On Mon, 15 Aug 2005, Linus Torvalds wrote: > On Tue, 16 Aug 2005, Johannes Schindelin wrote: > > > > BTW, I don't know how many people still use pine, but for those poor souls > > it may be good to mention that the quell-flowed-text is needed for recent > > versions. > > And 4.58 needs at least this > >[...] Sorry, I forgot the "no-strip-whitespace-before-send" option, too. AFAIK it was introduced in 4.60 (the "fix" Junio was referring to). Maybe we should enhance git-applymbox to detect whitespace corruption in particular, and output the User-Agent header (or if that does not exist, the Message-ID header; thanks, pine) on error. Ciao, Dscho - 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
Re: gitweb - option to disable rename detection
Linus Torvalds <[EMAIL PROTECTED]> writes: > This makes it somewhat more expensive - I was thinking about disabling it > in git-diff-tree, since the rename logic already knows how many > new/deleted files there are. That's doable. I'll rig something up on my next GIT day, along with the clean-up for diff option handling which we have postponed for some time. Clearly this would introduce another option to diffcore. OTOH, you could take totally the opposite avenue and take advantage of the fact that git commit ancestry is immultable. Once commitdiff is made, you do not have to regenerate it but cache it and reuse for the next request. I may be mistaken, but I vaguely recall kernel.org webservers already does something like that. If you have infinite amount of disk space, you could choose to cache everything, and also prime the cache before any real users ask for a page. Once you go that route, you could even give -C flag for copy detection, with --find-copies-harder which is an ultra expensive option, and nobody would notice. - 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
Re: [PATCH] Add SubmittingPatches
Johannes Schindelin <[EMAIL PROTECTED]> writes: > Maybe we should enhance git-applymbox to detect whitespace corruption in > particular, and output the User-Agent header (or if that does not > exist, the Message-ID header; thanks, pine) on error. We _could_ but I doubt it would help anybody. The damage is already done. - 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
Re: [PATCH] Add SubmittingPatches
Hi, On Mon, 15 Aug 2005, Junio C Hamano wrote: > Johannes Schindelin <[EMAIL PROTECTED]> writes: > > > Maybe we should enhance git-applymbox to detect whitespace corruption in > > particular, and output the User-Agent header (or if that does not > > exist, the Message-ID header; thanks, pine) on error. > Alternatively, SubmittingPatches could include a big fat CAVEAT, and a note that the submitter might want to send a single SP to herself, save the received mail and check that all is well, prior to sending the first patch. I mean, well, erm, it is sort of, uh, annoying, to send out a corrupt patch *speaksofyourstruly*. Ciao, Dscho - 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
How do I track pu branch?
Following an extenal repo, I am not getting all the heads. This is by design, AFAIK, and the question is how do I find what heads the repo offers and pull them in so I can call them by name? cheers, martin - 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
Re: How do I track pu branch?
Martin Langhoff <[EMAIL PROTECTED]> writes: > Following an extenal repo, I am not getting all the heads. This is by > design, AFAIK, and the question is how do I find what heads the repo > offers and pull them in so I can call them by name? I suspect the Subject: line and your question do not mesh well, but anyway.. $ git ls-remote http://www.kernel.org/pub/scm/git/git.git/ 2150cc99fe29fd81db1e9c5971e13bcb78373ebfrefs/heads/master ce1eb6614e4e8308585b75029ad0823389890eb9refs/heads/pu 14fb44880c1143ae0259842c808c036e78b516f6refs/heads/rc 0918385dbd9656cab0d1d81ba7453d49bbc16250refs/tags/junio-gpg-pub d6602ec5194c87b0fc87103ca4d67251c76f233arefs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441refs/tags/v0.99.2 7ceca275d047c90c0c7d5afb13ab97efdf51bd6erefs/tags/v0.99.3 b3e9704ecdf48869f635f0aa99ddfb513f885affrefs/tags/v0.99.4 NOTE. When talking to http(s) URL, the server side needs to be prepared to support the dumb server protocol. That is, to have run git-update-server-info there whenever the repository is updated. Other transports do not have this restriction. -jc - 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
Re: How do I track pu branch?
Junio C Hamano <[EMAIL PROTECTED]> writes: > Martin Langhoff <[EMAIL PROTECTED]> writes: > >> Following an extenal repo, I am not getting all the heads. This is by >> design, AFAIK, and the question is how do I find what heads the repo >> offers and pull them in so I can call them by name? Sorry, "git ls-remote" was the answer to only the first question. Regarding your second question. Once you have found out about them, the way to use shorthand the current tool offers is: $ echo 'http://www.kernel.org/pub/scm/git/git.git/#pu' \ >.git/branches/ko-pu $ git fetch ko-pu Any "git fetch" creates .git/FETCH_HEAD file which holds the SHA1 object name of the fetched commit, but when shorthand recorded in .git/branches is involved, it additionally creates the file ".git/refs/heads/ko-pu". Then you could: $ git checkout -b for-junio ko-pu $ git apply --index http://vger.kernel.org/majordomo-info.html
Re: [patch] possible memory leak in diff.c::diff_free_filepair()
At Sat, 13 Aug 2005 14:31:59 -0700, Junio C Hamano wrote: > > Yasushi SHOJI <[EMAIL PROTECTED]> writes: > > > oops. probably my english wasn't clear. my patch fixes > > diff_free_filepair(). > > When the command is run on linux-2.6 repository, virtual memory > consumption of git-diff-tree command skyrockets to about half a > gig, because it maps all files in two adjacent revisions of the > entire kernel tree. But it seems to reclaim things reasonably > well and goes back down to less than 10m when it starts to > process the next commit pair. it tunes out that, at least for my problem is to populating filespec data in parepare_temp_file() and not freeing it after creating temp file with prep_temp_blob(). parepare_temp_file() and diff_populate_filespec() has a lot in similarity. so it'd be nice to refactor some. and re-introduce diff_free_filespec_data() and call right after prep_temp_blob() in prepare_temp_file(). Junio, did you also mean to clean-up these functions when you said in the thread of "Re: gitweb - option to disable rename detection"? regards, -- yashi - 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
Re: How do I track pu branch?
On 8/16/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > Martin Langhoff <[EMAIL PROTECTED]> writes: > > > Following an extenal repo, I am not getting all the heads. This is by > > design, AFAIK, and the question is how do I find what heads the repo > > offers and pull them in so I can call them by name? > > I suspect the Subject: line and your question do not mesh well, > but anyway.. And even then, your answer is great. Thanks! I was half-expecting a mechanism to track "all branches/heads from a remote repo" by rsync'ing the refs/heads directory outside of the git protocol. That's perhaps why I had the wrong mindset. All in all, it is a bit of a roundabout way of tracking things. cheers, martin - 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
Re: [PATCH] Add SubmittingPatches
On Tue, Aug 16, 2005 at 03:41:04AM +0200, Johannes Schindelin wrote: > On Mon, 15 Aug 2005, Junio C Hamano wrote: > > > Johannes Schindelin <[EMAIL PROTECTED]> writes: > > > > > Maybe we should enhance git-applymbox to detect whitespace corruption in > > > particular, and output the User-Agent header (or if that does not > > > exist, the Message-ID header; thanks, pine) on error. > > > > Alternatively, SubmittingPatches could include a big fat CAVEAT, and a > note that the submitter might want to send a single SP to herself, save > the received mail and check that all is well, prior to sending the first > patch. I mean, well, erm, it is sort of, uh, annoying, to send out a > corrupt patch *speaksofyourstruly*. If you have some trouble sending them out, you can use git format-patch --mbox and git send-email which seems to consistently do the right thing. -- Ryan Anderson sometimes Pug Majere - 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
[PATCH 0/2] Fix local-pull on packed repository
This adds essentially the same logic to local-pull that http-pull has, with the exception that it reads the index out of the source directory, rather than copying it. This, in turn, requires the ability to use an index file in some other directory. 1: Use index file in another directory 2: Copy/link/symlink pack files as appropriate -Daniel *This .sig left intentionally blank* - 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
[PATCH] Add function to read an index file from an arbitrary filename.
Note that the pack file has to be in the usual location if it gets
installed later.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
cache.h |2 ++
sha1_file.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
59e5c6d163edae5da6136560d48a4750cceacdc6
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -319,6 +319,8 @@ extern int get_ack(int fd, unsigned char
extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match,
char **match);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
+extern struct packed_git *parse_pack_index_file(unsigned char *sha1,
+ char *idx_path);
extern void prepare_packed_git(void);
extern void install_packed_git(struct packed_git *pack);
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -476,12 +476,18 @@ struct packed_git *add_packed_git(char *
struct packed_git *parse_pack_index(unsigned char *sha1)
{
+ char *path = sha1_pack_index_name(sha1);
+ return parse_pack_index_file(sha1, path);
+}
+
+struct packed_git *parse_pack_index_file(unsigned char *sha1, char *idx_path)
+{
struct packed_git *p;
unsigned long idx_size;
void *idx_map;
- char *path = sha1_pack_index_name(sha1);
+ char *path;
- if (check_packed_git_idx(path, &idx_size, &idx_map))
+ if (check_packed_git_idx(idx_path, &idx_size, &idx_map))
return NULL;
path = sha1_pack_name(sha1);
-
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
[PATCH] Support packs in local-pull
If it doesn't find an object, it looks for an index that contains it
and uses the same methods on that instead.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
local-pull.c | 112 +++---
1 files changed, 91 insertions(+), 21 deletions(-)
aafbc7fb9ae059b9c9afa42e8d2c0548ea960f9f
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -15,34 +15,54 @@ void prefetch(unsigned char *sha1)
{
}
-int fetch(unsigned char *sha1)
+static struct packed_git *packs = NULL;
+
+void setup_index(unsigned char *sha1)
{
- static int object_name_start = -1;
- static char filename[PATH_MAX];
- char *hex = sha1_to_hex(sha1);
- const char *dest_filename = sha1_file_name(sha1);
+ struct packed_git *new_pack;
+ char filename[PATH_MAX];
+ strcpy(filename, path);
+ strcat(filename, "/objects/pack/pack-");
+ strcat(filename, sha1_to_hex(sha1));
+ strcat(filename, ".idx");
+ new_pack = parse_pack_index_file(sha1, filename);
+ new_pack->next = packs;
+ packs = new_pack;
+}
- if (object_name_start < 0) {
- strcpy(filename, path); /* e.g. git.git */
- strcat(filename, "/objects/");
- object_name_start = strlen(filename);
+int setup_indices()
+{
+ DIR *dir;
+ struct dirent *de;
+ char filename[PATH_MAX];
+ unsigned char sha1[20];
+ sprintf(filename, "%s/objects/pack/", path);
+ dir = opendir(filename);
+ while ((de = readdir(dir)) != NULL) {
+ int namelen = strlen(de->d_name);
+ if (namelen != 50 ||
+ strcmp(de->d_name + namelen - 5, ".pack"))
+ continue;
+ get_sha1_hex(sha1, de->d_name + 5);
+ setup_index(sha1);
}
- filename[object_name_start+0] = hex[0];
- filename[object_name_start+1] = hex[1];
- filename[object_name_start+2] = '/';
- strcpy(filename + object_name_start + 3, hex + 2);
+ return 0;
+}
+
+int copy_file(const char *source, const char *dest, const char *hex)
+{
if (use_link) {
- if (!link(filename, dest_filename)) {
+ if (!link(source, dest)) {
pull_say("link %s\n", hex);
return 0;
}
/* If we got ENOENT there is no point continuing. */
if (errno == ENOENT) {
- fprintf(stderr, "does not exist %s\n", filename);
+ fprintf(stderr, "does not exist %s\n", source);
return -1;
}
}
- if (use_symlink && !symlink(filename, dest_filename)) {
+ if (use_symlink && !symlink(source, dest)) {
pull_say("symlink %s\n", hex);
return 0;
}
@@ -50,25 +70,25 @@ int fetch(unsigned char *sha1)
int ifd, ofd, status;
struct stat st;
void *map;
- ifd = open(filename, O_RDONLY);
+ ifd = open(source, O_RDONLY);
if (ifd < 0 || fstat(ifd, &st) < 0) {
close(ifd);
- fprintf(stderr, "cannot open %s\n", filename);
+ fprintf(stderr, "cannot open %s\n", source);
return -1;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, ifd, 0);
close(ifd);
if (map == MAP_FAILED) {
- fprintf(stderr, "cannot mmap %s\n", filename);
+ fprintf(stderr, "cannot mmap %s\n", source);
return -1;
}
- ofd = open(dest_filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ ofd = open(dest, O_WRONLY | O_CREAT | O_EXCL, 0666);
status = ((ofd < 0) ||
(write(ofd, map, st.st_size) != st.st_size));
munmap(map, st.st_size);
close(ofd);
if (status)
- fprintf(stderr, "cannot write %s\n", dest_filename);
+ fprintf(stderr, "cannot write %s\n", dest);
else
pull_say("copy %s\n", hex);
return status;
@@ -77,6 +97,56 @@ int fetch(unsigned char *sha1)
return -1;
}
+int fetch_pack(unsigned char *sha1)
+{
+ struct packed_git *target;
+ char filename[PATH_MAX];
+ if (setup_indices())
+ return -1;
+ target = find_sha1_pack(sha1, packs);
+ if (!target)
+ return error("Couldn't find %s: not separate or in any pack",
+sha1_to_hex(sha1));
+ if (get_verbosely) {
+ fprintf(stderr, "Getting pack %s\n",
+ sha1_to_hex(target->sha1));
+ fprintf(stderr, " which contain
Re: [patch] possible memory leak in diff.c::diff_free_filepair()
Yasushi SHOJI <[EMAIL PROTECTED]> writes: > parepare_temp_file() and diff_populate_filespec() has a lot in > similarity. so it'd be nice to refactor some. and re-introduce > diff_free_filespec_data() and call right after prep_temp_blob() in > prepare_temp_file(). Another thing that may (or may not) help would be to move that prepare_temp_file() and stuff to happen in the forked child process instead of the parent, so that we do not have to worry about freeing the buffer; it has been some time since I worked on that part of the code so this may not be an option to make things easier. > Junio, did you also mean to clean-up these functions when you said in > the thread of "Re: gitweb - option to disable rename detection"? No. I was talking about cleaning up the similar option parsing code, and the call into diffcore_std() which takes more arguments every time a new option is added to the family. - 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
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
After exploration of the different -k modes in the cvs protocol, we use -kk
which kills keyword expansion wherever possible. Against the protocol
spec, -ko and -kb will sometimes expand keywords.
Should improve our chances of detecting merges and reduce imported
repository size.
Signed-off: Martin Langhoff <[EMAIL PROTECTED]>
---
Documentation/git-cvsimport-script.txt |7 ++-
git-cvsimport-script | 12 +++-
2 files changed, 13 insertions(+), 6 deletions(-)
3be96ff6fee32974b66fe1743eb701e93032fee5
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-cvsimport-script' [ -o ] [ -h ] [ -v ]
[ -d ] [ -p ]
- [ -C ] [ -i ] [ ]
+ [ -C ] [ -i ] [ -k ] [ ]
DESCRIPTION
@@ -38,6 +38,11 @@ OPTIONS
ensures the working directory and cache remain untouched and will
not create them if they do not exist.
+-k::
+ Kill keywords: will extract files with -kk from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
-o ::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
sub usage() {
print STDERR <{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
- # $self->{'socketo'}->write("Argument -ko\n") or return undef;
- # -ko: Linus' version doesn't use it
+ # -kk: Linus' version doesn't use it - defaults to off
+ if ($opt_k) {
+ $self->{'socketo'}->write("Argument -kk\n") or return undef;
+ }
$self->{'socketo'}->write("Argument -r\n") or return undef;
$self->{'socketo'}->write("Argument $rev\n") or return undef;
$self->{'socketo'}->write("Argument --\n") or return undef;
-
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
Re: symlinked directories in refs are now unreachable
Matt Draisey <[EMAIL PROTECTED]> writes: > On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote: >> I would like to know >> a use case or two to illustrate why there are symlinks pointing >> at real files outside .git/refs/ hierarchy, and how that >> arrangement is useful. >... > This email is a bit long-winded so I didn't CC it to the mailing list. Thanks for a clear explanation. Your arrangement indeed is an intriguing one, in that there are very similar issues in the fsck/prune area even with arrangements quite different from yours. I personally think your reasoning about this issue deserves to be shared with the list. I'll CC _this_ message to the list and leave it up to you to forward your words there as well. People are known to do something similar to what you are doing without having any special commit tool. They just do this: $ mkdir A B $ cd A && git init-db $ cd ../B && git init-db $ rm -fr .git/objects && ln -s ../../A/.git/objects .git/objects The repositories A and B share the same object database, and they have independent sets of refs. For the exact same reason as your arrangement, you cannot "git prune" in either repository, because they do not know about objects reachable only from the other side. Further, one repository can borrow objects from another repository via the .git/objects/info/alternates mechanism. This is useful when a repository is a local clone of another. You would do this: $ git clone -l -s linux-2.6/.git/ my-linux $ cd my-linux && cat .git/objects/info/alternates /path/to/linux-2.6/.git/ The new repository my-linux has the .git/objects with 256 fan-out subdirectories, but starts out without any object files in it. It literally borrows the existing objects from the neighbouring repository, and its own .git/objects hierarchy is only used to hold newly created objects in it. For the same reason as your arrangement, you should not "git prune" the linux-2.6 repository, either. However, my-linux repository can be pruned as long as somebody else does not "borrow" from it. So while I find your "do follow symlink" patch an improvement in that it makes things a little bit safer, I think there should be a more generalized way to say "this object database holds things that are refered by these refs/ directories outside. fsck/prune had better hold onto objects referenced by them, not just by the refs directory that happens to be next to th objects directory". That would be the inverse of .git/objects/info/alternates. -jc - 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
