Re: [PATCH] branch: give better message when no names specified for rename

On Sun, Mar 31, 2013 at 8:27 AM, Jonathon Mah wrote: > - if (argc == 1) > + if (!argc) > + die(_("branch name required")); > + else if (argc == 1) > rename_branch(head, argv[0], rename > 1); > e

[PATCH] branch: give better message when no names specified for rename

Signed-off-by: Jonathon Mah --- The previous message was incorrect when not enough arguments were specified: $ git branch -m fatal: too many branches for a rename operation I changed to "branch name required" instead of "new branch name required" in the hope that existing translat

[PATCH] bash: teach __git_ps1 about REVERT_HEAD

Signed-off-by: Robin Rosenberg --- contrib/completion/git-prompt.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index 341422a..756a951 100644 --- a/contrib/completion/git-prompt.sh +++ b/contrib/completion/git-prompt.sh

Re: [PATCH v2 07/12] utf8: keep NULs in reencode_string()

On Sun, Mar 31, 2013 at 12:06 AM, Torsten Bögershausen wrote: > On 30.03.13 10:35, Nguyễn Thái Ngọc Duy wrote: > [...] > The short version of a review: > Would it make sense to leave reencode_string() as it is, > and add a new function reencode_string_len() Hmm.. yeah. > +char *reencode_string_

[PATCH] git-svn: avoid self-referencing mergeinfo

When svn.pushmergeinfo is set, the target branch is included in the mergeinfo if it was previously merged into one of the source branches. SVN does not do this. Remove merge target branch path from resulting mergeinfo when svn.pushmergeinfo is set to better match the behavior of SVN. Update the sv

Re: stuck and need unstuck (git checkout)

On Mon, Mar 25, 2013 at 1:57 PM, J.V. wrote: > I was on a branch (local tracked with remote), and I wanted to checkout a > remote branch so did: > $git co myRemoteBranch > > and got a message that a lot of jar files were being untracked (files were > locked). I had a server running that had s

Re: [RFC] Add posibility to preload stat information.

