* Re: [RFC] git-pack-refs --prune
From: Junio C Hamano @ 2006-09-22 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609210815100.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 21 Sep 2006, Junio C Hamano wrote:
>>
>> Ok, so I did these and the result is a 4-patch series.
>
> Looks good to me. I would have combined 2/3, since the bulk of them is the
> calling conversion change, and they both add a new argument to the same
> function, so combining them would make just one patch that isn't even
> noticeably larger than either of the two originals, but that's just a
> small nitpick.
Actually I did these two as a single change and then later split
them. Unfortunately cherry-picking only 3 without 2 would not
have worked anyway in this particular case with git, but an
ideal SCM would have done a better job. It's just taste and
principle and splitting them into two would not have any
practical advantage in the real world.
Side note to interested bystanders.
Patch 2 changes function signature of for_each_ref() and
friends and adds one parameter, void *cbdata, to them and the
called-back functions. Typical changes looked like these:
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, void *cb_data);
-static int name_ref(const char *path, const unsigned char *sha1)
+static int name_ref(const char *path, const unsigned char *sha1, void *cb_data)
- for_each_ref(name_ref);
+ for_each_ref(name_ref, &tags_only);
Then patch 3 adds another parameter, int flags, to the same functions involved:
-typedef int each_ref_fn(const char *refname, const unsigned char *sha1, void *cb_data);
+#define REF_ISSYMREF 01
+#define REF_ISPACKED 02
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
-static int name_ref(const char *path, const unsigned char *sha1, void *cb_data)
+static int name_ref(const char *path, const unsigned char *sha1, int flags, void *cb_data)
An ideal SCM should help the user who wants to cherry pick patch
3 without patch 2, effectively applying a patch like this:
* Type definition of for_each_ref() callback function (with
flags but without callback data):
+#define REF_ISSYMREF 01
+#define REF_ISPACKED 02
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags);
* An actual callback function:
-static int name_ref(const char *path, const unsigned char *sha1)
+static int name_ref(const char *path, const unsigned char *sha1, int flags)
* The call-site of for_each_ref (note patch2 and patch2+patch3
have the same effect):
- for_each_ref(name_ref);
+ for_each_ref(name_ref, &tags_only);
^ permalink raw reply
* Re: [PATCH 4/6] gitweb: Link to associated tree from a particular log item in full log view
From: Junio C Hamano @ 2006-09-22 4:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060922011948.15909.59511.stgit@rover>
I presume you are running this version at repo.or.cz, but
(1) go to http://repo.or.cz/?p=stgit.git;a=log
(2) pick "tree" of one of the commits
(3) go browser-back, then pick "tree" from the top navbar
The resulting tree view of (2) lacks navbar while (3) looks much
saner.
You do not have the tree object name available in git_log to
generate an URL with both h and hb, and getting to it is an
extra work.
This would fix this particular breakage.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 34ef3fc..8c0fdf3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2732,9 +2732,9 @@ sub git_tree {
my $base = $hash_base || $hash;
$hash = git_get_hash_by_path($base, $file_name, "tree");
}
- if (!defined $hash_base) {
- $hash_base = $hash;
- }
+ }
+ if (!defined $hash_base) {
+ $hash_base = $hash;
}
$/ = "\0";
open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
^ permalink raw reply related
* Re: git-push of new, tiny branch doing more work than necessary?
From: Junio C Hamano @ 2006-09-22 2:31 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87fyekkg5r.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I've run through something quite like the following scenario a few
> times lately:
>
> git pull origin
> git checkout -b experiment
> # hack a file or two
> git commit -a -m "new experiment"
> git push origin experiment
>
> What I expect at this point is for git to push the few newly created
> objects out to the repository. Instead it talks about generating,
> deltifying, transferring, and unpacking thousands of objects (see
> below).
>
> Shouldn't the same WANT/HAVE hand shaking that makes git-fetch
> efficient be doing something similar here? Or am I just doing
> something wrong?
Depending on the version of git you are running, there are two
possibilities.
There has been a change to send-pack last week pushed out to
"master", in which Andy Whitcroft fixed a problem when there are
tons of refs on either end. Earlier we were limiting ourselves
to use 900 or so refs when generating the pack, but the new code
uses all refs it knows about (so it excludes commits pointed by
all remote refs, not just the ones that fits in the arbitrary
900 limit).
If you are seeing problem in a pair of repository with tons of
refs, it may be the problem Andy fixed with the above change, so
using the recent "master" version would help you.
If you are on the other han seeing the problem to start after
installing the recent "master", it could be that the above
change broke things for you. If you do not see the problem with
v1.4.2.1 but do see the problem with the current "master" that
would be an indication this is the case.
Another thing to watch out for is that send-pack/receive-pack
protocol does NOT do the full "want/have" conversation like
fetch-pack/upload-pack protocol does. It merely say "receiving
end has these at tips of branches and tags", "sending side has
these at tips of branches and tags", and does not ask about
what's befind the tips. So if you are in this situation, with
or without Andy's fix I can imagine you would see some redundant
sending of things.
- The origin repository has an ancient tag and the master
branch. Nothing else.
- Clone origin to victim repository. The victim repository
would now have origin and master (the same), and the tag.
- Somebody creates a commit in the "origin" repository on the
master branch.
- You create a commit on the "master" in the victim
repository.
- You run send-pack in the victim repository and try to push
your master to the master in the origin repository.
In this case, the update is not a fast forward, so you may need
to force it. When you do force, send-pack running on your end
learns from the other end about the ancient tag and its
"master", the latter of which it does not know about at all
(because you haven't pulled from the origin). So all it has to
work with as the common commit is the ancient tag -- which means
you would end up sending everything since that ancient tag til
your tip of "master".
I do not know if that is what is happening to you in this case,
though. While I think not doing the discovery harder like
upload-pack is a bug in send-pack, it is not an issue when you
are not forcing a non-fast forward, so it probably is a lower
priority bug than other things. To fix it properly I think we
would need a minor protocol update.
^ permalink raw reply
* [PATCH 6/6] gitweb: Relabel "head" as "HEAD"
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060922011941.15909.32671.stgit@rover>
"head" is a reference in refs/heads/, while those labels mean HEAD,
the latest revision of the default branch.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7b44c28..9c3546f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2444,7 +2444,7 @@ sub git_blame2 {
"history") .
" | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
- "head");
+ "HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
@@ -2513,7 +2513,7 @@ sub git_blame {
"history") .
" | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
- "head");
+ "HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
git_print_page_path($file_name, 'blob', $hash_base);
@@ -2697,7 +2697,7 @@ sub git_blob {
" | " .
$cgi->a({-href => href(action=>"blob",
hash_base=>"HEAD", file_name=>$file_name)},
- "head");
+ "HEAD");
} else {
$formats_nav .=
$cgi->a({-href => href(action=>"blob_plain", hash=>$hash)}, "raw");
@@ -2760,7 +2760,7 @@ sub git_tree {
"history"),
$cgi->a({-href => href(action=>"tree",
hash_base=>"HEAD", file_name=>$file_name)},
- "head");
+ "HEAD"),
}
if ($have_snapshot) {
# FIXME: Should be available when we have no hash base as well.
^ permalink raw reply related
* [PATCH 5/6] gitweb: Rename "plain" labels to "raw"
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060922011941.15909.32671.stgit@rover>
I don't have much preference either way and as far as I'm concerned, it may
go the other way as well. Consistency is what is important.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 45a5fbf..7b44c28 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2693,14 +2693,14 @@ sub git_blob {
" | " .
$cgi->a({-href => href(action=>"blob_plain",
hash=>$hash, file_name=>$file_name)},
- "plain") .
+ "raw") .
" | " .
$cgi->a({-href => href(action=>"blob",
hash_base=>"HEAD", file_name=>$file_name)},
"head");
} else {
$formats_nav .=
- $cgi->a({-href => href(action=>"blob_plain", hash=>$hash)}, "plain");
+ $cgi->a({-href => href(action=>"blob_plain", hash=>$hash)}, "raw");
}
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
@@ -3109,7 +3109,7 @@ sub git_blobdiff {
hash=>$hash, hash_parent=>$hash_parent,
hash_base=>$hash_base, hash_parent_base=>$hash_parent_base,
file_name=>$file_name, file_parent=>$file_parent)},
- "plain");
+ "raw");
git_header_html(undef, $expires);
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
@@ -3212,7 +3212,7 @@ sub git_commitdiff {
my $formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain",
hash=>$hash, hash_parent=>$hash_parent)},
- "plain");
+ "raw");
git_header_html(undef, $expires);
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
^ permalink raw reply related
* [PATCH 4/6] gitweb: Link to associated tree from a particular log item in full log view
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060922011941.15909.32671.stgit@rover>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0a91394..45a5fbf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2873,6 +2873,8 @@ sub git_log {
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") .
" | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
+ " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$commit), hash_base=>$commit}, "tree") .
"<br/>\n" .
"</div>\n" .
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
^ permalink raw reply related
* [PATCH 3/6] gitweb: Link to latest tree from the head line in heads list
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060922011941.15909.32671.stgit@rover>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1b1653a..0a91394 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2164,7 +2164,8 @@ sub git_heads_body {
"</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'})}, "shortlog") . " | " .
- $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log") .
+ $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$tag{'name'}, hash_base=>$tag{'name'})}, "tree") .
"</td>\n" .
"</tr>";
}
^ permalink raw reply related
* [PATCH 2/6] gitweb: Link to tree instead of snapshot in shortlog
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060922011941.15909.32671.stgit@rover>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 87df7bb..1b1653a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1976,9 +1976,6 @@ sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
- my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
- my $have_snapshot = (defined $ctype && defined $suffix);
-
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
@@ -2004,10 +2001,8 @@ sub git_shortlog_body {
print "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff");
- if ($have_snapshot) {
- print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
- }
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
print "</td>\n" .
"</tr>\n";
}
^ permalink raw reply related
* [PATCH 1/6] gitweb: More per-view navigation bar links
From: Petr Baudis @ 2006-09-22 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Navigation bars in various views were empty or missed important items that
should have been there, e.g. getting a snapshot in tree view or log of
ancestry in commit view...
This feeble patch attempts to consolidate that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 42 ++++++++++++++++++++++++++++++++++++++----
1 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0d2ff82..87df7bb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2444,6 +2444,9 @@ sub git_blame2 {
$cgi->a({-href => href(action=>"blob", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
"blob") .
" | " .
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ "history") .
+ " | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"head");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
@@ -2510,6 +2513,9 @@ sub git_blame {
$cgi->a({-href => href(action=>"blob", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
"blob") .
" | " .
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ "history") .
+ " | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"head");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
@@ -2685,6 +2691,10 @@ sub git_blob {
" | ";
}
$formats_nav .=
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ hash=>$hash, file_name=>$file_name)},
+ "history") .
+ " | " .
$cgi->a({-href => href(action=>"blob_plain",
hash=>$hash, file_name=>$file_name)},
"plain") .
@@ -2720,6 +2730,9 @@ sub git_blob {
}
sub git_tree {
+ my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
+ my $have_snapshot = (defined $ctype && defined $suffix);
+
if (!defined $hash) {
$hash = git_get_head_hash($project);
if (defined $file_name) {
@@ -2743,7 +2756,23 @@ sub git_tree {
my $base = "";
my ($have_blame) = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
- git_print_page_nav('tree','', $hash_base);
+ my @views_nav = ();
+ if (defined $file_name) {
+ push @views_nav,
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ hash=>$hash, file_name=>$file_name)},
+ "history"),
+ $cgi->a({-href => href(action=>"tree",
+ hash_base=>"HEAD", file_name=>$file_name)},
+ "head");
+ }
+ if ($have_snapshot) {
+ # FIXME: Should be available when we have no hash base as well.
+ push @views_nav,
+ $cgi->a({-href => href(action=>"snapshot")},
+ "snapshot");
+ }
+ git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
} else {
undef $hash_base;
@@ -2888,17 +2917,22 @@ sub git_commit {
my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
my $have_snapshot = (defined $ctype && defined $suffix);
- my $formats_nav = '';
+ my @views_nav = ();
if (defined $file_name && defined $co{'parent'}) {
my $parent = $co{'parent'};
- $formats_nav .=
+ push @views_nav,
$cgi->a({-href => href(action=>"blame", hash_parent=>$parent, file_name=>$file_name)},
"blame");
}
+ if (defined $co{'parent'}) {
+ push @views_nav,
+ $cgi->a({-href => href(action=>"shortlog", hash=>$hash)}, "shortlog"),
+ $cgi->a({-href => href(action=>"log", hash=>$hash)}, "log");
+ }
git_header_html(undef, $expires);
git_print_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',
$hash, $co{'tree'}, $hash,
- $formats_nav);
+ join (' | ', @views_nav));
if (defined $co{'parent'}) {
git_print_header_div('commitdiff', esc_html($co{'title'}) . $ref, $hash);
^ permalink raw reply related
* [PATCH] gitweb: Link (HEAD) tree for each project from projects list
From: Petr Baudis @ 2006-09-21 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Current projects list is oriented on easily getting "what's new"
information. But when already using gitweb as an interface to something,
I personally find myself to _much_ more frequently wanting to rather
see "what's in" (or "what's new in") and it's quite annoying to have to
go through the summary page (which is also rather expensive to generate)
just to get there.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 982ddbc..0d2ff82 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2283,7 +2283,8 @@ sub git_project_list {
"<td class=\"link\">" .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary")}, "summary") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
- $cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
"</td>\n" .
"</tr>\n";
}
^ permalink raw reply related
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Anand Kumria @ 2006-09-21 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <20060920004828.GI8259@pasky.or.cz>
On Wed, 20 Sep 2006 02:48:28 +0200, Petr Baudis wrote:
> Hi,
>
> there are various tiny repositories scatterred over the web that are
> on crappy broken webhostings, don't have lifetime long enough and most
> importantly have no gitweb interface for peeking inside - even e.g. the
> StGIT repository suffers from that.
>
[snip]
> Note that there is also a glibc CVS import available at that address,
> entirely coincidentally. That one is an exception and is not synced from
> any other Git repository. It took git-cvsimport two days to chew through
> on a decent machine (but over the network), the resulting size of 107M is
> pretty nice. I hope to set it up to automatically track glibc CVS further
> (and possibly other popular non-Git projects later). There's insane
> amount of tags which means the gitweb summary page takes "a bit" long to
> load, I wonder if using packed refs would improve that.
I've got some imports of some projects that I am tracking as well.
http://www.progsoc.org/~wildfire/git/
I have not (yet) enabled git-daemon support for them, so anyone cloning
them might find it takes a long amount of time. I haven't updated to the
most recent gitweb/git lately so it might be a bit slow.
I'll get around to making both git-daemon support available and updating
to a newer version of gitweb shortly.
If anyone wants me to track other projects, let me know.
Cheers,
Anand
^ permalink raw reply
* Re: git-push of new, tiny branch doing more work than necessary?
From: Johannes Schindelin @ 2006-09-21 22:34 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87fyekkg5r.wl%cworth@cworth.org>
Hi,
On Thu, 21 Sep 2006, Carl Worth wrote:
> I've run through something quite like the following scenario a few
> times lately:
>
> git pull origin
> git checkout -b experiment
> # hack a file or two
> git commit -a -m "new experiment"
> git push origin experiment
>
> What I expect at this point is for git to push the few newly created
> objects out to the repository. Instead it talks about generating,
> deltifying, transferring, and unpacking thousands of objects (see
> below).
I experienced something like this, too, but did not have the time to debug
it. But alas, some time (I think last week) it started working as expected
again.
> git version 1.4.2.rc2.gef1d9
Please try a more recent version (yours is from Jul 27).
Ciao,
Dscho
^ permalink raw reply
* git-push of new, tiny branch doing more work than necessary?
From: Carl Worth @ 2006-09-21 22:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
I've run through something quite like the following scenario a few
times lately:
git pull origin
git checkout -b experiment
# hack a file or two
git commit -a -m "new experiment"
git push origin experiment
What I expect at this point is for git to push the few newly created
objects out to the repository. Instead it talks about generating,
deltifying, transferring, and unpacking thousands of objects (see
below).
Shouldn't the same WANT/HAVE hand shaking that makes git-fetch
efficient be doing something similar here? Or am I just doing
something wrong?
-Carl
$ git --version
git version 1.4.2.rc2.gef1d9
$ git push cworth 8379
updating 'refs/heads/8379'
from 0000000000000000000000000000000000000000
to 44379202da96faf632b73cdcdd6c0a74fb4b54f4
Generating pack...
Done counting 4900 objects.
Result has 4622 objects.
Deltifying 4622 objects.
100% (4622/4622) done
Unpacking 4622 objects
Total 4622, written 4622 (delta 3411), reused 1259 (delta 946)
refs/heads/8379: 0000000000000000000000000000000000000000 ->
44379202da96faf632b73cdcdd6c0a74fb4b54f4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] show-branch: mark active branch with a '*' again
From: Johannes Schindelin @ 2006-09-21 22:07 UTC (permalink / raw)
To: git, junkio
This was lost in the packed-ref updates. The original test was a bit
dubious, so I cleaned that up, too. It fixes the case when the current HEAD
is refs/heads/bla/master: the original test was true for both bla/master
_and_ master.
However, it shares a hard-to-fix bug with the original test: if the current
HEAD is refs/heads/master, and there is a branch refs/heads/heads/master,
then both are marked active.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
... and since nobody uses headlen, there is no need to fix that up.
builtin-show-branch.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 5d6ce56..fb1a400 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -443,6 +443,12 @@ static int rev_is_head(char *head, int h
if ((!head[0]) ||
(head_sha1 && sha1 && hashcmp(head_sha1, sha1)))
return 0;
+ if (!strncmp(head, "refs/heads/", 11))
+ head += 11;
+ if (!strncmp(name, "refs/heads/", 11))
+ name += 11;
+ else if (!strncmp(name, "heads/", 6))
+ name += 6;
return !strcmp(head, name);
}
--
1.4.2.1.g9797-dirty
^ permalink raw reply related
* [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-21 21:56 UTC (permalink / raw)
To: git; +Cc: Sham Chukoury
Below there is preliminary (hence RFC) committag support for gitweb,
based on the idea introduced by Sham Chukoury to gitweb-xmms2.
The code has all the possible committags I could think of enabled;
not all are tested, though. This includes existing commitsha tag
support (full sha links to commit view, is sha is sha of commit),
mantis bug and feature tags from gitweb-xmms2 (there is no release
committag of gitweb-xmms2, but it should be fairly easy to add it),
bugzilla committag for the Linux kernel, plain text URL committag
(probably doesn't work that well, marking as links examples, and
sometimes protocol specification), and Message-Id committag via
GMane git mailing list (and not only) archive -- not tested.
Comments? Discussion?
This patch is rather not for inclusion; it is not in format-patch form.
P.S. I've corrected git_get_type for comparison
git_get_type($hash) eq "commit"
to work without Perl syntax errors.
-- >8 --
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7ed963c..5eb0dd0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -173,6 +173,118 @@ sub feature_pickaxe {
return ($_[0]);
}
+# You define site-wide comittags defaults here; override them with
+# $GITWEB_CONFIG as necessary.
+our %committags = (
+ # 'committag' => {
+ # 'pattern' => regexp (use 'qr' quote-like operator)
+ # 'sub' => committag-sub (subroutine),
+ # 'enabled' => is given committag enabled,
+ # fields below can be defined, but don't need to
+ # 'options' => [ default options...] (array reference),
+ # 'insubject' => should given committag be enabled in commit/tag subject,
+ # 'islink' => if the result is hyperlink,
+ # }
+ #
+ # You should ensure that enabled committags cannot overlap
+ #
+ # The committag subroutine is called with match for pattern,
+ # and options if they are defined. Match is replaced by return
+ # value of committag-sub.
+
+ 'commitsha' => {
+ 'pattern' => qr/[0-9a-fA-F]{40}/,
+ 'enabled' => 1,
+ 'islink' => 1,
+ 'sub' => \&tag_commit_id},
+
+ 'mantis' => {
+ 'pattern' => qr/(BUG|FEATURE)\(\d+\)/,
+ 'enabled' => 1,
+ 'insubject' => 1,
+ 'islink' => 1,
+ 'options' => [ 'http://bugs.xmms2.xmms.se/view.php?id=' ],
+ 'sub' => \&tag_bugtracker},
+
+ 'bugzilla' => {
+ 'pattern' => qr/bug( )+\(\d+\)/,
+ 'enabled' => 1,
+ 'insubject' => 1,
+ 'islink' => 1,
+ 'options' => [ 'http://bugzilla.kernel.org/show_bug.cgi?id=' ],
+ 'sub' => \&tag_bugtracker},
+
+ 'URL' => {
+ 'pattern' => qr!(http|ftp)s?://[a-zA-Z0-9_%./]+!,
+ 'enabled' => 1,
+ 'islink' => 1,
+ 'sub' => \&tag_url},
+
+ 'message_id' => {
+ 'pattern' => qr/(message|msg)[- ]?id <([^&]*)&rt;/i,
+ 'enabled' => 1,
+ 'options' => [
+ 'http://news.gmane.org/find-root.php?message_id=',
+ \"e_msgid_gmane ],
+ 'sub' => \&tag_msgid},
+);
+
+sub tag_commit_id {
+ my $hash_text = shift;
+
+ if (git_get_type($hash_text) eq "commit") {
+ return $cgi->a({-href => href(action=>"commit", hash=>$hash_text),
+ -class => "text"}, $hash_text);
+ }
+
+ return;
+}
+
+sub tag_bugtracker {
+ my $match = shift;
+ my $URL = shift || return $match;
+ my ($issue) = $match =~ m/(\d+)/;
+
+ return $match if (!defined $issue);
+
+ return $cgi->a({-href => "$URL$issue"}, $match);
+}
+
+sub tag_url {
+ my $url_text = shift;
+
+ return $cgi->a({-href => $url_text}, $url_text);
+}
+
+sub quote_msgid_gmane {
+ my $msgid = shift || return;
+
+ return '<'.(quotemeta $msgid).'>';
+}
+
+sub quote_msgid_marc {
+ my $msgid = shift || return;
+ my ($user, $host) = split(/\@/, $msgid, 2);
+ $host =~ s/\./ ! /g;
+
+ return $user.' () '.$host;
+}
+
+
+sub tag_msgid {
+ my $text = shift;
+ my $URL = shift || return $text;
+ my $repl = shift;
+
+ my ($msgid) =~ m/<([^&]*)&rt;/;
+ my $msgid_url = (ref($repl) eq "CODE") ? $repl->($msgid) : $msgid;
+ my $link = $cgi->a({-href => "$URL$msgid_url"}, $msgid);
+
+ $text =~ s/$msgid/$link/;
+
+ return $text;
+}
+
# rename detection options for git-diff and git-diff-tree
# - default is '-M', with the cost proportional to
# (number of removed files) * (number of new files).
@@ -191,6 +303,10 @@ our $git_version = qx($GIT --version) =~
$projects_list ||= $projectroot;
+# enabled committags, and committags enabled for subject
+our @committags = grep { $committags{$_}{'enabled'} } keys %committags;
+our @subjecttags = grep { $committags{$_}{'insubject'} } @committags;
+
# ======================================================================
# input validation and dispatch
our $action = $cgi->param('a');
@@ -577,18 +693,43 @@ ## which don't beling to other sections
# format line of commit message or tag comment
sub format_log_line_html {
my $line = shift;
+ my @tags = @_;
+ my $a_attr;
+ my %subst;
+
+ if (!@tags) {
+ @tags = @committags;
+ } else {
+ $a_attr = ref($tags[0]) eq "HASH" ? shift @tags : undef;
+ }
$line = esc_html($line);
$line =~ s/ / /g;
- if ($line =~ m/([0-9a-fA-F]{40})/) {
- my $hash_text = $1;
- if (git_get_type($hash_text) eq "commit") {
- my $link =
- $cgi->a({-href => href(action=>"commit", hash=>$hash_text),
- -class => "text"}, $hash_text);
- $line =~ s/$hash_text/$link/;
+
+ foreach my $ct (@tags) {
+ next unless exists $committags{$ct};
+ my $wrap = $a_attr && %$a_attr && $committags{$ct}{'islink'};
+ my @opts =
+ exists $committags{$ct}{'options'} ?
+ @{$committags{$ct}{'options'}} :
+ ();
+
+ while ($line =~ m/($committags{$ct}{'pattern'})/gc) {
+ my $match = $1;
+ my $repl = $committags{$ct}{'sub'}->($match, @opts);
+ next unless $repl;
+
+ if ($wrap) {
+ $repl = $cgi->end_a() . $repl . $cgi->start_a($a_attr);
+ }
+
+ $subst{quotemeta $match} = $repl;
}
}
+
+ while (my ($from, $to) = each %subst) {
+ $line =~ s/$from/$to/g;
+ }
return $line;
}
@@ -626,12 +767,13 @@ sub format_subject_html {
$extra = '' unless defined($extra);
if (length($short) < length($long)) {
- return $cgi->a({-href => $href, -class => "list subject",
- -title => $long},
- esc_html($short) . $extra);
+ my $a_attr = {-href => $href, -class => "list subject", -title => $long};
+ return $cgi->a($a_attr,
+ format_log_line_html($short, $a_attr, @subjecttags) . $extra);
} else {
- return $cgi->a({-href => $href, -class => "list subject"},
- esc_html($long) . $extra);
+ my $a_attr = {-href => $href, -class => "list subject"};
+ return $cgi->a($a_attr,
+ format_log_line_html($long, $a_attr, @subjecttags) . $extra);
}
}
@@ -693,9 +835,9 @@ sub git_get_type {
open my $fd, "-|", git_cmd(), "cat-file", '-t', $hash or return;
my $type = <$fd>;
- close $fd or return;
+ close $fd or return "unknown";
chomp $type;
- return $type;
+ return ($type || "unknown");
}
sub git_get_project_config {
@@ -1585,7 +1727,7 @@ sub git_print_log ($;%) {
$empty = 0;
}
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line, @committags) . "<br/>\n";
}
if ($opts{'-final_empty_line'}) {
^ permalink raw reply related
* [PATCH] Fix git-update-index --again
From: Johannes Schindelin @ 2006-09-21 21:29 UTC (permalink / raw)
To: git, junkio
It called read_ref(git_path(..)..), where read_ref does the git_path()
stuff itself.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-update-index.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 0620e77..09214c8 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -404,9 +404,9 @@ static int unresolve_one(const char *pat
static void read_head_pointers(void)
{
- if (read_ref(git_path("HEAD"), head_sha1))
+ if (read_ref("HEAD", head_sha1))
die("No HEAD -- no initial commit yet?\n");
- if (read_ref(git_path("MERGE_HEAD"), merge_head_sha1)) {
+ if (read_ref("MERGE_HEAD", merge_head_sha1)) {
fprintf(stderr, "Not in the middle of a merge.\n");
exit(0);
}
@@ -443,7 +443,7 @@ static int do_reupdate(int ac, const cha
int has_head = 1;
const char **pathspec = get_pathspec(prefix, av + 1);
- if (read_ref(git_path("HEAD"), head_sha1))
+ if (read_ref("HEAD", head_sha1))
/* If there is no HEAD, that means it is an initial
* commit. Update everything in the index.
*/
--
1.4.2.1.ge488
^ permalink raw reply related
* [NOTE] minor breakages here and there in "next"
From: Junio C Hamano @ 2006-09-21 20:00 UTC (permalink / raw)
To: git
I am at day-job today but have noticed a couple more minor
breakages coming from the resolve_ref() clean-up done recently
in "next". Nothing serious or major, but would be nice to fix.
- git-show-branch does not use '*' for the column for the
current branch anymore.
- "git update-index -g" updates everything, not just things
already different from HEAD.
The latter I think is probably read_ref() around l.446 in
builtin-update-index.c
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Nicolas Pitre @ 2006-09-21 18:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0609211027440.4388@g5.osdl.org>
On Thu, 21 Sep 2006, Linus Torvalds wrote:
> Right now, a plain "git pull" means "fetch all branches and merge the
> first one", and the thing is, that's generally the right thing _only_ if
> you pull into "master".
>
> It's usually exactly the _wrong_ thing to do for any other branch. In
> particular, if you work with a project that has lots of branches, and
> you're working in another branch (that is directly tracking a remote, for
> example), doing a "git pull" definitely should _not_ merge the first head.
> It should fetch everything, and possibly merge the _matching_ head.
>
> Which it doesn't do right now.
I think you're summarizing my grip about git pull quite well. This is
really counter-intuitive and I've been bitten by that behavior on many
occasions.
Nicolas
^ permalink raw reply
* RE: [PATCH] Build on Debian GNU/Hurd
From: Linus Torvalds @ 2006-09-21 17:53 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Gerrit Pape, git
In-Reply-To: <000001c6dda4$ad0b1ec0$c47eedc1@ramsay1.demon.co.uk>
On Thu, 21 Sep 2006, Ramsay Jones wrote:
>
> IMHO, setting the value in the Makefile, for systems that don't define
> PATH_MAX, is a much better solution. In fact, that is what I thought was
> already being done.
Well, considering that we _can_ test defines, why not just do it
automatically.
In other words, instead of this patch:
> > -
> > -#ifndef PATH_MAX
> > -# define PATH_MAX 4096
> > -#endif
> > +#include <limits.h>
Just make the code read
#include <limits.h>
/*
* Insane systems don't have a fixed PATH_MAX, it's POSIX
* compliant but not worth worrying about, so if we didn't
* get PATH_MAX from <limits.h>, just make up our own
*/
#ifndef PATH_MAX
# define PATH_MAX 4096
#endif
and after that we can just ignore the issue forever more.
The thing is, it's not like we even really _care_ what PATH_MAX is all
that deeply. We just want to get some random value that is reasonable.
Linus
^ permalink raw reply
* RE: [PATCH] Build on Debian GNU/Hurd
From: Ramsay Jones @ 2006-09-21 17:37 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20060919170335.28054.qmail@14e0e1fe2bc371.315fe32.mid.smarden.org>
On Tues Sept 19, 2006 at 18:04, Gerrit Pape wrote:
> On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote:
> > Gerrit Pape <pape@smarden.org> writes:
> > > Patch from Cyril Brulebois to make the build process detect
> and support the
> > > Debian GNU/Hurd architecture, see
> > > http://bugs.debian.org/379841
> > >
> > > Signed-off-by: Gerrit Pape <pape@smarden.org>
> > >
> > > +ifeq ($(uname_S),GNU)
> > > + # GNU stands for GNU/Hurd
> > > + NO_STRLCPY = YesPlease
> > > + ALL_CFLAGS += -DPATH_MAX=4096
> > > +endif
> >
> > Two questions come to mind. (1) Does GNU stand for GNU/Hurd and
> > nobody else? (2) Does everybody else have PATH_MAX?
>
> I'm not that familiar with the Hurd, but (1) seems to be so according
> to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU
> or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly
>
> git$ grep -B7 -A3 PATH_MAX Makefile
> ifeq ($(uname_S),IRIX64)
> NO_IPV6=YesPlease
> NO_SETENV=YesPlease
> NO_STRCASESTR=YesPlease
> NO_STRLCPY = YesPlease
> NO_SOCKADDR_STORAGE=YesPlease
> SHELL_PATH=/usr/gnu/bin/bash
> ALL_CFLAGS += -DPATH_MAX=1024
> # for now, build 32-bit version
> ALL_LDFLAGS += -L/usr/lib32
> endif
>
> that's where I got it from.
>
> > Adding NO_STRLCPY I do not have much problems with, but
> > something like the attached may be cleaner to deal with PATH_MAX;
> > of course now there is an issue of what the appropriate value
> > for that symbol should be.
>
> It's been so before it seems, I'm not sure why it changed.
Because without the change (below), git would not compile for me ;-)
Indeed it would not compile for any system that:
1) defines PATH_MAX in limits.h
AND 2) conditionally defines PATH_MAX to a different value.
(Actually, it does not have to be a different value, just a different
token sequence, including the presence/absence of whitespace/comments)
Note that other systems use a different "PATH_MAX value", (a value of
1024 is common), and in particular, earlier version of linux use a
value of 4095.
> http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot
> expect PATH_MAX to be defined on a POSIX system,
Correct. Although PATH_MAX is a POSIX symbol, it is not required to be
defined; it *may* be defined in limits.h and, if so, must have a value
of at least 256.
The symbol _PC_PATH_MAX *may* also be defined and, if so, may be used
in a call to pathconf() to *maybe* determine a "PATH_MAX value" at
runtime; it can return a value, indicate no limit, or an "indeterminate"
limit.
... so defining it
> conditionally IMHO is the right thing.
IMHO, setting the value in the Makefile, for systems that don't define
PATH_MAX, is a much better solution. In fact, that is what I thought was
already being done.
All the best,
Ramsay
>
> git$ PAGER=cat git log -p 579d1fb..8e76483
> commit 8e76483ce0ce256b01345abc4ca97b1f94aed354
> Author: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
> Date: Sun Jul 30 17:00:40 2006 +0100
>
> Fix header breakage due to redefining PATH_MAX.
>
> The header builtin.h was, incorrectly, redefining PATH_MAX which
> causes a header order dependency in builtin-write-tree.c. The fix
> is to simply include <limits.h> directly to obtain the correct
> definition of PATH_MAX.
>
> Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> diff --git a/builtin.h b/builtin.h
> index 1c8637a..88c4d84 100644
> --- a/builtin.h
> +++ b/builtin.h
> @@ -2,10 +2,7 @@ #ifndef BUILTIN_H
> #define BUILTIN_H
>
> #include <stdio.h>
> -
> -#ifndef PATH_MAX
> -# define PATH_MAX 4096
> -#endif
> +#include <limits.h>
>
> extern const char git_version_string[];
>
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Linus Torvalds @ 2006-09-21 17:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, git
In-Reply-To: <20060921164048.GY8259@pasky.or.cz>
On Thu, 21 Sep 2006, Petr Baudis wrote:
>
> This is artifact of the BitKeeper terminology. This is the meaning in
> most other VCSes but in BitKeeper, pull meant "get changes and merge
> them", not just "get changes". So the BitKeeper legacy lives on. :-)
Indeed. "pull/push" are the operations bk has.
BK doesn't have branches, and cannot do a "fetch", so there's no confusion
in BK - the pulls and the pushes are not mirror-images, but since there
are no other operations you'd normally use, you can pretty much ignore it.
(That's not entirely true. In BK, you can do "bk receive" and "bk resolve"
to "fetch" and "merge" another branch, but quite frankly, I personally
found them so confusing that I never used them at all).
I agree that the clarifications from Shawn are probably improvements, but
I'd actually like to solve the problem a bit differently. Namely, I was
hoping that the per-branch configuration would solve the confusion.
Right now, a plain "git pull" means "fetch all branches and merge the
first one", and the thing is, that's generally the right thing _only_ if
you pull into "master".
It's usually exactly the _wrong_ thing to do for any other branch. In
particular, if you work with a project that has lots of branches, and
you're working in another branch (that is directly tracking a remote, for
example), doing a "git pull" definitely should _not_ merge the first head.
It should fetch everything, and possibly merge the _matching_ head.
Which it doesn't do right now.
So I think the problem with "git pull" is not that it's a "fetch and
merge", it's that it merges the wrong head. It always merges the first
remote one (aka the remote "HEAD"), regardless of which head we happen to
be at right now.
So I was kind of hoping that the per-branch configuration stuff (that
petered out after the .git/config file format was worked out) would solve
the problem.
That said, maybe Shawn's suggestion is better. And maybe the fact that
we'd change the semantics mid-stream would make things even WORSE. I
dunno.
Linus
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Jakub Narebski @ 2006-09-21 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609211259340.2627@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 21 Sep 2006, Shawn Pearce wrote:
>
>> I think its probably too late to change the UI[*1*] but I think
>> it is definately an issue for folks learning Git. Calling push
>> push, fetch fetch and fetch+merge pull is probably a design flaw.
>> IMHO it probably should have been something like:
>>
>> Current Shoulda Been
>> --------------- ----------------
>> git-push git-push
>> git-fetch git-pull
>> git-pull . foo git-merge foo
>> git-pull git-pull --merge
>> git-merge git-merge-driver
>>
>> in other words pull does the download and doesn't automatically
>> start a merge unless --merge was also given and git-merge is a
>> cleaner wrapper around the Grand Unified Merge Driver that makes
>> it easier to start a merge.
>
> I must say that I second this. Although I'm rather familiar with GIT I
> still feel unconfortable with the current naming and behavior.
Using git-pull . <branch> for _merge_, and git-merge being mid-level
command (one of the arguments is <msg>, instead of having git-commit like
ways to provide/amend commit message) is somewhat confusing.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Johannes Schindelin @ 2006-09-21 17:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0609211259340.2627@xanadu.home>
Hi,
On Thu, 21 Sep 2006, Nicolas Pitre wrote:
> On Thu, 21 Sep 2006, Shawn Pearce wrote:
>
> > I think its probably too late to change the UI[*1*] but I think
> > it is definately an issue for folks learning Git. Calling push
> > push, fetch fetch and fetch+merge pull is probably a design flaw.
> > IMHO it probably should have been something like:
> >
> > Current Shoulda Been
> > --------------- ----------------
> > git-push git-push
> > git-fetch git-pull
> > git-pull . foo git-merge foo
> > git-pull git-pull --merge
> > git-merge git-merge-driver
> >
> > in other words pull does the download and doesn't automatically
> > start a merge unless --merge was also given and git-merge is a
> > cleaner wrapper around the Grand Unified Merge Driver that makes
> > it easier to start a merge.
>
> I must say that I second this. Although I'm rather familiar with GIT I
> still feel unconfortable with the current naming and behavior.
Originally, I wanted to shut up about this issue. But since there are two
voices against the current naming, I want to speak for it.
When I was introduced to CVS, _I_ found the _CVS_ names misleading. I
thought that cvs update would throw away my changes.
So let's face it, a single name cannot possibly convey the meaning to that
many people, and therefore, it is _necessary_ to have a nice short
introduction, after which users actually know that git-pull is a fetch +
merge. Once you know it, what can possibly go wrong? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Shawn Pearce @ 2006-09-21 17:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609211259340.2627@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 21 Sep 2006, Shawn Pearce wrote:
> > Current Shoulda Been
> > --------------- ----------------
> > git-push git-push
> > git-fetch git-pull
> > git-pull . foo git-merge foo
> > git-pull git-pull --merge
> > git-merge git-merge-driver
> >
> > in other words pull does the download and doesn't automatically
> > start a merge unless --merge was also given and git-merge is a
> > cleaner wrapper around the Grand Unified Merge Driver that makes
> > it easier to start a merge.
>
> I must say that I second this. Although I'm rather familiar with GIT I
> still feel unconfortable with the current naming and behavior.
The only way I've been able to resolve it internally is to say:
``I can pull the changes contained in branch foo into
my current working branch by `git pull . foo`. I'm
not merging changes, I'm pulling them.``
Uh, yea....
As a prior user of a popular VCS which was also used by some folks
on LKML and which also had a 'pull=fetch+merge' command I fully
understand why its pull in Git - but I don't like it.
--
Shawn.
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Nicolas Pitre @ 2006-09-21 17:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060921162401.GD3934@spearce.org>
On Thu, 21 Sep 2006, Shawn Pearce wrote:
> I think its probably too late to change the UI[*1*] but I think
> it is definately an issue for folks learning Git. Calling push
> push, fetch fetch and fetch+merge pull is probably a design flaw.
> IMHO it probably should have been something like:
>
> Current Shoulda Been
> --------------- ----------------
> git-push git-push
> git-fetch git-pull
> git-pull . foo git-merge foo
> git-pull git-pull --merge
> git-merge git-merge-driver
>
> in other words pull does the download and doesn't automatically
> start a merge unless --merge was also given and git-merge is a
> cleaner wrapper around the Grand Unified Merge Driver that makes
> it easier to start a merge.
I must say that I second this. Although I'm rather familiar with GIT I
still feel unconfortable with the current naming and behavior.
Nicolas
^ 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