* 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
* [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: [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
* 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: [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
* [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
* [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 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 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
* Re: [PATCH v2 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Thomas Rast @ 2009-10-16 8:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091016053230.GB10629@coredump.intra.peff.net>
Jeff King wrote:
> > + 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.
I had a slightly better idea today: We can just put an extra member
into the complete_reflogs struct, i.e., a short_ref to go along with
the ref. It'll take a bit of auditing to verify that all allocations
are zeroed, but since the struct is local to the file that shouldn't
be so hard.
> 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.
Ah, yeah, I looked for "reflog" instead of something about pretty, so
I ended up with t1411. t6006 is a better fit. Thanks for the extra
test!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2 0/5] Pretty formats for reflog data
From: Jakub Narebski @ 2009-10-16 9:00 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091016052003.GA10629@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 16, 2009 at 12:41:43AM +0200, Thomas Rast wrote:
> > 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.
Or we could go the whole nine miles, and implement some subset of
advanced shell syntax,
%(parameter:-word)
%(parameter:=word)
%(parameter:?word)
%(parameter:+word)
RPM spec syntax,
%(?parameter) # expand if exists
%(!?parameter) # expand if does not exists
%(?parameter:literal)
%(!?parameter:literal)
or RPM queryformat
%10(parameter)
%-30(parameter)
[ %(messagebody)\n] # messagebody is list of lines
[%(=param) %(list)\n] # param is not a list; repeat it
%|parameter?{present}:{missing}|
%(parameter:date)
%(parameter:shescape)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] grep: do not segfault when -f is used
From: Matt Kraai @ 2009-10-16 8:53 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
builtin-grep.c | 2 +-
t/t7002-grep.sh | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..1df25b0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -631,7 +631,7 @@ static int file_callback(const struct option *opt, const char *arg, int unset)
struct grep_opt *grep_opt = opt->value;
FILE *patterns;
int lno = 0;
- struct strbuf sb;
+ struct strbuf sb = STRBUF_INIT;
patterns = fopen(arg, "r");
if (!patterns)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae56a36..762f815 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -44,6 +44,10 @@ test_expect_success 'grep should not segfault with a bad input' '
test_must_fail git grep "("
'
+test_expect_success 'grep should not segfault with -f' '
+ test_must_fail git grep -f /dev/null
+'
+
for H in HEAD ''
do
case "$H" in
--
1.6.5
^ permalink raw reply related
* Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 9:07 UTC (permalink / raw)
To: git
Hi all,
I would like to say Hi! Git is great.
I made a hack to import the wikipedia changelogs into git, it is free
software and all checked in. I will be improving it to keep the git
repo in sync.
Here is the discussion on foundation-l :
http://www.gossamer-threads.com/lists/wiki/foundation/181163
the question is, is there a blame tool that we can use for multiple
horizontal diffs on the same line that will be needed for wikipedia
articles?
If not, I would work on this, if you give me some pointers.
thanks,
mike
^ permalink raw reply
* [PATCH v4] git-gui: adjust the minimum height of diff pane for shorter screen height
From: Vietor Liu @ 2009-10-16 9:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Schindelin, Junio C Hamano
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] grep: do not segfault when -f is used
From: Johannes Sixt @ 2009-10-16 10:34 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, gitster
In-Reply-To: <1255683204-28988-1-git-send-email-kraai@ftbfs.org>
Matt Kraai schrieb:
> "git grep" would segfault if its -f option was used because it would
> try to use an uninitialized strbuf, so initialize the strbuf.
Thanks for noticing and for the patch.
But...
> +test_expect_success 'grep should not segfault with -f' '
> + test_must_fail git grep -f /dev/null
> +'
there must be a better way to test whether grep -f behaves correctly.
-- Hannes
^ permalink raw reply
* Q: supplying large sets of path to git commands
From: Constantine Plotnikov @ 2009-10-16 10:40 UTC (permalink / raw)
To: Git Mailing List
Some git commands like git check-attr supports receiving paths from
stdin. For other commands like "git diff" and "git commit --only" I
have not found a way to supply a lot of paths (say 1000). Is there a
standard way pass a additional paths to git commands that works on
windows and unix? It would be nice to have --stdin option for all
commands that might receive a set of paths. Or even better would
something like "--options-from-stdin" and
"--options-from-file=file.txt" as a possible last argument specified
on the command line.
Constantine
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Johannes Schindelin @ 2009-10-16 11:26 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910160207x49feb40ej692188abb0a57473@mail.gmail.com>
Hi,
On Fri, 16 Oct 2009, jamesmikedupont@googlemail.com wrote:
> I made a hack to import the wikipedia changelogs into git, it is free
> software and all checked in. I will be improving it to keep the git
> repo in sync.
This is cool! I actually wanted this for quite some time, and could not
find the time to do it myself.
> Here is the discussion on foundation-l :
> http://www.gossamer-threads.com/lists/wiki/foundation/181163
I found the link to the bazaar repository there, but do you have a Git
repository, too?
> the question is, is there a blame tool that we can use for multiple
> horizontal diffs on the same line that will be needed for wikipedia
> articles?
I am not quite sure what you want to do horizontally there... Can you
explain what you want to see?
Ciao,
Dscho
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Bruno Harbulot @ 2009-10-16 11:20 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <28c656e20910151029s2e053f75q56e968f313d12b21@mail.gmail.com>
B Smith-Mannschott wrote:
>> I've had a quick look at the git-svn code to see how this ID was generated,
>> but couldn't find anything obvious.
>> I realise this isn't the cleanest approach possible, but any suggestion
>> would be appreciated.
>
> When I 'git svn clone' from a svnsync mirror I pass
> --use-svnsync-props. Have you tried that?
Thank you, I hadn't noticed this option, but it was the right one indeed.
Best wishes,
Bruno.
^ permalink raw reply
* Re: [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Johannes Schindelin @ 2009-10-16 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1255681702-5215-3-git-send-email-gitster@pobox.com>
Hi,
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> consumed = fn(sb, format, context);
> - if (consumed)
> + if ((ssize_t) consumed < 0)
> + break;
Would it not be much better to fix the signature of fn in a separate
commit before this one?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Johannes Schindelin @ 2009-10-16 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1255681702-5215-4-git-send-email-gitster@pobox.com>
Hi,
maybe "rewrap" would be a better name than "w"?
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> #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.
Can't we parse it once, i.e. the first time?
Ciao,
Dscho
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Martin Langhoff @ 2009-10-16 11:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jamesmikedupont@googlemail.com, git
In-Reply-To: <alpine.DEB.1.00.0910161321550.4985@pacific.mpi-cbg.de>
On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I am not quite sure what you want to do horizontally there... Can you
> explain what you want to see?
Highlight the changed bits on the line. Example - the red-bold highlight in:
http://en.wikipedia.org/w/index.php?title=David_Letterman&action=historysubmit&diff=320061135&oldid=320060840
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 11:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910161321550.4985@pacific.mpi-cbg.de>
On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> Here is the discussion on foundation-l :
>> http://www.gossamer-threads.com/lists/wiki/foundation/181163
>
> I found the link to the bazaar repository there, but do you have a Git
> repository, too?
Not yet. Where should I put it? Any suggestions.
>> the question is, is there a blame tool that we can use for multiple
>> horizontal diffs on the same line that will be needed for wikipedia
>> articles?
>
> I am not quite sure what you want to do horizontally there... Can you
> explain what you want to see?
Yes, I would like to see all the contributors to each word or line.
Basically one line of blame per contributor, so many lines of output.
Ideally we would have something that is usable in a html display. Lets
say, just an blame attribute for each word. so on one line :
This is a line with two changes first change Second change end of line
It would look like this in html :
This is a line with two changes <span blame=revisionid>first
change</span><span blame=revisionid>Second change</span> end of line
The blame edit could look like this :
REVISION ID 1 48 : This is a line with two changes first
change first change \
REVISTION ID 2 48 C: Second change end of line
let me see if I can find an online example.
Here is a blame tool with links to the edits:
http://hewgill.com/journal/entries/461-wikipedia-blame
here is the wikitrust tool that could be interesting :
http://wikitrust.soe.ucsc.edu/
http://wikitrust.collaborativetrust.com/screenshots
Thanks,
mike
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-16 11:48 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Johannes Sixt,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <200910141133.11386.trast@student.ethz.ch>
Hi,
On Wed, 14 Oct 2009, Thomas Rast wrote:
> [On the other hand, some users appear unwilling to learn something new
> because they "just want to version control this" or "just need to make a
> commit to this project".]
Frankly, if the choice is between "I just want to make a commit to this
project" and "Then I'll not use version control at all", I'd rather choose
the former.
Which is exactly what I did the other day, having to write a non-trivial
script to allow the user to do what he wants to do.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-16 12:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Johannes Sixt,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910161346560.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 14 Oct 2009, Thomas Rast wrote:
>
> > [On the other hand, some users appear unwilling to learn something new
> > because they "just want to version control this" or "just need to make a
> > commit to this project".]
>
> Frankly, if the choice is between "I just want to make a commit to this
> project" and "Then I'll not use version control at all", I'd rather choose
> the former.
Using your automatic gearbox analogy, I should point out that people
still spend significant amounts of time and money on learning how to
drive, despite the fact that learning the internals of the engine is
no longer required.
Yet for some reason, the same people want computers to read their
minds instead of learning how to operate (the more involved parts of)
it.
(Yeah, call me arrogant...)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-16 12:15 UTC (permalink / raw)
To: Daniel Barkalow
Cc: James Pickens, Jeff King, Junio C Hamano, Nicolas Pitre,
Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910151523020.32515@iabervon.org>
On Thu, 15 Oct 2009, Daniel Barkalow wrote:
> On Thu, 15 Oct 2009, James Pickens wrote:
>
>> How about not detaching the head at all if the user checks out any ref, and
>> reject commits if he checked out a tag or remote branch. For example:
>>
>> $ git checkout origin/master
>> $ git status
>> # On branch origin/master
>> $ git commit ;# complain
>
> $ git checkout origin/master
> $ git fetch
> $ git checkout origin/next
> Uncommited file '...' would be overwritten.
How about:
$ git checkout origin/master
$ git fetch
Refusing to fetch, as it would update a checkedout branch
"git fetch -f" will force the update, but you will need to run "git
reset --hard HEAD" to update your checkout to match.
?
--
Julian
---
If you care, you just get disappointed all the time. If you don't care
nothing matters so you are never upset. -- Calvin
^ 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