* [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <1255681702-5215-1-git-send-email-gitster@pobox.com>
This itself does not do a "nested" expansion, but it paves a way for
supporting an extended syntax to express a function that works on an
expanded substring, e.g. %[function(param...)expanded-string%], by
allowing the callback function to tell where the argument to the function
ends.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
strbuf.c | 23 +++++++++++++++++++----
strbuf.h | 3 ++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index a6153dc..2bbc49c 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -214,25 +214,40 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
strbuf_setlen(sb, sb->len + len);
}
-void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
- void *context)
+void strbuf_nested_expand(struct strbuf *sb, const char **format_p,
+ expand_fn_t fn, void *context)
{
+ const char *format = *format_p;
for (;;) {
const char *percent;
size_t consumed;
percent = strchrnul(format, '%');
strbuf_add(sb, format, percent - format);
+ format = percent;
if (!*percent)
break;
- format = percent + 1;
+ format++;
consumed = fn(sb, format, context);
- if (consumed)
+ if ((ssize_t) consumed < 0)
+ break;
+ else if (consumed)
format += consumed;
else
strbuf_addch(sb, '%');
}
+ *format_p = format;
+}
+
+void strbuf_expand(struct strbuf *sb, const char *o_format, expand_fn_t fn,
+ void *context)
+{
+ const char *format = o_format;
+ strbuf_nested_expand(sb, &format, fn, context);
+ if (*format)
+ die("format error: negative return from expand function: %s",
+ o_format);
}
size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
diff --git a/strbuf.h b/strbuf.h
index d05e056..e602899 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -109,8 +109,9 @@ static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2) {
}
extern void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len);
-typedef size_t (*expand_fn_t) (struct strbuf *sb, const char *placeholder, void *context);
+typedef size_t (*expand_fn_t)(struct strbuf *sb, const char *placeholder, void *context);
extern void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn, void *context);
+extern void strbuf_nested_expand(struct strbuf *sb, const char **format_p, expand_fn_t fn, void *context);
struct strbuf_expand_dict_entry {
const char *placeholder;
const char *value;
--
1.6.5.99.g9ed7e
^ permalink raw reply related
* [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <1255681702-5215-1-git-send-email-gitster@pobox.com>
This uses the strbuf_nested_expand() mechanism introduced earlier
to demonstrate how to implement a nested string function. It does
not "wrap" using the line-wrap code, but lifting the change by Dscho
and plugging it in should be a trivial exercise.
The overall idea is to parse something like "%[w(72,4,8)%an %ae %s%]" in
these steps:
#1 "%[" introduces the nested string function.
#2 After that, a name identifies what function to call.
#3 The function parses its parameters ("(72,4,8)" in the above example),
and makes a nested expansion on the remainder of the format string.
#4 The nested expansion is terminated at "%]" and returned to the
function.
#5 The function massages the string returned from #4, and the result
becomes the expansion of the whole thing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 587101f..a8a38c3 100644
--- a/pretty.c
+++ b/pretty.c
@@ -595,6 +595,80 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
+typedef int (*string_fmt_fn)(struct strbuf *sb, const char *placeholder, void *context);
+static size_t format_commit_item(struct strbuf *, const char *, void *);
+
+static int wrap_fn(struct strbuf *sb, const char *placeholder, void *context)
+{
+ const char *template = placeholder;
+ char *endptr;
+ long width = 0, indent1 = 0, indent2 = 0;
+
+ width = strtol(template, &endptr, 10);
+ if (*endptr == ',') {
+ template = endptr + 1;
+ indent1 = strtol(template, &endptr, 10);
+ if (*endptr == ',') {
+ template = endptr + 1;
+ indent2 = strtol(template, &endptr, 10);
+ }
+ }
+ if (*endptr++ != ')')
+ return 0;
+
+ template = endptr;
+ strbuf_nested_expand(sb, &template, format_commit_item, context);
+ if (*template++ != ']')
+ return 0;
+
+ /*
+ * NEEDSWORK: here you wrap the contents of substr with
+ * strbuf_wrap(&substr, width, indent1, indent2);
+ *
+ * ... but I am too lazy to do that here, and I just demonstrate
+ * how it should work by just upcasing the result ;-)
+ */
+ {
+ int i;
+ for (i = 0; i < sb->len; i++)
+ sb->buf[i] = toupper(sb->buf[i]);
+ }
+ return template - placeholder;
+}
+
+static struct {
+ const char *name;
+ string_fmt_fn fn;
+} format_fn_list[] = {
+ { "w(", wrap_fn }
+};
+
+static size_t format_fn(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ const char *template = placeholder;
+ size_t consumed;
+ struct strbuf substr = STRBUF_INIT;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(format_fn_list); i++)
+ if (!prefixcmp(template, format_fn_list[i].name))
+ break;
+ if (ARRAY_SIZE(format_fn_list) <= i)
+ return 0;
+ template += strlen(format_fn_list[i].name);
+ consumed = format_fn_list[i].fn(&substr, template, context);
+ if (!consumed) {
+ strbuf_release(&substr);
+ return 0;
+ }
+
+ strbuf_add(sb, substr.buf, substr.len);
+ template += consumed;
+ strbuf_release(&substr);
+ return template - placeholder;
+}
+
static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -603,9 +677,19 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
const char *msg = commit->buffer;
struct commit_list *p;
int h1, h2;
+ size_t nested;
/* these are independent of the commit */
switch (placeholder[0]) {
+ case ']':
+ return -1;
+ case '[':
+ /*
+ * %[func(arg...) string %]: we consumed the opening '['
+ * and the callee consumed up to the closing '%]'.
+ */
+ nested = format_fn(sb, placeholder + 1, context);
+ return nested ? 1 + nested : 0;
case 'C':
if (placeholder[1] == '(') {
const char *end = strchr(placeholder + 2, ')');
--
1.6.5.99.g9ed7e
^ permalink raw reply related
* [PATCH 0/3] Generalized "string function" syntax
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
I mentioned an idea to enhance the pretty=format language with a string
function syntax that people can extend by adding new functions in one of
the "What's cooking" messages earlier. The general syntax would be like
%[function(args...)any string here%]
where "any string here" part would have the usual pretty=format strings.
E.g. git show -s --format='%{w(72,8,4)%s%+b%]' should give you a line
wrapped commit log message if w(width,in1,in2) is such a function.
This series is a proof of concept, as I didn't actually plug the
"wrapping" code into it; it would be fairly straightforward to integrate
the logic Dscho made strbuf capable in js/log-wrap series (queued in 'pu')
to finish this.
Junio C Hamano (3):
format_commit_message(): fix function signature
strbuf_nested_expand(): allow expansion to interrupt in the middle
Add proof-of-concept %[w(width,in1,in2)<<any-string>>%]
implementation
commit.h | 2 +-
pretty.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
strbuf.c | 23 +++++++++++++---
strbuf.h | 3 +-
4 files changed, 107 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 1/3] format_commit_message(): fix function signature
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <1255681702-5215-1-git-send-email-gitster@pobox.com>
The format template string was declared as "const void *" for some unknown
reason, even though it obviously is meant to be passed a string. Make it
"const char *".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
commit.h | 2 +-
pretty.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.h b/commit.h
index f4fc5c5..95f981a 100644
--- a/commit.h
+++ b/commit.h
@@ -70,7 +70,7 @@ extern char *reencode_commit_message(const struct commit *commit,
const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
extern void format_commit_message(const struct commit *commit,
- const void *format, struct strbuf *sb,
+ const char *format, struct strbuf *sb,
enum date_mode dmode);
extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit*,
struct strbuf *,
diff --git a/pretty.c b/pretty.c
index f5983f8..587101f 100644
--- a/pretty.c
+++ b/pretty.c
@@ -740,7 +740,7 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
}
void format_commit_message(const struct commit *commit,
- const void *format, struct strbuf *sb,
+ const char *format, struct strbuf *sb,
enum date_mode dmode)
{
struct format_commit_context context;
--
1.6.5.99.g9ed7e
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-16 8:27 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Jeff King, Nicolas Pitre, James Pickens,
Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910160128400.32515@iabervon.org>
On 2009.10.16 02:02:09 -0400, Daniel Barkalow wrote:
> On Fri, 16 Oct 2009, Björn Steinbrink wrote:
>
> > On 2009.10.15 14:54:18 -0700, Junio C Hamano wrote:
> > > If it is very important to support:
> > >
> > > $ git checkout --look-but-not-touch origin/next^
> > >
> > > then James's approach would not be very useful, as we do have to detach
> > > HEAD and implement the "do not touch" logic for detached HEAD state
> > > anyway, so we might just use the same logic we would use for origin/next^
> > > when checking out origin/next itself.
> >
> > I don't have any numbers backing this up, but my gut feeling says that
> > most cases of "Where have my commits gone?" that I have seen on #git
> > were due to "git checkout HEAD~2"-like actions. Either because the user
> > assumed SVN-like behaviour (you can't commit until you do "svn up", like
> > "git reset --merge HEAD@{1}") or thought that "git checkout
> > <committish>" would act like "git reset --hard <committish>".
> >
> > For the latter I fail to envision any solution except for
> > education (and I have no idea why the user expected checkout to work
> > like reset).
> >
> > The former can be solved by the proposed extra information in HEAD,
> > forbidding changes to HEAD that make it reference a commit that's not
> > reachable through the head stored in the extra information[*1*] and providing
> > some command that acts like "svn up".
> >
> > This seems quite different from the plain "forbid committing" or "detach
> > and know how you get there", but more like "detach and know where you're
> > coming from".
>
> What's the state before the "git checkout HEAD~2"?
>
> If it's:
>
> $ git checkout origin/some-obscure-branch
> (get curious about the commit a bit back)
> $ git checkout HEAD~2
IIRC, most of the time it was:
git checkout master # not detaching
git checkout HEAD~2
Another version I recall (but that's what I use myself regularly, so I
might be biased and think that it's more common that it actually was)
is:
git checkout master
git log # Find commit, copy hash
git checkout <hash> # Pasting the copied hash
> And then the user doesn't know how to get back to where they were, then it
> should work if git had stored "origin/some-obscure-branch~2" at this point
> (having substituted "origin/some-obscure-branch" (the previous extra info)
> for HEAD). Then we could have a "git up" that would discard modifiers from
> the extra info and check that out. Or users might find "git checkout
> origin/some-obscure-branch" obvious enough if git is reporting something
> related.
I'd not put "origin/some-obscure-branch~2" in there, but just
"origin/some-obscure-branch". Rationale: The ~2 modifier may become
invalid when you do "git fetch". And I don't see any value in having
that modifier, and even if there are some corner-cases, those could use
"git describe" or so, to get the modifiers on the fly.
> I know I often find my git.git repos on "* (no branch)", and I don't
> remember if I checked that out as origin/master or origin/next. And that's
> an important clue as to when I'd been doing there previously, and what I
> might want to do next. Perhaps these users are having a similar problem,
> where they're relying on git to remember what they were doing?
Hm, maybe. I'm more inclined to think that they assumed that "git
checkout <branch_head>" 'binds' them to that branch head. But git allows
them to jump around freely, the 'binding' is very weak.
SVN has:
"svn up": Get an older/newer version of the branch I'm on
"svn switch": Switch to a different branch
You cannot jump around without binding yourself to any branch.
git has:
"git checkout": Go anywhere, bind to that till the next checkout.
With "git checkout <non-branch-head>" working like a temporary unnamed
branch head.
In my view, there's the huge conceptual difference that svn has named
branches, while git only has named branch heads, that have a history
(reflog) that isn't necessarily even remotely similar to that of the
branch it currently points at.
G---H---I (bar)
/ /
A---B---C---D---E (master)
\
F (foo)
In SVN, you'd have a history that describes how "bar" came into its
current state, consisting of: G, H, I (Not following the copy at
G).
In git, you have a history that describes how commit I came into
existence (not branch head "bar"!), that is: A, B, C, D, E, G, H, I.
And the actual history for "bar" in git (the reflog) might be as weird
as: E, F, H, I, B, I. Jumping wildly across the commit DAG.
My view is that with git you're never "on a branch", but you have an
active branch head (possibly unnamed [detached HEAD]) that marks a tip,
where the DAG grows. A branch, to me, has an extent. In the above graph,
G, H, I is a branch, and F is a branch, but "bar" is not. "bar" has no
extent, it's just where the "G, H, I" branch might possibly grow.
When you do "git checkout bar~2", you're not on "no branch". Your active
branch head is just unnamed. The branch is yet to be born (unless you
consider e.g. "A, B, C, G" to be your branch), but at least after doing
a "git commit", you'll have:
J (HEAD)
/
G---H---I (bar)
/ /
A---B---C---D---E (master)
\
F (foo)
And then you clearly do have a branch "J" there. At least if you stop saying
that a branch is just its head. And "git branch" saying that you're on
"no branch" makes no sense at all then.
Git simply doesn't expose branches in a sense of "a series of commit".
To get that, you need things like "git log master..bar" to get the "G, H,
I" branch.
SVN has this clear "this branch has this name" concept, git does not. I
prefer gits way. But maybe it should simply not use the term "branch"
when it means "branch head".
And the glossary even somewhat agrees with me, although it disagrees
with itself:
branch
A "branch" is an active line of development. The most recent commit
on a branch is referred to as the tip of that branch. The tip of
the branch is referenced by a branch head, which moves forward as
additional development is done on the branch. A single git
repository can track an arbitrary number of branches, but your
working tree is associated with just one of them (the "current" or
"checked out" branch), and HEAD points to that branch.
So a branch is an active line of development. If I do "git checkout
foo~2" and "git commit", I clearly do have an active line of
development. So it's not "no branch".
And a "branch head" references the tip (point of growth) of a branch.
It's not identical to a branch.
But then there comes HEAD, which is said to point to a branch, while it
of course points to a branch head. I guess the glossary is outdated WRT
detached HEAD, but if you ignore the implementation details, it could
still be said that in case of a detached HEAD, HEAD points to an unnamed
branch head.
The user manual also makes this distinction, but says that "when no
confusion will result, we often just use the term 'branch' both for
branches and for branch heads".
And the command man pages follow that "just use 'branch'" way:
"git checkout" is said to checkout (and possibly create) a branch, not a
branch head.
"git branch":
- List, create or delete branches
- --contains/--merged/--no-merged => show branches that...
But the clear winner is (from git-branch(1)):
"If the <commit> argument is missing it defaults to HEAD (i.e. the tip
of the current branch)."
Combine that with a detached HEAD and the according "git branch" output.
The <commit> argument will default to the tip of no branch! Epic.
Don't get me wrong though. I like git's model, and think that its
anonymous branches with named branch heads offer a lot more than e.g.
SVN's named branches (and namespace pollution is just a minor factor).
But I'm more and more convinced that suggesting the unknowing user who
didn't read the "we term A for A and B" notice in the manual, that git
does have named branches (branches being a series of commits) is a bad
thing that leads to confusion (in contrast to what the manual assumes).
Examples:
User asking about deleting a "branch" without deleting its commits:
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2113
User asking whether deleting master will mess up other "branches":
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-13#l2407
(I thought that there were two more in the last week, but I couldn't
find them, so maybe I was wrong, or they used some other word than
"delete", which I used to search the logs).
In both cases, the user wanted to delete the branch head, but was afraid
that that would kill the commits, as they were told that they will
delete the "branch" and assumed the "branch" to be all commits reachable
through the branch head.
And I kind of doubt that this just applies to SVN refugees that are used
to SVN's meaning of branches, but also to people that are new to any
kind of VCS and "naively" apply the branch-analogy to real-world trees,
where branches are more than just their tips.
And I believe that this is closely related to the detached HEAD thing.
See above for the "no branch" stuff that now doesn't even make any sense
to me anymore (even less after reading the git-branch(1) man page ;-)).
But also the fact that checkout is hardly about branches, but about
(possibly unnamed) branch heads. One might have certain branch heads
that are never rewound and thus might be more or less equal to a branch,
but that seems like it's almost(?) a special case if you consider what
"checkout" can actually do.
I'm not sure how this can be alleviated. Just saying "branch head"
instead of "branch" is more correct, but probably still doesn't really
express those differences that make git what it is. Making "git branch"
say "* (unnamed branch head)" instead of "* (no branch)" seems like a
good start, but the user manual would need a very close look to catch
all the text that stops to make sense when you suddenly start to make a
stronger difference between a branch and a branch head. I'll look into
that over the weekend, but won't promise anything.
Björn, hoping that he didn't run too far off the track
^ permalink raw reply
* Re: [PATCH] rebase -i: fix reword when using a terminal editor
From: Björn Gustavsson @ 2009-10-16 8:05 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1255674753-13949-1-git-send-email-bebarino@gmail.com>
2009/10/16 Stephen Boyd <bebarino@gmail.com>:
> We don't want to use output() on git-commit --amend when rewording the
> commit message. This leads to confusion as the editor is run in a
> subshell with it's output saved away, leaving the user with a seemingly
> frozen terminal.
>
> Fix by removing the output part.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> On top of next.
>
> I think this is right, although I'm not really experienced in the rebase -i
> code
Thanks!
Yes, it seems right to me too after a more thorough reading of the
existing rebase -i code. It seems that 'output' is only used for
non-interactive commands.
I never noticed the problem because I use 'emacsclient' as my
commit editor. I didn't think of testing with an editor that run in
the terminal window.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Mike Hommey @ 2009-10-16 7:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Antti-Juhani Kaijanaho, git
In-Reply-To: <4AD80BBD.8080504@zytor.com>
On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote:
> On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote:
> > On 2009-10-09, Junio C Hamano <gitster@pobox.com> wrote:
> >>> +If there is no repository at $GIT_URL, the server MUST respond with
> >>> +the '404 Not Found' HTTP status code.
> >>
> >> We may also want to add
> >>
> >> If there is no object at $GIT_URL/some/path, the server MUST respond
> >> with the '404 Not Found' HTTP status code.
> >>
> >> to help dumb clients.
> >
> > In both cases - is it really necessary to forbid the use of 410 (Gone)?
> >
>
> 410 means "we once had it, it's no longer here, no idea where it went."
> It's a largely useless code...
There is an additional meaning to it, that is "it will never ever
return". It thus has a stronger meaning than 404. Sadly, not even search
engine spiders consider it as a hint to not crawl there in the future...
Mike
^ permalink raw reply
* [PATCH] rebase -i: fix reword when using a terminal editor
From: Stephen Boyd @ 2009-10-16 6:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Björn Gustavsson
We don't want to use output() on git-commit --amend when rewording the
commit message. This leads to confusion as the editor is run in a
subshell with it's output saved away, leaving the user with a seemingly
frozen terminal.
Fix by removing the output part.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
On top of next.
I think this is right, although I'm not really experienced in the rebase -i
code
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a43ee22..a1879e3 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -346,7 +346,7 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- output git commit --amend
+ git commit --amend
;;
edit|e)
comment_for_reflog edit
--
1.6.5.103.g6b436.dirty
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-16 6:02 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Junio C Hamano, Jeff King, Nicolas Pitre, James Pickens,
Jay Soffian, git
In-Reply-To: <20091016042955.GA9233@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2511 bytes --]
On Fri, 16 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.15 14:54:18 -0700, Junio C Hamano wrote:
> > If it is very important to support:
> >
> > $ git checkout --look-but-not-touch origin/next^
> >
> > then James's approach would not be very useful, as we do have to detach
> > HEAD and implement the "do not touch" logic for detached HEAD state
> > anyway, so we might just use the same logic we would use for origin/next^
> > when checking out origin/next itself.
>
> I don't have any numbers backing this up, but my gut feeling says that
> most cases of "Where have my commits gone?" that I have seen on #git
> were due to "git checkout HEAD~2"-like actions. Either because the user
> assumed SVN-like behaviour (you can't commit until you do "svn up", like
> "git reset --merge HEAD@{1}") or thought that "git checkout
> <committish>" would act like "git reset --hard <committish>".
>
> For the latter I fail to envision any solution except for
> education (and I have no idea why the user expected checkout to work
> like reset).
>
> The former can be solved by the proposed extra information in HEAD,
> forbidding changes to HEAD that make it reference a commit that's not
> reachable through the head stored in the extra information[*1*] and providing
> some command that acts like "svn up".
>
> This seems quite different from the plain "forbid committing" or "detach
> and know how you get there", but more like "detach and know where you're
> coming from".
What's the state before the "git checkout HEAD~2"?
If it's:
$ git checkout origin/some-obscure-branch
(get curious about the commit a bit back)
$ git checkout HEAD~2
And then the user doesn't know how to get back to where they were, then it
should work if git had stored "origin/some-obscure-branch~2" at this point
(having substituted "origin/some-obscure-branch" (the previous extra info)
for HEAD). Then we could have a "git up" that would discard modifiers from
the extra info and check that out. Or users might find "git checkout
origin/some-obscure-branch" obvious enough if git is reporting something
related.
I know I often find my git.git repos on "* (no branch)", and I don't
remember if I checked that out as origin/master or origin/next. And that's
an important clue as to when I'd been doing there previously, and what I
might want to do next. Perhaps these users are having a similar problem,
where they're relying on git to remember what they were doing?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: H. Peter Anvin @ 2009-10-16 5:59 UTC (permalink / raw)
To: Antti-Juhani Kaijanaho; +Cc: git
In-Reply-To: <slrnhd0nfv.tq2.antti-juhani@kukkaseppele.kaijanaho.fi>
On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote:
> On 2009-10-09, Junio C Hamano <gitster@pobox.com> wrote:
>>> +If there is no repository at $GIT_URL, the server MUST respond with
>>> +the '404 Not Found' HTTP status code.
>>
>> We may also want to add
>>
>> If there is no object at $GIT_URL/some/path, the server MUST respond
>> with the '404 Not Found' HTTP status code.
>>
>> to help dumb clients.
>
> In both cases - is it really necessary to forbid the use of 410 (Gone)?
>
410 means "we once had it, it's no longer here, no idea where it went."
It's a largely useless code...
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH v2 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Jeff King @ 2009-10-16 5:32 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <012c71c4eab143691bc5e2d62b421f8c84effa0e.1255645570.git.trast@student.ethz.ch>
On Fri, Oct 16, 2009 at 12:41:46AM +0200, Thomas Rast wrote:
> Note that the --format="%h %gD: %gs" tests may not work in real
> repositories, as the --pretty formatter doesn't know to leave away the
> ": " on the last commit in an incomplete (because git-gc removed the
> old part) reflog. This equivalence is nevertheless the main goal of
> this patch.
Yeah, I see what you are talking about in my git.git repo. I am tempted
to suggest cutting it out of both formats, as it is somewhat confusing,
but it does actually convey a slight bit of information (even if
information that is extremely unlikely to be of use).
I am also fine with leaving it, and if we one day invent the
"conditionally include the ': '" syntax, using it then.
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 2a845b1..6359272 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -123,6 +123,9 @@ The placeholders are:
> - '%s': subject
> - '%f': sanitized subject line, suitable for a filename
> - '%b': body
> +- '%gD': reflog selector, e.g., `refs/stash@{1}`
> +- '%gd': shortened reflog selector, e.g., `stash@{1}`
> +- '%gs': reflog subject
> - '%Cred': switch color to red
> - '%Cgreen': switch color to green
> - '%Cblue': switch color to blue
Should we give a note that these do nothing if "-g" was not given?
> + if (shorten) {
> + if (last_ref != commit_reflog->reflogs->ref) {
> + free(last_short_ref);
> + last_short_ref = shorten_unambiguous_ref(commit_reflog->reflogs->ref, 0);
> + }
> + printed_ref = last_short_ref;
Clever. I hadn't considered caching, but you are right that
shorten_unambiguous_ref is a bit heavyweight to be calling for every
entry.
> diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
> index c18ed8e..cb8d0fd 100755
> --- a/t/t1411-reflog-show.sh
> +++ b/t/t1411-reflog-show.sh
> @@ -64,4 +64,16 @@ test_expect_success 'using --date= shows reflog date (oneline)' '
> test_cmp expect actual
> '
>
> +test_expect_success '--format="%h %gD: %gs" is same as git-reflog' '
> + git reflog >expect &&
> + git log -g --format="%h %gD: %gs" >actual &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success '--format="%h %gD: %gs" is same as git-reflog (with date)' '
> + git reflog --date=raw >expect &&
> + git log -g --format="%h %gD: %gs" --date=raw >actual &&
> + test_cmp expect actual
> +'
A test for '%gd' would be nice. A squashable one is below. I am tempted
to test all three forms in t6006, since the intent of that script is to
test all format specifiers. However, those tests would be somewhat
redundant with your t1411 tests.
---
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 59d1f62..d1f2476 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,4 +162,10 @@ test_expect_success 'empty email' '
}
'
+test_expect_success '%gd shortens ref name' '
+ echo "master@{0}" >expect.gd-short &&
+ git log -g -1 --format=%gd refs/heads/master >actual.gd-short &&
+ test_cmp expect.gd-short actual.gd-short
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH v2 0/5] Pretty formats for reflog data
From: Jeff King @ 2009-10-16 5:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255645570.git.trast@student.ethz.ch>
On Fri, Oct 16, 2009 at 12:41:43AM +0200, Thomas Rast wrote:
> Jeff King wrote:
> > Maybe a better solution would be a "short name" variant for pretty
> > format specifiers. We already have %(refname) and %(refname:short) [...]
> > The tricky part would be deciding on a syntax. This seems to come up a
> > fair bit.
>
> Ok, I settled for %g[dDs] for now to save on letters. I'm saving the
> syntax question for a later series while we discuss this one ;-)
:) That is probably sensible. Your %g[dD] doesn't support selecting
between the numbered version and the "date" version, which is something
we might want, but certainly it is no worse than the status quo (and
doing something like that probably _would_ want an extended syntax, as
you now have two orthogonal arguments: shorten and date/numbered).
> I think going for %(...) wouldn't be too bad since we already have
> that in for-each-ref, and it can be backwards compatible. So we would
> have different sets of short and long specifiers, e.g.
>
> %ae = %(authoremail)
> %aE = %(authoremail:mailmap)
>
> We can then pass arguments via some yet-to-be decided syntax, say,
> %(body:indent(10)).
That seems reasonable to me, though if we can limit ourselves to one
argument per specifier (I suspect most specifiers would simply be
boolean, but a few may take numbers or strings), then something like
%(body:indent=10) might be a little more readable.
It would also be nice to have some sort of conditional inclusion, which
could deal with your extra ": " in patch 3. Either something like:
%(reflog:short)%(reflog:+: )
or even
%(reflog:short:prefix=\: )
and note that allowing arbitrary arguments means we get to deal with
quoting.
But that is all for another potential series.
> Other changes in this version include:
>
> * I followed your struct suggestion, which is the new 1/5.
Thanks. It looks like it didn't turn out to be too invasive, and I think
some of the callsites are a bit more readable.
> * I fixed the warning that Junio found (and finally found the right
> combination of -W flags, though I cannot compile with -Werror myself
> because of *other* warnings...)
I always compile with -Wall -Werror (including testing your series);
what warnings are you getting?
> Thomas Rast (5):
> Refactor pretty_print_commit arguments into a struct
> reflog-walk: refactor the branch@{num} formatting
> Introduce new pretty formats %g[sdD] for reflog information
> stash list: use new %g formats instead of sed
> stash list: drop the default limit of 10 stashes
Thanks, this series looks really good to me. I have a few comments on
patch 3 which I'll send separately.
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-16 5:03 UTC (permalink / raw)
To: James Pickens
Cc: Junio C Hamano, Jeff King, Nicolas Pitre, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <885649360910151647v27a15334x63fe3b6f5035dbd2@mail.gmail.com>
On 2009.10.15 16:47:57 -0700, James Pickens wrote:
> On Thu, Oct 15, 2009 at 3:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> $ git checkout origin/next ;# ditto
> >> $ git symbolic-ref HEAD
> >> refs/remotes/origin/next
> >
> > Ok, after reading Daniel's message to remind us that "git fetch" after
> > this will get us into trouble, I agree that detaching HEAD is inevitable.
>
> Some people liked the idea, so let's not give up just yet. Here are a few
> things Git could do when a fetch wants to update the currently checked out
> branch:
>
> 1. Refuse the fetch.
> 2. Update the ref, leaving the user with a work tree and index that don't
> match their HEAD.
> 3. Detach the HEAD, then update the ref.
> 4. Update the ref, then check it out.
>
> Option 1 is ok, as long as the "next step" is not too complicated. It's no
> good if the user has to checkout a different branch, then fetch, then
> checkout the original branch again.
Not good. It makes "git fetch; git log ..origin/foo" impossible. And
that's IMHO a very useful thing for people that just want to follow
things and look at what happens.
> Option 2 is crap.
Agreed.
> Option 3 seems reasonable, but it might be just as scary/confusing to
> newbies as the current behavior, so I don't think it should be the default.
Doesn't seem very good to me. The idea was to stop people from
accidently getting on a detached HEAD, if common operations like "fetch"
now suddenly detach HEAD, that's _worse_ than before. And for a
single-branch remote, even "git pull" may detach HEAD then:
git init;
git remote add -f -t master origin git://...
git checkout origin/master
*wait*
git pull # Will work, as the fetch refspec is not a glob
But that "pull" does:
git fetch origin refs/heads/master:refs/remotes/origin/master
Which detaches HEAD before merging/fast-forwarding.
Bad.
And seeing that the requests for "clone just a single branch" seem to
increase in #git, I guess that such non-globbing refspecs for
remote.origin.fetch might become more common in the future.
> Option 4 also seems reasonable, but you run into problems if the user had
> changed the index or work tree. In that case Git could do 'checkout
> --merge' automatically. This option is also less "pure" since it lets 'git
> fetch' modify the index and work tree.
Same as for option 1, it kills "git fetch; git log ..origin/foo". And
that would basically turn "fetch" into a hypothetical "pull --reset".
That's IMHO better done in a separate command.
> So how about this:
> * 'git fetch' refuses the fetch by default.
> * 'git fetch --detach' detaches HEAD, then updates the ref
> * 'git pull' detaches HEAD, updates the ref, then checks out the new ref
> with --merge.
"fetch --detach" doesn't feel right to me. Wrong class of commands to
have such an option. And I'm not sure about adding a third mode to
"pull" (besides "merge" and "rebase") that only triggers for special
cases. Again, I'd prefer a separate command.
If we store "where did I come from" instead of just "where am I" in HEAD
when detached, those problems don't seem to show up (but just storing
that information correctly seems hard enough, see the other mail I wrote
a few minutes ago).
"git fetch" just updates the remote tracking branch, you stay at where
you are, "git log ..origin/foo" keeps working. It could give a special
hint that you might want to use "git checkout origin/foo" or "git
new-command" to update your working tree to the newest version, when
your working tree is based upon an old version of that remote tracking
branch.
And "git pull" might perform a fast-forward automatically (figuring out
the right remote from the extra info in HEAD), but refuse to do merges
(if upstream has been rewritten), pointing the user to "git checkout" or
"git new-command". (Interestingly, "pull --rebase" wouldn't suffer from
such history rewriting, as it looks at the reflog for the remote
tracking branch, but I guess a working "git pull --rebase" while "git
pull" fails is bound to cause major user confusion).
"git new-command" could act like "svn up", doing a fetch and a
"checkout --merge <remote_tracking_branch>" to just get the user
up-to-date keeping local uncommitted modifications. I can't tell why,
but my feeling is that this should be a new command, and not part of
pull, as said above.
Björn
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-16 4:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Nicolas Pitre, James Pickens, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <7v1vl42uid.fsf@alter.siamese.dyndns.org>
On 2009.10.15 14:54:18 -0700, Junio C Hamano wrote:
> If it is very important to support:
>
> $ git checkout --look-but-not-touch origin/next^
>
> then James's approach would not be very useful, as we do have to detach
> HEAD and implement the "do not touch" logic for detached HEAD state
> anyway, so we might just use the same logic we would use for origin/next^
> when checking out origin/next itself.
I don't have any numbers backing this up, but my gut feeling says that
most cases of "Where have my commits gone?" that I have seen on #git
were due to "git checkout HEAD~2"-like actions. Either because the user
assumed SVN-like behaviour (you can't commit until you do "svn up", like
"git reset --merge HEAD@{1}") or thought that "git checkout
<committish>" would act like "git reset --hard <committish>".
For the latter I fail to envision any solution except for
education (and I have no idea why the user expected checkout to work
like reset).
The former can be solved by the proposed extra information in HEAD,
forbidding changes to HEAD that make it reference a commit that's not
reachable through the head stored in the extra information[*1*] and providing
some command that acts like "svn up".
This seems quite different from the plain "forbid committing" or "detach
and know how you get there", but more like "detach and know where you're
coming from".
[*1*] If certain updates to HEAD aren't forbidden, a "checkout deadbeef"
(or a reset or update-ref) would possibly invalidate the extra
information in HEAD, which would require implicit detaching, making the
concept useless. For example:
A---B---C---D---E (master)
\ /
F---G---H---I (foo)
git checkout master
git checkout master~2 # Put refs/heads/master into the extra info
git reset --hard HEAD^ # Allow?
git reset --hard foo~2 # Allow? Change extra info? It's also in master
git checkout master
git checkout foo~2
Is that checkout allowed? "foo~2" is also reachable through master. Does
"checkout" do some smart parsing and puts refs/heads/foo into the extra
info? Or should refs/heads/master end up there?
git checkout master
git checkout foo~1
Basically, same deal as above, but foo~1 is not reachable through
master.
And finally the pure commit id cases:
git checkout master
git checkout $(git rev-parse master^)
Is that to be allowed? We can't derive the extra info from the argument
given to checkout, but could check that it's reachable from master
(currently referenced HEAD at the time of the command being run)
And:
git checkout master
git checkout $(git rev-parse foo^)
Neither can we guess what the extra info should be from the argument
given to checkout, nor is the given commit reachable through master. So
this should be forbidden and should require ^0?
This whole thing is indeed a whole lot less complex with a SVN-like
model, where you basically work with the linearly growing reflog only.
Björn
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Mark Lodato @ 2009-10-16 4:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255577814-14745-1-git-send-email-spearce@spearce.org>
On Wed, Oct 14, 2009 at 11:36 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> This series is still lacking:
>
> * The HTTP protocol documentation
> * Tests for the smart http transport code (existing tests pass)
* Dumb HTTP push support
It would be really nice if git-http-backend supported dumb pushing
over WebDAV. Currently, to support both smart and dumb pushing, one
has to configure Apache in a very awkward and confusing way (if it is
even possible - I'm still trying to figure it out). Without some way
to support older clients, it will be very hard to transition to the
new protocol.
Also, your examples use "DocumentRoot /pub/git", but I think most
people would want to have their main website as the DocumentRoot, have
the URL "/git" serve the repositories through gitweb, and have that
same "/git" URL be `git clone'-able. The Apache configuration for
this is complicated and non-intuitive, so I think an example of this
in the documentation is warranted. The following accomplishes what I
describe, except it does not work with dump HTTP push, and does not
allow anonymous read-only access. (I am currently trying to figure
out how to do both of these things.)
-- 8< --
DocumentRoot /var/www/htdocs
# Rest of httpd config...
<Directory /pub/git>
SetHandler git-http-backend
Action git-http-backend /git-http-backend virtual
</Directory>
# To allow anonymous access (but to disallow pushing), comment out the
following Location block.
<Location /git-http-backend>
AuthName "git"
AuthType Basic
AuthUserFile /etc/apache2/passwd/git.passwd
Require valid-user
</Location>
# Each of the following Aliases should be one line:
AliasMatch ^/git/(.*/(HEAD|info/refs|objects/(info/[^/]*|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack))$
"/pub/git/$1"
ScriptAlias /git "/var/www/cgi-bin/gitweb.cgi"
ScriptAlias /git-http-backend "/usr/local/libexec/git-core/git-http-backend"
-- >8 --
^ permalink raw reply
* [PATCHv3] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-16 4:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Linkify the avatar icon in log/shortlog view because the icon is directly
adjacent to the name and thus more related. The same is not true
when in commit/tag view where the icon is farther away.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Changes since v2:
* Add a title to make it not so suprising before you click (Jakub)
Changes since v1:
* CSS hack has been cleaned up to only remove the link border from
avatar icons when actually linked.
* Checking for search capability to avoid generating search links (Wincent)
* Linking of name and email are separate in commit/commitdiff/tag views
gitweb/gitweb.css | 4 ++++
gitweb/gitweb.perl | 40 +++++++++++++++++++++++++++++++++++-----
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 8faa94e..50067f2 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -32,6 +32,10 @@ img.avatar {
vertical-align: middle;
}
+a.list img.avatar {
+ border-style: none;
+}
+
div.page_header {
height: 25px;
padding: 8px;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0c71ee8..63e18f4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1625,6 +1625,29 @@ sub git_get_avatar {
}
}
+sub format_search_author {
+ my ($author, $searchtype, $displaytext) = @_;
+ my $have_search = gitweb_check_feature('search');
+
+ if ($have_search) {
+ my $performed = "";
+ if ($searchtype eq 'author') {
+ $performed = "authored";
+ } elsif ($searchtype eq 'committer') {
+ $performed = "committed";
+ }
+
+ return $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$author,
+ searchtype=>$searchtype), class=>"list",
+ title=>"Search for commits $performed by $author"},
+ $displaytext);
+
+ } else {
+ return $displaytext;
+ }
+}
+
# format the author name of the given commit with the given tag
# the author name is chopped and escaped according to the other
# optional parameters (see chop_str).
@@ -1633,8 +1656,10 @@ sub format_author_html {
my $co = shift;
my $author = chop_and_escape_str($co->{'author_name'}, @_);
return "<$tag class=\"author\">" .
- git_get_avatar($co->{'author_email'}, -pad_after => 1) .
- $author . "</$tag>";
+ format_search_author($co->{'author_name'}, "author",
+ git_get_avatar($co->{'author_email'}, -pad_after => 1) .
+ $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3433,10 +3458,11 @@ sub git_print_authorship {
my $co = shift;
my %opts = @_;
my $tag = $opts{-tag} || 'div';
+ my $author = $co->{'author_name'};
my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<$tag class=\"author_date\">" .
- esc_html($co->{'author_name'}) .
+ format_search_author($author, "author", esc_html($author)) .
" [$ad{'rfc2822'}";
print_local_time(%ad) if ($opts{-localtime});
print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
@@ -3455,8 +3481,12 @@ sub git_print_authorship_rows {
@people = ('author', 'committer') unless @people;
foreach my $who (@people) {
my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
- print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
- "<td rowspan=\"2\">" .
+ print "<tr><td>$who</td><td>" .
+ format_search_author($co->{"${who}_name"}, $who,
+ esc_html($co->{"${who}_name"})) . " " .
+ format_search_author($co->{"${who}_email"}, $who,
+ esc_html("<" . $co->{"${who}_email"} . ">")) .
+ "</td><td rowspan=\"2\">" .
git_get_avatar($co->{"${who}_email"}, -size => 'double') .
"</td></tr>\n" .
"<tr>" .
--
1.6.5.94.gb6c65
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-16 3:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Jeff King, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910160245310.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In this particular case, I cannot help but notice that commits performed
> on a detached HEAD will get lost _unless_ they are somehow put onto a
> named branch eventually. So the only question is whether you restrict
> flexibility by requiring to name the branch first before committing,
> instead of committing and then naming the branch.
You are forgetting another important case. You may not even want to keep
what you will be committing to the throw-away temporary state.
That is why I liked the proposal by James to introduce a third state
(i.e. not on local branch, but cannot commit) at the conceptual level,
even though as Daniel pointed out and Nico and I concurred later, the
implementation may need to be based on the detached HEAD to avoid "git
fetch" surprises.
You can of course fix it in different ways. The third state could be
implemented by pointing at a non local branch ref with HEAD, and then by
making fetch refuse to update, just like we refuse a push from side to
make the working tree state inconsistent.
Either way, confusion arising from accidental (or unintended) detaching
would be removed for new users, and that won't have to harm people who
need to (because they _are_ used to) be able to work on detached HEAD, no?
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-16 2:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Jeff King, Junio C Hamano, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910160357370.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> You are trying to educate the users to use the double-clutch. Rather than
> making the double-clutch obsolete.
I do not quite get your double-clutch rhetoric, in the sense that I do not
think it has anything analogous in the topic of detached HEAD we have been
discussing.
Didn't we discuss possible solutions to make sure that you do not have to
detach HEAD and lose commits by coming back without saving them? I would
consider that corresponds to inventing automatic (iow, making sure that
sightseeing can be done without having to worry about accidentally
committing on that state and later losing them). Obviously, you would
need to cover cases other than we have discussed (e.g. if "rebase -i"
detaches, it needs to allow "commit", "commit --amend", and "reset --soft
HEAD^", but you probably would not want to allow "checkout" to switch to
another branch). Thinking things through so that we can fill in all these
details is a tedious and hard work, but I would say it would be worth it.
In the ideal world, if you do not have to (nor want to) use the detached
HEAD feature, you do not have to.
But that is entirely different from saying "I do not need to use detached
HEAD, I cannot explain it to my users. Let's make it unusable, iow, I give
up". Unfortunately that is the impression I am getting from your whining.
If you have been advocating for something else, and you share the goal of
helping users by e.g. making it unnecessary to worry about accidentally
committing on that state and later losing them, you would need to do a
better job explaining yourself.
> Just recently, I had a user request (a very valid one, mind you) where the
> user does not want to provide a commit message, and wants to just commit
> all the current changes. In that particular case, it is very sensible to
> ask for these things. It is something utterly simple to ask for. Yet, it
> is utterly hard with Git, especially if I have to explain it.
I suspect the above is another example of your needing to do a better job
explaining yourself here, but from "just commit all the changes without
saying message", my knee-jerk reaction is "git commit -a -m 'no message'".
You would need to justify why -m 'no message' does not fit the bill better
than just saying "is very sensible to ask for these things", as I highly
suspect that I misunderstood what "these things" are in your five lines to
come up with that "solution" that you are now going to explain why that is
not what the end user wanted. And in this case, I do not think it is that
me being disconnected from the real world, but that your explanation is
insufficient.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-16 2:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910160357370.4985@pacific.mpi-cbg.de>
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Oct 2009, Nicolas Pitre wrote:
>
> > On Fri, 16 Oct 2009, Johannes Schindelin wrote:
> >
> > > We, the old Gits need to change. Not the many other people.
> > >
> > > Remember: you do not know how exactly the clutch interacts with the 2nd
> > > cylinder of the engine. And you do not _need_ to.
> >
> > Really, the detached HEAD concept can't be _that_ hard.
>
> You are trying to educate the users to use the double-clutch. Rather than
> making the double-clutch obsolete.
> That's what I call "BlameTheWrongThing".
I just can't convince myself to share that point of view. Doesn't mean
that I'm right though, but that's how I see it given the alternative.
> > > Neither should Git users need to.
> >
> > What you're asking for, though, is more comparable to asking old Gits to
> > give up on their clutch and manual gearbox because most American Git
> > users are expecting automatic transmissions. Maybe that's not the case
> > in Germany, but over here automatic transmissions are by far the norm
> > and a manual gearbox can be obtained only in limited cases if at all.
>
> Your point being? You really think Git is already at the stage where it
> has automatic transmission and all you have to do is hit the gas or the
> brake? No, Nico, you are too intelligent to believe that.
No, Git is not at the automatic transmission level, and I _don't_ want
it to, ever. That would not be _my_ choice.
> Besides, Git is not even at the stage of a manual gearbox.
Here I disagree.
> Just recently, I had a user request (a very valid one, mind you) where the
> user does not want to provide a commit message, and wants to just commit
> all the current changes. In that particular case, it is very sensible to
> ask for these things. It is something utterly simple to ask for. Yet, it
> is utterly hard with Git, especially if I have to explain it.
I hope this is a bad example. I just can't imagine how "very sensible"
you may consider messageless commits. I've dealt with them too many
times in my life.
But still, if someone just can't be bothered at all then the
"workaround" is easy: just use '-m.' or any other meaningless character
of your choice. At least _I_ will be able to identify those commits as
being purposely messageless and make a better informed opinion on that
committer instead of blaming it on ignorance.
> Maybe the core Git developers should spend a month explaining the core
> principles of Git to some random software developers, just so all of us
> get an idea just how wrong we are on the account of how intuitive Git is.
Sorry but I don't share that feeling of hopelessness that seems to
affect those random software developers you might have tried to teach
Git to. Well, actually I do have to deal with hopeless software
developers once in a while which are simply total idiots, and they
certainly shine at depicting Git, or any other tool at their disposal
for that matter, as utter crap. But fortunately for me, the few people
to whom I've explained Git so far simply got it in very little time.
In my opinion, the most important concept to explain first is Git
branching. Everything else is kinda secondary. Worked for me pretty
well so far.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-16 2:07 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910152118360.20122@xanadu.home>
Hi,
On Thu, 15 Oct 2009, Nicolas Pitre wrote:
> On Fri, 16 Oct 2009, Johannes Schindelin wrote:
>
> > We, the old Gits need to change. Not the many other people.
> >
> > Remember: you do not know how exactly the clutch interacts with the 2nd
> > cylinder of the engine. And you do not _need_ to.
>
> Really, the detached HEAD concept can't be _that_ hard.
You are trying to educate the users to use the double-clutch. Rather than
making the double-clutch obsolete.
That's what I call "BlameTheWrongThing".
> > Neither should Git users need to.
>
> What you're asking for, though, is more comparable to asking old Gits to
> give up on their clutch and manual gearbox because most American Git
> users are expecting automatic transmissions. Maybe that's not the case
> in Germany, but over here automatic transmissions are by far the norm
> and a manual gearbox can be obtained only in limited cases if at all.
Your point being? You really think Git is already at the stage where it
has automatic transmission and all you have to do is hit the gas or the
brake? No, Nico, you are too intelligent to believe that.
Besides, Git is not even at the stage of a manual gearbox.
Just recently, I had a user request (a very valid one, mind you) where the
user does not want to provide a commit message, and wants to just commit
all the current changes. In that particular case, it is very sensible to
ask for these things. It is something utterly simple to ask for. Yet, it
is utterly hard with Git, especially if I have to explain it.
Maybe the core Git developers should spend a month explaining the core
principles of Git to some random software developers, just so all of us
get an idea just how wrong we are on the account of how intuitive Git is.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-16 1:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910160256180.4985@pacific.mpi-cbg.de>
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
> We, the old Gits need to change. Not the many other people.
>
> Remember: you do not know how exactly the clutch interacts with the 2nd
> cylinder of the engine. And you do not _need_ to.
Really, the detached HEAD concept can't be _that_ hard. It is not like
if we were asking our users to fully grok the blob/tree/commit hierarchy
and delta compression heuristics to be able to work with Git.
> Neither should Git users need to.
What you're asking for, though, is more comparable to asking old Gits to
give up on their clutch and manual gearbox because most American Git
users are expecting automatic transmissions. Maybe that's not the case
in Germany, but over here automatic transmissions are by far the norm
and a manual gearbox can be obtained only in limited cases if at all.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-16 1:04 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910142237010.20122@xanadu.home>
Hi,
On Wed, 14 Oct 2009, Nicolas Pitre wrote:
> On Wed, 14 Oct 2009, Jeff King wrote:
>
> > On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
> >
> > > Nicolas Pitre <nico@fluxnic.net> writes:
> > >
> > > > Can't the user confusion be dealt with through some means other than
> > > > making the tool less flexible? I don't mind extra help message to be
> > > > displayed after a headless commit is made for example. But trying to
> > > > make the tool more friendly should perhaps come from better education
> > > > rather than added restrictions.
> > > >
> > > > My thoughts only.
> > >
> > > I actually share that but there apparently are people who have given up on
> > > the education route.
> >
> > I am personally undecided on this issue (my "this is the best option"
> > was the best of "a -f switch to commit, an 'expert' config option', or a
> > session-based option to commit").
> >
> > But we really seem to have reached an impasse with how to proceed with
> > git ui.
> >
> > People like Dscho are fed up with user complaints about parts of git
> > that can be unfriendly to new users. And I can understand that.
>
> People like Dscho have to grow a thicker skin then. There will _always_
> be user complaints regardless of how balanced you try to make a UI.
You are seriously misreading my intentions, then. Or my intelligence.
It is not about growing a thicker skin towards unmerited complaints.
It is about shedding the thick skin when there are merited complaints, and
some people are just too used to the old ways to understand that some of
the complaints have _a lot_ of merit.
It is just like with the olden days when only a precious few could drive
cars, and maintained that it _is_ hard to drive a car, and _not_ everybody
can do it _because_ you will have a breakdown with the car and you _have_
to be able to fix it yourself.
Fast-forward a hundred years.
None of this is true any longer.
None.
Guess what? In these days, we do not need a hundred years. Four is
plenty enough. We have a lot of Git users who do not understand the inner
workings of Git. And why should they need to?
Who are you to say they should?
We, the old Gits need to change. Not the many other people.
Remember: you do not know how exactly the clutch interacts with the 2nd
cylinder of the engine. And you do not _need_ to.
Neither should Git users need to.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-16 0:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Jeff King, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <7viqeha2zv.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 14 Oct 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > Can't the user confusion be dealt with through some means other than
> > making the tool less flexible? I don't mind extra help message to be
> > displayed after a headless commit is made for example. But trying to
> > make the tool more friendly should perhaps come from better education
> > rather than added restrictions.
> >
> > My thoughts only.
>
> I actually share that but there apparently are people who have given up on
> the education route.
At some point, when you try to teach something that people (i.e. more than
one person) do not get easily, you cannot do anything but admit that what
you try to teach is crap. Obviously you did not have that experience.
Maybe you are just more picky than me when it comes to who you try to
teach. But of course, that does not make what you try to teach less crap.
In this particular case, I cannot help but notice that commits performed
on a detached HEAD will get lost _unless_ they are somehow put onto a
named branch eventually. So the only question is whether you restrict
flexibility by requiring to name the branch first before committing,
instead of committing and then naming the branch.
So you are talking about "retaining flexibility" in favor of making the
tool less user-friendly, when all it would take from the few power-users
is to name the branch before committing to it, instead of the other way
round.
You must be kidding me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-16 0:43 UTC (permalink / raw)
To: James Pickens
Cc: Junio C Hamano, Jeff King, Nicolas Pitre, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <885649360910151647v27a15334x63fe3b6f5035dbd2@mail.gmail.com>
Hi,
On Thu, 15 Oct 2009, James Pickens wrote:
> On Thu, Oct 15, 2009 at 3:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> $ git checkout origin/next ;# ditto
> >> $ git symbolic-ref HEAD
> >> refs/remotes/origin/next
> >
> > Ok, after reading Daniel's message to remind us that "git fetch" after
> > this will get us into trouble, I agree that detaching HEAD is inevitable.
>
> Some people liked the idea, so let's not give up just yet. Here are a few
> things Git could do when a fetch wants to update the currently checked out
> branch:
>
> 1. Refuse the fetch.
> 2. Update the ref, leaving the user with a work tree and index that don't
> match their HEAD.
> 3. Detach the HEAD, then update the ref.
> 4. Update the ref, then check it out.
Everything but 1 and 4 would blatantly violate the law of the Least
Surprise.
And that very much includes what our beloved maintainer proposes.
BTW I appreciate that finally a few users join discussion. It felt
awfully lonely for a while.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-16 0:34 UTC (permalink / raw)
To: James Pickens
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <885649360910151647v27a15334x63fe3b6f5035dbd2@mail.gmail.com>
On Thu, 15 Oct 2009, James Pickens wrote:
> BTW I'm not convinced this is any better than the current UI... just
> thinking out loud.
I concur with that.
> And I find it more than a little depressing that most
> of these ideas have already been discussed almost 3 years ago (thanks Jeff
> for the pointer).
Rehashing them from time to time is not necessarily a bad idea. Maybe
something better might (or not) turn up this time.
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