* Re: [msysGit] [PATCH 02/15] Add define guards to compat/win32.h
From: Erik Faye-Lund @ 2009-09-16 9:42 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, j6t, lznuaa, raa.lkml,
snaury
In-Reply-To: <26c067500d8adf17a2d75e2956e4d4a6cef27fc1.1253088099.git.mstormo@gmail.com>
On Wed, Sep 16, 2009 at 10:20 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> --- a/compat/win32.h
> +++ b/compat/win32.h
> @@ -1,3 +1,6 @@
> +#ifndef WIN32_H
> +#define WIN32_H
> +
> /* common Win32 functions for MinGW and Cygwin */
> #include <windows.h>
>
> @@ -32,3 +35,5 @@ static inline int get_file_attr(const char *fname, WIN32_FILE_ATTRIBUTE_DATA *fd
> return ENOENT;
> }
> }
> +
> +#endif
Aren't these usually called "include guards" instead of "define guards"?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Junio C Hamano @ 2009-09-16 9:44 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <20090916074737.58044.42776.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> I have a repository at $dayjob where fetch was taking ~30s to tell me
> that there were no updates.
>
> It turns out that I appear to have added a nasty linear search of all
> remote refs for every commit (i.e. tag^{}) tag ref way back in the
> original C implementation of fetch. This doesn't scale well to large
> numbers of refs, so this replaces it with a hash table based lookup
> instead, which brings the time down to a few seconds even for very large
> ref counts.
>
> I haven't tested it with non-native transports, but there is no reason
> to believe that the code should be transport specific.
Very interesting.
A few questions (not criticisms).
* 1m50s to 4.5s is quite impressive, even if it is only in a repository
with unusual refs-vs-commits ratio, but I personally think 10 refs per
every commit is already on the borderline of being insane, and the
normal ratio would be more like 1 refs per every 10-20 commits.
What are possible downsides with the new code in repositories with more
reasonable refs-vs-commits ratio? A hash table (with a sensible hash
function) would almost always outperform linear search in an randomly
ordered collection, so my gut tells me that there won't be performance
downsides, but are there other potential issues we should worry about?
* In an insanely large refs-vs-commits case, perhaps not 50000:1 but more
like 100:1, but with a history with far more than one commit, what is
the memory consumption? Judging from a cursory view, I think the way
ref-dict re-uses struct ref might be quite suboptimal, as you are using
only next (for hash-bucket link), old_sha1[] and its name field, and
also your ref_dict_add() calls alloc_ref() which calls one calloc() per
requested ref, instead of attempting any bulk allocation.
* The outer loop is walking the list of refs from a transport, and the
inner loop is walking a copy of the same list of refs from the same
transport, looking for each refs/tags/X^{} what record, if any, existed
for refs/tags/X.
Would it make sense to further specialize your optimization? For
example, something like...
/* Your hash records this structure */
struct tag_ref_record {
const char *name;
struct ref *self;
struct ref *peeled;
};
static void add_to_tail(struct ref ***tail,
struct string_list *existing_refs,
struct string_list *new_refs,
const struct ref *ref,
const unsigned char sha1[]) {
... the "appending to *tail" thing as a helper function ...
}
for (ref in all refs from transport) {
if (ref is of form "refs/tags/X^{}")
look up tag_ref_record for "refs/tags/X" and store
ref in its peeled member;
else if (ref is of form "refs/tags/X")
look up tag_ref_record for "refs/tags/X" and store
ref in its self member;
}
for (trr in all tag_ref_record database) {
add_to_tail(tail, &existing_refs, &new_refs,
trr->self, self->old_sha1);
add_to_tail(tail, &existing_refs, &new_refs,
trr->peeled, self->old_sha1);
}
* It is tempting to use a hash table when you have to deal with an
unordered collection, but in this case, wouldn't the refs obtained from
the transport (it's essentially a ls-remote output, isn't it?) be
sorted? Can't you take advantage of that fact to optimize the loop,
without adding a specialized hash table implementation?
We find refs/tags/v0.99 immediately followed by refs/tags/v0.99^{} in
the ls-remote output. And the inefficient loop is about finding
refs/tags/v0.99 when we see refs/tags/v0.99^{}, so if we remember the
tag ref we saw in the previous round, we can check with that first to
make sure our "sorted" assumption holds true, and optimize the loop out
that way, no?
diff --git a/builtin-fetch.c b/builtin-fetch.c
index cb48c57..3f12e28 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -516,6 +516,7 @@ static void find_non_local_tags(struct transport *transport,
const struct ref *tag_ref;
struct ref *rm = NULL;
const struct ref *ref;
+ const struct ref *last_tag_seen = NULL;
for_each_ref(add_existing, &existing_refs);
for (ref = transport_get_remote_refs(transport); ref; ref = ref->next) {
@@ -528,6 +529,11 @@ static void find_non_local_tags(struct transport *transport,
if (!strcmp(ref_name + ref_name_len - 3, "^{}")) {
ref_name[ref_name_len - 3] = 0;
+ if (last_tag_seen &&
+ !strcmp(last_tag_seen->name, ref_name)) {
+ ref_sha1 = last_tag_seen->old_sha1;
+ goto quick;
+ }
tag_ref = transport_get_remote_refs(transport);
while (tag_ref) {
if (!strcmp(tag_ref->name, ref_name)) {
@@ -536,8 +542,11 @@ static void find_non_local_tags(struct transport *transport,
}
tag_ref = tag_ref->next;
}
+ } else {
+ last_tag_seen = ref;
}
+ quick:
if (!string_list_has_string(&existing_refs, ref_name) &&
!string_list_has_string(&new_refs, ref_name) &&
(has_sha1_file(ref->old_sha1) ||
^ permalink raw reply related
* Re: [PATCH 1/1] update gitignore
From: Pierre Habouzit @ 2009-09-16 10:03 UTC (permalink / raw)
To: gister; +Cc: git
In-Reply-To: <1253095295-28919-1-git-send-email-madcoder@debian.org>
Huh sorry, forget it, I though my repository was clean and those were
new by-products of the build, but it appears it was not.
On Wed, Sep 16, 2009 at 12:01:35PM +0200, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> .gitignore | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 47672b0..5604b82 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -105,6 +105,9 @@ git-reflog
> git-relink
> git-remote
> git-remote-curl
> +git-remote-ftp
> +git-remote-http
> +git-remote-https
> git-repack
> git-replace
> git-repo-config
> --
> 1.6.5.rc1.185.g9cbfa
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
^ permalink raw reply
* Re: [msysGit] [PATCH 02/15] Add define guards to compat/win32.h
From: Marius Storm-Olsen @ 2009-09-16 10:10 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: git, Johannes.Schindelin, msysgit, gitster, j6t, lznuaa, raa.lkml,
snaury
In-Reply-To: <40aa078e0909160242s4110ca8fj1e44e1e228676704@mail.gmail.com>
Erik Faye-Lund said the following on 16.09.2009 11:42:
> On Wed, Sep 16, 2009 at 10:20 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
>> --- a/compat/win32.h
>> +++ b/compat/win32.h
>> @@ -1,3 +1,6 @@
>> +#ifndef WIN32_H
>> +#define WIN32_H
>
> Aren't these usually called "include guards" instead of "define guards"?
Yup, of course they are. *thump*
--
.marius
^ permalink raw reply
* [PATCH 1/1] update gitignore
From: Pierre Habouzit @ 2009-09-16 10:01 UTC (permalink / raw)
To: gister; +Cc: git, Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
.gitignore | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 47672b0..5604b82 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,9 @@ git-reflog
git-relink
git-remote
git-remote-curl
+git-remote-ftp
+git-remote-http
+git-remote-https
git-repack
git-replace
git-repo-config
--
1.6.5.rc1.185.g9cbfa
^ permalink raw reply related
* [PATCH] archive: Refuse to write the archive to a terminal.
From: Josh Triplett @ 2009-09-16 10:31 UTC (permalink / raw)
To: git, gitster
If not given the -o/--output option, git archive writes the archive to
stdout. This proves unhelpful if not redirected or piped somewhere.
Rather than spewing binary at the user's terminal, die with an
appropriate message.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
I considered adding a -f/--force option, like gzip has, but writing an
archive to a tty seems like a sufficiently insane use case that I'll let
whoever actually needs that write the patch for it. ;)
builtin-archive.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 12351e9..73accd0 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -101,6 +101,9 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
create_output_file(output);
if (!format)
format = format_from_name(output);
+ } else if (isatty(1)) {
+ die("Archive not written to a terminal.\n"
+ "Specify output filename or redirect output.");
}
if (format) {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Paul Mackerras @ 2009-09-16 10:21 UTC (permalink / raw)
To: Alexey Borzenkov; +Cc: git
In-Reply-To: <1252437756-81986-1-git-send-email-snaury@gmail.com>
Alexey Borzenkov writes:
> gitk now includes patches for saving and restoring wm state, however
> because it saves wm geometry when window can still be maximized the
> maximize/restore button becomes useless after restarting gitk (you
> will get a huge displaced window if you try to restore it). This
> patch fixes this issue by storing window geometry in normal state.
Hmmm, shouldn't we be also saving the window state (zoomed/normal) and
restoring that as well?
Paul.
^ permalink raw reply
* Re: Gource - new GL Visualisation for git repositories
From: Felipe Contreras @ 2009-09-16 11:06 UTC (permalink / raw)
To: Mike Hommey; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <20090916064028.GA9482@glandium.org>
On Wed, Sep 16, 2009 at 9:40 AM, Mike Hommey <mh@glandium.org> wrote:
> On Wed, Sep 16, 2009 at 06:28:30PM +1200, Sam Vilain wrote:
>> A little fun candy to be had here:
>>
>> http://www.youtube.com/watch?v=GTMC3g2Xy8c
>> (HQ version coming, once processing completes...)
>>
>> Gource is a visualizer written in C++ which shows you the development of
>> the source code over time graphically. It's pretty neat. Home page at
>> http://code.google.com/p/gource/
>
> Code swarm (http://vis.cs.ucdavis.edu/~ogawa/codeswarm/) gives nice
> results, too.
And the ruby version too :)
http://www.youtube.com/watch?v=PxjLbj8oT1k
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Johannes Sixt @ 2009-09-16 11:11 UTC (permalink / raw)
To: Josh Triplett; +Cc: git, gitster
In-Reply-To: <20090916103129.GA21430@feather>
Josh Triplett schrieb:
> I considered adding a -f/--force option, like gzip has, but writing an
> archive to a tty seems like a sufficiently insane use case that I'll let
> whoever actually needs that write the patch for it. ;)
How about '--output -' instead?
-- Hannes
^ permalink raw reply
* Re: Gource - new GL Visualisation for git repositories
From: Reece Dunn @ 2009-09-16 11:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4AB0858E.6040805@vilain.net>
2009/9/16 Sam Vilain <sam@vilain.net>:
> A little fun candy to be had here:
>
> http://www.youtube.com/watch?v=GTMC3g2Xy8c
> (HQ version coming, once processing completes...)
>
> Gource is a visualizer written in C++ which shows you the development of
> the source code over time graphically. It's pretty neat. Home page at
> http://code.google.com/p/gource/
This looks nice.
Having a branch activity (as opposed to directory activity) rendering
would be nice as well.
I also noticed that this shows the committer's activity. It may be
more accurate to use the author (for example, the Wine project only
shows activity from one person and with Git, the activity for Junio is
similar being its maintainer).
In addition to this, for large projects that span a long time (5 or
more years), it would be nice to speed these up (possibly control the
rate as a command-line parameter).
Aside from that... very cool.
- Reece
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Mikael Magnusson @ 2009-09-16 11:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Josh Triplett, git, gitster
In-Reply-To: <4AB0C7DE.7030109@viscovery.net>
2009/9/16 Johannes Sixt <j.sixt@viscovery.net>:
> Josh Triplett schrieb:
>> I considered adding a -f/--force option, like gzip has, but writing an
>> archive to a tty seems like a sufficiently insane use case that I'll let
>> whoever actually needs that write the patch for it. ;)
>
> How about '--output -' instead?
You could always just add '|cat'.
--
Mikael Magnusson
^ permalink raw reply
* [PATCH] Initial manually svn property setting support for git-svn
From: David Fraser @ 2009-09-16 7:02 UTC (permalink / raw)
To: git; +Cc: David Moore
In-Reply-To: <1482075216.1261253084509966.JavaMail.root@klofta.sjsoft.com>
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Added minimal documentation for git-svn propset
Signed-off-by: David Fraser <davidf@sjsoft.com>
---
Documentation/git-svn.txt | 5 ++
git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Initial-manually-svn-property-setting-support-for-gi.patch --]
[-- Type: text/x-patch, Size: 7329 bytes --]
>From 521ed4fc7c877269fb029b9494ef57300c722a10 Mon Sep 17 00:00:00 2001
From: David Fraser <davidf@sjsoft.com>
Date: Wed, 16 Sep 2009 13:28:00 +0200
Subject: [PATCH] Initial manually svn property setting support for git-svn.
This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Added minimal documentation for git-svn propset
Signed-off-by: David Fraser <davidf@sjsoft.com>
---
Documentation/git-svn.txt | 5 ++
git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..b14bcf0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -345,6 +345,11 @@ Any other arguments are passed directly to 'git log'
Gets the Subversion property given as the first argument, for a
file. A specific revision can be specified with -r/--revision.
+'propset'::
+ Sets the Subversion property given as the first argument, to the value
+ given as the second argument, for files specifed as the remaining
+ arguments. The property will be sent with the next commit.
+
'show-externals'::
Shows the Subversion externals. Use -r/--revision to specify a
specific revision.
diff --git a/git-svn.perl b/git-svn.perl
index e0ec258..aaf92fb 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -80,7 +80,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag);
+ $_git_format, $_commit_url, $_tag, $_set_svn_props);
$Git::SVN::_follow_parent = 1;
$_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
@@ -147,6 +147,7 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'commit-url=s' => \$_commit_url,
+ 'set-svn-props=s' => \$_set_svn_props,
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
@@ -171,6 +172,9 @@ my %cmd = (
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
+ 'propset' => [ \&cmd_propset,
+ 'Set the value of a property on a file or directory - will be set on commit',
+ {} ],
'proplist' => [ \&cmd_proplist,
'List all properties of a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -892,6 +896,64 @@ sub cmd_propget {
print $props->{$prop} . "\n";
}
+sub check_attr
+{
+ my ($attr,$path) = @_;
+ if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
+ {
+ my $val = <$fh>;
+ close $fh;
+ $val =~ s/^[^:]*:\s*[^:]*:\s*(.*)\s*$/$1/;
+ return $val;
+ }
+ else
+ {
+ return undef;
+ }
+}
+
+# cmd_propset (PROPNAME, PROPVAL, PATH)
+# ------------------------
+# Adjust the SVN property PROPNAME to PROPVAL for PATH.
+sub cmd_propset {
+ my ($propname, $propval, $path) = @_;
+ $path = '.' if not defined $path;
+ $path = $cmd_dir_prefix . $path;
+ usage(1) if not defined $propname;
+ usage(1) if not defined $propval;
+ my $file = basename($path);
+ my $dn = dirname($path);
+ my $current_properties = check_attr( "svn-properties", $path );
+ my $new_properties = "";
+ if ($current_properties eq "unset" || $current_properties eq "" || $current_properties eq "set") {
+ $new_properties = "$propname=$propval";
+ } else {
+ # TODO: handle combining properties better
+ my @props = split(/;/, $current_properties);
+ my $replaced_prop = 0;
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ if ($n eq $propname)
+ {
+ $v = $propval;
+ $replaced_prop = 1;
+ }
+ if ($new_properties eq "") { $new_properties="$n=$v"; }
+ else { $new_properties="$new_properties;$n=$v"; }
+ }
+ }
+ if ($replaced_prop eq 0) {
+ $new_properties = "$new_properties;$propname=$propval";
+ }
+ }
+ my $attrfile = "$dn/.gitattributes";
+ open my $attrfh, '>>', $attrfile or die "Can't open $attrfile: $!\n";
+ # TODO: don't simply append here if $file already has svn-properties
+ print $attrfh "$file svn-properties=$new_properties\n";
+}
+
# cmd_proplist (PATH)
# -------------------
# Print the list of SVN properties for PATH.
@@ -4185,6 +4247,33 @@ sub apply_autoprops {
}
}
+sub apply_manualprops {
+ my ($self, $file, $fbat) = @_;
+ my $path = $cmd_dir_prefix . $file;
+ my $pending_properties = ::check_attr( "svn-properties", $path );
+ if ($pending_properties eq "") { return; }
+ # Parse the list of properties to set.
+ my @props = split(/;/, $pending_properties);
+ # TODO: get existing properties to compare to - this fails for add so currently not done
+ # my $existing_props = ::get_svnprops($file);
+ my $existing_props = {};
+ # TODO: caching svn properties or storing them in .gitattributes would make that faster
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ for ($n, $v) {
+ s/^\s+//; s/\s+$//;
+ }
+ if (defined $existing_props->{$n} && $existing_props->{$n} eq $v) {
+ my $needed = 0;
+ } else {
+ $self->change_file_prop($fbat, $n, $v);
+ }
+ }
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -4193,6 +4282,7 @@ sub A {
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->apply_autoprops($file, $fbat);
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -4204,6 +4294,7 @@ sub C {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -4223,6 +4314,7 @@ sub R {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->apply_autoprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
@@ -4239,6 +4331,7 @@ sub M {
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Reece Dunn @ 2009-09-16 11:48 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Johannes Sixt, Josh Triplett, git, gitster
In-Reply-To: <237967ef0909160427m4d7de120tf5ef3176f75123ad@mail.gmail.com>
2009/9/16 Mikael Magnusson <mikachu@gmail.com>:
> 2009/9/16 Johannes Sixt <j.sixt@viscovery.net>:
>> Josh Triplett schrieb:
>>> I considered adding a -f/--force option, like gzip has, but writing an
>>> archive to a tty seems like a sufficiently insane use case that I'll let
>>> whoever actually needs that write the patch for it. ;)
>>
>> How about '--output -' instead?
>
> You could always just add '|cat'.
Except when running on Windows. Yes MSYS and cygwin provide a version
of cat, but this cannot be guaranteed (e.g. with the series to support
building with MSVC).
The `--output -` / `-o -` syntax looks reasonable (the issue with
using -f/--force is: what are you forcing the operation of?). Is -
used elsewhere in git for specifying stdout?
Also, the die message might be more useful (and in keeping with the
other git commands) by showing the 'inline context help'; something
like:
Failed to generate the archive: output is a terminal.
Please specify the file to write to (using `-o archive.tar`) or
redirect the output (e.g. `... | gzip`).
If you want to write the archive out to the terminal, use `-o -`
to force the operation.
- Reece
^ permalink raw reply
* git-svn-problem: Unnecessary downloading entire branch?
From: Martin Larsson @ 2009-09-16 11:53 UTC (permalink / raw)
To: git
I have a local git-copy of the company svn-repository. The git-copy is
up-to-date (git svn fetch). I then add a new branch in the
svn-repository (svn cp http://.../trunk http://...branches/JIRA-4444).
When I then do 'git svn fetch' again, it pulls all the files from the
svn-repository.
I was expecting it to only pull the fact that a new branch was made
(taking milliseconds), not all the files in the branch (taking more than
half an hour to complete). Why does it need to transfer all the files?
I did have problems getting the original svn-repository. It took several
days and stopped several times in the process. Each time it stopped, I
just issued 'git svn fetch' again and it seemed to continue. Could this
be related? How could I make a better copy?
M.
^ permalink raw reply
* System wide gitattributes
From: David Förster @ 2009-09-16 11:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hi there,
from the documentation I understand that things like external diff tools
can be set up in a gitattributes file per repository (or subfolder).
Why is there no support for a ~/.gitattributes file? This would be very
handy, for example to always get a textual diff of OpenDocument files.
Regards,
- David
ps: Please cc, I'm not on the list.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3336 bytes --]
^ permalink raw reply
* Re: System wide gitattributes
From: Rustom Mody @ 2009-09-16 12:16 UTC (permalink / raw)
To: David Förster; +Cc: git
In-Reply-To: <4AB0D0EB.5080105@andrena.de>
2009/9/16 David Förster <david.foerster@andrena.de>:
> Hi there,
>
> from the documentation I understand that things like external diff tools can
> be set up in a gitattributes file per repository (or subfolder).
>
> Why is there no support for a ~/.gitattributes file? This would be very
> handy, for example to always get a textual diff of OpenDocument files.
>
They are there; see
http://www.kernel.org/pub/software/scm/git/docs/git-config.html#FILES
^ permalink raw reply
* Re: System wide gitattributes
From: Matthieu Moy @ 2009-09-16 12:53 UTC (permalink / raw)
To: Rustom Mody; +Cc: David Förster, git
In-Reply-To: <f46c52560909160516w1d888a23yedd1fafae515bfbe@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
> 2009/9/16 David Förster <david.foerster@andrena.de>:
>> Hi there,
>>
>> from the documentation I understand that things like external diff tools can
>> be set up in a gitattributes file per repository (or subfolder).
>>
>> Why is there no support for a ~/.gitattributes file? This would be very
>> handy, for example to always get a textual diff of OpenDocument files.
>>
>
> They are there; see
>
> http://www.kernel.org/pub/software/scm/git/docs/git-config.html#FILES
~/.gitconfig is there, but I don't see a ~/.gitattributes file
mentionned in this page ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Matthieu Moy @ 2009-09-16 12:57 UTC (permalink / raw)
To: Reece Dunn; +Cc: Mikael Magnusson, Johannes Sixt, Josh Triplett, git, gitster
In-Reply-To: <3f4fd2640909160448x1fbb7a64s1ce0adca2af5010@mail.gmail.com>
Reece Dunn <msclrhd@googlemail.com> writes:
> 2009/9/16 Mikael Magnusson <mikachu@gmail.com>:
>> 2009/9/16 Johannes Sixt <j.sixt@viscovery.net>:
>>> Josh Triplett schrieb:
>>>> I considered adding a -f/--force option, like gzip has, but writing an
>>>> archive to a tty seems like a sufficiently insane use case that I'll let
>>>> whoever actually needs that write the patch for it. ;)
>>>
>>> How about '--output -' instead?
>>
>> You could always just add '|cat'.
>
> Except when running on Windows. Yes MSYS and cygwin provide a version
> of cat, but this cannot be guaranteed (e.g. with the series to support
> building with MSVC).
In general, autodectection features sometimes fail, so it's good to
have an explicit override option.
> The `--output -` / `-o -` syntax looks reasonable
I like this too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Gource - new GL Visualisation for git repositories
From: Alex Riesen @ 2009-09-16 13:02 UTC (permalink / raw)
To: Reece Dunn; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <3f4fd2640909160416n7c0ac92eo3f055d6c45f9c0a2@mail.gmail.com>
On Wed, Sep 16, 2009 at 13:16, Reece Dunn <msclrhd@googlemail.com> wrote:
> In addition to this, for large projects that span a long time (5 or
> more years), it would be nice to speed these up (possibly control the
> rate as a command-line parameter).
It has a little of that, try gource -h (I forgot the option name).
Not _much_ faster, though.
^ permalink raw reply
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Pat Thoyts @ 2009-09-15 12:03 UTC (permalink / raw)
To: git; +Cc: Alexey Borzenkov
In-Reply-To: <1252437756-81986-1-git-send-email-snaury@gmail.com>
Alexey Borzenkov <snaury@gmail.com> writes:
>gitk now includes patches for saving and restoring wm state, however
>because it saves wm geometry when window can still be maximized the
>maximize/restore button becomes useless after restarting gitk (you
>will get a huge displaced window if you try to restore it). This
>patch fixes this issue by storing window geometry in normal state.
>
I tried this patch on windows and I find that it causes the columns in
the top view to creep each time you restart the application. This is I
think due to the way this patch sets the state to normal before
recording all the settings.
I will post an alternative patch that records the normal geometry
whenever it changes instead which seems to work better for me.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-16 13:35 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Git Mailing List
In-Reply-To: <BLU0-SMTP195165E447A0C42386D083AEE30@phx.gbl>
On Tue, Sep 15, 2009 at 2:14 PM, Sean Estabrooks <seanlkml@sympatico.ca> wrote:
> On Tue, 15 Sep 2009 13:43:17 -0400
> Tim Visher <tim.visher@gmail.com> wrote:
>
> [...]
>> It would be nicer to
>> have an arbitrary number of authors that can all exist separately, but
>> I'm fairly certain that git does not support that.
>
> Tim,
>
> If you're just looking for a way to quickly switch the author information
> quickly between individual commits. You could create a shell alias for
> each of the programmers that does:
>
> export GIT_AUTHOR_NAME="some name" GIT_AUTHOR_EMAIL="name@where.com"
>
> This will override the global and per repo configured author information
> for all subsequent commits.
That is an interesting idea. My point is really that having a
committer and an author is something that makes sense in terms of
non-pairing. Especially in the OS world where developers may never
even get to meet, let alone code together, one developer writes a
feature somewhere and then submits it to the maintainer and the
maintainer puts it in. Pairing, on the other hand, is much more
tightly integrated than that. Just like in Brian's post, it's really
a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
happened to be typing and doing most of the nitty-gritty developing.
Changing the authors between committs almost seems to introduce an
arbitrary level of distinction where it's no longer _both_ but _one
then the other_. Does that make my question any clearer?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-16 13:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m3zl8w2hpf.fsf@localhost.localdomain>
On Tue, Sep 15, 2009 at 2:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Tim Visher <tim.visher@gmail.com> writes:
>
>> I'm interested in hearing how people use Git for pair programming.
>> Specifically, how do you document that you are programming in pairs.
>
> [...]
>
>> I did find Brian Helmkamp's script
>> http://www.brynary.com/2008/9/1/setting-the-git-commit-author-to-pair-programmers-names
>> but that's not really what I'm looking for. [...]
>
> I'm not sure if this would help you, but take a look at "Pair
> Programming & git & github & Gravatar & You & You" blog post by Jon
> "Lark" Larkowski from May 30, 2009:
>
> http://blog.l4rk.com/2009/05/pair-programming-git-github-gravatar.html
Unfortunately my company firewall is blocking that post. I'll have to
read it later. Thanks for the pointer though!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Direct ancestors from commit to HEAD
From: Gonsolo @ 2009-09-16 14:01 UTC (permalink / raw)
To: git
Is there a way to see only the direct line of (merge) ancestors from
patch to HEAD? Something like:
commit 0cb583fd2862f19ea88b02eb307d11c09e51e2f8
Merge: 723e9db... a2d1056...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Sep 15 10:01:16 2009 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
commit 88512935a24305fea7aecc9ba4d675869e97fc2a
Merge: 8a62bab... 6b26dea...
Author: David S. Miller <davem@davemloft.net>
Date: Fri Aug 14 12:27:19 2009 -0700
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
commit edd7fc7003f31da48d06e215a93ea966a22c2a03
Author: Nick Kossifidis <mick@madwifi-project.org>
Date: Mon Aug 10 03:29:02 2009 +0300
ath5k: Wakeup fixes
Here I can see exactly how the ath5k patch came to mainline and since
when it is there.
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Nicolas Sebrecht @ 2009-09-16 14:17 UTC (permalink / raw)
To: Tim Visher; +Cc: Sean Estabrooks, Git Mailing List, Nicolas Sebrecht
In-Reply-To: <c115fd3c0909160635x4d7368aeg4370668d765fd242@mail.gmail.com>
The 16/09/09, Tim Visher wrote:
>
> Pairing, on the other hand, is much more
> tightly integrated than that. Just like in Brian's post, it's really
> a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
> happened to be typing and doing most of the nitty-gritty developing.
> Changing the authors between committs almost seems to introduce an
> arbitrary level of distinction where it's no longer _both_ but _one
> then the other_. Does that make my question any clearer?
FMPOV (and to follow the Pair Programming purpose), there isn't an "I"
in "Pair". So having the same author name and sign-off for each pair is
what makes most sense. IMHO, "dev1_and_dev2" is actually the best
option.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Direct ancestors from commit to HEAD
From: Jakub Narebski @ 2009-09-16 14:26 UTC (permalink / raw)
To: Gonsolo; +Cc: git
In-Reply-To: <4AB0EFC0.8020005@googlemail.com>
Gonsolo <gonsolo@gmail.com> writes:
> Is there a way to see only the direct line of (merge) ancestors from
> patch to HEAD? Something like:
>
> commit 0cb583fd2862f19ea88b02eb307d11c09e51e2f8
> Merge: 723e9db... a2d1056...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue Sep 15 10:01:16 2009 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>
> commit 88512935a24305fea7aecc9ba4d675869e97fc2a
> Merge: 8a62bab... 6b26dea...
> Author: David S. Miller <davem@davemloft.net>
> Date: Fri Aug 14 12:27:19 2009 -0700
>
> Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
>
> commit edd7fc7003f31da48d06e215a93ea966a22c2a03
> Author: Nick Kossifidis <mick@madwifi-project.org>
> Date: Mon Aug 10 03:29:02 2009 +0300
>
> ath5k: Wakeup fixes
>
>
> Here I can see exactly how the ath5k patch came to mainline and since
> when it is there.
I don't know whether --first-parent or --simplify-by-decoration, or
perhaps --dense is what you want (you can also use --graph for better
visualization).
Or use git-show-branch... :-)
--
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