On Thu, Mar 21, 2013 at 10:44 AM, Junio C Hamano wrote: > Thomas Rast writes: > >> I think it would actually be a somewhat interesting feature if it >> interacted with GIT_PS1_SHOW*. If you use these settings (I personally >> use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while

[PATCH] fixup! pathspec: support :(glob) syntax

A formatting fix for a patch currently cooking on nd/magic-pathspecs (cc3d8045ec1e2323c5654e2af834e887f26deb7e). --- The latest version of this wasn't posted to the list in full, so I'm not sure about the recommended way to provide feedback. Hopefully this is easy to squash in. Documentation/gi

Re: [PATCH v2 07/12] utf8: keep NULs in reencode_string()

On 30.03.13 10:35, Nguyễn Thái Ngọc Duy wrote: [...] The short version of a review: Would it make sense to leave reencode_string() as it is, and add a new function reencode_string_len() +char *reencode_string_len(const char *in, int insz, + const char *out_encoding, const char

[PATCH v6 5/5] pretty printing: extend %G? to include 'N' and 'U'

Expand %G? in pretty format strings to 'N' in case of no GPG signature and 'U' in case of a good but untrusted GPG signature in addition to the previous 'G'ood and 'B'ad. This eases writing anyting parsing git-log output. Signed-off-by: Sebastian Götte --- Documentation/pretty-formats.txt | 3 ++

[PATCH v6 4/5] merge/pull Check for untrusted good GPG signatures

When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte --- Documentation/merge-options.txt| 4 ++-- builtin/merge.c| 2 ++ commit.c | 2 ++ co

[PATCH v6 3/5] merge/pull: verify GPG signatures of commits being merged

When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte --- Documentatio

[PATCH v6 2/5] commit.c/GPG signature verification: Also look at the first GPG status line

Signed-off-by: Sebastian Götte --- commit.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/commit.c b/commit.c index eb645af..ca11919 100644 --- a/commit.c +++ b/commit.c @@ -1027,8 +1027,8 @@ static struct { char result; const char *che

[PATCH v6 0/5] Verify GPG signatures when merging and extend %G? pretty string

> Yuck. That termination condition is horrible. Ok, I reverted it to your suggestion. In this case, a much more elegant termination condition (foo == 1) is not possible without casts because foo is a pointer. >> +switch(signature_check.check_result){ >> +

[PATCH v6 1/5] Move commit GPG signature verification to commit.c

Signed-off-by: Sebastian Götte --- commit.c| 59 + commit.h| 10 +++ gpg-interface.h | 11 +++ pretty.c| 91 + 4 files changed, 93 insertions(+), 78 deletions(-) diff --git

check-attr doesn't respect recursive definitions

Hi, I am trying to write a custom archiving script that checks the export-ignore attribute to know which files from an ls-files output it should skip. Through this I noticed that for files in directories for which the export-ignore (or any other) attribute is set, check-attr still reports 'unspeci

[PATCH v2] checkout: add --no-widen for restoring files in sparse checkout mode

"git checkout -- " is usually used to restore all modified files in . In sparse checkout mode, this command is overloaded with another meaning: to add back all files in that are excluded by sparse patterns. Add "--no-widen" option to do what normal mode does: restore all modified files and nothin

[PATCH 2/2] optimize adjust_shared_perm() in path.c:

sometimes the chown() function is called even when not needed. (This can be provoced by running t1301, and adding some debug code) Save a chmod from 400 to 400, or from 600->600 on these files: .git/info/refs+ .git/objects/info/packs+ Save chmod on directories from 2770 to 2770: .git/refs .gi

[PATCH 1/2] optimize set_shared_perm() in path.c:

All calls to set_shared_perm() use mode == 0, so simplify the function. All callers use the macro adjust_shared_perm(path) from cache.h, convert adjust_shared_perm() from a macro into a function prototype Since path.c has much more functions than just mkpath(), improve a stale comment about path.

Re: [PATCH 2/2] optimize set_shared_perm()

On 29.03.13 22:20, Junio C Hamano wrote: [snip] > The last two points can become a separate "preparation" step. The > result would be easier to read. > > Your updated adjust_shared_perm() does not begin with: > > if (!shared_repository) > return 0; > > as the original, but i

[PATCH v2 12/12] pretty: support %>> that steal trailing spaces

This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not use up all 100 columns and %an needs more than 20 columns. By replacing %>(20) with %>>(20), %an can steal spaces from %s. %>> understands escape sequences, so %Cred does not stop it from stealing spaces in %<(100). Signed-off-

[PATCH v2 10/12] pretty: support padding placeholders, %< %> and %>

Either %<, %> or %>< standing before a placeholder specifies how many columns (at least as the placeholder can exceed it) it takes. Each differs on how spaces are padded: %< pads on the right (aka left alignment) %> pads on the left (aka right alignment) %>< pads both ways equally (aka cente

[PATCH v2 11/12] pretty: support truncating in %>, %< and %>

%>(N,trunc) truncates the right part after N columns and replace the last two letters with "..". ltrunc does the same on the left. mtrunc cuts the middle out. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 6 +++-- pretty.c | 51 ++

[PATCH v2 09/12] pretty: add %C(auto) for auto-coloring on the next placeholder

This is not simply convenient over %C(auto,xxx). Some placeholders (actually only one, %d) do multi coloring and we can't emit a multiple colors with %C(auto,xxx). Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 3 ++- pretty.c | 15 +++

[PATCH v2 07/12] utf8: keep NULs in reencode_string()

reencode_string() will be used in the next patch for re-encoding pretty output, which can contain NULs. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/fast-export.c| 3 ++- builtin/mailinfo.c | 3 ++- compat/precompose_utf8.c | 2 +- notes.c | 4 +++- pretty.c

[PATCH v2 08/12] pretty: two phase conversion for non utf-8 commits

Always assume format_commit_item() takes an utf-8 string for string handling simplicity (we can handle utf-8 strings, but can't with other encodings). If commit message is in non-utf8, or output encoding is not, then the commit is first converted to utf-8, processed, then output converted to outpu

[PATCH v2 06/12] pretty: get the correct encoding for --pretty:format=%e

parse_commit_header() provides the commit encoding for '%e' and it reads it from the re-encoded message, which contains the new encoding, not the original one in the commit object. Get the commit encoding from logmsg_reencode() instead. Signed-off-by: Nguyễn Thái Ngọc Duy --- pretty.c | 13

[PATCH v2 05/12] pretty: save commit encoding from logmsg_reencode if the caller needs it

The commit encoding is parsed by logmsg_reencode, there's no need for the caller to re-parse it again. The reencoded message now has the new encoding, not the original one. The caller would need to read commit object again before parsing. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/blame.c

[PATCH v2 04/12] utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences

Signed-off-by: Nguyễn Thái Ngọc Duy --- utf8.c | 20 ++-- utf8.h | 1 + 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/utf8.c b/utf8.c index 82c2ddf..38322a1 100644 --- a/utf8.c +++ b/utf8.c @@ -266,18 +266,26 @@ int utf8_width(const char **start, size_t *remain

[PATCH v2 03/12] utf8.c: move display_mode_esc_sequence_len() for use by other functions

Signed-off-by: Nguyễn Thái Ngọc Duy --- utf8.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/utf8.c b/utf8.c index 1087870..82c2ddf 100644 --- a/utf8.c +++ b/utf8.c @@ -9,6 +9,20 @@ struct interval { int last; }; +static size_t display_m

[PATCH v2 02/12] pretty: share code between format_decoration and show_decorations

This also adds color support to format_decoration() Signed-off-by: Nguyễn Thái Ngọc Duy --- log-tree.c | 60 +--- log-tree.h | 3 ++ pretty.c | 19 + t/t4207-log-decoration-colors

[PATCH v2 01/12] pretty-formats.txt: wrap long lines

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 105f18a..66345d1 100644 --- a/Documentation/pretty-formats.tx

[PATCH v2 00/12] Layout control placeholders for pretty format

The only difference in v2 is typo fixes (mostly in commit messages, but some in pretty-formats.txt). Also resend as a reminder to Junio if he forgot to pick it up. Nguyễn Thái Ngọc Duy (12): pretty-formats.txt: wrap long lines pretty: share code between format_decoration and show_decorations

Re: [PATCH 12/12] pretty: support %>> that steal trailing spaces

On Sun, Mar 17, 2013 at 4:06 PM, Eric Sunshine wrote: > On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy > wrote: >> This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not > > s/% an/%an/ No. The space after '%' is intentional. And thanks for proofreading in all my patches.

Re: Bug in "git rev-parse --verify"

Fwiw, look very a sound idea for me. Best 2013/3/30, Junio C Hamano : > Junio C Hamano writes: > >> What we may want is another type peeling operator, ^{object}. >> that makes sure it is an object, like this: >> >> rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object} >> >> It

Re: Bug in "git rev-parse --verify"

On 03/30/2013 08:05 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> What we may want is another type peeling operator, ^{object}. >> that makes sure it is an object, like this: >> >> rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object} >> >> It asks "I have this 40-hex

pandora bracelet charms is usually like all other expensive jewelry at a sens

You should be hunting for pandora bracelet charms on Connecticut, notably that ever in your life well known enchantment rings. It's a distinct and even classic variety of expensive jewelry which will started in Denmark. You can get an electric in Pandora expe

Re: Bug in "git rev-parse --verify"

Junio C Hamano writes: > What we may want is another type peeling operator, ^{object}. > that makes sure it is an object, like this: > > rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object} > > It asks "I have this 40-hex; I want an object out of it", just like > frotz^{tree}