* [PATCH] describe: load refnames before calling describe()
From: René Scharfe @ 2009-10-17 16:30 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Shawn O. Pearce
Get rid of the static variable that was used to prevent loading all
the refnames multiple times by moving that code out of describe(),
simply making sure it is only run once that way.
Also change the error message that is shown in case no refnames are
found to not include a hash any more, as the error condition is not
specific to any particular revision.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-describe.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..2dcfd3d 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -180,7 +180,6 @@ static void describe(const char *arg, int last_one)
unsigned char sha1[20];
struct commit *cmit, *gave_up_on = NULL;
struct commit_list *list;
- static int initialized = 0;
struct commit_name *n;
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
@@ -192,14 +191,6 @@ static void describe(const char *arg, int last_one)
if (!cmit)
die("%s is not a valid '%s' object", arg, commit_type);
- if (!initialized) {
- initialized = 1;
- for_each_ref(get_name, NULL);
- }
-
- if (!found_names)
- die("cannot describe '%s'", sha1_to_hex(sha1));
-
n = cmit->util;
if (n) {
/*
@@ -359,6 +350,10 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
return cmd_name_rev(i + argc, args, prefix);
}
+ for_each_ref(get_name, NULL);
+ if (!found_names)
+ die("No names found, cannot describe anything.");
+
if (argc == 0) {
describe("HEAD", 1);
} else {
--
1.6.5
^ permalink raw reply related
* Re: Git gui and gitk documentation
From: Sitaram Chamarty @ 2009-10-17 16:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: chris miles, git
In-Reply-To: <4AD870CD.1040709@drmicha.warpmail.net>
On Fri, Oct 16, 2009 at 6:40 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> chris miles venit, vidit, dixit 15.10.2009 22:51:
>> I'm looking for documentation on gitk and the gui that is distributed with git.
> How about
>
> man gitk
> man git-gui
Here's my attempt to document the GUI parts of gitk (the command line options
you can get from 'man gitk' suggested above). I haven't maintained it or
updated it in a while but what there is should still be correct. It may even
be useful :-)
http://sitaramc.github.com/1-basic-usage/gitk.html
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-17 15:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Björn Steinbrink, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vk4yvt7kp.fsf@alter.siamese.dyndns.org>
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>>
>>> Julian Phillips <julian@quantumfyre.co.uk> writes:
>>> ...
>>>> I don't care what git has to do, I'm talking about the user experience
>>>
>>> But Bj?rn is showing two commands the _user_ has to type, iow, the comment
>>> is about the user experience.
>>
>> Only Currently. My point was that _if_ we wanted to support this sort
>> of thing, then we can make is simpler to do by providing a simple
>> command for the user.
>>
>> The point I wanted to make was that the decision on what to do should
>> be driven by the user's experience - not by the fact that it is easier
>> to implement something else.
>
> Sorry, but I do not see in what way what you said in the thread connects
> to the above three lines. Are you talking about this one from you a few
> messages back?
>
> 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.
>
> I am not seeing "not the implementation ease but the user experience"
> drive in this suggestion. If you are driving from the user experience
> point of view, I would have instead suggested:
>
> How about:
>
> $ git checkout origin/master
> $ git fetch
>
> and fetch happily updates the tracked branch, without affecting the
> HEAD state (nor index nor the work tree, of course).
True. I was saying that having git stop and explain things is better than
making a mess for the user to clear up. Having it just work would of
course be even better. Hoist by my own petard indead ...
>> My interest in this thread is solely that it might provide a mechanism
>> to find out which tag was checked out.
>
> Hmm, what is lacking in "git describe HEAD" for that? I am not
> complaining that you might be asking for something that exists, but I _do_
> want to know if something that exists is not a satisfactory solution and
> if so how it can be improved.
What is lacking is the "checked out" part. "git describe HEAD" will tell
me _a_ tag that matches the currently checked out state. However, it
makes no guarantee that it was the one I checked out. If I tag the code
with "v1.0.0", and a colleague later tags it with "this_version_sucks",
then when I check out and build the code for the customer the version it
reports could well be "this_version_sucks" instead of "v1.0.0" ...
Nicolas Pitre suggested using the reflog, which does seem to include the
information that I want, but I feel a little uneasy about accessing it via
a script - how certain is it that the format of the message won't change?
Is accessing the reflog the sort of thing people expect as part of the
scripting interface?
--
Julian
---
Those who would repeat the past must control the teaching of history.
-- Bene Gesserit Coda
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-17 15:15 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Björn Steinbrink, Daniel Barkalow,
James Pickens, Jeff King, Jay Soffian, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0910161557500.20122@xanadu.home>
On Fri, 16 Oct 2009, Nicolas Pitre wrote:
> On Fri, 16 Oct 2009, Julian Phillips wrote:
>
>> My interest in this thread is solely that it might provide a mechanism to find
>> out which tag was checked out. So, I'm just chucking in my $0.02 as a user.
>
> Try this:
>
> $ git checkout v1.5.5
> Note: moving to 'v1.5.5' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 1d2375d... GIT 1.5.5
>
> [look around, and then ...]
>
> $ git checkout HEAD~2
> Previous HEAD position was 1d2375d... GIT 1.5.5
> HEAD is now at f61cc48... git-svn: fix following renamed paths when tracking a single path
>
> [go out for lunch ... and forget what this was about.]
>
> $ git reflog -3
> f61cc48 HEAD@{0}: checkout: moving from 1d2375d... to HEAD~2
> 1d2375d HEAD@{1}: checkout: moving from master to v1.5.5
> c274db7 HEAD@{2}: pull : Fast forward
>
> Here I have all the information to see what I did, and from what state.
> I even know that I did a pull on the master branch before moving away
> from it. The -3 limits the log to 3 entries. With no limit you get it
> all in your default pager.
>
> So there is no need for another mechanism to find out what tag was
> actually checked out -- you have it all already.
What I want is a way for my build process to reliably know what branch or
tag is currently being built. "git symbolic-ref HEAD" will give me the
branch name, but doesn't work for tags. "git describe" will find _a_ tag,
but I can't tell if it's actually the one checked out.
Using the reflog isn't something that had occured to me, but it seems a
bit ... uncontrolled ... for a script. I'd rather have a plumbing level
command that just told me what I had actually checked out. Though I may
well look into using the reflog until such a command is available (or I
find out there already is one).
--
Julian
---
I doubt, therefore I might be.
^ permalink raw reply
* Re: [PATCH v3.1 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Jakub Narebski @ 2009-10-17 15:06 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <e0ab6923eb4057bcbc8e97980dad5e4a37e53067.1255790816.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 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.
Perhaps just-introduced grouping syntax would help there? You could
for example write
--format="%h%[all() %gD: %gs%]"
which would expand nested group if _all_ placeholders within it have
expansion. Perhaps %[ ... %], or %[? ... %], or %[* ... %] could be
shorter versions...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-17 15:02 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Daniel Barkalow, James Pickens, Jeff King, Junio C Hamano,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <20091017075551.GA5474@atjola.homenet>
On Sat, 17 Oct 2009, Bj?rn Steinbrink wrote:
> On 2009.10.16 18:31:23 +0100, Julian Phillips wrote:
>> On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
>>> On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
>>>> 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.
>>>
>>> That would redefine -f (currently means "allow non-fast-forward
>>> updates"), the flag that allows the checked out branch head to be
>>> updated is -u, --update-head-ok, and is for internal use only.
>>>
>>> And suggesting "reset --hard" seems wrong, that just kills any
>>> uncommitted changes.
>>
>> Ok, so the commands were wrong. Not important.
>>
>> It was the approach that I was trying to suggest rather than the
>> actual commands. The point I was trying to make was how, as a user,
>> I would be happy to git behave.
>
> Your approach explicitly included "mess up the index/worktree state",
> otherwise, "git fetch" would not have to tell the user that he has to do
> a "git reset --hard HEAD". I honestly can't believe that you would be
> happy with git messing up your work.
>
>> So, I try to run fetch, git says "ooh, now that would be dangerous -
>> you can force it happen by running "git foo", but you will then be
>> in situation X, which you can then recover from by running "git
>> bar", though you may need to run "git stash" to save any edits you
>> have made" or something similar.
>
> But why make "git fetch" with non-"obscure" refspecs dangerous to begin
> with? If we detach but keep some extra information, there's no need to
> make "git fetch" dangerous, _and_ we can still provide a command that
> just fetches the most recent version of the "checked out" remote
> tracking branch and checks that out. May it be another mode of operation
> for "git pull" or some "git up" command or whatever.
My entire argument was in the context of the mail that I orginally replied
to, i.e. assuming that the decision to not detach had been taken. If that
is not the case, then everything I had said is irrelevant.
I wasn't arguing against detaching, but rather trying to say that _if_ we
are not going to detach then I think it would better like this than that.
I don't personally have any input on the detach or not, as I have been
using git for too long to know if detaching is a problem for others. I
can tell from my bash prompt if I'm detached or on a branch - and that's
fine for me.
--
Julian
---
Wedding is destiny, and hanging likewise.
-- John Heywood
^ permalink raw reply
* [PATCH v3.1 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Thomas Rast @ 2009-10-17 14:48 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <8a5b3a586d437f02e2a75edd2786636b605522a7.1255701207.git.trast@student.ethz.ch>
Add three new --pretty=format escapes:
%gD long reflog descriptor (e.g. refs/stash@{0})
%gd short reflog descriptor (e.g. stash@{0})
%gs reflog message
This is achieved by passing down the reflog info, if any, inside the
pretty_print_context struct.
We use the newly refactored get_reflog_selector(), and give it some
extra functionality to extract a shortened ref. The shortening is
cached inside the commit_reflogs struct; the only allocation of it
happens in read_complete_reflog(), where it is initialised to 0. Also
add another helper get_reflog_message() for the message extraction.
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.
Thanks to Jeff King for reviews, the %gd testcase and documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I wrote:
> [Tacking this on the corresponding v3 patch, but the text below is
> from <20091017011801.GA31443@coredump.intra.peff.net>.]
This sadly backfired, as I forgot to snip out the in-reply-to in the
mail itself and git-send-email apparently trusted that more. Sorry
for the confusion.
Jeff King wrote:
> I am tempted to do a note like the one below, but maybe the behavior is
> obvious enough to users that it isn't necessary.
[...]
> +NOTE: Some placeholders may depend on other options given to the
> +revision traversal engine. For example, the `%g*` reflog options will
> +insert an empty string unless we are traversing reflog entries (e.g., by
> +`git log -g`). The `%d` placeholder will use the "short" decoration
> +format if `--decorate` was not already provided on the command line.
Sure. I figured it was obvious enough, but since you already went to
the lengths of documenting the exact behaviour of %d, I squashed it
and adjusted the acknowledgement in the commit message accordingly.
Documentation/pretty-formats.txt | 9 +++++++++
commit.h | 1 +
log-tree.c | 1 +
pretty.c | 17 +++++++++++++++++
reflog-walk.c | 35 ++++++++++++++++++++++++++++++++---
reflog-walk.h | 8 ++++++++
t/t6006-rev-list-format.sh | 18 ++++++++++++++++++
7 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..38b9904 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
@@ -132,6 +135,12 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
+NOTE: Some placeholders may depend on other options given to the
+revision traversal engine. For example, the `%g*` reflog options will
+insert an empty string unless we are traversing reflog entries (e.g., by
+`git log -g`). The `%d` placeholder will use the "short" decoration
+format if `--decorate` was not already provided on the command line.
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
diff --git a/commit.h b/commit.h
index 011766d..15cb649 100644
--- a/commit.h
+++ b/commit.h
@@ -70,6 +70,7 @@ struct pretty_print_context
const char *after_subject;
enum date_mode date_mode;
int need_8bit_cte;
+ struct reflog_walk_info *reflog_info;
};
extern int non_ascii(int);
diff --git a/log-tree.c b/log-tree.c
index f57487f..8e782fc 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -409,6 +409,7 @@ void show_log(struct rev_info *opt)
ctx.date_mode = opt->date_mode;
ctx.abbrev = opt->diffopt.abbrev;
ctx.after_subject = extra_headers;
+ ctx.reflog_info = opt->reflog_info;
pretty_print_commit(opt->commit_format, commit, &msgbuf, &ctx);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index d6d57eb..fc65fca 100644
--- a/pretty.c
+++ b/pretty.c
@@ -7,6 +7,7 @@
#include "mailmap.h"
#include "log-tree.h"
#include "color.h"
+#include "reflog-walk.h"
static char *user_format;
@@ -701,6 +702,22 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'g': /* reflog info */
+ switch(placeholder[1]) {
+ case 'd': /* reflog selector */
+ case 'D':
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_selector(sb,
+ c->pretty_ctx->reflog_info,
+ c->pretty_ctx->date_mode,
+ (placeholder[1] == 'd'));
+ return 2;
+ case 's': /* reflog message */
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_message(sb, c->pretty_ctx->reflog_info);
+ return 2;
+ }
+ return 0; /* unknown %g placeholder */
}
/* For the rest we have to parse the commit header. */
diff --git a/reflog-walk.c b/reflog-walk.c
index 596bafe..caba4f7 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -8,6 +8,7 @@
struct complete_reflogs {
char *ref;
+ const char *short_ref;
struct reflog_info {
unsigned char osha1[20], nsha1[20];
char *email;
@@ -243,15 +244,26 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
void get_reflog_selector(struct strbuf *sb,
struct reflog_walk_info *reflog_info,
- enum date_mode dmode)
+ enum date_mode dmode,
+ int shorten)
{
struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ const char *printed_ref;
if (!commit_reflog)
return;
- strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (shorten) {
+ if (!commit_reflog->reflogs->short_ref)
+ commit_reflog->reflogs->short_ref
+ = shorten_unambiguous_ref(commit_reflog->reflogs->ref, 0);
+ printed_ref = commit_reflog->reflogs->short_ref;
+ } else {
+ printed_ref = commit_reflog->reflogs->ref;
+ }
+
+ strbuf_addf(sb, "%s@{", printed_ref);
if (commit_reflog->flag || dmode) {
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
strbuf_addstr(sb, show_date(info->timestamp, info->tz, dmode));
@@ -263,6 +275,23 @@ void get_reflog_selector(struct strbuf *sb,
strbuf_addch(sb, '}');
}
+void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+ size_t len;
+
+ if (!commit_reflog)
+ return;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ len = strlen(info->message);
+ if (len > 0)
+ len--; /* strip away trailing newline */
+ strbuf_add(sb, info->message, len);
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
@@ -272,7 +301,7 @@ void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
- get_reflog_selector(&selector, reflog_info, dmode);
+ get_reflog_selector(&selector, reflog_info, dmode, 0);
if (oneline) {
printf("%s: %s", selector.buf, info->message);
}
diff --git a/reflog-walk.h b/reflog-walk.h
index 74c9096..7bd2cd4 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -3,6 +3,8 @@
#include "cache.h"
+struct reflog_walk_info;
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
@@ -10,5 +12,11 @@ extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
+extern void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info);
+extern void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode,
+ int shorten);
#endif
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 59d1f62..7f61ab0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,4 +162,22 @@ test_expect_success 'empty email' '
}
'
+test_expect_success '"%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 '"%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
+'
+
+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
--
1.6.5.116.g4aaa3
^ permalink raw reply related
* [PATCH v3.1 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Thomas Rast @ 2009-10-17 14:39 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255789678.git.trast@student.ethz.ch>
Add three new --pretty=format escapes:
%gD long reflog descriptor (e.g. refs/stash@{0})
%gd short reflog descriptor (e.g. stash@{0})
%gs reflog message
This is achieved by passing down the reflog info, if any, inside the
pretty_print_context struct.
We use the newly refactored get_reflog_selector(), and give it some
extra functionality to extract a shortened ref. The shortening is
cached inside the commit_reflogs struct; the only allocation of it
happens in read_complete_reflog(), where it is initialised to 0. Also
add another helper get_reflog_message() for the message extraction.
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.
Thanks to Jeff King for reviews, the %gd testcase and documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[Tacking this on the corresponding v3 patch, but the text below is
from <20091017011801.GA31443@coredump.intra.peff.net>.]
Jeff King wrote:
> I am tempted to do a note like the one below, but maybe the behavior is
> obvious enough to users that it isn't necessary.
[...]
> +NOTE: Some placeholders may depend on other options given to the
> +revision traversal engine. For example, the `%g*` reflog options will
> +insert an empty string unless we are traversing reflog entries (e.g., by
> +`git log -g`). The `%d` placeholder will use the "short" decoration
> +format if `--decorate` was not already provided on the command line.
Sure. I figured it was obvious enough, but since you already went to
the lengths of documenting the exact behaviour of %d, I squashed it
and adjusted the acknowledgement in the commit message accordingly.
Documentation/pretty-formats.txt | 9 +++++++++
commit.h | 1 +
log-tree.c | 1 +
pretty.c | 17 +++++++++++++++++
reflog-walk.c | 35 ++++++++++++++++++++++++++++++++---
reflog-walk.h | 8 ++++++++
t/t6006-rev-list-format.sh | 18 ++++++++++++++++++
7 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..38b9904 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
@@ -132,6 +135,12 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
+NOTE: Some placeholders may depend on other options given to the
+revision traversal engine. For example, the `%g*` reflog options will
+insert an empty string unless we are traversing reflog entries (e.g., by
+`git log -g`). The `%d` placeholder will use the "short" decoration
+format if `--decorate` was not already provided on the command line.
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
diff --git a/commit.h b/commit.h
index 011766d..15cb649 100644
--- a/commit.h
+++ b/commit.h
@@ -70,6 +70,7 @@ struct pretty_print_context
const char *after_subject;
enum date_mode date_mode;
int need_8bit_cte;
+ struct reflog_walk_info *reflog_info;
};
extern int non_ascii(int);
diff --git a/log-tree.c b/log-tree.c
index f57487f..8e782fc 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -409,6 +409,7 @@ void show_log(struct rev_info *opt)
ctx.date_mode = opt->date_mode;
ctx.abbrev = opt->diffopt.abbrev;
ctx.after_subject = extra_headers;
+ ctx.reflog_info = opt->reflog_info;
pretty_print_commit(opt->commit_format, commit, &msgbuf, &ctx);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index d6d57eb..fc65fca 100644
--- a/pretty.c
+++ b/pretty.c
@@ -7,6 +7,7 @@
#include "mailmap.h"
#include "log-tree.h"
#include "color.h"
+#include "reflog-walk.h"
static char *user_format;
@@ -701,6 +702,22 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'g': /* reflog info */
+ switch(placeholder[1]) {
+ case 'd': /* reflog selector */
+ case 'D':
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_selector(sb,
+ c->pretty_ctx->reflog_info,
+ c->pretty_ctx->date_mode,
+ (placeholder[1] == 'd'));
+ return 2;
+ case 's': /* reflog message */
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_message(sb, c->pretty_ctx->reflog_info);
+ return 2;
+ }
+ return 0; /* unknown %g placeholder */
}
/* For the rest we have to parse the commit header. */
diff --git a/reflog-walk.c b/reflog-walk.c
index 596bafe..caba4f7 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -8,6 +8,7 @@
struct complete_reflogs {
char *ref;
+ const char *short_ref;
struct reflog_info {
unsigned char osha1[20], nsha1[20];
char *email;
@@ -243,15 +244,26 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
void get_reflog_selector(struct strbuf *sb,
struct reflog_walk_info *reflog_info,
- enum date_mode dmode)
+ enum date_mode dmode,
+ int shorten)
{
struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ const char *printed_ref;
if (!commit_reflog)
return;
- strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (shorten) {
+ if (!commit_reflog->reflogs->short_ref)
+ commit_reflog->reflogs->short_ref
+ = shorten_unambiguous_ref(commit_reflog->reflogs->ref, 0);
+ printed_ref = commit_reflog->reflogs->short_ref;
+ } else {
+ printed_ref = commit_reflog->reflogs->ref;
+ }
+
+ strbuf_addf(sb, "%s@{", printed_ref);
if (commit_reflog->flag || dmode) {
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
strbuf_addstr(sb, show_date(info->timestamp, info->tz, dmode));
@@ -263,6 +275,23 @@ void get_reflog_selector(struct strbuf *sb,
strbuf_addch(sb, '}');
}
+void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+ size_t len;
+
+ if (!commit_reflog)
+ return;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ len = strlen(info->message);
+ if (len > 0)
+ len--; /* strip away trailing newline */
+ strbuf_add(sb, info->message, len);
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
@@ -272,7 +301,7 @@ void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
- get_reflog_selector(&selector, reflog_info, dmode);
+ get_reflog_selector(&selector, reflog_info, dmode, 0);
if (oneline) {
printf("%s: %s", selector.buf, info->message);
}
diff --git a/reflog-walk.h b/reflog-walk.h
index 74c9096..7bd2cd4 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -3,6 +3,8 @@
#include "cache.h"
+struct reflog_walk_info;
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
@@ -10,5 +12,11 @@ extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
+extern void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info);
+extern void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode,
+ int shorten);
#endif
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 59d1f62..7f61ab0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,4 +162,22 @@ test_expect_success 'empty email' '
}
'
+test_expect_success '"%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 '"%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
+'
+
+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
--
1.6.5.116.g4aaa3
^ permalink raw reply related
* [PATCH] bash: complete more options for 'git rebase'
From: Björn Gustavsson @ 2009-10-17 9:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
I am primarily interested in having the --whitespace= option completed,
but while at it I have added completion for the other potentially useful
long options.
contrib/completion/git-completion.bash | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d3fec32..7c7318c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1323,8 +1323,18 @@ _git_rebase ()
fi
__git_complete_strategy && return
case "$cur" in
+ --whitespace=*)
+ __gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
+ return
+ ;;
--*)
- __gitcomp "--onto --merge --strategy --interactive"
+ __gitcomp "
+ --onto --merge --strategy --interactive
+ --preserve-merges --stat --no-stat
+ --committer-date-is-author-date --ignore-date
+ --ignore-whitespace --whitespace=
+ "
+
return
esac
__gitcomp "$(__git_refs)"
--
1.6.5.2.gd6127
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-17 9:04 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <20091017084025.GC5474@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Interestingly, I irregularly give advice to use "git stash; git
> checkout; git stash apply" instead of "git checkout -m" on #git, as that
> allows you to try again if you messed up the conflict resolution, and
> even allows you to completely go back to the initial state. Maybe that
> would be an option?
As I already said many times (here and elsewhere), "up" is an inferior and
more dangerous model we would be better off not following if we can.
It is not even entirely CVS/SVN's fault that their "scm up" is an error
prone operation. They use a centralized model, in which there is _no_ way
to record your local modification and run a retryable merge, so they have
an excuse to force users to do things in "work, then update without
recording wip anywhere" order.
You can afford to (and it is even more natural to) do things in "work,
save and then merge" order with git. I simply cannot believe people who
advocate for helping uninitiated would even think of modelling any "user
friendliness" features around "up" model.
The "save" part of the work-save-then-merge sequence should be made very
visible to help people get used to the "not up, but work-save-then-merge"
mental model. I do not think it would help people in the long run to make
the "save" step less visible by wrapping the sequence into an unreliable
"up" script, especially because the script would sometimes work but other
times *has to* force users to know that what is happening behind the scene
is work-save-then-merge in order to resolve and recover from conflicts
anyway.
> OTOH, it might be easier to just tell the user to do the stash thing
> himself. But I wonder how many users would really know how to get back
> to the initial state then.
I agree with the first sentence, but I do not understand what "the initial
state" you talk about here in the second sentence, sorry.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-17 8:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vws2ue8yc.fsf@alter.siamese.dyndns.org>
On 2009.10.17 01:11:23 -0700, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > ... If so, it does a "git checkout --merge
> > <upstream>" (possibly leaving conflicts for the uncommitted changes,
> > just like "svn update").
>
> Up to this point I was reading with quite a lot of interest. But here I
> strongly disagree to the point of getting actually disgusted.
>
> "svn up" is one of the areas Subversion folks failed to make their system
> a better CVS. It has the same "local changes are lost in the merge
> conflict mess in an irreversible way" failure mode, and we shouldn't be
> making it easy to new people. It is not something we should emulate.
>
> You can and should instead refuse the update, and suggest committing first
> so that the user has a safe record of what he has done and the merge with
> upstream can be retried if necessary. As you need to have that "refuse
> but guide the lost soul by telling what to do" mode anyway when...
Hm, probably I (mentally) focussed to much on "people that just want to
look" and didn't really think that they'd have much to lose. Not sure.
Over the time, I got so used to do "git checkout --merge <something>"
with some I-don't-care-much debugging or whatever change, that I lost
track of how bad that was with svn. If I have just I care about, I
commit, and then "git update" would no longer be an option anyway. But
yeah, not a good option to give to the uninitiated user...
Interestingly, I irregularly give advice to use "git stash; git
checkout; git stash apply" instead of "git checkout -m" on #git, as that
allows you to try again if you messed up the conflict resolution, and
even allows you to completely go back to the initial state. Maybe that
would be an option? But I fail to come up with a convenient and at the
same time error safe way for such a "stash wrap". The only thing that
comes to mind would be to have "git update" completely wrapping the
thing:
git update
- Stashes uncommitted changes
- fetches
- checks out
- "stash apply --index", if that fails, just "stash apply"
If there are conflicts, show options (similar to what rebase does):
git update --retry # Start over
- reset --hard
- "stash apply --index", if that fails, just "stash apply"
git update --abort
- git reset --hard HEAD@{1}
- "stash apply --index"
- "stash drop stash@{0}"
git update --done
- Check whether there are still unmerged files, if so: complain
- otherwise: "stash drop stash@{0}"
OTOH, it might be easier to just tell the user to do the stash thing
himself. But I wonder how many users would really know how to get back
to the initial state then.
Björn
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-17 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christoph Bartoschek, git, Daniel Barkalow
In-Reply-To: <7vr5t2h3do.fsf@alter.siamese.dyndns.org>
On 2009.10.17 00:43:31 -0700, Junio C Hamano wrote:
> Christoph Bartoschek <bartoschek@gmx.de> writes:
> > Daniel Barkalow wrote:
> >
> >> The upshot of the messages should be:
> >>
> >> $ git checkout origin/master
> >> Since you can't actually change "origin/master" yourself, you'll just
> >> be sightseeing unless you create a local branch to hold new local work.
> >>
> >> $ git branch
> >> * (not a local branch, but "origin/master")
> >>
> >> $ git commit
> >> You've been sightseeing "origin/master". The commit can't change that
> >> value, so your commit isn't held in any branch. If you want to create
> >> a branch to hold it, here's how.
[...]
> The second item in the Daniel's transcript above may be an improvement but
> I think it is a wrong economy to record and show 'but "origin/master"'
> (which cannot be correct forever and has to be invalidated once the user
> starts committing or resetting) in the message.
I don't think it's entirely wrong to record that information, git just
has to know when to invalidate it, possibly requiring the user to really
detach HEAD.
git checkout origin/master
git checkout origin/master~3
git checkout HEAD^2~5
git reset --hard HEAD~2
Those commands are all about walking the ancestry of origin/master in
some way. So it seems reasonable to assume that HEAD is still weakly
bound to origin/master. And based upon that, there could be something
like "git update", and things like "git status" could show that you're
browsing through the ancestry of origin/master, and that "git commit"
message could maybe say "You've been sightseeing 'origin/master'
[currently at 'origin/master~3^2~7'] ...".
> I am wondering if a similar effect to help new users can be had by
> rewording the message to:
>
> $ git branch
> * (not a local branch; see "git reflog" to learn how you got here)
>
> The user can see how he got there even after doing something else after
> the checkout (see Nico's write-up in $gmane/130527). The difference is
> between giving fish and teaching how to catch one himself.
That could be used when the user actively detached HEAD, invalidating
the "weak binding". Maybe implicitly by "git commit" or
"git reset <something_we_can't_keep_track_of>", or maybe explicitly,
if committing on a "semi-detached HEAD" becomes forbidden.
Or maybe it could always be shown, in addition to "You are here", you
also get told "Do this to find out how you got there". Does seem like a
good idea.
Björn
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-17 8:11 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <20091017075551.GA5474@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> ... If so, it does a "git checkout --merge
> <upstream>" (possibly leaving conflicts for the uncommitted changes,
> just like "svn update").
Up to this point I was reading with quite a lot of interest. But here I
strongly disagree to the point of getting actually disgusted.
"svn up" is one of the areas Subversion folks failed to make their system
a better CVS. It has the same "local changes are lost in the merge
conflict mess in an irreversible way" failure mode, and we shouldn't be
making it easy to new people. It is not something we should emulate.
You can and should instead refuse the update, and suggest committing first
so that the user has a safe record of what he has done and the merge with
upstream can be retried if necessary. As you need to have that "refuse
but guide the lost soul by telling what to do" mode anyway when...
> ... If a fast-forward is not possible, it
> complains, telling the user that he needs to use "git merge/rebase/pull"
> instead, and might want to create a branch head, in case of a detached
> HEAD.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-17 7:55 UTC (permalink / raw)
To: Julian Phillips
Cc: Daniel Barkalow, James Pickens, Jeff King, Junio C Hamano,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910161821230.30589@reaper.quantumfyre.co.uk>
On 2009.10.16 18:31:23 +0100, Julian Phillips wrote:
> On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
> >On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
> >>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.
> >
> >That would redefine -f (currently means "allow non-fast-forward
> >updates"), the flag that allows the checked out branch head to be
> >updated is -u, --update-head-ok, and is for internal use only.
> >
> >And suggesting "reset --hard" seems wrong, that just kills any
> >uncommitted changes.
>
> Ok, so the commands were wrong. Not important.
>
> It was the approach that I was trying to suggest rather than the
> actual commands. The point I was trying to make was how, as a user,
> I would be happy to git behave.
Your approach explicitly included "mess up the index/worktree state",
otherwise, "git fetch" would not have to tell the user that he has to do
a "git reset --hard HEAD". I honestly can't believe that you would be
happy with git messing up your work.
> So, I try to run fetch, git says "ooh, now that would be dangerous -
> you can force it happen by running "git foo", but you will then be
> in situation X, which you can then recover from by running "git
> bar", though you may need to run "git stash" to save any edits you
> have made" or something similar.
But why make "git fetch" with non-"obscure" refspecs dangerous to begin
with? If we detach but keep some extra information, there's no need to
make "git fetch" dangerous, _and_ we can still provide a command that
just fetches the most recent version of the "checked out" remote
tracking branch and checks that out. May it be another mode of operation
for "git pull" or some "git up" command or whatever.
> >And such uncommitted changes would be lost in the big "undo the fetch
> >update" diff. So you'd have to do:
> >git reset --soft HEAD@{1}
> >git checkout --merge HEAD@{1}
> >
> >to keep them, while updating to the new state of the remote tracking
> >branch. Not quite intuitive, is it?
>
> I don't care what git has to do, I'm talking about the user
> experience - if we have to write some new code to support it, that
> really isn't a terribly hard thing to do. UIs should be driven down
> from the user interaction not up from the implementation.
Those commands are those that git would have to show to you, instead of
"git reset --hard HEAD", i.e. they're what you, as the user, have to do.
And while "git reset --hard HEAD" might be remotely understandable to
the user, that command sequence is very unlikely to be understood by
most. And providing a command that does just this sequence is insane,
it's just a bandaid for git doing crap to your worktree/index state. So
let's better not start with git doing that crap at all.
My current "idea" (I don't think I'll have time to implement that any
time soon) is:
Keep some extra information in HEAD (or somewhere else) when HEAD is
detached about the ref that HEAD is "weakly" bound to. For example, "git
checkout origin/master" might create a weak binding to
refs/remotes/origin/master (for other [corner] cases, see the other
mail I wrote, in which I outlined some cases I considered interesting).
"git update" can use the branch.<name>.{remote,merge} setup, or
alternatively the "weak binding" information, to fetch from the right
remote, and checks whether a fast-forward of HEAD to the according
upstream branch head is possible. If so, it does a "git checkout --merge
<upstream>" (possibly leaving conflicts for the uncommitted changes,
just like "svn update"). If a fast-forward is not possible, it
complains, telling the user that he needs to use "git merge/rebase/pull"
instead, and might want to create a branch head, in case of a detached
HEAD.
If there's also going to be a rule that forbids commits on some kind of
detached HEAD, than the command could also tell the user (when a
fast-forward is not possible) that upstream possibly rewrote history,
and that the user might want to use "git checkout --merge <upstream>"
(or maybe "git update -f"?) to just go to the new upstream version (not
sure if that hint should be shown in addition to or instead of the "git
merge/rebase/pull" hint).
Björn
^ permalink raw reply
* Re: [PATCH] grep: do not segfault when -f is used
From: Junio C Hamano @ 2009-10-17 7:44 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <1255702405-7050-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> "git grep" would segfault if its -f option was used because it would
> try to use an uninitialized strbuf, so initialize the strbuf.
>
> Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
> test cases.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Thanks, both of you.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-17 7:43 UTC (permalink / raw)
To: Christoph Bartoschek; +Cc: git, Daniel Barkalow
In-Reply-To: <m49nq6-uk5.ln1@burns.bruehl.pontohonk.de>
Christoph Bartoschek <bartoschek@gmx.de> writes:
[jc: added Daniel back to cc list; please do not cull the cc list without
good reason]
> Daniel Barkalow wrote:
>
>> The upshot of the messages should be:
>>
>> $ git checkout origin/master
>> Since you can't actually change "origin/master" yourself, you'll just
>> be sightseeing unless you create a local branch to hold new local work.
>>
>> $ git branch
>> * (not a local branch, but "origin/master")
>>
>> $ git commit
>> You've been sightseeing "origin/master". The commit can't change that
>> value, so your commit isn't held in any branch. If you want to create
>> a branch to hold it, here's how.
> ...
> But then I was not able to verify that the checkout indeed matched the
> 1.3.0-beta. "git status" and "git branch" did not help here.
This is not going to help you, but "git reflog" would have helped here.
The reason my suggesting "git reflog" now won't help you is because the
word "reflog" does not connect the question "how did I get here" unless
and until you know git already; in other words, it is not your fault that
you got lost, but it is showing a wart in the UI.
If the question you were asking was "does the files I have in my work tree
after issuing that scary checkout actually match origin/1.3.0-beta?", you
could have asked that question in a more direct way, and the command to do
so is "git diff origin/1.3.0-beta". I do not think this would be asking
the user to be doing something unreasonably unintuitive.
If the question you were asking was (and it was not, from the description
of your experience, but you could be in that situation when you "return
some weeks later") "how does the checked out history relate to 1.3.0-beta?",
then there is a way to ask the question in a very direct way, and the
command to do so is "git show-branch HEAD origin/1.3.0-beta" (or give the
same argument to "gitk").
Although it is not _so_ unreasonable to expect "git status" to show the
information, I suspect it would not be practical. After all, whenever
somebody is lost, everything is "status". For a person who is lost and
does not know where in the history he is, it might be reasonable to expect
"status" to give the relationship between your HEAD and some branch/tag,
while for another person who was hit by "git gui" complaining that he has
too many loose objects, it might be reasonable for him to expect "status"
to give the number of loose objects in the repository. IOW, "status" is
too broad a word and following the path to cram everything into "status"
so that any new person who gets lost can get necessary infor from the
command will unfortunately lead to insanity.
The second item in the Daniel's transcript above may be an improvement but
I think it is a wrong economy to record and show 'but "origin/master"'
(which cannot be correct forever and has to be invalidated once the user
starts committing or resetting) in the message. I am wondering if a
similar effect to help new users can be had by rewording the message to:
$ git branch
* (not a local branch; see "git reflog" to learn how you got here)
The user can see how he got there even after doing something else after
the checkout (see Nico's write-up in $gmane/130527). The difference is
between giving fish and teaching how to catch one himself.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Sean Estabrooks @ 2009-10-17 7:24 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>
On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.
Hey Johannes,
It's actually easy, but maybe hard to find:
$ git commit --cleanup=verbatim -m ""
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Christoph Bartoschek @ 2009-10-16 22:36 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.2.00.0910140037570.32515@iabervon.org>
Daniel Barkalow wrote:
> The upshot of the messages should be:
>
> $ git checkout origin/master
> Since you can't actually change "origin/master" yourself, you'll just
> be sightseeing unless you create a local branch to hold new local work.
>
> $ git branch
> * (not a local branch, but "origin/master")
>
> $ git commit
> You've been sightseeing "origin/master". The commit can't change that
> value, so your commit isn't held in any branch. If you want to create
> a branch to hold it, here's how.
I appreciate such a message for git branch as a user. Today I had the
following problem:
I wanted to compile Qt Creator 1.3 from their repository. I cloned it with
git clone and then issued git checkout origin/1.3.0-beta. First there came a
the warning and I was not sure whether the checkout succeeded at all. I had
to ask in the IRC channel whether the checkout was ok.
But then I was not able to verify that the checkout indeed matched the
1.3.0-beta. "git status" and "git branch" did not help here.
Having an improved "git branch" would help a lot, especially if one returns
some weeks later to the directory and wants to know what the checkout is.
Christoph
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-17 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v3a5irkel.fsf@alter.siamese.dyndns.org>
Thank you very much for your input and advice,
I have a lot of learn about this great tool.
I am working on learning how the existing blame tool runs now.
Will report back when I have some code.
mike
On Sat, Oct 17, 2009 at 1:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "jamesmikedupont@googlemail.com" <jamesmikedupont@googlemail.com> writes:
>
>> What do you think of my idea to create blames along a specific user
>> defined byte positions ?
>
> Overly complicated and not enough time for _review_. If you are blaming
> one-byte (or one-char) per line, wouldn't it be enough to consider the
> line number in the output as byte (or char) position when reconstituting
> the original text?
>
^ permalink raw reply
* Re: [PATCH v3 0/5] Pretty formats for reflog data
From: Jeff King @ 2009-10-17 1:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255701207.git.trast@student.ethz.ch>
On Fri, Oct 16, 2009 at 04:20:32PM +0200, Thomas Rast wrote:
> I tried for some time, but all attempts at interrupting the lists
> ended up terminating it again, so that the %g family list would not
> line up with the rest of the parameters. Having the note there would
> be nice, but I think keeping the list together optically is more
> important. However, AFAICS it really is the first character that only
> works with certain options (%m makes little sense without A...B, but
> still expands to >).
Another example is "%d", but there we load decorations on the fly the
first time it is used. I don't think that's a good idea here, since
using "%gd" shouldn't automatically imply "-g", which drastically
changes the nature of the command.
The "%m" behavior does what I would expect. If you haven't done any
limiting, then there can be no "left" or "boundary" entries.
I am tempted to do a note like the one below, but maybe the behavior is
obvious enough to users that it isn't necessary.
> Looking at it did make me notice that @{1} is invalid asciidoc and
> needs to be spelled @\{1\} though :-)
Thanks. I am often very guilty of not actually building documentation
when reviewing patches, because it is so tedious to build and examine.
---
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 6359272..43192af 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -135,6 +135,12 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
+NOTE: Some placeholders may depend on other options given to the
+revision traversal engine. For example, the `%g*` reflog options will
+insert an empty string unless we are traversing reflog entries (e.g., by
+`git log -g`). The `%d` placeholder will use the "short" decoration
+format if `--decorate` was not already provided on the command line.
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
^ permalink raw reply related
* Re: [PATCH v3 0/5] Pretty formats for reflog data
From: Junio C Hamano @ 2009-10-17 0:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255701207.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Next round :-)
Very nicely done; I like it.
Thanks.
^ permalink raw reply
* Re: [PATCH] am: allow some defaults to be specified via git-config
From: Junio C Hamano @ 2009-10-17 0:50 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Nigel McNie
In-Reply-To: <1255650627-17576-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Some users prefer in particular '3way' to be the default, let them
> specify it via the config file - and some other boolean settings while
> we're at it.
I have to wonder how this will interact with the internal call rebase
makes into am. Would there be unexpected fallouts?
^ permalink raw reply
* Re: [PATCH RFC] git describe without refs distinguishes dirty working tree
From: Nicolas Pitre @ 2009-10-17 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jean Privat, Shawn O. Pearce, git
In-Reply-To: <7vvdifq6vw.fsf@alter.siamese.dyndns.org>
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> But the thing is, "git describe" without arguments already works on HEAD
> and describes it, and people depend on the behaviour.
>
> I originally thought this _might_ break and hoped it won't be a big issue,
> but now I've seen that even the kernel would break (it runs the command
> without saying "HEAD"), I do not want to risk breaking other projects I
> may not even heard of. Some people might have copied our GIT-VERSION-GEN
> (that says "HEAD"), but I would not bet against that many many more people
> would have copied the use of "git describe" from the kernel build tree
> than from us.
OpenOCD is another project that just started using Git and copied
describe usage from Linux.
Nicolas
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Junio C Hamano @ 2009-10-17 0:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git
In-Reply-To: <200910170200.03681.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Why not
>
> %[w(-1,4,4)%s%+b]
Yeah. As you said "subject unwrapped and body indented" or something like
that, I excluded that part outside the indentation, but log output indents
everything, so placing both inside %[w] would be correct.
> (i.e. %+ is this empty line between subject and body, if it exists).
As %+ is to add LF iff the next expansion is non-empty, it must always be
followed by an expansion, i.e. %something. That means "%+%something" is
unnecessary verbose and "%+something" is enough. "%+anything" syntax,
just like "%[func()anything]" syntax, is not limited to any particular
expansion.
> The %+x seems a bit strange... but I guess implementing conditional
> expansion a la shell or rpn spec/queryformat would be out of question
> (i.e. %?s:+ )...
Why not?
I can see us doing something like %[conditional%|iftrue%|iffalse%] quite
easily, now we have the "nested" variant of the strbuf_expand()
infrastructure.
But that is not the primary focus of the two patch series I've
demonstrated so far.
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Jakub Narebski @ 2009-10-17 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v7huurkif.fsf@alter.siamese.dyndns.org>
On Sat, 17 Oct 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > But even with original w(<width>,<indent1>,<indent2>) we can get output
> > of bare "git log" using pretty format... well, almost; it would be the
> > same if there was ability to put infinite width, and there doesn't seem
> > to be specifier for the whole, unchanged commit message (subject,
> > unwrapped + separating lines + body).
>
> I think I already discussed this when I sent out %s%+b patch. You would
> need to adjust and apply both series, but essentially it would become
> something like:
>
> %s%+[w(-1,4,4)%b]
>
> I.e. a single subject line, potentially followed by a LF and body indented
> by 4-place, but the LF will be there only when the body is not empty.
Why not
%[w(-1,4,4)%s%+b]
Or is it
%[w(-1,4,4)%s%+%b]
(i.e. %+ is this empty line between subject and body, if it exists).
The %+x seems a bit strange... but I guess implementing conditional
expansion a la shell or rpn spec/queryformat would be out of question
(i.e. %?s:+ )...
--
Jakub Narebski
Poland
^ 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