* Git 1.0 Synopis (Draft v4)
From: Ryan Anderson @ 2005-08-15 4:55 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Junio C Hamano
In-Reply-To: <200507312215.j6VMFeqn030963@laptop11.inf.utfsm.cl>
On Sun, Jul 31, 2005 at 06:15:40PM -0400, Horst von Brand wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git
>
> More bugging...
Ok, I think I've got all this addressed (plus the other email).
It just took me a lot longer to get to it than I planned.
Junio, do you want to pull this into the git tree? (I'll reply with a
patch)
==========
Source Code Management with git
In Linus's own words as the creator of git:
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
git is a "directory content manager". git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o The core git project considers itself to provide "plumbing" for other
projects, as well as to serve to arbitrate for compatibility between them.
The project built on top of the core git are referred to as "porcelain".
Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
tools, and providing an easy to use interface to various pieces of
functionality.
o Some other projects have taken the concepts from the core git project, and
are either porting an existing toolset to use the git tools, or
reimplementing the concepts internally, to benefit from the performance
improvements. This includes both Arch 2.0, and Darcs-git.
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves space and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Debian packages should be availabe in unstable (sid) as "git-core"
Or via git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
(rsync is generally faster for an initial clone, you can switch later
by editing .git/branches/origin and changing the url)
To get the 'Porcelain' tools mentioned above:
SCM Interface layers:
cogito - http://www.kernel.org/pub/software/scm/cogito/
Patch Management (similar to Quilt):
StGIT - http://www.procode.org/stgit/
History Visualization:
gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
distribution)
gitweb - http://www.kernel.org/pub/software/scm/gitweb/
qgit - http://sourceforge.net/projects/qgit
git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
git development takes place on the git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Ryan Anderson @ 2005-08-15 5:08 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: David Lang, git
In-Reply-To: <20050814001148.GV5411@kiste.smurf.noris.de>
On Sun, Aug 14, 2005 at 02:11:50AM +0200, Matthias Urlichs wrote:
> Hi,
>
> Ryan Anderson:
> >
> > #!/bin/sh
> > echo "Don't get a git - use gt!
> Ouch.
:) I meant it as a joke, obviously. I also thinkoed the sentence I was
aiming for, thus losing the humor. Oh well.
> > echo "Don't get a git - use gt!" >&2
> if at all.
True.
On this same topic, cogito seems to be consistently using the long forms
of the names (i.e, git-*-script), so renaming "git" in the core Debian
package should not be a problem, other than for the canned recipes
people are writing constantly to demonstrate the power of git.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Ryan Anderson @ 2005-08-15 5:09 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Junio C Hamano
In-Reply-To: <20050815045546.GA7001@mythryan2.michonline.com>
Add a SYNOPSIS/release summary to the tree.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
diff --git a/SYNOPSIS b/SYNOPSIS
new file mode 100644
--- /dev/null
+++ b/SYNOPSIS
@@ -0,0 +1,93 @@
+Source Code Management with git
+
+In Linus's own words as the creator of git:
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+ actually used by any common UNIX command. The fact that it is a
+ mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+ dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+ works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+git is a "directory content manager". git has been designed to handle
+absolutely massive projects with speed and efficiency, and the release of the
+2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
+does this task well.
+
+git falls into the category of distributed source code management tools,
+similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every git
+working directory is a full-fledged repository with full revision tracking
+capabilities, not dependent on network access to a central server.
+
+git provides a content-addressable pseudo filesystem, complete with its own
+version of fsck.
+
+ o Speed of use, both for the project maintainer, and the end-users, is
+ a key development principle.
+
+ o The history is stored as a directed acyclic graph, making long-lived
+ branches and repeated merging simple.
+
+ o The core git project considers itself to provide "plumbing" for other
+ projects, as well as to serve to arbitrate for compatibility between them.
+ The project built on top of the core git are referred to as "porcelain".
+ Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
+ tools, and providing an easy to use interface to various pieces of
+ functionality.
+
+ o Some other projects have taken the concepts from the core git project, and
+ are either porting an existing toolset to use the git tools, or
+ reimplementing the concepts internally, to benefit from the performance
+ improvements. This includes both Arch 2.0, and Darcs-git.
+
+ o Two, interchangeable, on-disk formats are used:
+ o An efficient, packed format that saves space and network
+ bandwidth.
+ o An unpacked format, optimized for fast writes and incremental
+ work.
+
+To get a copy of git:
+ Daily snapshots are available at:
+ http://www.codemonkey.org.uk/projects/git-snapshots/git/
+ (Thanks to Dave Jones)
+
+ Source tarballs and RPMs at:
+ http://www.kernel.org/pub/software/scm/git/
+
+ Debian packages should be availabe in unstable (sid) as "git-core"
+
+ Or via git itself:
+ git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
+ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
+
+ (rsync is generally faster for an initial clone, you can switch later
+ by editing .git/branches/origin and changing the url)
+
+To get the 'Porcelain' tools mentioned above:
+ SCM Interface layers:
+ cogito - http://www.kernel.org/pub/software/scm/cogito/
+
+ Patch Management (similar to Quilt):
+ StGIT - http://www.procode.org/stgit/
+
+ History Visualization:
+ gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
+ distribution)
+ gitweb - http://www.kernel.org/pub/software/scm/gitweb/
+ qgit - http://sourceforge.net/projects/qgit
+
+
+git distributions contain a tutorial in the Documentation subdirectory.
+Additionally, the Kernel-Hacker's git Tutorial at
+http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
+that document)
+
+git development takes place on the git mailing list. To subscribe, send an
+email with just "subscribe git" in the body to majordomo@vger.kernel.org.
+Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
+
+(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
+with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Junio C Hamano @ 2005-08-15 5:12 UTC (permalink / raw)
To: Matt Draisey; +Cc: git
In-Reply-To: <1124073677.27393.15.camel@della.draisey.ca>
Matt Draisey <mattdraisey@sympatico.ca> 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. 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.
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Junio C Hamano @ 2005-08-15 5:19 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050815045546.GA7001@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Junio, do you want to pull this into the git tree?
Yes, but I have been wondering where it should go. Should it go
under Documentation/ and made into html via asciidoc along with
other tools?
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Ryan Anderson @ 2005-08-15 6:35 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <20050814040233.GC6844@mythryan2.michonline.com>
On Sun, Aug 14, 2005 at 12:02:33AM -0400, Ryan Anderson wrote:
> On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:
>
> > 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).
>
> No, a commit is immutable. You can use "git format-patch" to rebase things if
> you need. I prefer to use "git format-patch --mbox", edit what I need
> to, then use git-applymbox to rebase it all against a clean tree.
Note (and I should have said this at first), doing it this way gives you
the opportunity to combine a few changes if you want.
Use git-format-patch-script to pull out what you want, delete the diff
from the bottom of the file, manually diff what you need using
git-diff-script, and stick that back at the end of the file
git-format-patch-script created.
This seems to be the easiest way to clean up your change history.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 6:51 UTC (permalink / raw)
To: GIT
[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 <martin.langhoff@gmail.com>
---
Documentation/git-cvsimport-script.txt | 7 ++++++-
git-cvsimport-script | 10 ++++++----
2 files changed, 12 insertions(+), 5 deletions(-)
f0b33908e48ac75a1e3f08a3e3159de3a9a371d9
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 <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ -k ] [ <CVS_module> ]
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 <branch-for-HEAD>::
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
@@ -35,12 +35,12 @@ sub usage() {
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ -i ] [ CVS_module ]
+ [ -i ] [ -k ] [ CVS_module ]
END
exit(1);
}
-getopts("hivo:d:p:C:z:") or usage();
+getopts("hivko:d:p:C:z:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -218,8 +218,10 @@ sub _file {
my($self,$fn,$rev) = @_;
$self->{'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;
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 6:56 UTC (permalink / raw)
To: GIT
In-Reply-To: <46a038f9050814235140877be7@mail.gmail.com>
On 8/15/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> [PATCH] Add -k kill keyword expansion option to git-cvsimport
Bad patch! Please ignore while I fix and resend...
apologies.
martin
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Ryan Anderson @ 2005-08-15 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7cv7p61.fsf@assigned-by-dhcp.cox.net>
On Sun, Aug 14, 2005 at 10:19:18PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > Junio, do you want to pull this into the git tree?
>
> Yes, but I have been wondering where it should go. Should it go
> under Documentation/ and made into html via asciidoc along with
> other tools?
I was somewhat thinking it should go in the main directory, and be a
useful introduction to the project for people.... but it's not really
aimed at that very well, now that I think about it.
To be fair, it's not really aimed well at being documentation for people
that already have git, either. I've been writing it with the idea of
"something to send to LWN when 1.0 happens so they can post it mostly
verbatim."
I guess this means, "I dunno, either place works for me."
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 7:10 UTC (permalink / raw)
To: GIT
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 <martin.langhoff@gmail.com>
---
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 <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ -k ] [ <CVS_module> ]
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 <branch-for-HEAD>::
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 <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ -i ] [ CVS_module ]
+ [ -i ] [ -k ] [ CVS_module ]
END
exit(1);
}
-getopts("hivo:d:p:C:z:") or usage();
+getopts("hivko:d:p:C:z:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -218,8 +218,10 @@ sub _file {
my($self,$fn,$rev) = @_;
$self->{'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;
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Junio C Hamano @ 2005-08-15 7:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f9050814235140877be7@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> 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?
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Junio C Hamano @ 2005-08-15 7:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050815065833.GE7001@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> 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 corbet@lwn.net" ;-).
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.
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6in65dp.fsf@assigned-by-dhcp.cox.net>
On 8/15/05, Junio C Hamano <junkio@cox.net> 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
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Junio C Hamano @ 2005-08-15 7:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90508150037f128d6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> 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?
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvf273aqb.fsf@assigned-by-dhcp.cox.net>
On 8/15/05, Junio C Hamano <junkio@cox.net> 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
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Ryan Anderson @ 2005-08-15 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jen6545.fsf@assigned-by-dhcp.cox.net>
On Mon, Aug 15, 2005 at 12:17:46AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> 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 corbet@lwn.net" ;-).
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
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Matt Draisey @ 2005-08-15 8:07 UTC (permalink / raw)
To: Junio C Hamano
In-Reply-To: <7v64u7941c.fsf@assigned-by-dhcp.cox.net>
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
> Matt Draisey <mattdraisey@sympatico.ca> 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.
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Matt Draisey @ 2005-08-15 8:12 UTC (permalink / raw)
To: git-list
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
> Matt Draisey <mattdraisey@sympatico.ca> 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.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Sven Verdoolaege @ 2005-08-15 8:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, GIT
In-Reply-To: <Pine.LNX.4.58.0508141937251.3553@g5.osdl.org>
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
^ permalink raw reply
* [PATCH] Add documentation for git repack and git-prune-packed.
From: Ryan Anderson @ 2005-08-15 8:16 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Ryan Anderson
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
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 <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+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 <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+See-Also
+--------
+git-pack-objects(1) git-prune-packed(1)
+
+GIT
+---
+Part of the link:git.html[git] suite
+
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Junio C Hamano @ 2005-08-15 8:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050815080218.GG7001@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> 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.
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Junio C Hamano @ 2005-08-15 8:18 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90508150037f128d6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> 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<any> => cvs default
cvsimport -k == cvsimport -ko => use cvs -ko
cvsimoprt -kv => use cvs -kv
^ permalink raw reply
* [PATCH] Add some simple howtos, culled from the mailing list.
From: Ryan Anderson @ 2005-08-15 8:25 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Ryan Anderson
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 <ryan@michonline.com>
---
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 <torvalds@osdl.org>
+To: Dave Jones <davej@redhat.com>
+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":
+
+ [torvalds@g5 ~]$ 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 <torvalds@osdl.org>
+To: Steve French <smfrench@austin.rr.com>
+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 everything looks sensible.
+
+And then, you can just remove the broken branch if you decide you really
+don't want it:
+
+ # remove 'broken' branch
+ rm .git/refs/heads/broken
+
+ # Prune old objects if you're really really sure
+ git prune
+
+And yeah, I'm sure there are other ways of doing this. And as usual, the
+above is totally untested, and I just wrote it down in this email, so if
+I've done something wrong, you'll have to figure it out on your own ;)
+
+ Linus
+-
+To unsubscribe from this list: send the line "unsubscribe git" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
+
+
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -0,0 +1,163 @@
+From: Junio C Hamano <junkio@cox.net>
+To: git@vger.kernel.org
+Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
+Subject: Re: sending changesets from the middle of a git tree
+Date: Sun, 14 Aug 2005 18:37:39 -0700
+
+Petr Baudis <pasky@suse.cz> writes:
+
+> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
+> where Junio C Hamano <junkio@cox.net> told me that...
+>> Linus Torvalds <torvalds@osdl.org> 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.
+
+I just have done a simpler one, this time using only the core
+GIT tools.
+
+I had a handful commits that were ahead of master in pu, and I
+wanted to add some documentation bypassing my usual habit of
+placing new things in pu first. At the beginning, the commit
+ancestry graph looked like this:
+
+ *"pu" head
+ master --> #1 --> #2 --> #3
+
+So I started from master, made a bunch of edits, and committed:
+
+ $ git checkout master
+ $ cd Documentation; ed git.txt git-apply-patch-script.txt ...
+ $ cd ..; git add Documentation/*.txt
+ $ git commit -s -v
+
+NOTE. The -v flag to commit is a handy way to make sure that
+your additions are not introducing bogusly formatted lines.
+
+After the commit, the ancestry graph would look like this:
+
+ *"pu" head
+ master^ --> #1 --> #2 --> #3
+ \
+ \---> master
+
+The old master is now master^ (the first parent of the master).
+The new master commit holds my documentation updates.
+
+Now I have to deal with "pu" branch.
+
+This is the kind of situation I used to have all the time when
+Linus was the maintainer and I was a contributor, when you look
+at "master" branch being the "maintainer" branch, and "pu"
+branch being the "contributor" branch. Your work started at the
+tip of the "maintainer" branch some time ago, you made a lot of
+progress in the meantime, and now the maintainer branch has some
+other commits you do not have yet. And "git rebase" was written
+with the explicit purpose of helping to maintain branches like
+"pu". You _could_ merge master to pu and keep going, but if you
+eventually want to cherrypick and merge some but not necessarily
+all changes back to the master branch, it often makes later
+operations for _you_ easier if you rebase (i.e. carry forward
+your changes) "pu" rather than merge. So I ran "git rebase":
+
+ $ git checkout pu
+ $ git rebase master pu
+
+What this does is to pick all the commits since the current
+branch (note that I now am on "pu" branch) forked from the
+master branch, and forward port these changes.
+
+ master^ --> #1 --> #2 --> #3
+ \ *"pu" head
+ \---> master --> #1' --> #2' --> #3'
+
+The diff between master^ and #1 is applied to master and
+committed to create #1' commit with the commit information (log,
+author and date) taken from commit #1. On top of that #2' and #3'
+commits are made similarly out of #2 and #3 commits.
+
+Old #3 is not recorded in any of the .git/refs/heads/ file
+anymore, so after doing this you will have dangling commit if
+you ran fsck-cache, which is normal. After testing "pu", you
+can run "git prune" to get rid of those original three commits.
+
+While I am talking about "git rebase", I should talk about how
+to do cherrypicking using only the core GIT tools.
+
+Let's go back to the earlier picture, with different labels.
+
+You, as an individual developer, cloned upstream repository and
+amde a couple of commits on top of it.
+
+ *your "master" head
+ upstream --> #1 --> #2 --> #3
+
+You would want changes #2 and #3 incorporated in the upstream,
+while you feel that #1 may need further improvements. So you
+prepare #2 and #3 for e-mail submission.
+
+ $ git format-patch master^^ master
+
+This creates two files, 0001-XXXX.txt and 0002-XXXX.txt. Send
+them out "To: " your project maintainer and "Cc: " your mailing
+list. You could use contributed script git-send-email-script if
+your host has necessary perl modules for this, but your usual
+MUA would do as long as it does not corrupt whitespaces in the
+patch.
+
+Then you would wait, and you find out that the upstream picked
+up your changes, along with other changes.
+
+ where *your "master" head
+ upstream --> #1 --> #2 --> #3
+ used \
+ to be \--> #A --> #2' --> #3' --> #B --> #C
+ *upstream head
+
+The two commits #2' and #3' in the above picture record the same
+changes your e-mail submission for #2 and #3 contained, but
+probably with the new sign-off line added by the upsteam
+maintainer and definitely with different committer and ancestry
+information, they are different objects from #2 and #3 commits.
+
+You fetch from upstream, but not merge.
+
+ $ git fetch upstream
+
+This leaves the updated upstream head in .git/FETCH_HEAD but
+does not touch your .git/HEAD nor .git/refs/heads/master.
+You run "git rebase" now.
+
+ $ git rebase FETCH_HEAD master
+
+Earlier, I said that rebase applies all the commits from your
+branch on top of the upstream head. Well, I lied. "git rebase"
+is a bit smarter than that and notices that #2 and #3 need not
+be applied, so it only applies #1. The commit ancestry graph
+becomes something like this:
+
+ where *your old "master" head
+ upstream --> #1 --> #2 --> #3
+ used \ your new "master" head*
+ to be \--> #A --> #2' --> #3' --> #B --> #C --> #1'
+ *upstream
+ head
+
+Again, "git prune" would discard the disused commits #1-#3 and
+you continue on starting from the new "master" head, which is
+the #1' commit.
+
+-jc
+
+-
+To unsubscribe from this list: send the line "unsubscribe git" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
+
+
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Wolfgang Denk @ 2005-08-15 8:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, GIT
In-Reply-To: <Pine.LNX.4.58.0508141737270.3553@g5.osdl.org>
In message <Pine.LNX.4.58.0508141737270.3553@g5.osdl.org> 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: wd@denx.de
"The number of Unix installations has grown to 10, with more
expected." - The Unix Programmer's Manual, 2nd Edition, June, 1972
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Junio C Hamano @ 2005-08-15 8:48 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905081501301bd9a801@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> 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.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox