* Re: Git 1.0 Synopis (Draft v4)
From: Daniel Barkalow @ 2005-08-15 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7vhddr397g.fsf@assigned-by-dhcp.cox.net>
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> 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.
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*
^ permalink raw reply
* Re: gitweb - option to disable rename detection
From: Linus Torvalds @ 2005-08-15 18:53 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87d5ofoxvt.wl@mail2.atmark-techno.com>
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
^ permalink raw reply
* gitweb - option to disable rename detection
From: Yasushi SHOJI @ 2005-08-15 18:31 UTC (permalink / raw)
To: git
Hi all,
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
so here is a proposal patch to add an option to disable rename
detection on selected project.
# please bear with me! I _know_ my perl code sucks. this is just to
# show my idea.
regards,
--
yashi
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -40,6 +40,11 @@ my $home_text = "indextext.html";
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# rename detection on big change require a lot of memory. If your tree
+# has big change commit, list those project names to disable rename
+# detection. most sane project doesn't need to disable this feature.
+my $projects_disable_rename_detection = "";
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1572,6 +1577,17 @@ sub git_log {
git_footer_html();
}
+sub git_diff_tree_options {
+ my $found = 0;
+ my @list = split(/ /, $projects_disable_rename_detection);
+ foreach my $p (@list) {
+ if ($project eq $p) {
+ $found = 1;
+ }
+ }
+ $found ? "" : "-M";
+}
+
sub git_commit {
my %co = git_read_commit($hash);
if (!%co) {
@@ -1587,7 +1603,8 @@ 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 $opts = git_diff_tree_options();
+ 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();
^ permalink raw reply
* [PATCH] Fixed two bugs in git-cvsimport-script.
From: David Kågedal @ 2005-08-15 18:18 UTC (permalink / raw)
To: git; +Cc: Junio C. Hamano
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 <davidk@lysator.liu.se>
---
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 <target-dir>::
+ 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 <options-for-cvsps>::
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 <fuzz>::
+ 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(<CVS>) {
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
^ permalink raw reply
* Re: Cloning speed comparison
From: Daniel Barkalow @ 2005-08-15 17:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813015402.GC20812@pasky.ji.cz>
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-pull 660s
>
> cogito clone-pack:ssh 35s (!)
> cogito rsync 140s
> cogito ssh-pull 480s
> 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://pasky@localhost/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*
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Linus Torvalds @ 2005-08-15 16:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Martin Langhoff, GIT
In-Reply-To: <20050815080931.64F0D352633@atlas.denx.de>
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
^ permalink raw reply
* Making note, in the repository, of push/pull relationships
From: Carl Baldwin @ 2005-08-15 16:25 UTC (permalink / raw)
To: git
(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
<local branch>:<remote branch> 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 Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Carl Baldwin @ 2005-08-15 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git
In-Reply-To: <7vacjmqnu7.fsf@assigned-by-dhcp.cox.net>
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
<local branch>:<remote branch> 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 <cnb@fc.hp.com> writes:
>
> > On Fri, Jul 29, 2005 at 08:10:51AM +0000, 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
> <src> and <dst> repository, the following should do the same
> thing:
>
> On <src> repository machine, with GIT_DIR being the <src> repository:
> $ git push <dst> <ref-local-name>:<ref-remote-name>...
>
> On <dst> repository machine, with GIT_DIR being the <dst> repository:
> $ git pull <src> <ref-remote-name>:<ref-local-name>...
>
> 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 Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* [PATCH] Just run Ispell through git.txt
From: Yasushi SHOJI @ 2005-08-15 15:23 UTC (permalink / raw)
To: git
[PATCH] Just run Ispell through git.txt
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
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 <object> can also use the following
+Any git command accepting any <object> 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.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Sven Verdoolaege @ 2005-08-15 11:45 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git, Wolfgang Denk
In-Reply-To: <pan.2005.08.15.10.38.50.677503@smurf.noris.de>
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
^ permalink raw reply
* [PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
From: Martin Langhoff @ 2005-08-15 11:32 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050815113123.BDEA03300AD@ng.eduforge.org>
[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 <martin.langhoff@gmail.com>
---
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 <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 -kk 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
+ # -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;
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <46a038f9050815020511574e3d@mail.gmail.com>
On 8/15/05, Martin Langhoff <martin.langhoff@gmail.com> 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
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Matthias Urlichs @ 2005-08-15 10:38 UTC (permalink / raw)
To: git
In-Reply-To: <20050815080931.64F0D352633@atlas.denx.de>
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 | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
As crazy as hauling timber into the woods.
-- Quintus Horatius Flaccus (Horace)
^ permalink raw reply
* Re: [ANNOUNCE] qgit-0.9
From: Marco Costalba @ 2005-08-15 10:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ryan Anderson, git
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
^ permalink raw reply
* [PATCH] Add git-show-branches-script
From: Junio C Hamano @ 2005-08-15 9:56 UTC (permalink / raw)
To: git
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 <junkio@cox.net>
---
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 <reference>...'
+
+DESCRIPTION
+-----------
+Shows the head commits from the named <reference> (or all refs under
+$GIT_DIR/refs/heads), and displays concise list of commit logs
+to show their relationship semi-visually.
+
+OPTIONS
+-------
+<reference>::
+ Name of the reference under $GIT_DIR/refs/heads/.
+
+
+OUTPUT
+------
+Given N <references>, 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 <junkio@cox.net>
+
+
+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
^ permalink raw reply
* [PATCH] Audit rev-parse users.
From: Junio C Hamano @ 2005-08-15 9:55 UTC (permalink / raw)
To: git
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 <junkio@cox.net>
---
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
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Martin Langhoff @ 2005-08-15 9:48 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.15.09.07.10.118103@smurf.noris.de>
On 8/15/05, Matthias Urlichs <smurf@smurf.noris.de> 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
^ permalink raw reply
* Re: [ANNOUNCE] qgit-0.9
From: Martin Langhoff @ 2005-08-15 9:41 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Marco Costalba, git
In-Reply-To: <20050814115834.GD6844@mythryan2.michonline.com>
> 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
^ permalink raw reply
* [PATCH] cvsgit fixes: spaces in filenames and CVS server dialog woes
From: Matthias Urlichs @ 2005-08-15 9:28 UTC (permalink / raw)
To: git
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(<CVS>) {
$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 | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Let he who takes the plunge remember to return it by Tuesday.
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Catalin Marinas @ 2005-08-15 9:27 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <42FEBC16.9050309@austin.rr.com>
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 <smfrench@austin.rr.com> 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 <name>'), 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
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Matthias Urlichs @ 2005-08-15 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0508141937251.3553@g5.osdl.org>
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 | smurf@smurf.noris.de
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
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-15 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7cv1t89.fsf@assigned-by-dhcp.cox.net>
On 8/15/05, Junio C Hamano <junkio@cox.net> 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
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Matt Draisey @ 2005-08-15 9:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x4v4pfx.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-08-15 at 00:41 -0700, Junio C Hamano wrote:
> Matt Draisey <mattdraisey@sympatico.ca> 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)
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Catalin Marinas @ 2005-08-15 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7vfytc9dzw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> 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.
Have been on holiday and couldn't reply. I will follow up.
--
Catalin
^ 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