* Re: [PATCH] git-status: show short sequencer state
From: Matthieu Moy @ 2012-10-23 6:05 UTC (permalink / raw)
To: Phil Hord
Cc: phil.hord, Junio C Hamano, konglu, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <1350948569-28445-2-git-send-email-hordp@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> + merge a git-merge is in progress
> + am a git-am is in progress
> + rebase a git-rebase is in progress
> + rebase-interactive a git-rebase--interactive is in progress
> + cherry-pick a git-cherry-pick is in progress
> + bisect a git-bisect is in progress
Avoid using git-foo syntax in documentation, it suggests that this is
valid command, which isn't true anymore. `git foo` seems the most common
syntax. Also, git-rebase--interactive is not user-visible => `git rebase
--interactive`.
> - if (state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_NOMINAL)
> status_printf_ln(s, color,
> _("The current patch is empty."));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The "if" suggests everything is allright, and the
message below is very specific. This at least deserves a comment.
> if (advice_status_hints) {
> - if (!state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_CONFLICTED)
Spaces around ==.
> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
> +{
> + color_fprintf(s->fp, color, "%s", token);
> + fputc(s->null_termination ? '\0' : '\n', s->fp);
> +}
The output format seems to be meant only for machine-consumption. Is
there any case when we'd want color? I'd say we can disable coloring
completely for this format (normally, color=auto does the right thing,
but I prefer being 100% sure I'll get no color when writing scripts)
> +static void wt_shortstatus_print_sequencer(struct wt_status *s)
[...]
> +void wt_sequencer_print(struct wt_status *s)
> +{
> + wt_shortstatus_print_sequencer(s);
> +}
> +
Why do you need this trivial wrapper?
Other than that, I like the idea (although I have no concrete use-case
in mind), but I didn't actually test the patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-23 6:27 UTC (permalink / raw)
To: git
Hi Git Listeners,
I'm facing one problem when pushing to git repository via gerrit port.
Don't stop to look into the below content, as I doubt it might be a
git problem.
The pushing takes me 7mins~11mins each time every I had git gc on remote.
The remote server is 24 core with scsi disk. And the connection is
within 1000M/s intranet.
The pushing is only slowly on this kernel project, but faster on other
android projects, takes seconds only.
I tried on 4 core and 24 core clients to do the push, the time is
almost the same. So I think it's not the client problem.
The command I use as below. I also tried to pushing to git repository
directly, it is also slow, only some seconds benifit. So I think it
might be not the gerrit problem.
$ git push -v ssh://remote_url:29418/kernel/msm.git HEAD:refs/changes/33599
The stderr stops at remote: Resolving deltas: 0% (0/2) for 99% of the time.
I added some timestamp in the git source code, Like git version 1.8.0.
The receive_status called by send_pack inside send-pack.c takes the
99% of the time.
It looks like the client is waiting the pushing result status from
server although by checking server side, the real object has already
been upload succeed.
Below is the log after adding time info.
$ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
HEAD:refs/changes/33599 2>&1|tee -a log.txt
Pushing to ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
error: Time start packet_flush: Tue Oct 23 14:14:47 2012
error: Time finish packet_trace: Tue Oct 23 14:14:47 2012
error: Time finish safe_write: Tue Oct 23 14:14:47 2012
error: Time start receive_status: Tue Oct 23 14:14:47 2012
remote: Resolving deltas: 0% (0/2)
remote: (W) afafdad: no files changed, message updated
error: Time start packet_read_line: Tue Oct 23 14:24:41 2012
, len=10
error: Time packet_read_line: Tue Oct 23 14:24:41 2012
, len=22
error: Time packet_read_line: Tue Oct 23 14:24:41 2012
, len=0
error: Time finish receive_status: Tue Oct 23 14:24:41 2012
To ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
* [new branch] HEAD -> refs/changes/33599
real 9m56.928s
user 0m0.364s
sys 0m0.160s
--
-Joey Jiao
^ permalink raw reply
* git merge man page, upstream
From: Angelo Borsotti @ 2012-10-23 7:40 UTC (permalink / raw)
To: git
Hello,
the git merge man page, OPTIONS, <commit> ... states:
"If no commit is given from the command line, and if
merge.defaultToUpstream configuration variable is set, merge the
remote tracking branches that the current branch is configured to use
as its upstream. See also the configuration section of this manual
page."
Actually, in this case git merge merges the upstream branch, not the
remote tracking branch.
Proposed change:
"If no commit is given from the command line, and if
merge.defaultToUpstream configuration variable is set, merge the
upstream branches that the current branch has currently configured.
See also the configuration section of this manual page."
-Angelo Borsotti
^ permalink raw reply
* Re: git merge man page, upstream
From: Matthieu Moy @ 2012-10-23 7:51 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9BT3F1_yvf7jQQyT72_EWskFS4bEgXCkmJs7uZOPhEK8w@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hello,
>
> the git merge man page, OPTIONS, <commit> ... states:
>
> "If no commit is given from the command line, and if
> merge.defaultToUpstream configuration variable is set, merge the
> remote tracking branches that the current branch is configured to use
> as its upstream. See also the configuration section of this manual
> page."
>
> Actually, in this case git merge merges the upstream branch, not the
> remote tracking branch.
It merges the upstream branch, which is a remote-tracking branch (notice
the - between remote and tracking, it's a branch that tracks a remote
branch, not a remote branch that tracks something).
I'll send a patch to fix that.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git merge man page, upstream
From: Angelo Borsotti @ 2012-10-23 9:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk3uhr5gp.fsf@grenoble-inp.fr>
Hi Matthieu,
the upstream branch can also be a local branch.
-Angelo
^ permalink raw reply
* git-pull suggests deprecated git-branch --set-upstream flag
From: Tomas Carnecky @ 2012-10-23 9:23 UTC (permalink / raw)
To: git
I just ran git pull, and it suggested that I should use `git branch
--set-upstream`. Yet when I used it, git-branch told me that the flag is
deprecated. Git version 1.8.0.
tom
^ permalink raw reply
* Re: Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-23 10:11 UTC (permalink / raw)
To: git
In-Reply-To: <CAKOmCvp23fALGsDe4Ck7ZXpMJmOAq+YWCXPe_xb6GfQcjJi_kQ@mail.gmail.com>
Well, after checked pushing directly to git which takes only 6
seconds. So it should be not a issue of git in c. But might be an
issue with jgit or gerrit.
2012/10/23 Joey Jiao <joey.jiaojg@gmail.com>:
> Hi Git Listeners,
> I'm facing one problem when pushing to git repository via gerrit port.
> Don't stop to look into the below content, as I doubt it might be a
> git problem.
>
> The pushing takes me 7mins~11mins each time every I had git gc on remote.
> The remote server is 24 core with scsi disk. And the connection is
> within 1000M/s intranet.
> The pushing is only slowly on this kernel project, but faster on other
> android projects, takes seconds only.
> I tried on 4 core and 24 core clients to do the push, the time is
> almost the same. So I think it's not the client problem.
>
> The command I use as below. I also tried to pushing to git repository
> directly, it is also slow, only some seconds benifit. So I think it
> might be not the gerrit problem.
> $ git push -v ssh://remote_url:29418/kernel/msm.git HEAD:refs/changes/33599
> The stderr stops at remote: Resolving deltas: 0% (0/2) for 99% of the time.
>
> I added some timestamp in the git source code, Like git version 1.8.0.
> The receive_status called by send_pack inside send-pack.c takes the
> 99% of the time.
>
> It looks like the client is waiting the pushing result status from
> server although by checking server side, the real object has already
> been upload succeed.
>
> Below is the log after adding time info.
> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> HEAD:refs/changes/33599 2>&1|tee -a log.txt
> Pushing to ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> error: Time start packet_flush: Tue Oct 23 14:14:47 2012
>
> error: Time finish packet_trace: Tue Oct 23 14:14:47 2012
>
> error: Time finish safe_write: Tue Oct 23 14:14:47 2012
>
> error: Time start receive_status: Tue Oct 23 14:14:47 2012
>
> remote: Resolving deltas: 0% (0/2)
> remote: (W) afafdad: no files changed, message updated
> error: Time start packet_read_line: Tue Oct 23 14:24:41 2012
> , len=10
> error: Time packet_read_line: Tue Oct 23 14:24:41 2012
> , len=22
> error: Time packet_read_line: Tue Oct 23 14:24:41 2012
> , len=0
> error: Time finish receive_status: Tue Oct 23 14:24:41 2012
>
> To ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> * [new branch] HEAD -> refs/changes/33599
>
> real 9m56.928s
> user 0m0.364s
> sys 0m0.160s
> --
> -Joey Jiao
--
-Joey Jiao
^ permalink raw reply
* [PATCH] Document git-svn fetch --log-window-size parameter
From: Gunnlaugur Þór Briem @ 2012-10-23 10:33 UTC (permalink / raw)
To: git; +Cc: Gunnlaugur Þór Briem
The --log-window-size parameter to git-svn fetch is undocumented.
Minimally describe what it does and why the user might change it.
Signed-off-by: Gunnlaugur Þór Briem <gunnlaugur@gmail.com>
---
Documentation/git-svn.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cfe8d2b..64756c9 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -146,6 +146,12 @@ Skip "branches" and "tags" of first level directories;;
------------------------------------------------------------------------
--
+--log-window-size=<n>;;
+ Fetch <n> log entries per request when scanning Subversion history.
+ The default is 100. For very large Subversion repositories, larger
+ values may be needed for 'clone'/'fetch' to complete in reasonable
+ time. But overly large values may lead to request timeouts.
+
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
directory based on the basename of the URL passed to it;
--
1.7.12.3
^ permalink raw reply related
* [PATCH] Documentation: remote tracking branch -> remote-tracking branch
From: Matthieu Moy @ 2012-10-23 11:34 UTC (permalink / raw)
To: git, gitster; +Cc: angelo.borsotti, Matthieu Moy
In-Reply-To: <vpqk3uhr5gp.fsf@grenoble-inp.fr>
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2
2010, Replace "remote tracking" with "remote-tracking"), but new
instances of remote tracking (without dash) were introduced in the
meantime.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Here's the patch.
I'm not opposed to dropping completely the remote-tracking part in the
case of merge (i.e. "remote-tracking branches that the current branch
is configured to use as its upstream" -> "upstream branch") on top of
that, but if we do this, merge-config.txt should be updated too).
Documentation/git-clone.txt | 4 ++--
Documentation/git-merge.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/merge-config.txt | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 6d98ef3..7fefdb0 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,9 +196,9 @@ objects from the source repository into a pack in the cloned repository.
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
Further fetches into the resulting repository will only update the
- remote tracking branch for the branch this option was used for the
+ remote-tracking branch for the branch this option was used for the
initial cloning. If the HEAD at the remote did not point at any
- branch when `--single-branch` clone was made, no remote tracking
+ branch when `--single-branch` clone was made, no remote-tracking
branch is created.
--recursive::
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 20f9228..d34ea3c 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -99,7 +99,7 @@ commit or stash your changes before running 'git merge'.
more than two parents (affectionately called an Octopus merge).
+
If no commit is given from the command line, and if `merge.defaultToUpstream`
-configuration variable is set, merge the remote tracking branches
+configuration variable is set, merge the remote-tracking branches
that the current branch is configured to use as its upstream.
See also the configuration section of this manual page.
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 22d2580..fe46c42 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -175,7 +175,7 @@ useful if you write an alias or script around 'git push'.
--recurse-submodules=check|on-demand::
Make sure all submodule commits used by the revisions to be
- pushed are available on a remote tracking branch. If 'check' is
+ pushed are available on a remote-tracking branch. If 'check' is
used git will verify that all submodule commits that changed in
the revisions to be pushed are available on at least one remote
of the submodule. If any commits are missing the push will be
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 861bd6f..9bb4956 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -9,11 +9,11 @@ merge.conflictstyle::
merge.defaultToUpstream::
If merge is called without any commit argument, merge the upstream
branches configured for the current branch by using their last
- observed values stored in their remote tracking branches.
+ observed values stored in their remote-tracking branches.
The values of the `branch.<current branch>.merge` that name the
branches at the remote named by `branch.<current branch>.remote`
are consulted, and then they are mapped via `remote.<remote>.fetch`
- to their corresponding remote tracking branches, and the tips of
+ to their corresponding remote-tracking branches, and the tips of
these tracking branches are merged.
merge.ff::
--
1.7.12.410.g5f38766
^ permalink raw reply related
* Re: git merge man page, upstream
From: Matthieu Moy @ 2012-10-23 11:35 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9CEbT=Y=yjw2tPSLiLibejDSheabcBPEpHCLa_TS+6Cpw@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hi Matthieu,
>
> the upstream branch can also be a local branch.
In this case, it's:
[branch "branch"]
remote = .
merge = refs/heads/master
which can arguably be considered as a special case of remote branch
whose location happens to be ".". But as said in the patch, I don't mind
if someone wants to drop the remote-tracking mention on top of my patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [RFC PATCH 0/2] Localize log output
From: Peter Krefting @ 2012-10-23 12:24 UTC (permalink / raw)
To: Git Mailing List
In v1.8.0, I saw a regression in, among other, "git show --stat" in
that it would no longer output the diffstat in Swedish. This turned
out to be intentional, to fix format-patch and friends, but I liked
the old behaviour.
This series tries to fix that, and related code such as "git log",
while making sure that "git format-patch" still outputs in English.
I am posting this as a RFC, as I might very well have broken something
else in the process, from not knowing the code well enough.
The branch is also available from
https://github.com/nafmo/git-l10n-sv/commits/fix-diff-translation-20121023-1.8.0
with an updated Swedish translation.
Peter Krefting (2):
Use localized date in log output
Localize diff and log output
builtin/apply.c | 2 +-
builtin/commit.c | 4 +--
builtin/log.c | 6 ++--
commit.h | 3 +-
date.c | 4 ++-
diff.c | 22 +++++++++-----
diff.h | 5 +++-
gettext.c | 1 +
log-tree.c | 11 +++++--
pretty.c | 87 +++++++++++++++++++++++++++++++++++++++++++-------------
strbuf.c | 10 +++++++
strbuf.h | 1 +
12 files changed, 119 insertions(+), 37 deletions(-)
--
1.8.0
^ permalink raw reply
* [RFC PATCH 1/2] Use localized date in log output
From: Peter Krefting @ 2012-10-23 12:25 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1210231323480.602@ds9.cixit.se>
When outputting a normal log, without having specified which date format
to use, we should output the current user locale's default format. Do this
by initializing LC_TIME properly and using strftime() to format the date.
---
date.c | 4 +++-
gettext.c | 1 +
strbuf.c | 10 ++++++++++
strbuf.h | 1 +
4 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 57331ed..88f928c 100644
--- a/date.c
+++ b/date.c
@@ -203,7 +203,7 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
weekday_names[tm->tm_wday], tm->tm_mday,
month_names[tm->tm_mon], tm->tm_year + 1900,
tm->tm_hour, tm->tm_min, tm->tm_sec, tz);
- else
+ else if (mode == DATE_RAW)
strbuf_addf(&timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
month_names[tm->tm_mon],
@@ -212,6 +212,8 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
tm->tm_year + 1900,
(mode == DATE_LOCAL) ? 0 : ' ',
tz);
+ else
+ strbuf_strftime(&timebuf,"%c",tm);
return timebuf.buf;
}
diff --git a/gettext.c b/gettext.c
index 71e9545..a87d144 100644
--- a/gettext.c
+++ b/gettext.c
@@ -126,6 +126,7 @@ void git_setup_gettext(void)
podir = GIT_LOCALE_PATH;
bindtextdomain("git", podir);
setlocale(LC_MESSAGES, "");
+ setlocale(LC_TIME, "");
init_gettext_charset("git");
textdomain("git");
}
diff --git a/strbuf.c b/strbuf.c
index 0510f76..d393de9 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -228,6 +228,16 @@ void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap)
strbuf_setlen(sb, sb->len + len);
}
+void strbuf_strftime(struct strbuf *sb, const char *fmt, struct tm *tm)
+{
+ int len;
+
+ if (!strbuf_avail(sb))
+ strbuf_grow(sb, 256);
+ len = strftime(sb->buf + sb->len, sb->alloc - sb->len, fmt, tm);
+ strbuf_setlen(sb, sb->len + len);
+}
+
void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
void *context)
{
diff --git a/strbuf.h b/strbuf.h
index be941ee..9ca1d59 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -99,6 +99,7 @@ __attribute__((format (printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
__attribute__((format (printf,2,0)))
extern void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap);
+extern void strbuf_strfime(struct strbuf *sb, const char *fmt, struct tm *tm);
extern void strbuf_add_lines(struct strbuf *sb, const char *prefix, const char *buf, size_t size);
--
1.8.0
^ permalink raw reply related
* [RFC PATCH 2/2] Localize diff and log output
From: Peter Krefting @ 2012-10-23 12:25 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1210231323480.602@ds9.cixit.se>
The output of "git diff --stat", "git show --stat" and "git log" should be
translated to the local user language. The output of "git format-patch"
should not, however. Add localization where needed, and add a flag for
making sure that "format-patch"'s output remains in English.
This partially reverts commit 218adaaaa064c436115dbcd5705a0e2c42e90a25 (Revert
diffstat back to English; 2012-09-13).
---
builtin/apply.c | 2 +-
builtin/commit.c | 4 +--
builtin/log.c | 6 ++--
commit.h | 3 +-
diff.c | 22 +++++++++-----
diff.h | 5 +++-
log-tree.c | 11 +++++--
pretty.c | 87 +++++++++++++++++++++++++++++++++++++++++++-------------
8 files changed, 104 insertions(+), 36 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 156b3ce..9ead305 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3644,7 +3644,7 @@ static void stat_patch_list(struct patch *patch)
show_stats(patch);
}
- print_stat_summary(stdout, files, adds, dels);
+ print_stat_summary(stdout, files, adds, dels, NULL);
}
static void numstat_patch_list(struct patch *patch)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..406346e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1248,11 +1248,11 @@ static void print_summary(const char *prefix, const unsigned char *sha1,
format_commit_message(commit, "%an <%ae>", &author_ident, &pctx);
format_commit_message(commit, "%cn <%ce>", &committer_ident, &pctx);
if (strbuf_cmp(&author_ident, &committer_ident)) {
- strbuf_addstr(&format, "\n Author: ");
+ strbuf_addstr(&format, _("\n Author: "));
strbuf_addbuf_percentquote(&format, &author_ident);
}
if (!user_ident_sufficiently_given()) {
- strbuf_addstr(&format, "\n Committer: ");
+ strbuf_addstr(&format, _("\n Committer: "));
strbuf_addbuf_percentquote(&format, &committer_ident);
if (advice_implicit_identity) {
strbuf_addch(&format, '\n');
diff --git a/builtin/log.c b/builtin/log.c
index 09cf43e..0c579d7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -381,7 +381,7 @@ static void show_tagger(char *buf, int len, struct rev_info *rev)
pp.fmt = rev->commit_format;
pp.date_mode = rev->date_mode;
- pp_user_info(&pp, "Tagger", &out, buf, get_log_output_encoding());
+ pp_user_info(&pp, _("Tagger"), _("TaggerDate"), 0, &out, buf, get_log_output_encoding());
printf("%s", out.buf);
strbuf_release(&out);
}
@@ -804,7 +804,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
msg = body;
pp.fmt = CMIT_FMT_EMAIL;
pp.date_mode = DATE_RFC2822;
- pp_user_info(&pp, NULL, &sb, committer, encoding);
+ pp_user_info(&pp, NULL, NULL, 0, &sb, committer, encoding);
pp_title_line(&pp, &msg, &sb, encoding, need_8bit_cte);
pp_remainder(&pp, &msg, &sb, 0);
add_branch_description(&sb, branch_name);
@@ -1222,6 +1222,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
/* Always generate a patch */
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
+ /* Never translate format-patch output */
+ rev.diffopt.output_format |= DIFF_FORMAT_ENGLISH;
if (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)
DIFF_OPT_SET(&rev.diffopt, BINARY);
diff --git a/commit.h b/commit.h
index 9f21313..2a9ac6a 100644
--- a/commit.h
+++ b/commit.h
@@ -114,7 +114,8 @@ extern void pretty_print_commit(const struct pretty_print_context *pp,
extern void pp_commit_easy(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb);
void pp_user_info(const struct pretty_print_context *pp,
- const char *what, struct strbuf *sb,
+ const char *what, const char *whatdate, int extra_padding,
+ struct strbuf *sb,
const char *line, const char *encoding);
void pp_title_line(const struct pretty_print_context *pp,
const char **msg_p,
diff --git a/diff.c b/diff.c
index 35d3f07..ef655d1 100644
--- a/diff.c
+++ b/diff.c
@@ -1391,18 +1391,22 @@ static void fill_print_name(struct diffstat_file *file)
file->print_name = pname;
}
-int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
+int print_stat_summary(FILE *fp, int files, int insertions, int deletions, struct diff_options *options)
{
struct strbuf sb = STRBUF_INIT;
int ret;
+ int english = options && !!(options->output_format & DIFF_FORMAT_ENGLISH);
+
if (!files) {
assert(insertions == 0 && deletions == 0);
- return fprintf(fp, "%s\n", " 0 files changed");
+ return fprintf(fp, "%s\n", english ? " 0 files changed"
+ : _(" 0 files changed"));
}
strbuf_addf(&sb,
- (files == 1) ? " %d file changed" : " %d files changed",
+ english ? ((files == 1) ? " %d file changed" : " %d files changed")
+ : Q_(" %d file changed", " %d files changed", files),
files);
/*
@@ -1419,7 +1423,9 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
* do not translate it.
*/
strbuf_addf(&sb,
- (insertions == 1) ? ", %d insertion(+)" : ", %d insertions(+)",
+ english ? ((insertions == 1) ? ", %d insertion(+)" : ", %d insertions(+)")
+ : Q_(", %d insertion(+)", ", %d insertions(+)",
+ insertions),
insertions);
}
@@ -1429,7 +1435,9 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
* do not translate it.
*/
strbuf_addf(&sb,
- (deletions == 1) ? ", %d deletion(-)" : ", %d deletions(-)",
+ english ? ((deletions == 1) ? ", %d deletion(-)" : ", %d deletions(-)")
+ : Q_(", %d deletion(-)", ", %d deletions(-)",
+ deletions),
deletions);
}
strbuf_addch(&sb, '\n');
@@ -1681,7 +1689,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
extra_shown = 1;
}
fprintf(options->file, "%s", line_prefix);
- print_stat_summary(options->file, total_files, adds, dels);
+ print_stat_summary(options->file, total_files, adds, dels, options);
}
static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
@@ -1710,7 +1718,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
options->output_prefix_data);
fprintf(options->file, "%s", msg->buf);
}
- print_stat_summary(options->file, total_files, adds, dels);
+ print_stat_summary(options->file, total_files, adds, dels, options);
}
static void show_numstat(struct diffstat_t *data, struct diff_options *options)
diff --git a/diff.h b/diff.h
index a658f85..73684f7 100644
--- a/diff.h
+++ b/diff.h
@@ -54,6 +54,9 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct diff_options *opt, void *data)
#define DIFF_FORMAT_CALLBACK 0x1000
+/* Never output translated content, used by format-patch et.al */
+#define DIFF_FORMAT_ENGLISH 0x2000
+
#define DIFF_OPT_RECURSIVE (1 << 0)
#define DIFF_OPT_TREE_IN_RECURSIVE (1 << 1)
#define DIFF_OPT_BINARY (1 << 2)
@@ -334,6 +337,6 @@ extern struct userdiff_driver *get_textconv(struct diff_filespec *one);
extern int parse_rename_score(const char **cp_p);
extern int print_stat_summary(FILE *fp, int files,
- int insertions, int deletions);
+ int insertions, int deletions, struct diff_options *options);
#endif /* DIFF_H */
diff --git a/log-tree.c b/log-tree.c
index c894930..0f68413 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -601,8 +601,12 @@ void show_log(struct rev_info *opt)
&ctx.need_8bit_cte);
} else if (opt->commit_format != CMIT_FMT_USERFORMAT) {
fputs(diff_get_color_opt(&opt->diffopt, DIFF_COMMIT), stdout);
+ /*
+ * TRANSLATORS: This string precedes the commit identifier in git log
+ * output.
+ */
if (opt->commit_format != CMIT_FMT_ONELINE)
- fputs("commit ", stdout);
+ fputs(_("commit "), stdout);
if (!opt->graph)
put_revision_mark(opt, commit);
@@ -612,8 +616,11 @@ void show_log(struct rev_info *opt)
show_parents(commit, abbrev_commit);
if (opt->children.name)
show_children(opt, commit, abbrev_commit);
+ /*
+ * TRANSLATORS: %s is a commit identifier.
+ */
if (parent)
- printf(" (from %s)",
+ printf(_(" (from %s)"),
find_unique_abbrev(parent->object.sha1,
abbrev_commit));
show_decorations(opt, commit);
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..8623bbd 100644
--- a/pretty.c
+++ b/pretty.c
@@ -320,7 +320,8 @@ needquote:
}
void pp_user_info(const struct pretty_print_context *pp,
- const char *what, struct strbuf *sb,
+ const char *what, const char *whatdate, int extra_padding,
+ struct strbuf *sb,
const char *line, const char *encoding)
{
char *date;
@@ -365,24 +366,37 @@ void pp_user_info(const struct pretty_print_context *pp,
}
strbuf_add(sb, name_tail, namelen - display_name_length);
strbuf_addch(sb, '\n');
- } else {
- strbuf_addf(sb, "%s: %.*s%.*s\n", what,
- (pp->fmt == CMIT_FMT_FULLER) ? 4 : 0,
- " ", namelen, line);
- }
- switch (pp->fmt) {
- case CMIT_FMT_MEDIUM:
- strbuf_addf(sb, "Date: %s\n", show_date(time, tz, pp->date_mode));
- break;
- case CMIT_FMT_EMAIL:
strbuf_addf(sb, "Date: %s\n", show_date(time, tz, DATE_RFC2822));
- break;
- case CMIT_FMT_FULLER:
- strbuf_addf(sb, "%sDate: %s\n", what, show_date(time, tz, pp->date_mode));
- break;
- default:
- /* notin' */
- break;
+ } else {
+ /*
+ * Calculate the padding to use to get the two fields we are outputting
+ * here aligned. We are passed the padding we need to get these fields
+ * aligned with whatever fields are output in other calls to
+ * pp_user_info().
+ *
+ * FIXME: strlen() used to measure string width; should use mblen()
+ * or similar, but since that is expensive, it should be done further
+ * up the callstack, not on each commit. */
+ int datelen = 0, whatlen = 0;
+
+ if (pp->fmt != CMIT_FMT_FULLER)
+ whatdate = _("Date");
+ if (pp->fmt == CMIT_FMT_MEDIUM || pp->fmt == CMIT_FMT_FULLER) {
+ datelen = whatdate ? strlen(whatdate) : 0;
+ whatlen = what ? strlen(what) : 0;
+ }
+
+ strbuf_addf(sb, "%s: %.*s%.*s%.*s\n", what,
+ (datelen > whatlen ? datelen - whatlen : 0), " ",
+ extra_padding, " ",
+ namelen, line);
+
+ if (pp->fmt == CMIT_FMT_MEDIUM || pp->fmt == CMIT_FMT_FULLER) {
+ strbuf_addf(sb, "%s: %.*s%.*s%s\n", whatdate,
+ (whatlen > datelen ? whatlen - datelen : 0), " ",
+ extra_padding, " ",
+ show_date(time, tz, pp->date_mode));
+ }
}
}
@@ -1218,6 +1232,39 @@ static void pp_header(const struct pretty_print_context *pp,
struct strbuf *sb)
{
int parents_shown = 0;
+ const char *author_label = _("Author");
+ const char *authordate_label = _("AuthorDate");
+ const char *commit_label = _("Commit");
+ const char *commitdate_label = _("CommitDate");
+ int extra_padding_author = 0, extra_padding_commit = 0;
+
+ /*
+ * Calculate the padding to use to get all the fields aligned.
+ *
+ * pp_user_info() makes sure to align the Author and Date strings, but
+ * we aso need to align between the Author and Commit block (if outputting
+ * FULL or FULLER
+ *
+ * FIXME: strlen() used to measure string width; should use mblen()
+ * or similar, but since that is expensive, it should be done further
+ * up the callstack, not on each commit. */
+ if (pp->fmt == CMIT_FMT_FULL || pp->fmt == CMIT_FMT_FULLER) {
+ int author_label_width = strlen(author_label);
+ int commit_label_width = strlen(commit_label);
+
+ if (pp->fmt == CMIT_FMT_FULLER) {
+ int authordate_label_width = strlen(authordate_label);
+ int commitdate_label_width = strlen(commitdate_label);
+ if (authordate_label_width > author_label_width)
+ author_label_width = authordate_label_width;
+ if (commitdate_label_width > commit_label_width)
+ commit_label_width = commitdate_label_width;
+ }
+ extra_padding_author = commit_label_width > author_label_width
+ ? commit_label_width - author_label_width : 0;
+ extra_padding_commit = author_label_width > commit_label_width
+ ? author_label_width - commit_label_width : 0;
+ }
for (;;) {
const char *line = *msg_p;
@@ -1262,12 +1309,12 @@ static void pp_header(const struct pretty_print_context *pp,
*/
if (!memcmp(line, "author ", 7)) {
strbuf_grow(sb, linelen + 80);
- pp_user_info(pp, "Author", sb, line + 7, encoding);
+ pp_user_info(pp, author_label, authordate_label, extra_padding_author, sb, line + 7, encoding);
}
if (!memcmp(line, "committer ", 10) &&
(pp->fmt == CMIT_FMT_FULL || pp->fmt == CMIT_FMT_FULLER)) {
strbuf_grow(sb, linelen + 80);
- pp_user_info(pp, "Commit", sb, line + 10, encoding);
+ pp_user_info(pp, commit_label, commitdate_label, extra_padding_commit, sb, line + 10, encoding);
}
}
}
--
1.8.0
^ permalink raw reply related
* Re: Git submodule for a local branch?
From: W. Trevor King @ 2012-10-23 13:21 UTC (permalink / raw)
To: Git
In-Reply-To: <20121022123714.GL25563@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Mon, Oct 22, 2012 at 08:37:14AM -0400, W. Trevor King wrote:
> but cloning a remote repository (vs. checking out a local branch)
> seems to be baked into the submodule implementation.
Perhaps --local would set submodule.$name.url to '.', and ome
combination of GIT_WORK_TREE, GIT_DIR, and object references could be
used to setup and manage the local submodule.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: The config include mechanism doesn't allow for overwriting
From: Ævar Arnfjörð Bjarmason @ 2012-10-23 14:13 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20121022211505.GA3301@sigill.intra.peff.net>
On Mon, Oct 22, 2012 at 11:15 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> I was hoping to write something like this:
>>
>> [user]
>> name = Luser
>> email = some-default@example.com
>> [include]
>> path = ~/.gitconfig.d/user-email
>>
>> Where that file would contain:
>>
>> [user]
>> email = local-email@example.com
>
> The intent is that it would work as you expect, and produce
> local-email@example.com.
>
>> But when you do that git prints:
>>
>> $ git config --get user.email
>> some-default@example.com
>> error: More than one value for the key user.email: local-email@example.com
>
> Ugh. The config code just feeds all the values sequentially to the
> callback. The normal callbacks within git will overwrite old values,
> whether from earlier in the file, from a file with lower priority (e.g.,
> /etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
> you can check with:
>
> $ git var GIT_AUTHOR_IDENT
> Luser <local-email@example.com> 1350936694 -0400
>
> But git-config takes it upon itself to detect duplicates in its
> callback. Which is just silly, since it is not something that regular
> git would do. git-config should behave as much like the internal git
> parser as possible.
>
>> I think config inclusion is much less useful when you can't clobber
>> previously assigned values.
>
> Agreed. But I think the bug is in git-config, not in the include
> mechanism. I think I'd like to do something like the patch below, which
> just reuses the regular config code for git-config, collects the values,
> and then reports them. It does mean we use a little more memory (for the
> sake of simplicity, we store values instead of streaming them out), but
> the code is much shorter, less confusing, and automatically matches what
> regular git_config() does.
>
> It fails a few tests in t1300, but it looks like those tests are testing
> for the behavior we have identified as wrong, and should be fixed.
I think this patch looks good.
One other thing I think is worth clarifying (and I think should be
broken) is if you write a configuration like:
[foo]
bar = one
[foo]
bar = two
[foo]
bar = three
"git-{config,var} -l" will both give you:
foo.bar=one
foo.bar=two
foo.bar=three
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
"git-{config,var} -l" by only printing:
foo.bar=three
Or are there too many variables like "include.path" that can
legitimately appear more than once.
^ permalink raw reply
* Launch separate program for HTTPS prompt
From: 乙酸鋰 @ 2012-10-23 14:39 UTC (permalink / raw)
To: git
Hi,
Could you launch a separate program for HTTPS prompt like SSH_ASKPASS?
This allows GUI programs to answer the trust or not, not via stdin.
Regards,
ch3cooli
^ permalink raw reply
* Re: Launch separate program for HTTPS prompt
From: Matthieu Moy @ 2012-10-23 14:48 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6QY-PYUKbNUicox_Ayh70bUSJOL7LGZrQQMqgbVBDmEiA@mail.gmail.com>
乙酸鋰 <ch3cooli@gmail.com> writes:
> Hi,
>
> Could you launch a separate program for HTTPS prompt like SSH_ASKPASS?
> This allows GUI programs to answer the trust or not, not via stdin.
Read about credential helpers, this is what they are meant for, and they
do launch separate programs.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Git push slowly under 1000M/s network
From: Shawn Pearce @ 2012-10-23 17:09 UTC (permalink / raw)
To: Joey Jiao; +Cc: git
In-Reply-To: <CAKOmCvp23fALGsDe4Ck7ZXpMJmOAq+YWCXPe_xb6GfQcjJi_kQ@mail.gmail.com>
On Mon, Oct 22, 2012 at 11:27 PM, Joey Jiao <joey.jiaojg@gmail.com> wrote:
> It looks like the client is waiting the pushing result status from
> server although by checking server side, the real object has already
> been upload succeed.
>
> Below is the log after adding time info.
> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> HEAD:refs/changes/33599 2>&1|tee -a log.txt
...
> remote: Resolving deltas: 0% (0/2)
> remote: (W) afafdad: no files changed, message updated
...
> real 9m56.928s
> user 0m0.364s
> sys 0m0.160s
What version of Gerrit are you using?
How many changes already exist in this project?
I am fairly certain this is an issue with Gerrit. Which may be better
discussed at http://groups.google.com/group/repo-discuss
^ permalink raw reply
* Re: git merge man page, upstream
From: Angelo Borsotti @ 2012-10-23 17:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqehkpqv3k.fsf@grenoble-inp.fr>
Hi Matthiew,
man pages should be clear, and easy to read. "Remote" usually means
"another repository"
(git glossary), and also in natural language conveys the notion of
something far away.
Internally, it can be handled as a special case of url, of course.
My suggestion is to be consistent with the git glossary, that defines
"upstream branch" as: "The default branch that is merged into the
branch in question", which is exactly what that paragraph of the
git-merge man page is describing.
-Angelo
^ permalink raw reply
* [Patch 0/1] Makefile extensions for topic ta/doc-cleanup in pu
From: Thomas Ackermann @ 2012-10-23 17:55 UTC (permalink / raw)
To: git; +Cc: gitster, peff, th.acker66
This patch adds rules to the "html" taget in Documentation/Makefile to create html
also for the new asciidoc files in Documentation/technical and Documentation/howto
which were added in this topic.
---
Thomas
^ permalink raw reply
* [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Thomas Ackermann @ 2012-10-23 17:58 UTC (permalink / raw)
To: th.acker66, git; +Cc: gitster, peff, th.acker66
In-Reply-To: <139737172.296334.1351014913982.JavaMail.ngmail@webmail16.arcor-online.net>
- target "html" creates html for all files in Documentation/howto and Documentation/technical
Signed-off-by: Thomas Ackermann <th.acker66@arcor.de>
---
Documentation/Makefile | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 267dfe1..c4e5594 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -24,8 +24,30 @@ SP_ARTICLES = user-manual
SP_ARTICLES += howto/revert-branch-rebase
SP_ARTICLES += howto/using-merge-subtree
SP_ARTICLES += howto/using-signed-tag-in-pull-request
+SP_ARTICLES += howto/use-git-daemon
+SP_ARTICLES += howto/update-hook-example
+SP_ARTICLES += howto/setup-git-server-over-http
+SP_ARTICLES += howto/separating-topic-branches
+SP_ARTICLES += howto/revert-a-faulty-merge
+SP_ARTICLES += howto/recover-corrupted-blob-object
+SP_ARTICLES += howto/rebuild-from-update-hook
+SP_ARTICLES += howto/rebuild-from-update-hook
+SP_ARTICLES += howto/rebase-from-internal-branch
+SP_ARTICLES += howto/maintain-git
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
+
+TECH_DOCS = technical/index-format
+TECH_DOCS += technical/pack-format
+TECH_DOCS += technical/pack-heuristics
+TECH_DOCS += technical/pack-protocol
+TECH_DOCS += technical/protocol-capabilities
+TECH_DOCS += technical/protocol-common
+TECH_DOCS += technical/racy-git
+TECH_DOCS += technical/send-pack-pipeline
+TECH_DOCS += technical/shallow
+TECH_DOCS += technical/trivial-merge
+SP_ARTICLES += $(TECH_DOCS)
SP_ARTICLES += technical/api-index
DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
@@ -231,7 +253,7 @@ clean:
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
$(RM) *.pdf
$(RM) howto-index.txt howto/*.html doc.dep
- $(RM) technical/api-*.html technical/api-index.txt
+ $(RM) technical/*.html technical/api-index.txt
$(RM) $(cmds_txt) *.made
$(RM) manpage-base-url.xsl
@@ -264,7 +286,7 @@ technical/api-index.txt: technical/api-index-skel.txt \
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
-$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
+$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt
$(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
--
1.7.11.msysgit.1
---
Thomas
^ permalink raw reply related
* Re: [PATCH] git-status: show short sequencer state
From: Phil Hord @ 2012-10-23 18:03 UTC (permalink / raw)
To: Matthieu Moy
Cc: phil.hord@gmail.com, Junio C Hamano, konglu@minatec.inpg.fr,
Kong Lucien, git@vger.kernel.org, Duperray Valentin, Jonas Franck,
Nguy Thomas, Nguyen Huynh Khoi Nguyen
In-Reply-To: <vpqsj95soxp.fsf@grenoble-inp.fr>
Matthieu Moy wrote:
> Phil Hord <hordp@cisco.com> writes:
>
>> + merge a git-merge is in progress
>> + am a git-am is in progress
>> + rebase a git-rebase is in progress
>> + rebase-interactive a git-rebase--interactive is in progress
>> + cherry-pick a git-cherry-pick is in progress
>> + bisect a git-bisect is in progress
> Avoid using git-foo syntax in documentation, it suggests that this is
> valid command, which isn't true anymore. `git foo` seems the most common
> syntax. Also, git-rebase--interactive is not user-visible => `git rebase
> --interactive`.
Thanks.
>> - if (state->am_empty_patch)
>> + if (state->substate==WT_SUBSTATE_NOMINAL)
>> status_printf_ln(s, color,
>> _("The current patch is empty."));
> This looks weird. First, spaces around == (here and below). Then, the
> logic is unintuitive. The "if" suggests everything is allright, and the
> message below is very specific. This at least deserves a comment.
Yes, I agree. It was less clear but more reasonable before I tried to
clear it up some. It's driven by the short-token printer. The state is
"you're in a 'git am' but I do not see any conflicted files. Therefore,
your patch must be empty." I suspect this may be a leaving from the
git-am machinery where it did not choose to clean up after itself if the
patch was empty, but perhaps it should have. I seldom use git-am, so I
do not know if this code reflects a common and useful state.
I'll try to make this more explicit. Currently the short-status
version will say either "am" or "am \n conflicted" when a 'git am' is in
progress. The logical path to follow if I re-add 'git-am-empty' state
tracker is for this to now show either "am \n am-is-empty" or "am \n
conflicted". But I think I should suppress the "am-is-empty" report in
that case. What do you think
>> if (advice_status_hints) {
>> - if (!state->am_empty_patch)
>> + if (state->substate==WT_SUBSTATE_CONFLICTED)
> Spaces around ==.
>
>> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
>> +{
>> + color_fprintf(s->fp, color, "%s", token);
>> + fputc(s->null_termination ? '\0' : '\n', s->fp);
>> +}
> The output format seems to be meant only for machine-consumption. Is
> there any case when we'd want color? I'd say we can disable coloring
> completely for this format (normally, color=auto does the right thing,
> but I prefer being 100% sure I'll get no color when writing scripts)
Originally I had this output nested in the normal 'git status --short'
output, like a shortened form of the "advice". Then, 'git-status
--porcelain' would show the tokens without color, but 'git status
--short' would show them with color. I thought I might be going back
there, or that I might combine this with full 'git status' again
somehow, and colors seemed appropriate still.
The --short status report is too confusing when tokens may or may-not
appear, and it would likely break some scripts, even though they should
be using --porcelain. And the full status already has its long versions
of the same text. So I can remove this color decorator until someone
finds a need for it.
>> +static void wt_shortstatus_print_sequencer(struct wt_status *s)
> [...]
>> +void wt_sequencer_print(struct wt_status *s)
>> +{
>> + wt_shortstatus_print_sequencer(s);
>> +}
>> +
> Why do you need this trivial wrapper?
Another left-over from its previous multiple versions. I'll simplify it.
> Other than that, I like the idea (although I have no concrete use-case
> in mind), but I didn't actually test the patch.
My own use-case involves $PS1. I keep running into "you cannot
cherry-pick because you are in the middle of a rebase" in submodules in
which I have long forgotten about the failed action and have gone on to
write many new commits, or switched branches, or worse. I do not know
what 'git rebase --abort' will give me in those cases, and I wonder what
work I might have lost for having been interrupted in the middle of that
action in the past. These tokens will help me decorate my prompt to
remind me I left some baggage untended.
Thanks for the feedback.
Phil
^ permalink raw reply
* Re: tag storage format
From: Uri Moszkowicz @ 2012-10-23 18:28 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2vce2xh06.fsf@igel.home>
That did the trick - thanks!
On Mon, Oct 22, 2012 at 5:46 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> Uri Moszkowicz <uri@4refs.com> writes:
>
> > Perhaps Git should switch to a single-file block text or binary format
> > once a large number of tags becomes present in a repository.
>
> This is what git pack-refs (called by git gc) does (by putting the refs
> in .git/packed-refs).
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
^ permalink raw reply
* Long clone time after "done."
From: Uri Moszkowicz @ 2012-10-23 18:30 UTC (permalink / raw)
To: git
I have a large repository which I ran "git gc --aggressive" on that
I'm trying to clone on a local file system. I would expect it to
complete very quickly with hard links but it's taking about 6min to
complete with no checkout (git clone -n). I see the message "Clining
into 'repos'... done." appear after a few seconds but then Git just
hangs there for another 6min. Any idea what it's doing at this point
and how I can speed it up?
^ permalink raw reply
* [PATCH] git-status: show short sequencer state
From: Phil Hord @ 2012-10-23 18:58 UTC (permalink / raw)
To: hordp
Cc: phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as "conflicted" or "resolved".
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-pick a git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editing interactive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
---
Documentation/git-status.txt | 18 +++++++
builtin/commit.c | 12 ++++-
wt-status.c | 125 +++++++++++++++++++++++++++++++++++--------
wt-status.h | 14 ++++-
4 files changed, 145 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..31ffabd 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a merge is in progress
+ am an am is in progress
+ rebase a rebase is in progress
+ rebase-interactive an interactive rebase is in progress
+ cherry-pick a cherry-pick is in progress
+ bisect a bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editing interactive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', "branch", &s.show_branch,
N_("show branch information")),
+ OPT_SET_INT('S', "sequence", &status_format,
+ N_("show sequencer state"),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, "porcelain", &status_format,
N_("machine-readable output"),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(&s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(&s);
+ break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
s.ignore_submodule_arg = ignore_submodule_arg;
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..81d91e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,7 +781,7 @@ static void show_merge_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You have unmerged paths."));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -802,11 +802,11 @@ static void show_am_in_progress(struct wt_status *s,
{
status_printf_ln(s, color,
_("You are in the middle of an am session."));
- if (state->am_empty_patch)
+ if (state->substate == WT_SUBSTATE_AM_EMPTY)
status_printf_ln(s, color,
_("The current patch is empty."));
if (advice_status_hints) {
- if (!state->am_empty_patch)
+ if (state->substate == WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and then run \"git am --resolved\")"));
status_printf_ln(s, color,
@@ -867,9 +867,7 @@ static void show_rebase_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- struct stat st;
-
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
@@ -879,19 +877,19 @@ static void show_rebase_in_progress(struct wt_status *s,
status_printf_ln(s, color,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
- } else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
+ } else if (state->substate == WT_SUBSTATE_RESOLVED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
- } else if (split_commit_in_progress(s)) {
+ } else if (state->substate == WT_SUBSTATE_SPLITTING) {
status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (Once your working directory is clean, run \"git rebase --continue\")"));
} else {
status_printf_ln(s, color, _("You are currently editing a commit during a rebase."));
- if (advice_status_hints && !s->amend) {
+ if (advice_status_hints && state->substate == WT_SUBSTATE_EDITING) {
status_printf_ln(s, color,
_(" (use \"git commit --amend\" to amend the current commit)"));
status_printf_ln(s, color,
@@ -907,7 +905,7 @@ static void show_cherry_pick_in_progress(struct wt_status *s,
{
status_printf_ln(s, color, _("You are currently cherry-picking."));
if (advice_status_hints) {
- if (has_unmerged(s))
+ if (state->substate == WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and run \"git commit\")"));
else
@@ -928,34 +926,68 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s , struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
+ // Determine main sequencer activity
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
+ state->am_in_progress = 1;
if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->substate = WT_SUBSTATE_AM_EMPTY;
+ else
+ state->substate = WT_SUBSTATE_CONFLICTED;
} else {
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st))
- state.bisect_in_progress = 1;
+ state->bisect_in_progress = 1;
+
+ // Check for unmerged files
+ if (state->rebase_in_progress || state->rebase_interactive_in_progress ||
+ state->cherry_pick_in_progress || state->merge_in_progress) {
+ if (has_unmerged(s)) {
+ state->substate = WT_SUBSTATE_CONFLICTED;
+ } else {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ }
+ }
+
+ // Interactive Rebase is more nuanced
+ if (state->rebase_interactive_in_progress && state->substate != WT_SUBSTATE_CONFLICTED) {
+ if (!stat(git_path("MERGE_MSG"), &st)) {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ } else if (split_commit_in_progress(s)) {
+ state->substate = WT_SUBSTATE_SPLITTING;
+ } else {
+ if (s->amend) {
+ state->substate = WT_SUBSTATE_EDITED;
+ } else {
+ state->substate = WT_SUBSTATE_EDITING;
+ }
+ }
+ }
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -1192,6 +1224,55 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
fputc(s->null_termination ? '\0' : '\n', s->fp);
}
+static void wt_print_token(struct wt_status *s, const char *token)
+{
+ fprintf(s->fp, "%s", token);
+ fputc(s->null_termination ? '\0' : '\n', s->fp);
+}
+
+void wt_sequencer_print(struct wt_status *s)
+{
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
+
+ if (state.merge_in_progress)
+ wt_print_token(s, "merge");
+ if (state.am_in_progress)
+ wt_print_token(s, "am");
+ if (state.rebase_in_progress)
+ wt_print_token(s, "rebase");
+ if (state.rebase_interactive_in_progress)
+ wt_print_token(s, "rebase-interactive");
+ if (state.cherry_pick_in_progress)
+ wt_print_token(s, "cherry-pick");
+ if (state.bisect_in_progress)
+ wt_print_token(s, "bisect");
+
+ switch (state.substate) {
+ case WT_SUBSTATE_NOMINAL:
+ break;
+ case WT_SUBSTATE_CONFLICTED:
+ wt_print_token(s, "conflicted");
+ break;
+ case WT_SUBSTATE_RESOLVED:
+ wt_print_token(s, "resolved");
+ break;
+ case WT_SUBSTATE_EDITED:
+ wt_print_token(s, "edited");
+ break;
+ case WT_SUBSTATE_EDITING:
+ wt_print_token(s, "editing");
+ break;
+ case WT_SUBSTATE_SPLITTING:
+ wt_print_token(s, "splitting");
+ break;
+ case WT_SUBSTATE_AM_EMPTY:
+ wt_print_token(s, "am-empty");
+ break;
+ }
+}
+
void wt_shortstatus_print(struct wt_status *s)
{
int i;
diff --git a/wt-status.h b/wt-status.h
index 236b41f..900889c 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -59,6 +59,7 @@ struct wt_status {
unsigned colopts;
int null_termination;
int show_branch;
+ int show_sequencer;
/* These are computed during processing of the individual sections */
int commitable;
@@ -71,14 +72,24 @@ struct wt_status {
struct string_list ignored;
};
+enum wt_status_substate {
+ WT_SUBSTATE_NOMINAL = 0,
+ WT_SUBSTATE_CONFLICTED,
+ WT_SUBSTATE_RESOLVED,
+ WT_SUBSTATE_SPLITTING,
+ WT_SUBSTATE_EDITING,
+ WT_SUBSTATE_EDITED,
+ WT_SUBSTATE_AM_EMPTY,
+};
+
struct wt_status_state {
int merge_in_progress;
int am_in_progress;
- int am_empty_patch;
int rebase_in_progress;
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ enum wt_status_substate substate;
};
void wt_status_prepare(struct wt_status *s);
@@ -86,6 +97,7 @@ void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
void wt_shortstatus_print(struct wt_status *s);
+void wt_sequencer_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
void status_printf_ln(struct wt_status *s, const char *color, const char *fmt, ...)
--
1.8.0.2.gc921d59.dirty
^ permalink raw reply related
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