* Re: Pull request for sub-tree merge into /contrib/gitstats
From: David Symonds @ 2008-11-03 7:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, sverre, git
In-Reply-To: <alpine.DEB.1.00.0811030729071.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sun, Nov 2, 2008 at 11:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Actually, I suggested that the end result be submitted as a single patch
> against contrib/, but dsymonds objected that that would lose all history,
> and I concurred that it would be nice to have all changes with the design
> decisions recorded as commit messages, too.
I chatted to Sverre separately, and I think we concluded that we could
probably just do a single patch (no history, no changelogs, etc.), and
just point to the complete git-stats.git repo for folk who want the
detail.
Dave.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-03 7:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Björn Steinbrink, Johannes Schindelin, David Symonds, git,
Stephan Beyer
In-Reply-To: <7vljw2yo93.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 10:30:16AM -0800, Junio C Hamano wrote:
> > Looking at --cached/--index we have basically three things:
> >
> > --cached to refer to the state of the index (diff, grep, [stash], ...)
> > --cached to _work on_ the index only (rm, apply, ...)
> > --index to _work on_ both the index and the working tree (apply, ...)
>
> I think the earlier two are the same thing. The only difference between
> them is that in the first one, the definition of your "work on" happens to
> be a read-only operation. Am I mistaken?
I think that is somewhat the case for "grep", for example. But the
confusion is that diff is really a different beast, because you are
comparing two _different_ locations.
So "git diff --staged", while it makes sense to us (since we are asking
"what is staged"), is not consistent with the discussed rules. In
particular:
1. It operates on just the "stage" and not the working tree, so it
should be "--staged-only". But the only there is nonsensical.
2. The default is _already_ operating on the staging area, so you are
really switching up the working tree for the HEAD in what you are
diffing. So in that sense, it doesn't convey the change in
operation very well.
And I am not proposing a change here (except to perhaps "git diff
--staged" instead of "--cached"). Just pointing out that it does not
follow the "--staged operates on both, --staged-only operates on just
the index" rule.
Hrm. For that matter, grep is a bit different, too. Since I would expect
"git grep --staged" to find only staged things, not things in both the
working tree and the index. So perhaps there is a difference between
commands that modify and commands that inspect.
-Peff
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: Sverre Rabbelier @ 2008-11-03 8:40 UTC (permalink / raw)
To: David Symonds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <ee77f5c20811022307r59dc4d09m20551a339a2993ea@mail.gmail.com>
On Mon, Nov 3, 2008 at 08:07, David Symonds <dsymonds@gmail.com> wrote:
> I chatted to Sverre separately, and I think we concluded that we could
> probably just do a single patch (no history, no changelogs, etc.), and
> just point to the complete git-stats.git repo for folk who want the
> detail.
Either is fine with me, anything to get more exposure is fine with me :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 8:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Nicolas Pitre
In-Reply-To: <200810310836.02908.jnareb@gmail.com>
On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
> > > git checkout --track origin/wr34251-do-something
> >
> > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
> > too verbose.
>
> Well, either you have a little bit more verbose, or you have to have
> some DWIM-mery, which (as usual with DWIM) can go wrong.
That's right, you need to choose when to assume that the user meant
something that they didn't write very carefully.
But look at this:
git checkout origin/master
git checkout -t origin/master
The option is called "--track", yet in this case what it actually means
in the default situation where you have autosetupmerge (or whatever it's
really called) set to true, is that it modifies the command to imply "-b
master". So, in this situation, that is clearly what was meant.
Perhaps you can give an example of why this particular piece of DWIM
might not be WYM?
Sam.
^ permalink raw reply
* Re: error: non-monotonic index
From: Pierre Habouzit @ 2008-11-03 8:51 UTC (permalink / raw)
To: Peter Teoh; +Cc: git
In-Reply-To: <804dabb00811021832k28276bf7ke0146a8bbd648574@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
On Mon, Nov 03, 2008 at 02:32:44AM +0000, Peter Teoh wrote:
> I git pull and got errors, then git repack and pull again......the
> error increased....what happened?
what is your local git version and the remote one ?
It's likely that your local git is not aware of packs v2 which is now
default. You want to upgrade your local git, if you're on Debian etch,
updates have been pushed in the last dot release. Or you can even use
git-core from backports.org which is even more up to date (1.6.sth I
guess).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Pierre Habouzit @ 2008-11-03 8:53 UTC (permalink / raw)
To: Ian Hilt; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0811021629110.25369@sys-0.hiltweb.site>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Sun, Nov 02, 2008 at 09:34:53PM +0000, Ian Hilt wrote:
> On Sun, 2 Nov 2008, Pierre Habouzit wrote:
> > On Sun, Nov 02, 2008 at 06:18:08AM +0000, Junio C Hamano wrote:
> > > Having said that, if we were to do this, let's do it the right way and put
> > > these "temporary" files under $GIT_DIR.
> >
> > Agreed, I should have done that.
>
> Perhaps like this:
>
> my $compose_filename = $repo->repo_path() . "/sendemail.msg.$$";
>
> where $repo is a repository instance.
$repo is a repository instance, I'm waiting for all the comments to fade
up to take them into account and resend a proper series.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: .gitattributes glob matching broken
From: Jeff King @ 2008-11-03 9:09 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83od0yaxzk.fsf@kalahari.s2.org>
On Sun, Nov 02, 2008 at 06:33:51PM +0200, Hannu Koivisto wrote:
> It seems that, for example, glob pattern *.s matches files with .sh
> extension at least with checkout and reset --hard but git status
> thinks otherwise:
I think your analysis is incorrect. I will try to explain what is
happening.
> mkdir test
> cd test
> git init
> echo -e "*.sh -crlf\n*.s crlf" > .gitattributes
> echo -e "foobar\nfoobar\nfoobar" > kala.s
> echo -e "foobar\nfoobar\nfoobar" > kala.sh
> git add .gitattributes kala.s kala.sh
> git commit -m "Foo."
OK, so here we have two files, one of which we are telling git is text
and one of which we are telling git is not text. Since we don't have
autocrlf set at all, of course nothing happens here.
> git clone -n test test2
And here we clone without checking out, so there are no files yet.
> cd test2
> git config core.autocrlf true
> git checkout
And now we do check out the files, with autocrlf applied. But what are
we left with? When I run this, _both_ files were detected as text and
have CRLF line endings. So here I think is where git didn't do what you
expected: kala.sh should not have had CRLF conversion applied.
This is a known limitation of the attributes mechanism: it only reads
from .gitattributes in the filesystem (or from .git/info/attributes),
and not from the tree that is being checked out. This is something that
should be addressed, but nobody has stepped up with a patch yet (though
there has been some preliminary discussion).
> git status
>
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> # directory)
> #
> # modified: kala.sh
> #
> no changes added to commit (use "git add" and/or "git commit -a")
So yes, this status makes perfect sense, then. The file "kala.sh" has
CRLFs in the filesystem, but we have told git that it is not a file
which gets converted. So it looks like those CRs have been added.
The problem, again, is that we have inconsistently applied the
gitattributes. They were _not_ applied during checkout (because
.gitattributes did not exist yet), but they _are_ being applied here.
To "fix" this, you can then do a "git reset --hard" which will respect
your .gitattributes (since it is now checked out). And further file
creation and checkout should work OK.
-Peff
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Pierre Habouzit @ 2008-11-03 9:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081102180220.GA5726@sigio.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]
On Sun, Nov 02, 2008 at 06:02:21PM +0000, Jeff King wrote:
> On Sun, Nov 02, 2008 at 10:39:07AM +0100, Pierre Habouzit wrote:
>
> > Well it still messes the file/reference name conflict with no way to
> > prevent it because of the backward compatibility, and even if unlikely
> > it's still possible.
>
> Hmm. As Junio mentioned, this is really an easier way of doing:
>
> git format-patch -o tmp "$@"
> $EDITOR tmp/*
> git send-email tmp
>
> So I guess a wrapper program would suffice, that just called send-email.
> But of course then you would have to think of a new name, and explain
> the confusion between it and send-email.
Well that defeats the purpose of fixing send-email to me. I really would
like to see this fixed properly like it should. I mean it makes sense to
me to use _three_ commands where one should be enough. Not to mention
that introducing a new command is just completely against the spirit of
*simplifying* the current UI ;)
Actually I see a few possibilities.
(1) The first one is to pass a --[no]-format-patch flag to
git-send-email which says that it should understand arguments as
format-patch arguments. You add to that a sendemail.format-patch
setting that would default to false for backward compatibility sake,
that would allow the user to force --format-patch as a default.
This would e.g. cleanly allow: git send-email --format-patch -3 HEAD.
I would understand if people dislike the setting: it basically
modifies the behaviour of a git command a lot, which has been
frowned upon in the past. Even though I would argue than using
git-send-email in scripting is quite bad, for something that you can
probably replace with:
while read patchname; do mail some@where.org < $patchname; done < git format-patch "$@"
But if people think it's too dangerous, replacing it with a short
switch so that it's not too painful to use would fly for me,
something like -F or whatever.
(2) Another way is to add a --pass-to-format-patch kind of option that
would take its arguments and pass it to git-format-patch. Like in:
git send-email --pass-to-format-patch "-3 HEAD". (Of course a short
switch would help ;p).
(3) Use -- for mandatory separating <format-patch> arguments like this:
git send-email [send-email options] -- -3 HEAD
or if you want to send patches that would modify only a given path:
git send-email [s-e options] -- origin/next.. -- git-gui
that would run internally:
git format-patch origin/next.. -- git-gui
I would say that I dislike (2) a LOT because it's a pain to use: needs a
lot of quoting, and it gets worse if you want to pass things with spaces
in it to format-patch.
(2) has the small drawback of not being 100% backward compatible: with
the current use of perl Getoptions, -- is used to stop options
processing, and people _may_ have used it to do `git s-e -- --my.patch`
and such a use would break. However this is highly unlikely to cause
issues in real life I think (unlike the problem of refs against filename
clashes).
In (1) people may dislike the idea of a setting, I've not strong
feelings about it, I won't mind if it gets rejected, a short switch will
do just fine then.
As a summary, I'd say that I like both (1) and (3) because those are
handy, short, and either completely or mostly backward compatible. My
way would be to go down (1) and add a alias.s-e = !git send-email -F in
my .gitconfig.
What do you think ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-11-03 9:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
Yes, but it's broken in the sense that if you're in a non matching
branch it creates it remotely. The way to configure it is to say
remote.push = HEAD in your .gitconfig or sth similar. I removed it
because I've created 2 times a new branch remotely that I didn't want to
because I was tired and forgot to checkout and merge into the proper
one.
I rarely do mistakes with git, but something like more than half of my
mistakes are with push. I've argued that in the past, I know most of the
other core git developers disagree with the fact that git-push UI is not
helping users to not shoot themselves in the foot, I disagree, but there
is not much I can do if I'm 1:10 to think that ;)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-11-03 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pasky, srabbelier
In-Reply-To: <7viqr5wgl7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
On Mon, Nov 03, 2008 at 04:58:44AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > +case "$prune_empty,$filter_commit" in
> > +',')
> > + filter_commit='git commit-tree "$@"';;
> > +'t,')
> > + filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
> > +','*)
> > + ;;
> > +*)
> > + die "Cannot set --prune-empty and --filter-commit at the same time"
> > +esac
>
> This is only style issue, but I find the above extremely difficult to
> read. If it were either:
>
> case ... in
> ,) do "neither set case" ;;
> t,) do "prune but not filter case" ;;
> *) do "both set case" ;;
> esac
>
> or (rather amateurish but conveys what it wants to do more clearly):
>
> case ... in
> '','') do "neither set case" ;;
> t,'') do "prune but not filter case" ;;
> t,t) do "both set case" ;;
> esac
>
> I wouldn't have to wonder which sq pairs with which one.
agreed.
> > diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> > index b0a9d7d..352b56b 100755
> > --- a/t/t7003-filter-branch.sh
> > +++ b/t/t7003-filter-branch.sh
> > @@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
> > test_cmp expect actual
> > '
> >
> > +test_expect_success 'Prune empty commits' '
> > + make_commit to_remove &&
> > + (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
>
> I am not sure what this one is doing.
>
> - Isn't this the same as "git rev-list HEAD^"?
> - Do you need a subshell?
The filter-branch is supposed to prune the last commit done (current
HEAD) from the revision list. So I build the rev-list we're supposed to
have in the end, and remove the matching ref from it. I don't see how to
avoid the subshell though, but if someone knows better please do :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-cvsimport.perl: use human readable names for option values
From: Francis Galiegue @ 2008-11-03 9:31 UTC (permalink / raw)
To: git
Hello,
As I am keen to make my company use git eventually, but they have a really,
really messy CVS tree that git-cvs*.perl cannot handle right now, I've
decided to have a serious look at the code.
But if others want to have a look at the code, I think it should be made a
little more readable first, hence this patch.
Comments? In particular, I'm thinking about the option names, maybe some are
not in sync with what git internal really are.
---
git-cvsimport.perl: use human readable names for option values
It has reclaimed to rewrite the read_repo_config() function as well, but the
good thing is that "no strcit 'refs'" is gone too.
---
git-cvsimport.perl | 244
++++++++++++++++++++++++++++++++--------------------
1 files changed, 150 insertions(+), 94 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e439202..b9a552f 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,51 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,
$opt_P, $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
+#
+# Option values
+#
+my $help = undef; # -h
+my $branch_for_head = undef; # -o
+my $verbose = undef; # -v
+my $cvs_kill_keywords = undef; # -k
+my $convert_underscores = undef; # -u
+my $cvsroot = undef; # -d
+my $cvsps_options = undef; # -p
+my $git_repos_root = undef; # -C
+my $cvsps_fuzz = undef; # -z
+my $import_only = undef; # -i
+my $cvsps_output_file = undef; # -P
+my $branch_subst = undef, # -s
+my $detect_merges = undef; # -m
+my @more_merge_regexes = (); # -M
+my $author_conv_file = undef; # -A
+my $skip_paths = undef; # -S
+my $commit_limits = undef; # -L
+my $all_commits = undef; # -a
+my $remote_path = undef; # -r
+
+my %options = (
+ "h" => \$help,
+ "o=s" => \$branch_for_head,
+ "v" => \$verbose,
+ "k" => \$cvs_kill_keywords,
+ "u" => \$convert_underscores,
+ "d=s" => \$cvsroot,
+ "p=s" => \$cvsps_options,
+ "C=s" => \$git_repos_root,
+ "z=s" => \$cvsps_fuzz,
+ "i" => \$import_only,
+ "P=s" => \$cvsps_output_file,
+ "s=s" => \$branch_subst,
+ "m" => \$detect_merges,
+ "M=s" => \@more_merge_regexes,
+ "A=s" => \$author_conv_file,
+ "S=s" => \$skip_paths,
+ "L=s" => \$commit_limits,
+ "a" => \$all_commits,
+ "r=s" => \$remote_path
+);
+
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -88,37 +132,48 @@ sub write_author_info($) {
close ($f);
}
-# convert getopts specs for use by git config
-sub read_repo_config {
- # Split the string between characters, unless there is a ':'
- # So "abc:de" becomes ["a", "b", "c:", "d", "e"]
- my @opts = split(/ *(?!:)/, shift);
- foreach my $o (@opts) {
- my $key = $o;
- $key =~ s/://g;
- my $arg = 'git config';
- $arg .= ' --bool' if ($o !~ /:$/);
-
- chomp(my $tmp = `$arg --get cvsimport.$key`);
- if ($tmp && !($arg =~ /--bool/ && $tmp eq 'false')) {
- no strict 'refs';
- my $opt_name = "opt_" . $key;
- if (!$$opt_name) {
- $$opt_name = $tmp;
- }
+sub read_repo_config ()
+{
+ my @option_keys = keys %options;
+
+ while (my ($opt, $ref) = each %options) {
+ my $key = $opt;
+ my $is_boolean = 0;
+ my $cmd = "git config";
+ unless ($key =~ s/=s$//) {
+ $is_boolean = 1;
+ $cmd .= " --bool";
+ }
+ $cmd .= " cvsimport.$key";
+
+ chomp(my $tmp = qx/$cmd/);
+ $tmp or next;
+
+ if (ref($ref) eq "ARRAY") {
+ #
+ # FIXME: unhandled...
+ # However this could be handled by splitting $tmp with
+ # /\s*,\s*/ and pusing the result into @$ref (for the -M
+ # option)
+ #
+ next;
+ }
+
+ if ($is_boolean) {
+ $$ref = ("$tmp" eq "true") ? 1 : 0;
+ } else {
+ $$ref = "$tmp";
}
}
}
-my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
-read_repo_config($opts);
+
+read_repo_config();
Getopt::Long::Configure( 'no_ignore_case', 'bundling' );
-# turn the Getopt::Std specification in a Getopt::Long one,
-# with support for multiple -M options
-GetOptions( map { s/:/=s/; /M/ ? "$_\@" : $_ } split( /(?!:)/, $opts ) )
- or usage();
-usage if $opt_h;
+GetOptions(%options) or usage();
+
+usage() if $help;
if (@ARGV == 0) {
chomp(my $module = `git config --get cvsimport.module`);
@@ -126,31 +181,32 @@ if (@ARGV == 0) {
}
@ARGV <= 1 or usage("You can't specify more than one CVS module");
-if ($opt_d) {
- $ENV{"CVSROOT"} = $opt_d;
+if ($cvsroot) {
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif (-f 'CVS/Root') {
open my $f, '<', 'CVS/Root' or die 'Failed to open CVS/Root';
- $opt_d = <$f>;
- chomp $opt_d;
+ $cvsroot = <$f>;
+ chomp $cvsroot;
close $f;
- $ENV{"CVSROOT"} = $opt_d;
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif ($ENV{"CVSROOT"}) {
- $opt_d = $ENV{"CVSROOT"};
+ $cvsroot = $ENV{"CVSROOT"};
} else {
usage("CVSROOT needs to be set");
}
-$opt_s ||= "-";
-$opt_a ||= 0;
+$branch_subst ||= "-";
+$all_commits ||= 0;
-my $git_tree = $opt_C;
+my $git_tree = $git_repos_root;
$git_tree ||= ".";
my $remote;
-if (defined $opt_r) {
- $remote = 'refs/remotes/' . $opt_r;
- $opt_o ||= "master";
+
+if (defined $remote_path) {
+ $remote = 'refs/remotes/' . $remote_path;
+ $branch_for_head ||= "master";
} else {
- $opt_o ||= "origin";
+ $branch_for_head ||= "origin";
$remote = 'refs/heads';
}
@@ -168,11 +224,11 @@ if ($#ARGV == 0) {
}
our @mergerx = ();
-if ($opt_m) {
+if ($detect_merges) {
@mergerx = ( qr/\b(?:from|of|merge|merging|merged) ([-\w]+)/i );
}
-if (@opt_M) {
- push (@mergerx, map { qr/$_/ } @opt_M);
+if (@more_merge_regexes) {
+ push (@mergerx, map { qr/$_/ } @more_merge_regexes);
}
# Remember UTC of our starting time
@@ -370,7 +426,7 @@ sub _file {
$self->{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
# -kk: Linus' version doesn't use it - defaults to off
- if ($opt_k) {
+ if ($cvs_kill_keywords) {
$self->{'socketo'}->write("Argument -kk\n") or return undef;
}
$self->{'socketo'}->write("Argument -r\n") or return undef;
@@ -487,7 +543,7 @@ sub _fetchfile {
package main;
-my $cvs = CVSconn->new($opt_d, $cvs_tree);
+my $cvs = CVSconn->new($cvsroot, $cvs_tree);
sub pdate($) {
@@ -565,7 +621,7 @@ unless (-d $git_dir) {
system("git-read-tree");
die "Cannot init an empty tree: $?\n" if $?;
- $last_branch = $opt_o;
+ $last_branch = $branch_for_head;
$orig_branch = "";
} else {
open(F, "git-symbolic-ref HEAD |") or
@@ -592,8 +648,8 @@ unless (-d $git_dir) {
$branch_date{$head} = $1;
}
close(H);
- if (!exists $branch_date{$opt_o}) {
- die "Branch '$opt_o' does not exist.\n".
+ if (!exists $branch_date{$branch_for_head}) {
+ die "Branch '$branch_for_head' does not exist.\n".
"Either use the correct '-o branch' option,\n".
"or import to a new repository.\n";
}
@@ -605,31 +661,31 @@ unless (-d $git_dir) {
# now we read (and possibly save) author-info as well
-f "$git_dir/cvs-authors" and
read_author_info("$git_dir/cvs-authors");
-if ($opt_A) {
- read_author_info($opt_A);
+if ($author_conv_file) {
+ read_author_info($author_conv_file);
write_author_info("$git_dir/cvs-authors");
}
#
# run cvsps into a file unless we are getting
-# it passed as a file via $opt_P
+# it passed as a file via $cvsps_output_file
#
my $cvspsfile;
-unless ($opt_P) {
- print "Running cvsps...\n" if $opt_v;
+unless ($cvsps_output_file) {
+ print "Running cvsps...\n" if $verbose;
my $pid = open(CVSPS,"-|");
my $cvspsfh;
die "Cannot fork: $!\n" unless defined $pid;
unless ($pid) {
my @opt;
- @opt = split(/,/,$opt_p) if defined $opt_p;
- unshift @opt, '-z', $opt_z if defined $opt_z;
- unshift @opt, '-q' unless defined $opt_v;
- unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
+ @opt = split(/,/,$cvsps_options) if defined $cvsps_options;
+ unshift @opt, '-z', $cvsps_fuzz if defined $cvsps_fuzz;
+ unshift @opt, '-q' unless defined $verbose;
+ unless (defined($cvsps_options) && $cvsps_options =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
- exec("cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
+ exec("cvsps","--norc",@opt,"-u","-A",'--root',$cvsroot,$cvs_tree);
die "Could not start cvsps: $!\n";
}
($cvspsfh, $cvspsfile) = tempfile('gitXXXXXX', SUFFIX => '.cvsps',
@@ -641,7 +697,7 @@ unless ($opt_P) {
$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
- $cvspsfile = $opt_P;
+ $cvspsfile = $cvsps_output_file;
}
open(CVS, "<$cvspsfile") or die $!;
@@ -688,7 +744,7 @@ sub write_tree () {
or die "Cannot get tree id ($tree): $!";
close($fh)
or die "Error running git-write-tree: $?\n";
- print "Tree ID $tree\n" if $opt_v;
+ print "Tree ID $tree\n" if $verbose;
return $tree;
}
@@ -699,7 +755,7 @@ my (@old,@new,@skipped,%ignorebranch);
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
sub commit {
- if ($branch eq $opt_o && !$index{branch} &&
+ if ($branch eq $branch_for_head && !$index{branch} &&
!get_headref("$remote/$branch")) {
# looks like an initial commit
# use the index primed by git-init
@@ -725,7 +781,7 @@ sub commit {
@old = @new = ();
my $tree = write_tree();
my $parent = get_headref("$remote/$last_branch");
- print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
+ print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $verbose;
my @commit_args;
push @commit_args, ("-p", $parent) if $parent;
@@ -734,10 +790,10 @@ sub commit {
# based on the commit msg
foreach my $rx (@mergerx) {
next unless $logmsg =~ $rx && $1;
- my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
+ my $mparent = $1 eq 'HEAD' ? $branch_for_head : $1;
if (my $sha1 = get_headref("$remote/$mparent")) {
push @commit_args, '-p', "$remote/$mparent";
- print "Merge parent branch: $mparent\n" if $opt_v;
+ print "Merge parent branch: $mparent\n" if $verbose;
}
}
@@ -764,10 +820,10 @@ sub commit {
print($commit_write "$logmsg\n") && close($commit_write)
or die "Error writing to git-commit-tree: $!\n";
- print "Committed patch $patchset ($branch $commit_date)\n" if $opt_v;
+ print "Committed patch $patchset ($branch $commit_date)\n" if $verbose;
chomp(my $cid = <$commit_read>);
is_sha1($cid) or die "Cannot get commit id ($cid): $!\n";
- print "Commit ID $cid\n" if $opt_v;
+ print "Commit ID $cid\n" if $verbose;
close($commit_read);
waitpid($pid,0);
@@ -779,14 +835,14 @@ sub commit {
if ($tag) {
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
- $xtag =~ tr/_/\./ if ( $opt_u );
- $xtag =~ s/[\/]/$opt_s/g;
+ $xtag =~ tr/_/\./ if ( $convert_underscores );
+ $xtag =~ s/[\/]/$branch_subst/g;
$xtag =~ s/\[//g;
system('git-tag', '-f', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
- print "Created tag '$xtag' on '$branch'\n" if $opt_v;
+ print "Created tag '$xtag' on '$branch'\n" if $verbose;
}
};
@@ -822,14 +878,14 @@ while (<CVS>) {
$state = 4;
} elsif ($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
- tr/_/\./ if ( $opt_u );
- s/[\/]/$opt_s/g;
+ tr/_/\./ if ( $convert_underscores );
+ s/[\/]/$branch_subst/g;
$branch = $_;
$state = 5;
} elsif ($state == 5 and s/^Ancestor branch:\s+//) {
s/\s+$//;
$ancestor = $_;
- $ancestor = $opt_o if $ancestor eq "HEAD";
+ $ancestor = $branch_for_head if $ancestor eq "HEAD";
$state = 6;
} elsif ($state == 5) {
$ancestor = undef;
@@ -847,19 +903,19 @@ while (<CVS>) {
$logmsg = "";
$state = 8;
} elsif ($state == 8 and /^Members:/) {
- $branch = $opt_o if $branch eq "HEAD";
+ $branch = $branch_for_head if $branch eq "HEAD";
if (defined $branch_date{$branch} and $branch_date{$branch} >= $date) {
# skip
- print "skip patchset $patchset: $date before $branch_date{$branch}\n" if
$opt_v;
+ print "skip patchset $patchset: $date before $branch_date{$branch}\n" if
$verbose;
$state = 11;
next;
}
- if (!$opt_a && $starttime - 300 - (defined $opt_z ? $opt_z : 300) <= $date)
{
+ if (!$all_commits && $starttime - 300 - (defined $cvsps_fuzz ?
$cvsps_fuzz : 300) <= $date) {
# skip if the commit is too recent
# given that the cvsps default fuzz is 300s, we give ourselves another
# 300s just in case -- this also prevents skipping commits
# due to server clock drift
- print "skip patchset $patchset: $date too recent\n" if $opt_v;
+ print "skip patchset $patchset: $date too recent\n" if $verbose;
$state = 11;
next;
}
@@ -870,8 +926,8 @@ while (<CVS>) {
}
if ($ancestor) {
if ($ancestor eq $branch) {
- print STDERR "Branch $branch erroneously stems from itself -- changed
ancestor to $opt_o\n";
- $ancestor = $opt_o;
+ print STDERR "Branch $branch erroneously stems from itself -- changed
ancestor to $branch_for_head\n";
+ $ancestor = $branch_for_head;
}
if (defined get_headref("$remote/$branch")) {
print STDERR "Branch $branch already exists!\n";
@@ -905,18 +961,18 @@ while (<CVS>) {
my $fn = $1;
my $rev = $3;
$fn =~ s#^/+##;
- if ($opt_S && $fn =~ m/$opt_S/) {
+ if ($skip_paths && $fn =~ m/$skip_paths/) {
print "SKIPPING $fn v $rev\n";
push(@skipped, $fn);
next;
}
- print "Fetching $fn v $rev\n" if $opt_v;
+ print "Fetching $fn v $rev\n" if $verbose;
my ($tmpname, $size) = $cvs->file($fn,$rev);
if ($size == -1) {
push(@old,$fn);
- print "Drop $fn\n" if $opt_v;
+ print "Drop $fn\n" if $verbose;
} else {
- print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $opt_v;
+ print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $verbose;
my $pid = open(my $F, '-|');
die $! unless defined $pid;
if (!$pid) {
@@ -934,12 +990,12 @@ while (<CVS>) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
- print "Delete $fn\n" if $opt_v;
+ print "Delete $fn\n" if $verbose;
} elsif ($state == 9 and /^\s*$/) {
$state = 10;
} elsif (($state == 9 or $state == 10) and /^-+$/) {
$commitcount++;
- if ($opt_L && $commitcount > $opt_L) {
+ if ($commit_limits && $commitcount > $commit_limits) {
last;
}
commit();
@@ -957,7 +1013,7 @@ while (<CVS>) {
}
commit() if $branch and $state != 11;
-unless ($opt_P) {
+unless ($cvsps_output_file) {
unlink($cvspsfile);
}
@@ -985,31 +1041,31 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if ($orig_branch) {
- print "DONE.\n" if $opt_v;
- if ($opt_i) {
+ print "DONE.\n" if $verbose;
+ if ($import_only) {
exit 0;
}
my $tip_at_end = `git-rev-parse --verify HEAD`;
if ($tip_at_start ne $tip_at_end) {
for ($tip_at_start, $tip_at_end) { chomp; }
- print "Fetched into the current branch.\n" if $opt_v;
+ print "Fetched into the current branch.\n" if $verbose;
system(qw(git-read-tree -u -m),
$tip_at_start, $tip_at_end);
die "Fast-forward update failed: $?\n" if $?;
}
else {
- system(qw(git-merge cvsimport HEAD), "$remote/$opt_o");
- die "Could not merge $opt_o into the current branch.\n" if $?;
+ system(qw(git-merge cvsimport HEAD), "$remote/$branch_for_head");
+ die "Could not merge $branch_for_head into the current branch.\n" if $?;
}
} else {
$orig_branch = "master";
- print "DONE; creating $orig_branch branch\n" if $opt_v;
- system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
+ print "DONE; creating $orig_branch branch\n" if $verbose;
+ system("git-update-ref", "refs/heads/master", "$remote/$branch_for_head")
unless defined get_headref('refs/heads/master');
- system("git-symbolic-ref", "$remote/HEAD", "$remote/$opt_o")
- if ($opt_r && $opt_o ne 'HEAD');
+ system("git-symbolic-ref", "$remote/HEAD", "$remote/$branch_for_head")
+ if ($remote_path && $branch_for_head ne 'HEAD');
system('git-update-ref', 'HEAD', "$orig_branch");
- unless ($opt_i) {
+ unless ($import_only) {
system('git checkout -f');
die "checkout failed: $?\n" if $?;
}
--
fge
^ permalink raw reply related
* How to send patch series without storing them to disk?
From: Liu Yubao @ 2008-11-03 9:33 UTC (permalink / raw)
To: git
Hi,
I want to send patches like this:
git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
It seems git-send-email can't read email from stdin.
I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
git send-email --from <myemail> --to <my-another-email> \
--smtp-pass <mypass> --smtp-user <myaccount> \
--smtp-server <the-smtp-server> \
--smtp-encryption auth \
0001-just-a-test.patch
The parameters about smtp are right, I tested with msmtp. What's wrong?
I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
ssl and tls.
^ permalink raw reply
* Re: Git and Media repositories....
From: Jakub Narebski @ 2008-11-03 9:40 UTC (permalink / raw)
To: Tim Ansell; +Cc: git, Dana How
In-Reply-To: <1225655428.11693.10.camel@vaio>
Tim Ansell <mithro@mithis.com> writes:
> Last week at the GitTogether I lead some discussions about how we could
> make Git better support large media repositories (which is one area
> where Subversion still make sense). It was suggested that I post to this
> list to get a discussion going.
>
> The general idea is that we always clone the complete meta-data (tags,
> commits and trees) and then only clone blobs when they are needed (using
> something like alternates). This allows us to support shallow, narrow
> and sparse checkouts while still being able to perform operations such
> as committing and merging.
>
> You can find a copy of the summary presentation at
> http://www.thousandparsec.net/~tim/media+git.pdf
>
> I have started working on adapting git to check a remote http alternate
> to provide a proof of concept.
>
> I appreciate any help or suggestions.
Dana How (CC-ed) worked on better support for large files, but in
corporate setting. The solution that was the result of all discussion
and all patches (not all accpeted) was to create kept packfile for
those large files, and share those packfiles (perhaps via alternates)
using network filesystem, instead of keeping separate copies and
trasferring them on fetch / push.
>From what I remember there was one serious attempt (by serious I mean
here with patches) to add 'lazy clone' / 'sparse clone' / 'remote
alternates', using some kind of "stub" objects and trasferring objects
lazily. This patch was fairly intrusive, and didn't get accepted.
I think you can find it in archives. Unfortunately I haven't bookmarked
this thread...
The problem with lazy clone is that git assumes in many places that if
it has some object, it has all its dependencies. Lazy clone
(on-demand object loading) breaks this assumption... although in your
case (only blobs of large size can be asked to be loaded lazily) it is
migitated somehow.
I also think that you would have to have 'sparse checkout' support.
If you don't have blob in object repository (and don't want to have it
there), you can not check it out. Fortunately this feature is quite
alive, and worked on by Duy (pclouds), see "What's cooking..."
(nd/narrow branch in 'pu').
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make Pthread link flags configurable
From: Jakub Narebski @ 2008-11-03 9:44 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git
In-Reply-To: <1225669400-79505-1-git-send-email-david.syzdek@acsalaska.net>
david.syzdek@acsalaska.net writes:
> From: David M. Syzdek <david.syzdek@acsalaska.net>
>
> FreeBSD 4.x systems use the linker flags `-pthread' instead of the
> linker flags `-lpthread' when linking against the pthread library.
>
> Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
> ---
> Makefile | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Would it be possible to add support for this also to configure.ac
(and config.mak.in)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-11-03 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <1225691960.20883.41.camel@maia.lan>
Sam Vilain wrote:
> On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>> + * 'git push --matching' does what 'git push' does today (without
>>>> + explicit configuration)
>>>
>>> I think this is reasonable even without other changes, just to override
>>> any configuration.
>>
>> I don't. Can't you say "git push $there HEAD" these days? I vaguely
>> recall that there is a way to configure push that way for people too lazy
>> to type "origin HEAD" after "git push".
>
> I don't think it's about laziness, it's more about making sure that
> without specifying behaviour, the action of the command is conservative.
> Pushing all matching refs is not conservative; it's "magic". And in my
> experience, people get bitten by it, because they think, "ok, time to
> push this branch", type "git push" and then a lot more than they
> expected gets pushed.
>
> I can see that some people want this behaviour by default; but to me
> "push the current branch back to where it came from" seems like far more
> a rational default for at least 90% of users.
"git remote <remote> push" for push matching?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-03 9:49 UTC (permalink / raw)
To: Andy Parkins, git
In-Reply-To: <490E36C0.5040701@pcharlan.com>
Pete Harlan wrote:
> Sorry for the repeat emails....this first-time "git send-email" user was
> a little surprised that it appears to always cc git@vger...
No, Pete, it only cc'd the "Signed-of-by:" address, which you filtered
to your git-list mailbox.
Sorry for this noise. I'll get the hang of things sooner or later.
If you think the patch, or the idea, could be worth applying in some
form, I'd appreciate any feedback.
Thanks,
--Pete
>
> <hides behind rock>
>
> --Pete
>
> Pete Harlan wrote:
>> Add configuration option hooks.showrev, letting the user override how
>> revisions will be shown in the commit email.
>
> --
> 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: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sverre Rabbelier @ 2008-11-03 9:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gemhdp$lev$1@ger.gmane.org>
On Mon, Nov 3, 2008 at 10:48, Jakub Narebski <jnareb@gmail.com> wrote:
> "git remote <remote> push" for push matching?
Not another command that is made to perform yet another piece of
funcionality. Let's let remote handle (configuring, and maintaining
of) remote related things, not also make it do push stuff.
Unless ofcourse, you mean that "git remote push <remote>" (certainly
not the other way around) is for configuration only.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: why not TortoiseGit
From: Nigel Magnay @ 2008-11-03 10:00 UTC (permalink / raw)
To: Li Frank; +Cc: Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE961E728C@zch01exm23.fsl.freescale.net>
> I read some code of TortoiseSVN and TortoiseHg Code.
> At beginning, TortoiseGit can git command to get information like Qgit.
> After linkable library ready, replace "git command".
>
> I think TortoiseGit can start base on below way.
>
> 1. Base on TortoiseHg, It is python Script. Replace below hg operator
> with Git.
> 2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
> ToritoiseSVN provide some built in diff and merge tools.
> 3. Base on Qgit, which provide some basic UI, such comment dialogbox,
> history view and file annotate.
>
>
TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and
you might run out, and I'd imagine lots of people wanting both.
On the minus side, building (Tortoise)SVN requires a lot of
environment setup just to get it to build - most of which can be
immediately thrown away as it's specific to SVN.
But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows
if files are dirty.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-03 10:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081102015041.GG15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> Eh, I disagree here. In git.git today "struct commit" exposes its
>>> buffer with the canonical commit encoding. Having that visible
>>> wrecks what Nico and I were thinking about doing with pack v4 and
>>> encoding commits in a non-canonical format when stored in packs.
>>> Ditto with trees.
>> Err... isn't that backwards?
>
> No.
>
>> Surely you want to store stuff in the
>> canonical format so you're forced to do as few translations as
>> possible?
>
> No. We suspect that canonical format is harder to decompress and
> parse during revision traversal. Other encodings in the pack file
> may produce much faster runtime performance, and reduce page faults
> (due to smaller pack sizes).
>
> We hardly ever use the canonical format for actual output; most
> output rips the canonical format apart and then formats the data
> the way it was requested. If we have the data *already* parsed in
> the pack its much faster to output.
>
I'll have to look into the pack v4 stuff, as I can't get what you're
saying to make sense to me. Not canonicalizing the data when storing
it means you'll have to have conversion routines from all the various
encodings, unless you first canonicalize it and then encode it in the
way you need it in the pack way. Never using canonical format means
it has no potential for combinatorial explosion, and every converter
needs to know about every other format.
>> Or are you trying to speed up packing by skipping the
>> canonicalization part?
>
> Wrong; we're trying to speed up reading. Packing may go slower,
> especially during the first conversion of v2->v4 for any given
> repository, but packing is infrequent so the minor (if any) drop
> in performance here is probably worth the reading performance gains.
>
>> Well, if macro usage is adhered to one wouldn't have to worry,
>> since the macro can just be rewritten with a function later (if,
>> for example, translation or some such happens to be required).
>> Older code linking to a newer library would work (assuming the
>> size of the commit object doesn't change anyway),
>
> You are assuming too much magic. If the older ABI used a macro
> and the newer one (which supports pack v4) organized struct commit
> differently and the user upgrades libgit2.so the older applications
> just broke, horribly.
>
Naturally. Re-sizing objects that weren't previously protected by
accessor functions will always break the ABI unless the layout of
the previously existing items in the object doesn't change, which
is exactly what I said.
> We know we want to do pack v4 in the near future. Or at least
> experiment with it and see if it works. If it does, we don't
> want to have to cause a major ABI breakage across all those newly
> installed libgit2s... yikes.
>
That's not necessary, although it requires a bit more thought when
changing the objects.
> I'm really in favor of accessor functions for the first version of
> the library. They can always be converted to macros once someone
> shows that their git visualizer program saves 10 ms on a 8,000 ms
> render operation by avoiding accessor functions. I'd rather spend
> our brain cycles optimizing the runtime and the in-core data so
> we spend less time in our tight revision traversal loops.
>
I agree that for early versions they should definitely be functions,
but since we've been talking about "final design" earlier in the
thread, that's what I was referring to here to.
> Seriously. We make at least 10 or 11 function calls *per commit*
> that comes out of get_revision(). If the formatting application is
> really suffering from its 4 or 5 accessor function calls in order
> to get that returned data, we probably should also be looking at
> how we can avoid function cals in the library.
>
> Oh, and even with 4 or 5 accessor functions per commit in the
> application that is *still* better than the 10 or so calls the
> application probably makes today scraping "git log --format=raw"
> off a pipe and segment it into the different fields it needs.
>
Right.
> Unless pipes in Linux somehow allow negative time warping with
> CPU counters. Though on dual-core systems they might, since the
> two processes can run on different cores. But oh, you didn't want
> to worry about threading support too much in libgit2, so I guess
> you also don't want to use multi-core systems.
>
All comps where I use git today are multi-core systems, so I'm very
much in favour of parallell processing. Otoh, I also don't think it
makes sense to jump through hoops to make sure one can, fe, read and
parse all tags in multiple threads simultaneously. In other words, I
don't think we need to bother adding thread-safety for stuff that
really only should happen if the application is poorly designed
(unless it's straightforward to do so, ofcourse).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* how to ignore all .xvpics directories
From: Christoph Duelli @ 2008-11-03 10:11 UTC (permalink / raw)
To: git
Is it possible to ignore (once and for all) that directories like .pics
or .xvpics (that might occur all over the place where xv was called)
should be ignored?
[ Note: some time ago this issue has already popped up:
http://thread.gmane.org/gmane.comp.version-control.git/50504
However, adding a line with just .xvpics in the toplevel .gitignore does
not help. Neither does /**/.xvpics
]
Best regards
--
Christoph Duelli
^ permalink raw reply
* Re: git/lib and git/git-gui/lib merge mis-hap?
From: Andreas Ericsson @ 2008-11-03 10:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20081101202201.GA15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Settling down to get some libgit2 hacking done (adding build-rules
>> to git.git), I noticed that there's a file in git.git called
>> lib/remote_add.tcl, which looks as if it belongs in git-gui/lib.
>>
>> I don't know how this happened, but since I assume it's subtree
>> merged (thus requiring more work to correct than a simple patch),
>> it would be nifty if it could get corrected so as to make space
>> for the up-and-coming git library :-)
>
> That was a bad merge of git-gui on my part. I thought it was fixed.
> It only happened in next, and was there only for a day before
> someone pointed it out to me, and I fixed it in the tree.
>
> FWIW, "git mv lib/remote_add.tcl git-gui/lib" is all you need to
> fix it. There's nothing special about the subtree merge.
>
I just pulled latest next, and it's fixed now. Thanks.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-cvsimport.perl: use human readable names for option values
From: Francis Galiegue @ 2008-11-03 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <200811031031.59196.fg@one2team.net>
Le Monday 03 November 2008 10:31:59 Francis Galiegue, vous avez écrit :
> Hello,
>
> As I am keen to make my company use git eventually, but they have a really,
> really messy CVS tree that git-cvs*.perl cannot handle right now, I've
> decided to have a serious look at the code.
>
As stated in one mail I sent earlier on, the real problem is that
git-cvsimport won't detect empty branches for two reasons:
* it relies on cvsps output, which doesn't tell about it either;
* however, it doesn't make use of another file that cvsps generates in
$HOME/.cvsps by default, which can help about giving this information.
I'll try the following:
* instead of capturing cvsps output directly, I'll use its -p option, which
has the advantage of generating one file per patchset;
* I'll consolidate the information of the other generated file in a hash and
correlate the information found in there with the individual patchset: my
hope is that I'll be able to detect so-far undetected branches and create
them.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Andreas Ericsson @ 2008-11-03 10:35 UTC (permalink / raw)
To: drafnel; +Cc: git, gitster, nico
In-Reply-To: <14536526.1225596838300.JavaMail.teamon@b301.teamon.com>
drafnel@gmail.com wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> Objects residing in pack files that have an associated .keep file are not
> supposed to be repacked into new pack files, but they are.
>
I think that's a misconception. Packfiles that are marked with .keep files
should never be deleted. There are, afaik, no rules against packing the
same objects into other packfiles as well. This is nifty for dumb ref
walkers, as they can use a small pack for incremental fetching while using
a mega-pack for initial cloning.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Offtopic [Re: Can't use gitk.]
From: Andreas Ericsson @ 2008-11-03 10:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <4d8e3fd30811021128q5f172a97pbc8e657d08f9ac8c@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On Mon, Nov 14, 2005 at 7:24 PM, Linus Torvalds <torvalds@osdl.org> wrote:
>> On Mon, 14 Nov 2005, Franck wrote:
>
> Sorry for commenting on this email only now but I found it in my
> archive while looking for a different thread :-)
>
>>> oops, sorry Andreas for that ! I use to spelling this name without 's'
>>> that's why I did the mistake I think.
>> In Finland and Sweden Andrea without the "s" is a girls name, while
>> Andreas with the "s" (or André without "-as") is a boy.
>>
>> It's not even very rare. "Andrea" was the 84th most popular female name in
>> Sweden in 2000.
>>
>> It can be confusing, since in Italy (and, I think, southern Germany and
>> much of Eastern Europe), "Andrea" is a boy, and in fact, the name
>> originally comes from the Greek meaning "man".
>
> In Italy Andrea might be a girl as well even if that name is often
> used for a boy.
>
Little did my parents know that the name they gave me would spawn a
discussion lasting very nearly three years.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Jakub Narebski @ 2008-11-03 11:49 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <490ECE54.5090505@melosgmbh.de>
Christoph Duelli <duelli@melosgmbh.de> writes:
> Is it possible to ignore (once and for all) that directories like
> .pics or .xvpics (that might occur all over the place where xv was
> called) should be ignored?
>
> [ Note: some time ago this issue has already popped up:
> http://thread.gmane.org/gmane.comp.version-control.git/50504
>
> However, adding a line with just .xvpics in the toplevel .gitignore
> does not help. Neither does /**/.xvpics
Could you reproduce the steps you tried? Because I have checked, and
putting .xvpics or .xvpics/ in top level .gitignore (or in
.git/info/excludes, or ~/.gitignore) works as expected: filename
without '/' in it is match agains _basename_.
Note that .gitignore is about contents which is not tracked (not known
to git). If you added .xvpics to commit by accident, .gitignore will
do nothing then.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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