* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Michael J Gruber @ 2009-09-10 10:59 UTC (permalink / raw)
To: Johan Herland
Cc: git, Michael J Gruber, Johannes Schindelin, Junio C Hamano,
Jeff King, Björn Steinbrink, Pete Wyckoff
In-Reply-To: <200909101218.06789.johan@herland.net>
Johan Herland venit, vidit, dixit 10.09.2009 12:18:
> On Thursday 10 September 2009, Michael J Gruber wrote:
>> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
>>> Often, it is quite interesting to inspect the branch tracked by a
>>> given branch. This patch introduces a nice notation to get at the
>>> tracked branch: '<branch>@{tracked}' can be used to access that
>>> tracked branch.
>>>
>>> A special shortcut '@{tracked}' refers to the branch tracked by the
>>> current branch.
>>
>> Sorry, I didn't know the name of the long form was up for discussion.
>> But it should certainly coincide with the key which for-each-ref
>> uses, shouldn't it? I don't care whether tracked or upstream, but
>> for-each-ref's "upstream" has set the precedent.
>
> ...and 'git branch --track' set an even earlier precedent...
an unfortunate one, yes. It brings us back to an old discussion. The
consensus was what's in the glossary:
tracking branch
A regular git branch that is used to follow changes from
another repository. A tracking branch should
not contain direct modifications or have local commits made
to it. A tracking branch can usually be
identified as the right-hand-side ref in a Pull: refspec.
I.e., a tracking branch is something under refs/remotes/ (usually; I'll
use that simplification).
If I checkout -b myworkonit refs/remotes/origin/theirstuff then
myworkonit *does not track* origin/theirstuff according to the glossary
(but git checkout says so, unfortunately, and the option is named
likewise); rather, it has origin/theirstuff as its upstream.
In fact, refs/remotes/origin/theirstuff tracks whatever the name is on
the left hand side of the correspondig fetch refspec.
Maybe this is a good time to either
- change the definition of "tracking branch" (to one having an upstream
which is in refs/remotes/; and call "remote upbranch" what's in
refs/remotes/) or
- rename the option and output of git checkout -b/git branch --track.
Accordingly, either tracked or something else (such as upstream) would
be appropriate for the for-each-ref key and the ref specifier.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johan Herland @ 2009-09-10 10:18 UTC (permalink / raw)
To: git
Cc: Michael J Gruber, Johannes Schindelin, Junio C Hamano, Jeff King,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <4AA8CA88.9060802@drmicha.warpmail.net>
On Thursday 10 September 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
> > Often, it is quite interesting to inspect the branch tracked by a
> > given branch. This patch introduces a nice notation to get at the
> > tracked branch: '<branch>@{tracked}' can be used to access that
> > tracked branch.
> >
> > A special shortcut '@{tracked}' refers to the branch tracked by the
> > current branch.
>
> Sorry, I didn't know the name of the long form was up for discussion.
> But it should certainly coincide with the key which for-each-ref
> uses, shouldn't it? I don't care whether tracked or upstream, but
> for-each-ref's "upstream" has set the precedent.
...and 'git branch --track' set an even earlier precedent...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 10:14 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Jeff King, Björn Steinbrink, Pete Wyckoff,
git
In-Reply-To: <4AA8CA88.9060802@drmicha.warpmail.net>
Hi,
On Thu, 10 Sep 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
> >
> > Often, it is quite interesting to inspect the branch tracked by a given
> > branch. This patch introduces a nice notation to get at the tracked
> > branch: '<branch>@{tracked}' can be used to access that tracked branch.
> >
> > A special shortcut '@{tracked}' refers to the branch tracked by the
> > current branch.
>
> Sorry, I didn't know the name of the long form was up for discussion.
> But it should certainly coincide with the key which for-each-ref uses,
> shouldn't it? I don't care whether tracked or upstream, but
> for-each-ref's "upstream" has set the precedent.
You're right.
sed -i -e 's/@{tracked}/@{upstream}/g' -e 's/@{t}/@{u}/g' $PATCH
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Michael J Gruber @ 2009-09-10 9:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Björn Steinbrink, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909101135590.8306@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
>
> Often, it is quite interesting to inspect the branch tracked by a given
> branch. This patch introduces a nice notation to get at the tracked
> branch: '<branch>@{tracked}' can be used to access that tracked branch.
>
> A special shortcut '@{tracked}' refers to the branch tracked by the
> current branch.
Sorry, I didn't know the name of the long form was up for discussion.
But it should certainly coincide with the key which for-each-ref uses,
shouldn't it? I don't care whether tracked or upstream, but
for-each-ref's "upstream" has set the precedent.
>
> Suggested by Pasky.
>
> The syntax was suggested by Junio.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I decided that I like @{tracked} better than @{upstream} (which
> reads to me more like the upstream _repository_), but hey, I made
> the code flexible enough to change that at a whim.
>
> Documentation/git-rev-parse.txt | 4 ++
> sha1_name.c | 37 ++++++++++++++++++++--
> t/t1506-rev-parse-tracked.sh | 64 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 102 insertions(+), 3 deletions(-)
> create mode 100755 t/t1506-rev-parse-tracked.sh
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 82045a2..09a2145 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -231,6 +231,10 @@ when you run 'git-merge'.
> * The special construct '@\{-<n>\}' means the <n>th branch checked out
> before the current one.
>
> +* The suffix '@{tracked}' to a ref (short form 'blabla@{t}') refers to
> + the branch tracked by that ref. If no ref was specified, it means the
> + branch tracked by the current branch.
> +
> * A suffix '{caret}' to a revision parameter means the first parent of
> that commit object. '{caret}<n>' means the <n>th parent (i.e.
> 'rev{caret}'
> diff --git a/sha1_name.c b/sha1_name.c
> index 44bb62d..a886846 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -5,6 +5,7 @@
> #include "blob.h"
> #include "tree-walk.h"
> #include "refs.h"
> +#include "remote.h"
>
> static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
> {
> @@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
> return slash;
> }
>
> +static inline int tracked_suffix(const char *string, int len)
> +{
> + const char *suffix[] = { "@{tracked}", "@{t}" };
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(suffix); i++) {
> + int suffix_len = strlen(suffix[i]);
> + if (len >= suffix_len && !memcmp(string + len - suffix_len,
> + suffix[i], suffix_len))
> + return suffix_len;
> + }
> + return 0;
> +}
> +
> /*
> * *string and *len will only be substituted, and *string returned (for
> - * later free()ing) if the string passed in is of the form @{-<n>}.
> + * later free()ing) if the string passed in is of the form @{-<n>} or
> + * of the form <branch>@{tracked}.
> */
> static char *substitute_branch_name(const char **string, int *len)
> {
> @@ -254,6 +270,19 @@ static char *substitute_branch_name(const char **string, int *len)
> return (char *)*string;
> }
>
> + ret = tracked_suffix(*string, *len);
> + if (ret) {
> + char *ref = xstrndup(*string, *len - ret);
> + struct branch *tracking = branch_get(*ref ? ref : NULL);
> +
> + free(ref);
> + if (tracking->merge && tracking->merge[0]->dst) {
> + *string = xstrdup(tracking->merge[0]->dst);
> + *len = strlen(*string);
> + return (char *)*string;
> + }
> + }
> +
> return NULL;
> }
>
> @@ -340,8 +369,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
> if (len && str[len-1] == '}') {
> for (at = len-2; at >= 0; at--) {
> if (str[at] == '@' && str[at+1] == '{') {
> - reflog_len = (len-1) - (at+2);
> - len = at;
> + if (!tracked_suffix(str + at, len - at)) {
> + reflog_len = (len-1) - (at+2);
> + len = at;
> + }
> break;
> }
> }
> diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
> new file mode 100755
> index 0000000..89193e1
> --- /dev/null
> +++ b/t/t1506-rev-parse-tracked.sh
> @@ -0,0 +1,64 @@
> +#!/bin/sh
> +
> +test_description='test <branch>@{tracked} syntax'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'setup' '
> +
> + test_commit 1 &&
> + git checkout -b side &&
> + test_commit 2 &&
> + git checkout master &&
> + git clone . clone &&
> + test_commit 3 &&
> + (cd clone &&
> + test_commit 4 &&
> + git branch --track my-side origin/side)
> +
> +'
> +
> +full_name () {
> + (cd clone &&
> + git rev-parse --symbolic-full-name "$@")
> +}
> +
> +commit_subject () {
> + (cd clone &&
> + git show -s --pretty=format:%s "$@")
> +}
> +
> +test_expect_success '@{tracked} resolves to correct full name' '
> + test refs/remotes/origin/master = "$(full_name @{tracked})"
> +'
> +
> +test_expect_success '@{t} resolves to correct full name' '
> + test refs/remotes/origin/master = "$(full_name @{t})"
> +'
> +
> +test_expect_success 'my-side@{tracked} resolves to correct full name' '
> + test refs/remotes/origin/side = "$(full_name my-side@{t})"
> +'
> +
> +test_expect_success 'my-side@{t} resolves to correct commit' '
> + git checkout side &&
> + test_commit 5 &&
> + (cd clone && git fetch) &&
> + test 2 = "$(commit_subject my-side)" &&
> + test 5 = "$(commit_subject my-side@{t})"
> +'
> +
> +test_expect_success 'not-tracking@{t} fails' '
> + test_must_fail full_name non-tracking@{t} &&
> + (cd clone && git checkout --no-track -b non-tracking) &&
> + test_must_fail full_name non-tracking@{t}
> +'
> +
> +test_expect_success '<branch>@{t}@{1} resolves correctly' '
> + test_commit 6 &&
> + (cd clone && git fetch) &&
> + test 5 = $(commit_subject my-side@{t}@{1})
> +'
> +
> +test_done
^ permalink raw reply
* [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 9:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Björn Steinbrink, Michael J Gruber, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909100941330.8306@pacific.mpi-cbg.de>
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '<branch>@{tracked}' can be used to access that tracked branch.
A special shortcut '@{tracked}' refers to the branch tracked by the
current branch.
Suggested by Pasky.
The syntax was suggested by Junio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I decided that I like @{tracked} better than @{upstream} (which
reads to me more like the upstream _repository_), but hey, I made
the code flexible enough to change that at a whim.
Documentation/git-rev-parse.txt | 4 ++
sha1_name.c | 37 ++++++++++++++++++++--
t/t1506-rev-parse-tracked.sh | 64 +++++++++++++++++++++++++++++++++++++++
3 files changed, 102 insertions(+), 3 deletions(-)
create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 82045a2..09a2145 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -231,6 +231,10 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The suffix '@{tracked}' to a ref (short form 'blabla@{t}') refers to
+ the branch tracked by that ref. If no ref was specified, it means the
+ branch tracked by the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..a886846 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
+static inline int tracked_suffix(const char *string, int len)
+{
+ const char *suffix[] = { "@{tracked}", "@{t}" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(suffix); i++) {
+ int suffix_len = strlen(suffix[i]);
+ if (len >= suffix_len && !memcmp(string + len - suffix_len,
+ suffix[i], suffix_len))
+ return suffix_len;
+ }
+ return 0;
+}
+
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form <branch>@{tracked}.
*/
static char *substitute_branch_name(const char **string, int *len)
{
@@ -254,6 +270,19 @@ static char *substitute_branch_name(const char **string, int *len)
return (char *)*string;
}
+ ret = tracked_suffix(*string, *len);
+ if (ret) {
+ char *ref = xstrndup(*string, *len - ret);
+ struct branch *tracking = branch_get(*ref ? ref : NULL);
+
+ free(ref);
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
@@ -340,8 +369,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (len && str[len-1] == '}') {
for (at = len-2; at >= 0; at--) {
if (str[at] == '@' && str[at+1] == '{') {
- reflog_len = (len-1) - (at+2);
- len = at;
+ if (!tracked_suffix(str + at, len - at)) {
+ reflog_len = (len-1) - (at+2);
+ len = at;
+ }
break;
}
}
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..89193e1
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+test_description='test <branch>@{tracked} syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '@{tracked} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{tracked})"
+'
+
+test_expect_success '@{t} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{t})"
+'
+
+test_expect_success 'my-side@{tracked} resolves to correct full name' '
+ test refs/remotes/origin/side = "$(full_name my-side@{t})"
+'
+
+test_expect_success 'my-side@{t} resolves to correct commit' '
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject my-side@{t})"
+'
+
+test_expect_success 'not-tracking@{t} fails' '
+ test_must_fail full_name non-tracking@{t} &&
+ (cd clone && git checkout --no-track -b non-tracking) &&
+ test_must_fail full_name non-tracking@{t}
+'
+
+test_expect_success '<branch>@{t}@{1} resolves correctly' '
+ test_commit 6 &&
+ (cd clone && git fetch) &&
+ test 5 = $(commit_subject my-side@{t}@{1})
+'
+
+test_done
--
1.6.4.313.g3d9e3
^ permalink raw reply related
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-10 9:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <200909081436.30761.johan@herland.net>
On Tuesday 08 September 2009, Johan Herland wrote:
> On Tuesday 08 September 2009, Johannes Schindelin wrote:
> > On Tue, 8 Sep 2009, Johan Herland wrote:
> > > Algorithm / Notes tree git log -n10 (x100) git log --all
> > > ------------------------------------------------------------
> > > next / no-notes 4.77s 63.84s
> > >
> > > before / no-notes 4.78s 63.90s
> > > before / no-fanout 56.85s 65.69s
> > >
> > > 16tree / no-notes 4.77s 64.18s
> > > 16tree / no-fanout 30.35s 65.39s
> > > 16tree / 2_38 5.57s 65.42s
> > > 16tree / 2_2_36 5.19s 65.76s
> > >
> > > flexible / no-notes 4.78s 63.91s
> > > flexible / no-fanout 30.34s 65.57s
> > > flexible / 2_38 5.57s 65.46s
> > > flexible / 2_2_36 5.18s 65.72s
> > > flexible / ym 5.13s 65.66s
> > > flexible / ym_2_38 5.08s 65.63s
> > > flexible / ymd 5.30s 65.45s
> > > flexible / ymd_2_38 5.29s 65.90s
> > > flexible / y_m 5.11s 65.72s
> > > flexible / y_m_2_38 5.08s 65.67s
> > > flexible / y_m_d 5.06s 65.50s
> > > flexible / y_m_d_2_38 5.07s 65.79s
[snip]
> > - I'd love to see performance numbers for less than 157118 notes.
> > Don't get me wrong, it is good to see the worst-case scenario in
> > terms of notes/commits ratio. But it will hardly be the common case,
> > and I very much would like to optimize for the common case.
> >
> > So, I'd appreciate if you could do the tests with something like
> > 500 notes, randomly spread over the commits (rationale: my original
> > understanding was that the notes could amend commit messages, and
> > that is much more likely to be done with relatively old commits that
> > you cannot change anymore).
>
> Ok. I will try to test that.
Here are the results of the 500-notes-in-kernel-repo test:
Algorithm / Notes tree git log -n10 (x100) git log --all
next / no-notes 4.83s 64.78s
before / no-notes 4.84s 64.76s
before / no-fanout 4.98s 64.89s
16tree / no-notes 4.84s 64.61s
16tree / no-fanout 4.92s 64.68s
16tree / 2_38 4.85s 64.45s
16tree / 2_2_36 4.85s 64.63s
flexible / no-notes 4.84s 64.82s
flexible / no-fanout 4.91s 65.01s
flexible / 2_38 4.85s 64.93s
flexible / 2_2_36 4.85s 64.63s
flexible / ym 4.83s 64.63s
flexible / ym_2_38 4.86s 64.72s
flexible / ymd 4.91s 64.74s
flexible / ymd_2_38 4.91s 64.56s
flexible / y_m 4.86s 64.76s
flexible / y_m_2_38 4.86s 64.71s
flexible / y_m_d 4.86s 64.73s
flexible / y_m_d_2_38 4.84s 64.50s
I don't like the noise level in the second column ('git log --all'). Then
again, I don't find that column very interesting (it's mostly there to
verify that we don't have any abysmal worst-case behaviours in the notes
code).
The first column is fairly nice and tidy, though. At a first glance it shows
pretty much the same results as the 157000-notes table previously posted.
Obviously the abysmal performance of no-fanout is gone (500 notes in a
single tree object is not _that_ bad), although a 2/38-fanout is still a
better choice for 500 notes (but 2/2/36 does not provide any additional
improvement).
>From this we can start to guess that the threshold for moving from no fanout
to 2/38 is somewhere below 500 notes, while the theshold for moving from
2/38 to 2/2/36 is between 500 and ~157000 notes (probably much closer to
157000 than to 500; I wouldn't be surprised if ~256 entries per level turns
out to be good a threshold).
The date-based fanout performs on par with the SHA1-based fanout, although
it's hard to say anything conclusively when the numbers are as close as
this. However, the ymd and ymd_2_38 fanout probably show signs of too much
overhead (too many levels) at only 500 notes. This is not surprising.
My gut feeling tells me that moving from 'no-fanout' to either '2_38' or
'ym' is a good idea at ~256 notes. Then, if we went with '2_38', we'd have
to switch to '2_2_36' at ~64K notes (i.e. when each /38 level reaches ~256
notes) However, it seems that with 'ym', we could stick with it for much
longer before having to consider switching to a different fanout alternative
(probably 'ym_2_38' or 'y_m_d').
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-10 9:16 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
On Thu, 10 Sep 2009, Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Brendan Miller <catphive@catphive.net> writes:
>> First question: which git version do you use?
>
> It sounds like a bunch of things have been fixed in yet to be released
> versions. That's great.
Both "git init --bare" and cloning empty repository are in _released_
versions.
>>> This is what I want to do 90% of the time, so it should just have the
>>> proper defaults, and not make me look at the man page every time I
>>> want to use it.
>>
>> You learn those idioms.
>
> I guess. Is that a good thing? Is the goal of interface design to make
> it difficult so I need to learn a lot of things, or easy so I can
> remain blissfully ignorant but still do what I want?
There are at least two issues:
1. What you want to do 90% of time might be not what other people want
to do 90% of time.
2. Some thing are due to git philosophy (like e.g. "git commit -a").
As to git-archive example: first, git-archive _has_ default format, and
it is tar. Second, compression is better left to separate program, but
I guess we can follow GNU tar example and add equivalents of -Z/-z/-j
and --use-compress-program options when using --output=<file>. Third,
when using e.g. tar you have to specify files to compress, so I don't
know why you complain that git-archive requires equivalent, HEAD in your
example.
>>> 6. Where is the bug tracker? If people users can't find the bug
>>> tracker, they can't report issues, and obnoxious bugs go unfixed, or
>>> people have to whine on the mailing list. There should be a nice big
>>> link on the front page of git-scm.com. A bug tracker is really the
>>> only way for the vast majority of a community that use a tool can give
>>> feedback on the problems the tool has.
>>
>> Do you offer to maintain and manage such bug tracker? I mean here
>> taking care of duplicated bugs, tracking which bugs are resolved and
>> which are not, checking if bug is reproductible, etc. Do you?
>> Unmaintained bugtracker is worse than useless.
>>
>> Using mailing list for bug reports and for patches is time-honored
>> workflow, which works rather well for smaller projects such as Git.
>> Note that git mailing list is free for all; you don't need to
>> subscribe to send, and you can watch it via many archives and gateways
>> (like GMane).
>
> Bug trackers are a hassle, believe me, I know... but I think they
> contribute to the overall quality of the product if used effectively.
> Mailing lists seem like a good way to forget about bugs after people
> have given up on getting developers to fix them.
This is a good way to separate important from unimportant bug reports
and feature requests ;-)
>>> 7. Man pages: It's nice we have them, but we shouldn't need them to do
>>> basic stuff. I rarely had to look at the man pages using svn, but
>>> every single time I use git I have to dig into these things. Frankly,
>>> I have better things to do than RTFM.
>>
>> Learn. If you learn the philosophy behind git design, you would have
>> much easier understanding and remembering git.
>
> I think what you mean by philosophy is the underlying data structures,
> which are discussed in the manual (how many apps do you have that do
> that!). I have read that. However, that one needs to understand
> underlying data structure is just one more hurdle to understanding
> git.
No, I didn't mean understanding underlying data structures, but
understanding philosophy: graph of revisions; tracking contents; refs
as pointers to graph of revisions; the trifecta of working area,
the index and repository, etc.
> If I use GCC, do I need to know that it has a recursive descent
> parser? That it is implemented with a garbage collector? No. I just
> need to know that I give it C, and it gives me a binary.
Better example would be using "make". You need to understand 'make'
philosophy to write all but most simple of Makefiles.
>
> Example:
> gcc main.c
>
> Think about all the defaults that are specified here! I don't
> explicitly tell it how to find libc.so or what path the dynamic linker
> is at. I don't even really need to tell it which operation it is
> performing, i.e. generating a binary, .o, .so, .os, .a, etc because it
> has a smart default.
And if you are smart, you never use this form, but "gcc -o main main.c".
And you have to specify '-lm' if you use math routines. Not that simple,
isn't it?
> This an order of magnitude more complex than any git operation in
> terms of implementation, but it is dead simple from the users
> perspective.
When git (or the concept of DVCS) is as old as gcc (or C compiler) is
now, then we can talk.
>> There is "Git User's Manual", "The Git Community Book", "Pro Git" and
>> many other references.
>
> Yeah, I've been reading them. I'm saying that the docs are a crutch.
> RTFM is the problem not the solution. It makes the user do more work
> to avoid fixing usability issues.
When the tool is more complicated (like DVCS), you can't use it in all
but simplest cases without understanding it.
> A CLI has some inherent limitations in that it doesn't have big
> labeled buttons to press. However, that doesn't mean it has to be hard
> to use. I think a lot of the strength of the linux CLI is that most of
> the utilities have actually pretty well thought out interfaces that
> have been refined over time. That one's that aren't like that... well,
> no one uses them.
>
> I'm not saying that a unixy approach is wrong, but that most unix
> utilities are much easier to use than git, and that git needs
> improvement on this front.
I'm not saying that git doesn't need UI (and documentation) improvements.
But first, your attitude is a bit grating, and second, your examples
are not it.
On the other hand there is inherent problems that serious git
contributors use git for a long time and are used to (and perhaps even
attached to) git UI warts, and newbies which start to use git not always
can distinguish between things that can be changed and things that cannot
be changed.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH] Add import -p option
From: Karl Wiberg @ 2009-09-10 8:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Gustav Hållberg, Git Mailing List
In-Reply-To: <b0943d9e0909091509i16b556f0x9dd3aa6788054298@mail.gmail.com>
On 2009-09-09 23:09:51 +0100, Catalin Marinas wrote:
> 2009/9/8 Karl Wiberg <kha@treskal.com>:
>
> > On 2009-09-08 22:43:39 +0100, Catalin Marinas wrote:
> >
> > > + if strip:
> > > + cmd += ['-p', strip]
> >
> > This test should probably be "if strip != None". It doesn't
> > _really_ matter, technically, since -p0 is the default, but still
> > ...
>
> I modified it after posting the patch. The git default is -p1, so we
> would miss the -p0 case.
Ah ha! Sometimes it actually does pay to be pedantic ...
--
Karl Wiberg, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: tracking branch for a rebase
From: Johannes Schindelin @ 2009-09-10 7:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Björn Steinbrink, Michael J Gruber, Pete Wyckoff,
git
In-Reply-To: <7vzl93cncn.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 9 Sep 2009, Junio C Hamano wrote:
> I find a prefix % not descriptive enough (besides being ugly); if it were
> "^branch", as some people said, it would probably have matched its meaning
> "up", but that notation is already taken for "uninteresting".
How about ^^branch? *ducks*
Seriously again, I think that ^{tracking} (with shorthand ^t, maybe) is
not too shabby an option. The point is: if we make this unattractive
enough by requiring a lot of typing, we will never get to the point where
it is popular enough to make a shorthand: it just will not be used at all.
> When I say there is only one kind of magic notation for refs, I am
> primarily talking about the end-user perception. @{time}, @{number} and
> @{-number} all do their magic using the reflog, but that is about _how_
> they do what they do. End-user perception begins with _what_ they do, and
> at that level, the magic consistently works on refs and different genie is
> summoned depending on what is inside {}.
>
> The @{upstream} thing won't be using reflog to do its job, but that is
> about _how_ it is implemented, and the end users don't care.
Ah, I get what you're saying. @{2.days.ago} says something about this
branch locally, but @{upstream} says something about this branch remotely
(well, our local cache). From that view point, it makes sense.
But my point stands: @{upstream} is too awkward to type. Let's have _at
least_ a shortcut '@{up}'.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] git-p4: Avoid modules deprecated in Python 2.6.
From: Reilly Grant @ 2009-09-10 7:02 UTC (permalink / raw)
To: git, gitster; +Cc: Reilly Grant
The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
Python 2.5). Both popen2 and sha are not actually used in git-p4.
Replace usage of sets.Set with the builtin set object.
The built-in set object was added in Python 2.4 and is already used in
other parts of this script, so this dependency is nothing new.
Signed-off-by: Reilly Grant <reillyeon@qotw.net>
---
contrib/fast-import/git-p4 | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 38438f3..e710219 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -8,12 +8,10 @@
# License: MIT <http://www.opensource.org/licenses/mit-license.php>
#
-import optparse, sys, os, marshal, popen2, subprocess, shelve
-import tempfile, getopt, sha, os.path, time, platform
+import optparse, sys, os, marshal, subprocess, shelve
+import tempfile, getopt, os.path, time, platform
import re
-from sets import Set;
-
verbose = False
@@ -864,8 +862,8 @@ class P4Sync(Command):
self.usage += " //depot/path[@revRange]"
self.silent = False
- self.createdBranches = Set()
- self.committedChanges = Set()
+ self.createdBranches = set()
+ self.committedChanges = set()
self.branch = ""
self.detectBranches = False
self.detectLabels = False
@@ -1662,7 +1660,7 @@ class P4Sync(Command):
if len(self.changesFile) > 0:
output = open(self.changesFile).readlines()
- changeSet = Set()
+ changeSet = set()
for line in output:
changeSet.add(int(line))
--
1.6.3.3
^ permalink raw reply related
* Re: tracking branch for a rebase
From: Junio C Hamano @ 2009-09-10 6:42 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090909104550.GA20108@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I wonder if it is worth adding @{upstream} now, which is fairly safe,
> letting it cook for a while, and then adding a "%" alias later after the
> concept has proved itself (and people say "I like this feature, but it
> really is too much to type").
That's a sane suggestion, I think. We can always have a descriptive
longhand (e.g. "branch@{upstream}") and later add a shorthand for often
used ones (e.g. "branch^up", "branch/.up" --- the former is possible
because it cannot be upth parent of the commit at the tip of the branch,
and the latter is possible because component of hierarchical refname
cannot begin with a dot).
I find a prefix % not descriptive enough (besides being ugly); if it were
"^branch", as some people said, it would probably have matched its meaning
"up", but that notation is already taken for "uninteresting". If we are
going to use funny symbol as a notation to invoke magic, I think it is
easier for new people if we limit the number of symbols used. We already
have ^n, ^{type} and ~n magic, all of which operate on objects and peel
them in three different ways.
Then there currently is only one kind of magic that works on refs and it
is spelled as ref@{magic}. Let's try not to introduce more notation
before it is absolutely necessary.
When I say there is only one kind of magic notation for refs, I am
primarily talking about the end-user perception. @{time}, @{number} and
@{-number} all do their magic using the reflog, but that is about _how_
they do what they do. End-user perception begins with _what_ they do, and
at that level, the magic consistently works on refs and different genie is
summoned depending on what is inside {}.
The @{upstream} thing won't be using reflog to do its job, but that is
about _how_ it is implemented, and the end users don't care.
What is more important is _what_ it does. Given a ref, the @{} magic
notation finds something that is related to the ref. @{time} and
@{number} finds what the ref itself used to point at. @{-number}
(applicable only to HEAD ref) finds the ref it used to point at. And
@{upstream} will find another ref that it merges from (or rebases onto).
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Stephen R. van den Berg @ 2009-09-10 6:23 UTC (permalink / raw)
To: Johan Herland
Cc: Johannes Schindelin, git, Junio C Hamano, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200909090046.45213.johan@herland.net>
Johan Herland wrote:
>I was, however, naive enough to assume that when git.git decided on using
>2/38 fanout for its loose objects, then some performance-related thoughts
>went into that decision. If there are indications that multiple-of-2-type
I presume that that choice was based on the fact that on a typical filesystem
(e.g. ext2 old-style) without directory indexing, the sort-of optimal fanout
should aim for no more than 100-200 directory entries per directory.
--
Sincerely,
Stephen R. van den Berg.
Mommy, what happens to your files when you die?
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Björn Steinbrink @ 2009-09-10 1:32 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
On 2009.09.09 14:27:56 -0700, Brendan Miller wrote:
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
>
> git remote setdefault origin
Because "git remote" is the wrong tool. The default remote for
fetch/push is configured per branch head, not globally.
> or even
>
> git remote add --default origin http://somegiturl.org/
Because that would likely mean changing all the existing branch head
configurations, quite possibly making them invalid, because the
branch.<name>.merge value suddenly makes no sense anymore.
> This come up in the use case where I:
> 1. set up a remote bare repo
> 2. push from my local repo, and thence forth want to keep local and
> remote in sink.
Maybe you want something like this?
http://thread.gmane.org/gmane.comp.version-control.git/107671
> Right now I have to modify .git/config to do this.
You can also do:
git config branch.<name>.remote <remote>
which does the config editing for you.
And maybe:
git config branch.<name>.merge <ref>
if you also want just "git pull" to work, or use push.default = tracking.
There's also still my old "retrack" hack, which John Wiegley extended:
http://github.com/jwiegley/git-scripts/blob/6ba3184d7b9f6dae3d10379a6bac29a01ceef190/git-retrack
That's a bit more comfortable, but probably doesn't work for a lot of
"non-standard" setups.
Björn
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Todd Zullinger @ 2009-09-10 1:25 UTC (permalink / raw)
To: Brendan Miller; +Cc: Jakub Narebski, git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Brendan Miller <catphive@catphive.net> writes:
>> First question: which git version do you use?
>
> It sounds like a bunch of things have been fixed in yet to be released
> versions. That's great.
If I am not mistaken, support for cloning an empty repo was available
in 1.6.2, which was released in March.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Drugs may lead to nowhere, but at least it's the scenic route.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [git-svn] always prompted for passphrase with subversion 1.6
From: Tim Potter @ 2009-09-10 0:58 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090905064649.GD22272@dcvr.yhbt.net>
Eric Wong wrote:
> Tim Potter <tpot@hp.com> wrote:
>> Hi everyone. I am using git-svn with the Subversion 1.6 client compiled
>> with GNOME Keyring support. This neat features allows a SSL client
>> certificate password to be cached inside GNOME Keyring instead of being
>> prompted to enter it every time. However the git-svn script doesn't
>> appear to know about this and always prompts for a password.
>>
>> Obviously there's some tweak required in the _auth_providers()
>> subroutine but I don't know enough about the Subversion Perl client to
>> figure out a fix.
>>
>> Has anyone else run in to this problem? I did a quick search on the
>> list but didn't find anything relevant.
>
> Hi Tim,
>
> I think one user wanted to get SSL certificate authentication going but
> my SSL knowledge was too weak at the time[1] and I think we both forgot
> about it or lost interest.
Hi Eric. Thanks for the reply.
It's probably just a matter of adding another entry to the
_auth_providers() function in git-svn. My thought was that there might
be a new auth provider in the Subversion 1.6 client library for GNOME
Keyring support that could be used for this.
I'll have a search through and see what I can find.
Regards,
Tim.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Brendan Miller @ 2009-09-10 0:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3fxavvl5k.fsf@localhost.localdomain>
On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Brendan Miller <catphive@catphive.net> writes:
> First question: which git version do you use?
It sounds like a bunch of things have been fixed in yet to be released
versions. That's great.
>>
>> This is what I want to do 90% of the time, so it should just have the
>> proper defaults, and not make me look at the man page every time I
>> want to use it.
>
> You learn those idioms.
I guess. Is that a good thing? Is the goal of interface design to make
it difficult so I need to learn a lot of things, or easy so I can
remain blissfully ignorant but still do what I want?
>
>>
>> 6. Where is the bug tracker? If people users can't find the bug
>> tracker, they can't report issues, and obnoxious bugs go unfixed, or
>> people have to whine on the mailing list. There should be a nice big
>> link on the front page of git-scm.com. A bug tracker is really the
>> only way for the vast majority of a community that use a tool can give
>> feedback on the problems the tool has.
>
> Do you offer to maintain and manage such bug tracker? I mean here
> taking care of duplicated bugs, tracking which bugs are resolved and
> which are not, checking if bug is reproductible, etc. Do you?
> Unmaintained bugtracker is worse than useless.
>
> Using mailing list for bug reports and for patches is time-honored
> workflow, which works rather well for smaller projects such as Git.
> Note that git mailing list is free for all; you don't need to
> subscribe to send, and you can watch it via many archives and gateways
> (like GMane).
Bug trackers are a hassle, believe me, I know... but I think they
contribute to the overall quality of the product if used effectively.
Mailing lists seem like a good way to forget about bugs after people
have given up on getting developers to fix them.
>
>>
>> 7. Man pages: It's nice we have them, but we shouldn't need them to do
>> basic stuff. I rarely had to look at the man pages using svn, but
>> every single time I use git I have to dig into these things. Frankly,
>> I have better things to do than RTFM.
>
> Learn. If you learn the philosophy behind git design, you would have
> much easier understanding and remembering git.
I think what you mean by philosophy is the underlying data structures,
which are discussed in the manual (how many apps do you have that do
that!). I have read that. However, that one needs to understand
underlying data structure is just one more hurdle to understanding
git.
If I use GCC, do I need to know that it has a recursive descent
parser? That it is implemented with a garbage collector? No. I just
need to know that I give it C, and it gives me a binary.
Example:
gcc main.c
Think about all the defaults that are specified here! I don't
explicitly tell it how to find libc.so or what path the dynamic linker
is at. I don't even really need to tell it which operation it is
performing, i.e. generating a binary, .o, .so, .os, .a, etc because it
has a smart default.
This an order of magnitude more complex than any git operation in
terms of implementation, but it is dead simple from the users
perspective.
>
> There is "Git User's Manual", "The Git Community Book", "Pro Git" and
> many other references.
Yeah, I've been reading them. I'm saying that the docs are a crutch.
RTFM is the problem not the solution. It makes the user do more work
to avoid fixing usability issues.
A CLI has some inherent limitations in that it doesn't have big
labeled buttons to press. However, that doesn't mean it has to be hard
to use. I think a lot of the strength of the linux CLI is that most of
the utilities have actually pretty well thought out interfaces that
have been refined over time. That one's that aren't like that... well,
no one uses them.
I'm not saying that a unixy approach is wrong, but that most unix
utilities are much easier to use than git, and that git needs
improvement on this front.
Brendan
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Nanako Shiraishi @ 2009-09-09 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Clemens Buchacher, SZEDER Gbor, git
In-Reply-To: <7vy6ot4x61.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> We could probably declare "In 1.X.0 everything will be relative to the
> root and you have to give an explicit '.' if you mean the cwd".
>
> Three questions:
>
> #1 What are the commands that will be affected, other than "add -u" and
> "grep"? Are there others?
>
> #2 Do all the commands in the answer to #1 currently behave exactly the
> same when run without any path parameter and when run with a single
> '.'?
'git-archive' behaves relative to your current directory.
http://thread.gmane.org/gmane.comp.version-control.git/41300/focus=44125
You can limit it to the current directory with a dot.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Pierre Habouzit @ 2009-09-09 22:58 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On Wed, Sep 09, 2009 at 02:27:56PM -0700, Brendan Miller wrote:
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
>
> git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
>
> Should just be:
> git archive
> run from the root of the repo.
You can't, because "myproject" cannot be guessed most of the time.
If you really want to automatize it, it's a 2 liner shell script, or
alternatively you can add that to your .gitconfig:
[alias]
archive-gz=!git archive --prefix="$(basename "$(dirname "$(readlink -m "$(git rev-parse --git-dir)")")")"/ HEAD | gzip -c
It will use the name of the directory containing your .git/ directory as a
prefix, and compress it using gzip to stdout.
git archive-gz > myproject.tar.gz will do what you want.
See, that's the point about git having so many flags. You only need to
look the man page _once_ (despite what you pretend): the one time you
need to write your convenient wrapper around git commands that suits
your exact needs.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Problem with "dashless options"
From: Pierre Habouzit @ 2009-09-09 22:49 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: Jeff King, git
In-Reply-To: <4EEF55B5-46E1-4C06-AA60-62F700F7B279@isy.liu.se>
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
On Wed, Sep 09, 2009 at 11:12:12PM +0200, Henrik Tidefelt wrote:
> No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so
> to avoid the trouble I was previously experiencing from accidentally
> typing the instead of space without being able to see the
> difference on screen. Why would it matter?
well because then one of your space could have been that, and the shell
doesn't consider non breakable space as .. breakable, hence you can read
something where you believe there is (n+1) arguments but the shell (and
git) see only n.
It often yields errors really hard to grasp like the dreaded:
$ ls | grep
zsh: command not found: grep
notice the ^
sorry then I don't really know what happened...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Wincent Colaiuta @ 2009-09-09 22:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Brendan Miller, git
In-Reply-To: <m3fxavvl5k.fsf@localhost.localdomain>
El 09/09/2009, a las 23:54, Jakub Narebski escribió:
> Brendan Miller <catphive@catphive.net> writes:
>
>> 5. Most commands require lots of flags, and don't have reasonable
>> defaults. e.g. archive.
>>
>> git archive --format=tar --prefix=myproject/ HEAD | gzip
>> >myproject.tar.gz
>>
>> Should just be:
>> git archive
>> run from the root of the repo.
>
> I'd rather not have "git archive" work without specifying tree-ish.
Why, out of interest? I would've thought that HEAD would be a pretty
good default, although I confess that I have never used "git archive"
without specifying a particular signed tag.
Cheers,
Wincent
^ permalink raw reply
* Re: [StGit PATCH] Add import -p option
From: Catalin Marinas @ 2009-09-09 22:09 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Gustav Hållberg, Git Mailing List
In-Reply-To: <20090908223714.GA6364@diana.vm.bytemark.co.uk>
2009/9/8 Karl Wiberg <kha@treskal.com>:
> On 2009-09-08 22:43:39 +0100, Catalin Marinas wrote:
>
>> This patch renames some of the existing import options and adds the
>> -p (--strip) option which allows stripping the leading slashes of
>> the diff paths.
>
> Looks good (and the intent is very good). The import test should
> probably be augmented with a test case for -pN, though.
Yes. I'll try to add one. As you noticed, not all options are tested.
>> + if strip:
>> + cmd += ['-p', strip]
>
> This test should probably be "if strip != None". It doesn't _really_
> matter, technically, since -p0 is the default, but still ...
I modified it after posting the patch. The git default is -p1, so we
would miss the -p0 case.
--
Catalin
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Sverre Rabbelier @ 2009-09-09 21:58 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
Heya,
On Wed, Sep 9, 2009 at 23:27, Brendan Miller<catphive@catphive.net> wrote:
> 1. cloning from a new empty repo fails, and so do a lot of other
> operations. This adds unnecessary steps to setting up a new shared
> repo.
Actually, it works in recent git.
> 2. git --bare init. The flag goes before the operation unlike every other flag?
Because unlike most flags it applies to anything git does, e.g. 'git
--bare status' to treat the current directory as a git repository
rather than looking for a .git directory.
> 4. The index is inconsistently referred to as too many different
> things (cache, index, staging area) and only the last one makes any
> intuitive sense to a new user. This is partially a CLI issue, and
> partially a documentation issue, but both add up to cause confusion.
>
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
Most git commands need no more than two flags, and the defaults are
reasonable to me; of course everybody has different needs, git
aliasses make it easy to overcome this.
> This is what I want to do 90% of the time, so it should just have the
> proper defaults, and not make me look at the man page every time I
> want to use it.
Again, make an alias if you use it a lot; it might be what _you_ want
to do, but as you can see from the plethora of other examples, it is
perhaps not what everybody else wants to do 90% of the time.
> 6. Where is the bug tracker? If people users can't find the bug
> tracker, they can't report issues, and obnoxious bugs go unfixed, or
> people have to whine on the mailing list. There should be a nice big
> link on the front page of git-scm.com. A bug tracker is really the
> only way for the vast majority of a community that use a tool can give
> feedback on the problems the tool has.
Nope, that's not how things work for us. We _want_ people to 'whine'
on the mailing list, so that if they really don't care that much about
something, it is "dropped on the floor" (because the thread becomes
stale) after a while, and we move on. Bug trackers are notorious for
growing in size very fast, and becoming cluttered (I have experience
with this as well, and am very pleased with how the git's mailing list
approach solves this).
> 7. Man pages: It's nice we have them, but we shouldn't need them to do
> basic stuff. I rarely had to look at the man pages using svn, but
> every single time I use git I have to dig into these things. Frankly,
> I have better things to do than RTFM.
Honestly, you never had to consult the help for svn? Perhaps the help
was not in a man page, but in some obscure website online; I for one
welcome our on-disk information bringing overlords.
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
> It's ok to have kind of a weak UI on a new tool, when people are busy
> adding basic functionality. However, at this point git already has way
> more features than most of the competition, and the needless
> complexity of the CLI is the biggest issue in day to day use.
If you don't need all that functionality, why not just use one of them
fancy GUI's out there?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-09 21:54 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
Brendan Miller <catphive@catphive.net> writes:
> Here are a bunch of really basic usability issues I have with git:
First question: which git version do you use?
> 1. cloning from a new empty repo fails, and so do a lot of other
> operations. This adds unnecessary steps to setting up a new shared
> repo.
I think it works in modern git (where modern might mean 'master',
i.e. not yet released version)
>
> 2. git --bare init. The flag goes before the operation unlike every
> other flag?
"git init --bare" works in fit version 1.6.4.2
In "git --bare init" the --bare option is to 'git' wrapper, not to
git-init command (see git(1)):
--bare Treat the repository as a bare repository. If GIT_DIR
environment is not set, it is set to the current working
directory.
>
> 3. It's not obvious whether operations work on the working
> directory/the "index"/the repository
> e.g. get reset --soft, --mixed, --hard. git diff --cached
There is "git diff --staged" synonym for "git diff --cached"
>
> 4. The index is inconsistently referred to as too many different
> things (cache, index, staging area) and only the last one makes any
> intuitive sense to a new user. This is partially a CLI issue, and
> partially a documentation issue, but both add up to cause confusion.
Usage of '--index' and '--cached' in CLI is consistent, and different.
See gitcli(7) manpage.
Some of those inconsistences are historical remainings (I think we got
rid of 'dircache' and 'ent'). Do you offer to do a cleanup?
>
> 5. Most commands require lots of flags, and don't have reasonable
> defaults. e.g. archive.
>
> git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
>
> Should just be:
> git archive
> run from the root of the repo.
I'd rather not have "git archive" work without specifying tree-ish.
As for having to do compression using separate program: do one thing
and do it well is UNIX philosophy, and Git is UNIX-y tool.
BTW. git-archive _has_ default format type (and empty prefix by
default).
>
> This is what I want to do 90% of the time, so it should just have the
> proper defaults, and not make me look at the man page every time I
> want to use it.
You learn those idioms.
>
> 6. Where is the bug tracker? If people users can't find the bug
> tracker, they can't report issues, and obnoxious bugs go unfixed, or
> people have to whine on the mailing list. There should be a nice big
> link on the front page of git-scm.com. A bug tracker is really the
> only way for the vast majority of a community that use a tool can give
> feedback on the problems the tool has.
Do you offer to maintain and manage such bug tracker? I mean here
taking care of duplicated bugs, tracking which bugs are resolved and
which are not, checking if bug is reproductible, etc. Do you?
Unmaintained bugtracker is worse than useless.
Using mailing list for bug reports and for patches is time-honored
workflow, which works rather well for smaller projects such as Git.
Note that git mailing list is free for all; you don't need to
subscribe to send, and you can watch it via many archives and gateways
(like GMane).
>
> 7. Man pages: It's nice we have them, but we shouldn't need them to do
> basic stuff. I rarely had to look at the man pages using svn, but
> every single time I use git I have to dig into these things. Frankly,
> I have better things to do than RTFM.
Learn. If you learn the philosophy behind git design, you would have
much easier understanding and remembering git.
There is "Git User's Manual", "The Git Community Book", "Pro Git" and
many other references.
>
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
origin is default, I think.
>
> git remote setdefault origin
>
> or even
>
> git remote add --default origin http://somegiturl.org/
>
> This come up in the use case where I:
> 1. set up a remote bare repo
> 2. push from my local repo, and thence forth want to keep local and
> remote in sink.
>
> Right now I have to modify .git/config to do this.
And?
> It's ok to have kind of a weak UI on a new tool, when people are busy
> adding basic functionality. However, at this point git already has way
> more features than most of the competition, and the needless
> complexity of the CLI is the biggest issue in day to day use.
Creating good UI is not easy, especially if you are limited by
backward compatibility.
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-09 21:47 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Nanako Shiraishi, Matthieu Moy, Teemu Likonen,
git
In-Reply-To: <20090909203939.GA10438@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... It also turns typo-checking into
> a run-time error rather than a compile-time error, which is IMHO a bad
> idea. And if you care about such things, it is worse for using something
> like ctags to find variable uses.
Fair enough.
^ permalink raw reply
* obnoxious CLI complaints
From: Brendan Miller @ 2009-09-09 21:27 UTC (permalink / raw)
To: git
Here are a bunch of really basic usability issues I have with git:
1. cloning from a new empty repo fails, and so do a lot of other
operations. This adds unnecessary steps to setting up a new shared
repo.
2. git --bare init. The flag goes before the operation unlike every other flag?
3. It's not obvious whether operations work on the working
directory/the "index"/the repository
e.g. get reset --soft, --mixed, --hard. git diff --cached
4. The index is inconsistently referred to as too many different
things (cache, index, staging area) and only the last one makes any
intuitive sense to a new user. This is partially a CLI issue, and
partially a documentation issue, but both add up to cause confusion.
5. Most commands require lots of flags, and don't have reasonable
defaults. e.g. archive.
git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
Should just be:
git archive
run from the root of the repo.
This is what I want to do 90% of the time, so it should just have the
proper defaults, and not make me look at the man page every time I
want to use it.
6. Where is the bug tracker? If people users can't find the bug
tracker, they can't report issues, and obnoxious bugs go unfixed, or
people have to whine on the mailing list. There should be a nice big
link on the front page of git-scm.com. A bug tracker is really the
only way for the vast majority of a community that use a tool can give
feedback on the problems the tool has.
7. Man pages: It's nice we have them, but we shouldn't need them to do
basic stuff. I rarely had to look at the man pages using svn, but
every single time I use git I have to dig into these things. Frankly,
I have better things to do than RTFM.
8. There's no obvious way to make a remote your default push pull
location without editing the git config file. Why not just something
like
git remote setdefault origin
or even
git remote add --default origin http://somegiturl.org/
This come up in the use case where I:
1. set up a remote bare repo
2. push from my local repo, and thence forth want to keep local and
remote in sink.
Right now I have to modify .git/config to do this.
It's ok to have kind of a weak UI on a new tool, when people are busy
adding basic functionality. However, at this point git already has way
more features than most of the competition, and the needless
complexity of the CLI is the biggest issue in day to day use.
Brendan
^ 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