* Re: [PATCH/RFC 0/7] Column output
From: Nguyen Thai Ngoc Duy @ 2011-02-09 0:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110208224745.GA14190@sigill.intra.peff.net>
2011/2/9 Jeff King <peff@peff.net>:
> On Tue, Feb 08, 2011 at 10:22:14PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> In short, the series is very simple: give porcelain commands column
>> output, just like good old "ls". There could be a few more candidates,
>> I believe René Scharfe mentioned other files in "git status".
>
> I don't really care for column output myself, so maybe you have a good
> reason why my idea won't work. But why not use the BSD column program?
Solaris did not have one last time I checked. Windows obviously does
not either, but I don't use msysgit so it does not count.
--
Duy
^ permalink raw reply
* [PATCH v3 0/3] Updated patch series for default upstream merge
From: Jared Hance @ 2011-02-09 0:23 UTC (permalink / raw)
To: git; +Cc: Jared Hance
In-Reply-To: <1297198129-3403-1-git-send-email-jaredhance@gmail.com>
This patch series allows for `git merge` to default to the upstream branch
of the current branch.
Notes/Complications:
- I'm not sure whether the option should be merge.defaultUpstream
or merge.defaultToUpstream
- Should [remotes] be changed to [branches]? I felt like it was
a completely different change and didn't belong in the patch series.
- I left one of the ifs with unnecessary braces for clarity because
of a nested if-else: is this the preferred style?
Jared Hance (3):
Add setup_merge_commit function to merge/builtin.c.
Add function per_branch_config.
Add support for merging from upstream by default.
Documentation/config.txt | 6 +++
builtin/merge.c | 87 ++++++++++++++++++++++++++++++++-------------
2 files changed, 68 insertions(+), 25 deletions(-)
--
1.7.4
^ permalink raw reply
* [PATCH v3 1/3] Add setup_merge_commit function to merge/builtin.c.
From: Jared Hance @ 2011-02-09 0:23 UTC (permalink / raw)
To: git; +Cc: Jared Hance
In-Reply-To: <1297211028-14382-1-git-send-email-jaredhance@gmail.com>
Adds a new function that will be used in a later patch as well as the
current code to reduce redundancy.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
---
builtin/merge.c | 32 +++++++++++++++++++-------------
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 42fff38..bc1ae94 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -911,6 +911,24 @@ static int evaluate_result(void)
return cnt;
}
+static void setup_merge_commit(struct strbuf *buf,
+ struct commit_list ***remotes, const char *s)
+{
+ struct object *o;
+ struct commit *commit;
+
+ o = peel_to_type(s, 0, NULL, OBJ_COMMIT);
+ if (!o)
+ die("%s - not something we can merge", s);
+ commit = lookup_commit(o->sha1);
+ commit->util = (void *)s;
+ *remotes = &commit_list_insert(commit, *remotes)->next;
+
+ strbuf_addf(buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
+ setenv(buf->buf, s, 1);
+ strbuf_reset(buf);
+}
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -1059,19 +1077,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strbuf_reset(&buf);
for (i = 0; i < argc; i++) {
- struct object *o;
- struct commit *commit;
-
- o = peel_to_type(argv[i], 0, NULL, OBJ_COMMIT);
- if (!o)
- die("%s - not something we can merge", argv[i]);
- commit = lookup_commit(o->sha1);
- commit->util = (void *)argv[i];
- remotes = &commit_list_insert(commit, remotes)->next;
-
- strbuf_addf(&buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
- setenv(buf.buf, argv[i], 1);
- strbuf_reset(&buf);
+ setup_merge_commit(&buf, &remotes, argv[i]);
}
if (!use_strategies) {
--
1.7.4
^ permalink raw reply related
* [PATCH v3 2/3] Add function per_branch_config.
From: Jared Hance @ 2011-02-09 0:23 UTC (permalink / raw)
To: git; +Cc: Jared Hance
In-Reply-To: <1297211028-14382-1-git-send-email-jaredhance@gmail.com>
Adds a configuration function to be filled up more in the next patch.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
---
builtin/merge.c | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index bc1ae94..818bfc7 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -498,11 +498,15 @@ cleanup:
strbuf_release(&bname);
}
-static int git_merge_config(const char *k, const char *v, void *cb)
+static int per_branch_config(const char *k, const char *v, void *cb)
{
- if (branch && !prefixcmp(k, "branch.") &&
- !prefixcmp(k + 7, branch) &&
- !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
+ const char *variable;
+ if (!branch || prefixcmp(k, "branch.")
+ || prefixcmp(k + 7, branch))
+ return 1; /* not what I handle */
+
+ variable = k + 7 + strlen(branch);
+ if (!strcmp(variable, ".mergeoptions")) {
const char **argv;
int argc;
char *buf;
@@ -518,8 +522,20 @@ static int git_merge_config(const char *k, const char *v, void *cb)
parse_options(argc, argv, NULL, builtin_merge_options,
builtin_merge_usage, 0);
free(buf);
+
+ return 0;
}
+ return 1; /* not what I handle */
+}
+
+static int git_merge_config(const char *k, const char *v, void *cb)
+{
+ int status = per_branch_config(k, v, cb);
+
+ if (status <= 0)
+ return status;
+
if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
show_diffstat = git_config_bool(k, v);
else if (!strcmp(k, "pull.twohead"))
--
1.7.4
^ permalink raw reply related
* [PATCH v3 3/3] Add support for merging from upstream by default.
From: Jared Hance @ 2011-02-09 0:23 UTC (permalink / raw)
To: git; +Cc: Jared Hance
In-Reply-To: <1297211028-14382-1-git-send-email-jaredhance@gmail.com>
Adds the option merge.defaultupstream to add support for merging from the
upstream branch by default. The upstream branch is found using
branch.[name].merge.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
---
Documentation/config.txt | 6 ++++++
builtin/merge.c | 31 +++++++++++++++++++++++--------
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c5e1835..4415691 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1389,6 +1389,12 @@ man.<tool>.path::
include::merge-config.txt[]
+merge.defaultUpstream::
+ If merge is called without any ref arguments, merge from the branch
+ specified in branch.<current branch>.merge, which is considered to be
+ the upstream branch for the current branch, possibly set by --track or
+ --set-upstream.
+
mergetool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
diff --git a/builtin/merge.c b/builtin/merge.c
index 818bfc7..cd646fb 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -37,7 +37,7 @@ struct strategy {
};
static const char * const builtin_merge_usage[] = {
- "git merge [options] <remote>...",
+ "git merge [options] [<remote>...]",
"git merge [options] <msg> HEAD <remote>",
NULL
};
@@ -58,6 +58,8 @@ static int option_renormalize;
static int verbosity;
static int allow_rerere_auto;
static int abort_current_merge;
+static int default_upstream;
+static const char *upstream_branch;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -525,6 +527,8 @@ static int per_branch_config(const char *k, const char *v, void *cb)
return 0;
}
+ else if (!strcmp(variable, ".merge"))
+ return git_config_string(&upstream_branch, k, v);
return 1; /* not what I handle */
}
@@ -536,7 +540,9 @@ static int git_merge_config(const char *k, const char *v, void *cb)
if (status <= 0)
return status;
- if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
+ if (!strcmp(k, "merge.defaultupstream"))
+ default_upstream = git_config_bool(k, v);
+ else if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
show_diffstat = git_config_bool(k, v);
else if (!strcmp(k, "pull.twohead"))
return git_config_string(&pull_twohead, k, v);
@@ -1017,9 +1023,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (!allow_fast_forward && fast_forward_only)
die("You cannot combine --no-ff with --ff-only.");
- if (!argc)
- usage_with_options(builtin_merge_usage,
- builtin_merge_options);
+ if (!argc) {
+ if (!default_upstream || !upstream_branch)
+ usage_with_options(builtin_merge_usage,
+ builtin_merge_options);
+ else
+ setup_merge_commit(&buf, &remotes, upstream_branch);
+ }
/*
* This could be traditional "merge <msg> HEAD <commit>..." and
@@ -1082,9 +1092,14 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
- if (head_invalid || !argc)
- usage_with_options(builtin_merge_usage,
- builtin_merge_options);
+ if (head_invalid)
+ usage_msg_opt("cannot use old-style invocation from an unborn"
+ "branch",
+ builtin_merge_usage, builtin_merge_options);
+
+ if (!argc && !(default_upstream && upstream_branch))
+ usage_msg_opt("no commit to merge specified",
+ builtin_merge_usage, builtin_merge_options);
strbuf_addstr(&buf, "merge");
for (i = 0; i < argc; i++)
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] rebase: use @{upstream} if no upstream specified
From: Martin von Zweigbergk @ 2011-02-09 0:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Martin von Zweigbergk, Sverre Rabbelier, git, Junio C Hamano,
Yann Dirson
In-Reply-To: <20110208220505.GA17981@elie>
On Tue, 8 Feb 2011, Jonathan Nieder wrote:
> Martin von Zweigbergk wrote:
> > On Tue, 8 Feb 2011, Sverre Rabbelier wrote:
>
> >> I particularly like that you explain to the user clearly what they
> >> have to do to make this work (e.g., configure the upstream). Nice.
> >
> > Thanks, but that was stolen from git-pull.sh ;-)
>
> Doesn't that suggest it might belong in some common git-upstream--lib.sh
> (or git-sh-setup.sh)?
Maybe it does... For comparison, I pasted the two sections below.
git-rebase.sh (after my patch):
if test -z "$branch_name"
then
die "You are not currently on a branch, so I cannot use any
'branch.<branchname>.merge' in your configuration file.
Please specify which upstream branch you want to use on the command
line and try again (e.g. 'git rebase <upstream branch>').
See git-rebase(1) for details."
else
die "You asked me to rebase without telling me which branch you
want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git rebase <upstream branch>').
See git-rebase(1) for details."
fi
git-pull.sh:
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
echo "Please specify which remote branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
echo "your configuration file does not tell me, either. Please"
echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
echo "If you often $op_type $op_prep the same branch, you may want to"
echo "use something like the following in your configuration file:"
echo
echo " [branch \"${curr_branch}\"]"
echo " remote = <nickname>"
echo " merge = <remote-ref>"
test rebase = "$op_type" &&
echo " rebase = true"
echo
echo " [remote \"<nickname>\"]"
echo " url = <url>"
echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
I had forgotten that I trimmed the last part of it. Maybe I should
have also included that? Then it would make even more sense to extract
this piece of code.
/Martin
^ permalink raw reply
* Re: [PATCH v3 0/3] Updated patch series for default upstream merge
From: Junio C Hamano @ 2011-02-09 0:34 UTC (permalink / raw)
To: Jared Hance; +Cc: git, Jonathan Nieder
In-Reply-To: <1297211028-14382-1-git-send-email-jaredhance@gmail.com>
Jared Hance <jaredhance@gmail.com> writes:
> Notes/Complications:
> - I'm not sure whether the option should be merge.defaultUpstream
> or merge.defaultToUpstream
Probably the latter.
> - Should [remotes] be changed to [branches]? I felt like it was
> a completely different change and didn't belong in the patch series.
Perhaps at the beginning (just like your 1/3 refactoring) or at the end as
a separate patch?
> - I left one of the ifs with unnecessary braces for clarity because
> of a nested if-else: is this the preferred style?
If you are talking about the one at @@ -1017,9 +1023,13 @@, it looks fine
to me. The new "else" you added to @@ -525,6 +527,8 @@ may probably want
to start on the same line as closing "}" of the "if", though. IOW, like
this:
if (cond) {
...
} else {
...
}
not like this:
if (cond) {
...
}
else {
...
}
But other than that looks reasonable.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/3] Add function per_branch_config.
From: Jonathan Nieder @ 2011-02-09 1:14 UTC (permalink / raw)
To: Jared Hance; +Cc: git, Junio C Hamano
In-Reply-To: <1297211028-14382-3-git-send-email-jaredhance@gmail.com>
Jared Hance wrote:
> [PATCH v3 2/3] Add function per_branch_config.
>
> Adds a configuration function to be filled up more in the next patch.
Micronit: subject should be of the form
subsystem: do something really great
with no full stop. So the series might be, roughly:
- merge: introduce setup_merge_commit helper function
- merge: introduce per-branch configuration helper function
- merge: add support for merging from upstream by default
Commit message bodies tend to be in the imperative mood, just like the
patches themselves.
Anyway, I like patch 1. One tiny nit on this one:
> +++ b/builtin/merge.c
> @@ -498,11 +498,15 @@ cleanup:
> strbuf_release(&bname);
> }
>
> -static int git_merge_config(const char *k, const char *v, void *cb)
> +static int per_branch_config(const char *k, const char *v, void *cb)
> {
> - if (branch && !prefixcmp(k, "branch.") &&
> - !prefixcmp(k + 7, branch) &&
> - !strcmp(k + 7 + strlen(branch), ".mergeoptions")) {
> + const char *variable;
> + if (!branch || prefixcmp(k, "branch.")
> + || prefixcmp(k + 7, branch))
> + return 1; /* not what I handle */
Alignment: isn't the "||" meant to be one space over?
Based on a quick grep[1], it seems the prevailing style is rather
if (!branch || prefixcmp(k, "branch.") ||
prefixcmp(k + 7, branch))
return 1;
with the || at the end of the line, though I'm not sure I care
much. :)
With or without an extra space before the ||,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks for a nice cleanup.
Jonathan
[1]
addup () {
sum=0
while read term
do
: $((sum = sum + term))
done
echo $sum
}
$ git grep --cached -c -e '||$' | cut -d: -f2 | addup
730
$ git grep --cached -c -e ' ||' | cut -d: -f2 | addup
98
$ git grep --cached -c -e ' ||' | cut -d: -f2 | addup
79
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-09 1:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, git, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <7vzkq6p1ap.fsf@alter.siamese.dyndns.org>
On Wednesday 09 February 2011, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Ah, yes, I should have been more specific:
> > remote.origin.fetch = ~refs/tags/*:refs/tags/*
>
> Hmmm, I was in the vicinity of builtin/fetch.c:find_non_local_tags()
> today, and I had to wonder what the implementation of this would look
> like....
AFAIK, find_non_local_tags() is called to produce a list of refs to be auto-
followed. Currently it produces this list by traversing the remote refs, and
selecting refs that follow all of these criteria:
A. Ref name starts with "refs/tags"
B. Ref refers (after peeling) to an object that is either already locally
available, or is already on the list of objects to be fetched.
C. Ref name does not already exist locally.
Now, here's roughly how I would change it to implement the "~from:to"-style
refspecs:
0. Change its name from find_non_local_tags() to find_auto_follow_refs().
1. At the top, enumerate the auto-following refspecs
("~refs/tags/*:refs/tags/*" in this case)
2. When traversing the remote refs, instead of criteria A above, we want to
check if ref->name matches the remote side of any of the auto-following
refspecs enumerated in step #1. Skip past all non-matches.
3. Criteria B stays unchanged.
4. When checking criteria C, we want to check against the _local_ side of
the matched auto-following refspec.
AFAICS, that's pretty much what should be needed. There are some other
things to consider as well, but IMHO none of those seem like show stoppers:
For example, there may be command-line options for making auto-following
refspecs explicit (i.e. corresponding to --tags; basically disables the "~"
in the refspec), or disabling auto-following (i.e. corresponding to --no-
tags; basically disregards refspecs with "~").
Another slight complication is refspecs with _both_ "~" and "+" (i.e. both
auto-following and --force behavior), which may be resolved by disregarding
criteria C for those refspecs.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH v3 3/3] Add support for merging from upstream by default.
From: Jonathan Nieder @ 2011-02-09 1:41 UTC (permalink / raw)
To: Jared Hance; +Cc: git, Junio C Hamano
In-Reply-To: <1297211028-14382-4-git-send-email-jaredhance@gmail.com>
Jared Hance wrote:
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1389,6 +1389,12 @@ man.<tool>.path::
>
> include::merge-config.txt[]
>
> +merge.defaultUpstream::
[...]
Might make sense to put this in merge-config.txt, to get documentation
in git-merge(1) for free.
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -525,6 +527,8 @@ static int per_branch_config(const char *k, const char *v, void *cb)
>
> return 0;
> }
> + else if (!strcmp(variable, ".merge"))
> + return git_config_string(&upstream_branch, k, v);
Style:
} else if (...) {
return git_config_string(...);
}
> @@ -1017,9 +1023,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> if (!allow_fast_forward && fast_forward_only)
> die("You cannot combine --no-ff with --ff-only.");
>
> - if (!argc)
> - usage_with_options(builtin_merge_usage,
> - builtin_merge_options);
> + if (!argc) {
> + if (!default_upstream || !upstream_branch)
> + usage_with_options(builtin_merge_usage,
> + builtin_merge_options);
> + else
> + setup_merge_commit(&buf, &remotes, upstream_branch);
Why the "else"? usage_msg_opt doesn't return to the caller.
Hopefully someone will chime in with some tests to complement
t5520-pull (hint, hint). :)
Jonathan
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index c1efaaa..bc8ce25 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash]
[-s <strategy>] [-X <strategy-option>]
- [--[no-]rerere-autoupdate] [-m <msg>] <commit>...
+ [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
'git merge' <msg> HEAD <commit>...
'git merge' --abort
@@ -97,7 +97,10 @@ commit or stash your changes before running 'git merge'.
Commits, usually other branch heads, to merge into our branch.
You need at least one <commit>. Specifying more than one
<commit> obviously means you are trying an Octopus.
-
++
+By default, if no commit is specified then git will error out.
+However, the `merge.defaultToUpstream` configuration item (see below)
+changes that.
PRE-MERGE CHECKS
----------------
^ permalink raw reply related
* Re: [PATCH v2] Add support for merging from upstream by default.
From: Jonathan Nieder @ 2011-02-09 1:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jared Hance, git, Martin von Zweigbergk, Andreas Schwab,
Bert Wesarg, Jeff King, Felipe Contreras
In-Reply-To: <7vpqr2oyy3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Could you give an example of breakage this configurability is designed
>> to prevent?
>
> I think there is no "prevent" or "breakage"; the patch is to give people a
> way to turn the feature on; without the configuration, "git merge" will
> keep the traditional behaviour, no?
Yes. One answer to my question is that a person might try
git fetch git://some/random/repository branch
git merge
and at least for now it seems sensible to make that error out by
default rather than doing something unexpected.
In other words, another possible rule is "default to the last fetched
branch" (FETCH_HEAD), so the intent behind running "git merge" without
a branchname for the first time is not as obvious as I would hope.
^ permalink raw reply
* Re: [PATCH] rebase: use @{upstream} if no upstream specified
From: Martin von Zweigbergk @ 2011-02-09 1:50 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Jonathan Nieder, Sverre Rabbelier, git, Junio C Hamano,
Yann Dirson
In-Reply-To: <alpine.DEB.2.00.1102081916330.9042@debian>
On Tue, 8 Feb 2011, Martin von Zweigbergk wrote:
> On Tue, 8 Feb 2011, Jonathan Nieder wrote:
>
> > Martin von Zweigbergk wrote:
> > > On Tue, 8 Feb 2011, Sverre Rabbelier wrote:
> >
> > >> I particularly like that you explain to the user clearly what they
> > >> have to do to make this work (e.g., configure the upstream). Nice.
> > >
> > > Thanks, but that was stolen from git-pull.sh ;-)
> >
> > Doesn't that suggest it might belong in some common git-upstream--lib.sh
> > (or git-sh-setup.sh)?
>
> Maybe it does...
Maybe something like this on top? I put it in git-parse-remote.sh for
now. There were some related functions there, so maybe it's not so
bad. Should I put it there (and rename to git-upstream--lib.sh?), in
new git-upstream--lib.sh or in git-sh-setup.sh.
Changes to the text compared to before:
* "remote branch" became "upstream branch", even for git pull
* "You asked me to pull" became "You asked me to merge" or "You asked
me to rebase", even for git pull
* Now printed to stderr, because I simply didn't think about it. Good
or bad?
What do you think?
-- 8< --
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 1cc2ba6..ff58d5b 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -99,3 +99,40 @@ get_remote_merge_branch () {
esac
esac
}
+
+error_on_missing_default_upstream () {
+ op_type="$1"
+ op_prep="$2"
+ example="$3"
+ documentation="$4"
+ branch_name=$(git symbolic-ref -q HEAD)
+ if test -z "$branch_name"
+ then
+ die "You are not currently on a branch, so I cannot use any
+'branch.<branchname>.merge' in your configuration file.
+Please specify which upstream branch you want to use on the command
+line and try again (e.g. '$example').
+See $documentation for details."
+ else
+ echo &2> "You asked me to $op_type without telling me which branch you
+want to $op_type $op_prep, and 'branch.${branch_name#refs/heads/}.merge' in
+your configuration file does not tell me, either. Please
+specify which branch you want to use on the command line and
+try again (e.g. '$example').
+See $documentation for details.
+
+If you often $op_type $op_prep the same branch, you may want to
+use something like the following in your configuration file:
+ [branch \"${branch_name#refs/heads/}\"]
+ remote = <nickname>
+ merge = <remote-ref>"
+ test rebase = "$op_type" &&
+ echo &2> " rebase = true"
+ die "
+ [remote \"<nickname>\"]
+ url = <url>
+ fetch = <refspec>
+
+See git-config(1) for details."
+ fi
+}
diff --git a/git-pull.sh b/git-pull.sh
index eb87f49..8ec1d3d 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -163,34 +163,10 @@ error_on_no_merge_candidates () {
echo "You asked to pull from the remote '$1', but did not specify"
echo "a branch. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
- elif [ -z "$curr_branch" ]; then
- echo "You are not currently on a branch, so I cannot use any"
- echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which remote branch you want to use on the command"
- echo "line and try again (e.g. 'git pull <repository> <refspec>')."
- echo "See git-pull(1) for details."
- elif [ -z "$upstream" ]; then
- echo "You asked me to pull without telling me which branch you"
- echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me, either. Please"
- echo "specify which branch you want to use on the command line and"
- echo "try again (e.g. 'git pull <repository> <refspec>')."
- echo "See git-pull(1) for details."
- echo
- echo "If you often $op_type $op_prep the same branch, you may want to"
- echo "use something like the following in your configuration file:"
- echo
- echo " [branch \"${curr_branch}\"]"
- echo " remote = <nickname>"
- echo " merge = <remote-ref>"
- test rebase = "$op_type" &&
- echo " rebase = true"
- echo
- echo " [remote \"<nickname>\"]"
- echo " url = <url>"
- echo " fetch = <refspec>"
- echo
- echo "See git-config(1) for details."
+ elif [ -z "$curr_branch" -o -z "$upstream" ]; then
+ . git-parse-remote
+ error_on_missing_default_upstream $op_type $op_prep \
+ "git pull <repository> <refspec>" "git-pull(1)"
else
echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
echo "from the remote, but no such ref was fetched."
diff --git a/git-rebase.sh b/git-rebase.sh
index 5975642..8b39cab 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -144,25 +144,6 @@ run_pre_rebase_hook () {
fi
}
-error_on_missing_default_upstream () {
- branch_name=$(git symbolic-ref -q HEAD)
- if test -z "$branch_name"
- then
- die "You are not currently on a branch, so I cannot use any
-'branch.<branchname>.merge' in your configuration file.
-Please specify which upstream branch you want to use on the command
-line and try again (e.g. 'git rebase <upstream branch>').
-See git-rebase(1) for details."
- else
- die "You asked me to rebase without telling me which branch you
-want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
-your configuration file does not tell me, either. Please
-specify which branch you want to use on the command line and
-try again (e.g. 'git rebase <upstream branch>').
-See git-rebase(1) for details."
- fi
-}
-
test -f "$apply_dir"/applying &&
die 'It looks like git-am is in progress. Cannot rebase.'
@@ -381,8 +362,13 @@ if test -z "$rebase_root"
then
case "$#" in
0)
- upstream_name=$(git rev-parse --symbolic-full-name --verify -q \
- @{upstream}) || error_on_missing_default_upstream
+ if ! upstream_name=$(git rev-parse --symbolic-full-name \
+ --verify -q @{upstream})
+ then
+ . git-parse-remote
+ error_on_missing_default_upstream "rebase" "against" \
+ "git rebase <upstream branch>" "git-rebase(1)"
+ fi
;;
*) upstream_name="$1"
shift
^ permalink raw reply related
* [PATCH] request-pull: Include newline in output
From: Michael Witten @ 2011-02-09 2:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Date: Tue, 9 Feb 2011 02:17:47 +0000
Output looked like this:
The following changes since commit 7811d9600f02e70c9f835719c71156c967a684f7:
pull: Document the "--[no-]recurse-submodules" options (2011-02-07 15:19:09 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/git/git.git something
Now it looks like this:
The following changes since commit 7811d9600f02e70c9f835719c71156c967a684f7:
pull: Document the "--[no-]recurse-submodules" options (2011-02-07 15:19:09 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/git/git.git something
Isn't that nice?
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-request-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 6fdea39..d8e7ba3 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -70,7 +70,7 @@ git show -s --format='The following changes since commit %H:
%s (%ci)
-are available in the git repository at:' $baserev &&
+are available in the git repository at:%n' $baserev &&
echo " $url $branch" &&
echo &&
--
1.7.4.15.g7811d.dirty
^ permalink raw reply related
* Re: [PATCH] Support different branch layouts in git-p4
From: Ian Wienand @ 2011-02-09 3:46 UTC (permalink / raw)
To: Tor Arvid Lund, Pete Wyckoff; +Cc: git@vger.kernel.org
In-Reply-To: <AANLkTimGKc4MTwb=AnZ_Bv1EGS7yfgrFupxBOVVSm4s8@mail.gmail.com>
Thanks for the review
On 07/02/11 15:27, Tor Arvid Lund wrote:
> I'm just guessing from memory regarding these patterns, but assuming
> that the section separator is exactly the string '... ' seems risky,
> no? :)
Good point. If we go past the end of the depot ...'s, then the rest
of the line strip()ed should just be the client I guess.
> What if a line doesn't end with "..." ? Maybe add an "if cv_index>= 0"
I think it would mess us up. I put in a failure case for this.
On 07/02/11 17:22, Pete Wyckoff wrote:
> If you look at "p4 help views", they have lots of oddities
> that in theory should be accounted for here. It doesn't
> even mention the thing about quotes, but obviously that is
> supported. Wildcards ... and * can appear multiple
> times. And %%[1-9] can be used to reorder the path. Also the
> order of lines matters, and "+" can be used to merge entries.
> Whew.
Those %%'s would also mess us up, I put in an escape hatch for that
too.
I'm pretty sure this covers the majority of cases; if people have
really weird clients I guess they're going to have to do some more
work to get git-p4 to recognise it properly. Personally, I struggle
to see why it is a feature to have every user re-organsing their views
of the tree -- it seems to move a lot of uncaptured state to the
client side. anyway...
So here's another version; I agree some testing would be good as I've
only run it locally on //depot/proj/branch clients
-i
---
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..3304f36 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -910,6 +910,22 @@ class P4Sync(Command):
return files
def stripRepoPath(self, path, prefixes):
+ if self.useClientSpec:
+
+ # if using the client spec, we use the output directory
+ # specified in the client. For example, a view
+ # //depot/foo/branch/... //client/branch/foo/...
+ # will end up putting all foo/branch files into
+ # branch/foo/
+ for val in self.clientSpecDirs:
+ if path.startswith(val[0]):
+ # replace the depot path with the client path
+ path = path.replace(val[0], val[1][1])
+ # now strip out the client (//client/...)
+ path = re.sub("^(//[^/]+/)", '', path)
+ # the rest is all path
+ return path
+
if self.keepRepoPath:
prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
@@ -1032,7 +1048,7 @@ class P4Sync(Command):
includeFile = True
for val in self.clientSpecDirs:
if f['path'].startswith(val[0]):
- if val[1] <= 0:
+ if val[1][0] <= 0:
includeFile = False
break
@@ -1475,19 +1491,45 @@ class P4Sync(Command):
for entry in specList:
for k,v in entry.iteritems():
if k.startswith("View"):
+
+ # p4 has these %%1 to %%9 arguments in specs to
+ # reorder paths; which we can't handle (yet :)
+ if re.match('\%\%d', v) != None:
+ print "Sorry, can't handle %%n arguments in client specs"
+ sys.exit(1)
+
if v.startswith('"'):
start = 1
else:
start = 0
index = v.find("...")
+
+ # save the "client view"; i.e the RHS of the view
+ # line that tells the client where to put the
+ # files for this view.
+ cv = v[index+3:].strip() # +3 to remove previous '...'
+
+ # if the client view doesn't end with a
+ # ... wildcard, then we're going to mess up the
+ # output directory, so fail gracefully.
+ if not cv.endswith('...'):
+ print 'Sorry, client view in "%s" needs to end with wildcard' % (k)
+ sys.exit(1)
+ cv=cv[:-3]
+
+ # now save the view; +index means included, -index
+ # means it should be filtered out.
v = v[start:index]
if v.startswith("-"):
v = v[1:]
- temp[v] = -len(v)
+ include = -len(v)
else:
- temp[v] = len(v)
+ include = len(v)
+
+ temp[v] = (include, cv)
+
self.clientSpecDirs = temp.items()
- self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
+ self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
def run(self, args):
self.depotPaths = []
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 49b3359..e09da44 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -191,6 +191,11 @@ git-p4.useclientspec
git config [--global] git-p4.useclientspec false
+The P4CLIENT environment variable should be correctly set for p4 to be
+able to find the relevant client. This client spec will be used to
+both filter the files cloned by git and set the directory layout as
+specified in the client (this implies --keep-path style semantics).
+
Implementation Details...
=========================
^ permalink raw reply related
* Re: [PATCH] rebase: use @{upstream} if no upstream specified
From: Jonathan Nieder @ 2011-02-09 4:17 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Sverre Rabbelier, git, Junio C Hamano, Yann Dirson
In-Reply-To: <alpine.DEB.2.00.1102081959210.14152@debian>
Martin von Zweigbergk wrote:
> Maybe something like this on top? I put it in git-parse-remote.sh for
> now.
Thanks. That sounds like a good place.
> Changes to the text compared to before:
>
> * "remote branch" became "upstream branch", even for git pull
Sensible for pull --rebase. I'm not so sure about plain pull --- what
if I am upstream and pulling from downstream?
> * "You asked me to pull" became "You asked me to merge" or "You asked
> me to rebase", even for git pull
"To pull" would be clearer if the reader is new and unfamiliar with
the details.
> * Now printed to stderr, because I simply didn't think about it. Good
> or bad?
If this were a new message, I'd say stderr is better.
As is, the change to stderr seems relatively harmless, though I haven't
thought about it deeply. But a part of me likes to see functional
changes isolated in separate commits to make tracking down bugs a
little easier.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/7] Move term_columns() to pager.c and save terminal width before pager
From: Jonathan Nieder @ 2011-02-09 5:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, René Scharfe
In-Reply-To: <1297178541-31124-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> term_columns() checks for terminal width via ioctl(1).
ioctl(2). :)
I like the idea of checking width before launching a pager
and exporting it, yes.
> --- a/cache.h
> +++ b/cache.h
> @@ -1045,6 +1045,7 @@ extern void setup_pager(void);
> extern const char *pager_program;
> extern int pager_in_use(void);
> extern int pager_use_color;
> +extern int term_columns();
Should say (void) rather than leaving the parameter list unspecified,
no?
It will only be needed by a few translation units, I hope. Putting
it in column.h can avoid some pointless recompilation.
[...]
> +++ b/pager.c
> @@ -12,6 +12,7 @@
> */
>
> static int spawned_pager;
> +static int max_columns;
Could be stored in the COLUMNS environment variable, but an integer
variable like this is is simpler.
[...]
> @@ -80,6 +81,15 @@ void setup_pager(void)
>
> spawned_pager = 1; /* means we are emitting to terminal */
>
> +#ifdef TIOCGWINSZ
> + {
> + struct winsize ws;
> + if (!ioctl(1, TIOCGWINSZ, &ws)) {
> + if (ws.ws_col)
> + max_columns = ws.ws_col;
> + }
> + }
> +#endif
Mm, repeated code.
How about something like this on top? Not sure if the
"if (ws.ws_col)" is useful. I've left it alone.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 1 +
cache.h | 1 -
column.h | 6 ++++++
help.c | 1 +
| 48 ++++++++++++++++++++++++++----------------------
5 files changed, 34 insertions(+), 23 deletions(-)
create mode 100644 column.h
diff --git a/Makefile b/Makefile
index 775ee83..ed9e94b 100644
--- a/Makefile
+++ b/Makefile
@@ -1956,6 +1956,7 @@ builtin/prune.o builtin/reflog.o reachable.o: reachable.h
builtin/commit.o builtin/revert.o wt-status.o: wt-status.h
builtin/tar-tree.o archive-tar.o: tar.h
connect.o transport.o http-backend.o: url.h
+pager.o help.o: column.h
http-fetch.o http-walker.o remote-curl.o transport.o walker.o: walker.h
http.o http-walker.o http-push.o http-fetch.o remote-curl.o: http.h url.h
diff --git a/cache.h b/cache.h
index bcbd5f2..d83d68c 100644
--- a/cache.h
+++ b/cache.h
@@ -1045,7 +1045,6 @@ extern void setup_pager(void);
extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
-extern int term_columns();
extern const char *editor_program;
extern const char *askpass_program;
diff --git a/column.h b/column.h
new file mode 100644
index 0000000..55d8067
--- /dev/null
+++ b/column.h
@@ -0,0 +1,6 @@
+#ifndef COLUMN_H
+#define COLUMN_H
+
+extern int term_columns(void);
+
+#endif
diff --git a/help.c b/help.c
index 1344208..62a479b 100644
--- a/help.c
+++ b/help.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "column.h"
#include "levenshtein.h"
#include "help.h"
#include "common-cmds.h"
--git a/pager.c b/pager.c
index ad447cf..e6f7d86 100644
--- a/pager.c
+++ b/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include "column.h"
#ifndef DEFAULT_PAGER
#define DEFAULT_PAGER "less"
@@ -14,6 +15,21 @@
static int spawned_pager;
static int max_columns;
+#ifdef TIOCGWINSZ
+static int retrieve_terminal_width(void)
+{
+ struct winsize ws;
+ if (ioctl(1, TIOCGWINSZ, &ws)) /* e.g., ENOSYS */
+ return 0;
+ return ws.ws_col;
+}
+#else
+static int retrieve_terminal_width(void)
+{
+ return 0;
+}
+#endif
+
#ifndef WIN32
static void pager_preexec(void)
{
@@ -75,21 +91,17 @@ const char *git_pager(int stdout_is_tty)
void setup_pager(void)
{
const char *pager = git_pager(isatty(1));
+ int width;
if (!pager)
return;
spawned_pager = 1; /* means we are emitting to terminal */
-#ifdef TIOCGWINSZ
- {
- struct winsize ws;
- if (!ioctl(1, TIOCGWINSZ, &ws)) {
- if (ws.ws_col)
- max_columns = ws.ws_col;
- }
- }
-#endif
+ width = retrieve_terminal_width();
+ if (width)
+ max_columns = width;
+
/* spawn the pager */
pager_argv[0] = pager;
pager_process.use_shell = 1;
@@ -127,24 +139,16 @@ int pager_in_use(void)
return env ? git_config_bool("GIT_PAGER_IN_USE", env) : 0;
}
-int term_columns()
+int term_columns(void)
{
char *col_string = getenv("COLUMNS");
int n_cols;
if (col_string && (n_cols = atoi(col_string)) > 0)
return n_cols;
-
- else if (spawned_pager && max_columns)
+ if (spawned_pager && max_columns)
return max_columns;
-#ifdef TIOCGWINSZ
- else {
- struct winsize ws;
- if (!ioctl(1, TIOCGWINSZ, &ws)) {
- if (ws.ws_col)
- return ws.ws_col;
- }
- }
-#endif
- return 80;
+
+ n_cols = retrieve_terminal_width();
+ return n_cols ? n_cols : 80;
}
--
1.7.4
^ permalink raw reply related
* Re: [PATCH/RFC 0/7] Column output
From: Jonathan Nieder @ 2011-02-09 5:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git
In-Reply-To: <AANLkTi=WKnj8M2Uh+ACSay1STgOhWAjQbmspYSja3y0+@mail.gmail.com>
Some general reflections.
Nguyen Thai Ngoc Duy wrote:
> 2011/2/9 Jeff King <peff@peff.net>:
>> I don't really care for column output myself,
Me neither. I tricked myself into reading with a vague hope that it
might lead to a porcelain-level "git ls" command.
[...]
>> But why not use the BSD column program?
>
> Solaris did not have one last time I checked. Windows obviously does
> not either, but I don't use msysgit so it does not count.
A good reason to port the "column" program, no? I admit I find this a
compelling excuse not to bother with getting --column options and
core.column configuration right.
All that said.
Patches 1, 2, and 5 replace git help's existing columnation code
with something more reusable and functional. After those patches,
git --paginate help -a
no longer forces 80-column output. Another application of
term_columns could be to teach "git log" and "git log --graph"
to wrap to terminal width some day.
So if I ran the world, I would put those three patches before
--column et al in a possible reroll. :)
Thanks for some clear and pleasant reading.
Jonathan
^ permalink raw reply
* Re: [PATCH/RFC 0/7] Column output
From: Nguyen Thai Ngoc Duy @ 2011-02-09 5:59 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, git
In-Reply-To: <20110209054210.GA2019@elie>
On Wed, Feb 9, 2011 at 12:42 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Some general reflections.
>
> Nguyen Thai Ngoc Duy wrote:
>> 2011/2/9 Jeff King <peff@peff.net>:
>
>>> I don't really care for column output myself,
>
> Me neither. I tricked myself into reading with a vague hope that it
> might lead to a porcelain-level "git ls" command.
Wait for it. I have something hackish but usable. Non-recursive,
colorized column output. Not full of feature as GNU ls though (for
example, sorting by date can't be implemented).
--
Duy
^ permalink raw reply
* Re: [PATCH 2/7] Add column layout
From: Jonathan Nieder @ 2011-02-09 7:36 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, René Scharfe
In-Reply-To: <1297178541-31124-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> +++ b/column.c
> @@ -0,0 +1,177 @@
[...]
> +static int item_length(const struct column_layout *c, const char *s)
> +{
> + int a_len = 0;
> +
> + if (!(c->mode & COL_ANSI))
> + return strlen(s);
> +
> + while ((s = strstr(s, "\033[")) != NULL) {
> + int len = strspn(s+2, "0123456789;");
> + s += len+3; /* \033[<len><func char> */
> + a_len += len+3;
> + }
> + return a_len;
> +}
I think you mean "return strlen(orig_s) - a_len".
Something like the following could be more obvious, though
it is unfortunately verbose.
int len = 0;
while (*s) {
const char *next;
/* \033[<len><func char> */
if (!prefixcmp(s, "\033[")) {
s += strlen("\033[");
s += strspn(s, "0123456789;");
if (!*s)
... handle somehow ...
s++;
}
next = strchrnul(s, '\033');
len += next - s;
s = next;
}
Both miscompute the width of "Dépôt". Something like this can do ok
if the string is modifiable and we know it is UTF-8:
char save;
...
next = strchrnul(s, '\033');
/*
* NEEDSWORK: a utf8_strwidth variant that
* accepts a memory area not terminated by \0
* would avoid this ugliness.
*/
save = *next;
*next = '\0';
len += utf8_strwidth(s);
*next = save;
POSIX does not provide a strwidth function, so if we want to handle
encodings like SHIFT-JIS then something uglier[1] might come to life.
> +static void layout(const struct column_layout *c,
> + int total_width, int padding,
> + int *width,
> + int *rows, int *cols)
> +{
[...]
> + *rows = c->items.nr / *cols;
> + if (c->items.nr > *rows * *cols)
> + (*rows)++;
Maybe
*rows = DIV_ROUND_UP(c->items.nr, *cols);
?
> +static int squeeze_columns(const struct column_layout *c,
> + int *width, int padding,
> + int rows, int cols)
What does this function do?
Ah, it is for computing smaller, unequal column widths.
> +{
> + int x, y, i, len, item_len, spare = 0;
> + const char *s;
> +
> + for (x = 0; x < cols; x++) {
/* Find minimum width for column. */
int len = 0;
> + for (y = len = 0; y < rows; y++) {
[...]
> + len += padding;
> + if (len < width[x]) {
> + spare += width[x] - len;
> + width[x] = len;
> + }
This "if" is unnecessary, I hope. A simple
assert(len <= width[x]);
would check that.
[...]
> +static void relayout(const struct column_layout *c,
> + int padding, int spare,
> + int *initial_width, int **width,
> + int *rows, int *cols)
> +{
> + int new_rows, new_cols, new_initial_width;
> + int i, *new_width, new_spare, total_width;
> +
> + /*
> + * Assume all columns have same width, we would need
> + * initial_width*cols. But then after squeezing, we have
> + * "spare" more chars. Assume a new total_width with
> + * additional chars, then re-squeeze to see if it fits
> + * c->width.
> + */
Might be easier to debug if this part were deferred to a separate
patch. :)
> + total_width = (*initial_width)*(*cols) + spare;
An odd heuristic. Does it work well in practice?
> +static void display_columns_first(const struct column_layout *c,
> + int padding, const char *indent)
> +{
[...]
> + for (y = 0; y < rows; y++) {
> + for (x = 0; x < cols; x++) {
[...]
> + const char *s;
> + int len;
> +
> + i = x * rows + y;
> + if (i >= c->items.nr)
> + break;
> + s = c->items.items[i].string;
> + len = item_length(c, s);
> + if (width[x] < initial_width)
> + len += initial_width - width[x];
The "if" is unnecessary, I hope. (With that hope being checkable
by assert(width[x] <= initial_width).)
> +
> + printf("%s%s%s",
> + x == 0 ? indent : "",
> + c->items.items[i].string,
> + /* If the next column at same row is
> + out of range, end the line. Else pad
> + some space. */
> + i + rows >= c->items.nr ? "\n" : empty_cell + len);
Nice. The loop body could be a separate display_cell() function for
easier contemplation.
[...]
> +++ b/column.h
> @@ -0,0 +1,20 @@
[...]
> +#define COL_DENSE (1 << 5) /* "Ragged-right" mode, relayout if enough space */
I might be confused, but would it not be clearer to call it "unequal
column width" mode? In other words, is it about columns not all
having the same width as one another or about having a ragged right
margin?
Thanks for a pleasant read.
Jonathan
[1] Based on tuklib_mbstr_width:
size_t remaining = strlen(s);
size_t len = 0;
mbstate_t state;
memset(&state, 0, sizeof(state));
while (remaining) {
wchar_t ch;
size_t nbytes;
int width;
if (!prefixcmp(s, "\033["))
...
nbytes = mbrtowc(&ch, s, remaining, &state);
if (!nbytes || nbytes > remaining)
... handle error ...
s += nbytes;
remaining -= nbytes;
width = wcwidth(ch);
if (width < 0)
... handle nonprintable character ...
len += width;
}
^ permalink raw reply
* Re: [PATCH 5/7] help: reuse struct column_layout
From: Jonathan Nieder @ 2011-02-09 7:39 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1297178541-31124-6-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
[...]
> +++ b/help.c
> @@ -72,29 +73,17 @@ void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes)
[...]
> + struct column_layout c;
> + int i;
> +
> + memset(&c, 0, sizeof(c));
Might be nice to have a COLUMN_LAYOUT_INIT, I suppose.
Looks sane. What output changes would be noticeable, if any?
^ permalink raw reply
* grub-mkrescue: manpage points to non-existent info doc
From: Yann Dirson @ 2011-02-09 8:18 UTC (permalink / raw)
To: git list
Package: grub-common
Version: 1.99~20110112-1
manpage says:
The full documentation for grub-mkrescue is maintained as a
Texinfo manual. If the info and grub-mkrescue programs are
properly installed at your site, the command
info grub-mkrescue
should give you access to the complete manual.
info doc is not present, and apt-file confirms it does not exist:
$ apt-file search grub-mkrescue
grub-common: /usr/bin/grub-mkrescue
grub-common: /usr/share/man/man1/grub-mkrescue.1.gz
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* [PATCH] Documentation/merge subtree How-To: fix typo
From: Uwe Kleine-König @ 2011-02-09 9:04 UTC (permalink / raw)
To: git
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Documentation/howto/using-merge-subtree.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt
index 0953a50..2933056 100644
--- a/Documentation/howto/using-merge-subtree.txt
+++ b/Documentation/howto/using-merge-subtree.txt
@@ -71,5 +71,5 @@ Additional tips
relevant parts of your tree.
- Please note that if the other project merges from you, then it will
- connects its history to yours, which can be something they don't want
+ connect its history to yours, which can be something they don't want
to.
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] Documentation/merge subtree How-To: fix typo
From: Uwe Kleine-König @ 2011-02-09 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <1297242283-11532-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Wed, Feb 09, 2011 at 10:04:43AM +0100, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/howto/using-merge-subtree.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt
> index 0953a50..2933056 100644
> --- a/Documentation/howto/using-merge-subtree.txt
> +++ b/Documentation/howto/using-merge-subtree.txt
> @@ -71,5 +71,5 @@ Additional tips
> relevant parts of your tree.
>
> - Please note that if the other project merges from you, then it will
> - connects its history to yours, which can be something they don't want
> + connect its history to yours, which can be something they don't want
AFAIK additionally it should be "your's". Should I resend?
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: grub-mkrescue: manpage points to non-existent info doc
From: Sverre Rabbelier @ 2011-02-09 9:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: git list
In-Reply-To: <20110209091845.2145da9b@chalon.bertin.fr>
Heya,
On Wed, Feb 9, 2011 at 09:18, Yann Dirson <dirson@bertin.fr> wrote:
> Package: grub-common
I think you meant to send this to a different list?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Documentation/merge subtree How-To: fix typo
From: Miles Bader @ 2011-02-09 9:38 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20110209090821.GP27982@pengutronix.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
>> - Please note that if the other project merges from you, then it will
>> - connects its history to yours, which can be something they don't want
>> + connect its history to yours, which can be something they don't want
> AFAIK additionally it should be "your's". Should I resend?
No, "yours" is correct.
-Miles
--
Erudition, n. Dust shaken out of a book into an empty skull.
^ 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