Re: [PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

On Tue, Jun 7, 2016 at 6:31 PM, Eric Sunshine wrote: > On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: >> +int bisect_clean_state(void) >> +{ I forgot to mention that this and other functions should be 'static'. >> + int result = 0; >>

Re: [PATCH] tree-diff: avoid alloca for large allocations

On Tue, Jun 07, 2016 at 05:36:59PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > An alternative to this would be implement something like: > > > > struct tree *tp, tp_fallback[2]; > > if (nparent <= ARRAY_SIZE(tp_fallback)) > > tp = tp_fallback; > > else

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

Tom Russello writes: > +# Check if two files have the same content, non-order sensitive > +test_cmp_noorder () { > + sort $1 >$1; Here is what I think happens: 0) the shell parses this command line; 1) the shell notices that the output has to go to

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

Edward Thomson writes: > On Wed, Jun 01, 2016 at 09:00:34AM -0700, Junio C Hamano wrote: >> >> Unlike the "something like this" we saw earlier, this draws the >> boundary of responsibility between the caller and the API at a much >> more sensible place. > > This

Re: [PATCH] tree-diff: avoid alloca for large allocations

Jeff King writes: > An alternative to this would be implement something like: > > struct tree *tp, tp_fallback[2]; > if (nparent <= ARRAY_SIZE(tp_fallback)) > tp = tp_fallback; > else > ALLOC_ARRAY(tp, nparent); > ... > if (tp != tp_fallback) >

Re: [PATCH 2/4] t6030: explicitly test for bisection cleanup

On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: > This is not an improvement in the test coverage but it helps in making > it explicit as to what exactly would be the error as other tests are > focussed on testing other things. It's not clear why you consider this as

Re: [PATCH 4/8] Rename struct diff_filespec's sha1_valid member.

On Tue, Jun 07, 2016 at 12:14:42PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Tue, Jun 07, 2016 at 08:21:26AM +0200, Johannes Sixt wrote: > > > >> > diff --git a/combine-diff.c b/combine-diff.c > >> > index f39be434..a20caa80 100644 > >> > --- a/combine-diff.c > >>

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Wed, Jun 01, 2016 at 09:00:34AM -0700, Junio C Hamano wrote: > > Unlike the "something like this" we saw earlier, this draws the > boundary of responsibility between the caller and the API at a much > more sensible place. This makes sense to me - Junio, are you taking (or have you already

[PATCH] tree-diff: avoid alloca for large allocations

Commit 72441af (tree-diff: rework diff_tree() to generate diffs for multiparent cases as well, 2014-04-07) introduced the use of alloca so that the common cases of commits with 1 or 2 parents would not be adversely affected by going through the multi-parent code. However, our xalloca is not ideal

[PATCH v4 3/3] doc: more consistency in environment variables format

Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped (italic type) environment variables which are followed by the word "environment". It was obtained with: perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt One of the main purposes is to stick to the

[PATCH v4 2/3] doc: change environment variables format

This change GIT_* variables that where in italic style to monospaced font according to the guideline. It was obtained with perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by

[PATCH v4 1/3] doc: clearer rule about formatting literals

Make the guideline text that we want for our documentation clearer. Signed-off-by: Tom Russello Signed-off-by: Erwan Mathoniere Signed-off-by: Samuel Groot Signed-off-by: Matthieu Moy

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 7, 2016 at 3:29 PM, Jeff King wrote: > or even: > > git tag --show-tag-name foo/v1.0 > > when refs/remotes/foo/v1.0 exists? > > The rule right now is generally that "git tag" takes actual tag names. Ahh, I forgot about that. Yes, indeed the command does not work like

[PATCH v4 0/3] Documentation more consistent

Hello, as `MAN_BOLD_LITERAL` knob is just now turned on by default with 5945717 (Documentation: bold literals in man, 2016-05-31), it is the right time to make our documentation more consistent. Documentation/CodingGuidelines| 13 -- Documentation/config.txt | 58

Re: [PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

On Tue, Jun 7, 2016 at 4:54 PM, Pranit Bauva wrote: > Reimplement `bisect_clean_state` shell function in C and add a > `bisect-clean-state` subcommand to `git bisect--helper` to call it from > git-bisect.sh . > [...] > Signed-off-by: Pranit Bauva >

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:21:48PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > If you are suggesting that you can do the whole thing today by parsing > > the tag object yourself, then sure, I agree. I thought the point of the > > exercise was to make that less painful

Re: [PATCH v4 27/38] i18n: config: unfold error messages marked for translation

Vasco Almeida writes: > Introduced in 473166b ("config: add 'origin_type' to config_source > struct", 2016-02-19), Git can inform the user about the origin of a > config error, but the implementation does not allow translators to > translate the keywords 'file', 'blob,

Re: [RFC/PATCH] verify-tag: add --check-name flag

Jeff King writes: > If you are suggesting that you can do the whole thing today by parsing > the tag object yourself, then sure, I agree. I thought the point of the > exercise was to make that less painful for the callers. Yes, and I somehow thought everybody agreed that

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 06:13:25PM -0400, Jeff King wrote: > On Tue, Jun 07, 2016 at 03:11:47PM -0700, Junio C Hamano wrote: > > > On Tue, Jun 7, 2016 at 3:07 PM, Jeff King wrote: > > >> > > >> Puzzled. I didn't even use --format=%(tagname) in the above. > > > > > > No, but you

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:11:47PM -0700, Junio C Hamano wrote: > On Tue, Jun 7, 2016 at 3:07 PM, Jeff King wrote: > >> > >> Puzzled. I didn't even use --format=%(tagname) in the above. > > > > No, but you used --show-tagname, which does not exist today (and which > > IMHO should

Re: [PATCH v4 37/38] i18n: unmark die messages for translation

Vasco Almeida writes: > These messages are relevant for the programmer only, not for the end > user. Thus, they can be unmarked for translation, saving translator > some work. > > Signed-off-by: Vasco Almeida > --- > git-bisect.sh | 2 +- >

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:05:50PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Tue, Jun 07, 2016 at 02:50:23PM -0700, Junio C Hamano wrote: > > > >> >> Or it could even do this: > >> >> > >> >> tag="$1" > >> >> if ! git tag -v "$tag" > >> >>

Re: [RFC/PATCH] verify-tag: add --check-name flag

Jeff King writes: > On Tue, Jun 07, 2016 at 02:50:23PM -0700, Junio C Hamano wrote: > >> >> Or it could even do this: >> >> >> >> tag="$1" >> >> if ! git tag -v "$tag" >> >> if ! git tag -v "$tag" >> >> then >> >> echo >&2 "Bad tag." >> >>

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 02:50:23PM -0700, Junio C Hamano wrote: > >> Or it could even do this: > >> > >>tag="$1" > >>if ! git tag -v "$tag" > >>if ! git tag -v "$tag" > >> then > >>echo >&2 "Bad tag." > >> exit 1 > >>fi > >> + tag=$(git tag

Re: [RFC/PATCH] verify-tag: add --check-name flag

Jeff King writes: > git tag -v --format='%(tag)%n%(tagger)' > > or similar. In fact you can already do that with a separate step (modulo > %n, which we do not seem to understand here), but like your example: Yes, "--format=%(tag)" is all that is needed to make the example work.

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 05:08:56PM -0400, Jeff King wrote: > On Tue, Jun 07, 2016 at 03:56:08PM -0400, santi...@nyu.edu wrote: > > > diff --git a/tag.c b/tag.c > > index d1dcd18..591b31e 100644 > > --- a/tag.c > > +++ b/tag.c > > @@ -55,6 +55,14 @@ int gpg_verify_tag(const unsigned char *sha1,

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 05:17:07PM -0400, Jeff King wrote: > That is much more flexible, as they could even do some more complicated > matching than a single string (though in practice, for security things, > I think simpler is better). > > I think this option is going to become a blueprint for

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 02:05:20PM -0700, Junio C Hamano wrote: > santi...@nyu.edu writes: > > > 1.- Using a tag ref as a check-out mechanism is pretty common by package > > managers and other tools. Verifying the tag signature provides > > authentication guarantees, but there is no

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 05:13:14PM -0400, Santiago Torres wrote: > > 2. What do we do for non-annotated tags? Is it always a failure? > > Right now, verify-tag fails with non-annotated tags like this: > > santiago at ~/.../git ✔ ./git-verify-tag master > error: master: cannot verify

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 02:05:20PM -0700, Junio C Hamano wrote: > It is true that "git cat-file tag v1.4.11" lets you examine all > lines of a given tag object, but the calling program needs to pick > pieces apart with something like: > > git cat-file tag v1.4.11 | sed -e '/^$/q' -e

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:56:08PM -0400, santi...@nyu.edu wrote: > diff --git a/tag.c b/tag.c > index d1dcd18..591b31e 100644 > --- a/tag.c > +++ b/tag.c > @@ -55,6 +55,14 @@ int gpg_verify_tag(const unsigned char *sha1, const char > *name_to_report, > > ret = run_gpg_verify(buf, size,

Re: [RFC/PATCH] verify-tag: add --check-name flag

santi...@nyu.edu writes: > 1.- Using a tag ref as a check-out mechanism is pretty common by package > managers and other tools. Verifying the tag signature provides > authentication guarantees, but there is no feedback that the > signature being verified belongs to the intended tag.

Re: [PATCH] git-p4.py: Make submit working on bare repository

Junio C Hamano writes: > Amadeusz Żołnowski writes: > >>> Has anything happened to this topic after this? I am wondering if I >>> should discard the topic az/p4-bare-no-rebase without prejudice. I think you can discard the topic, because we're moving

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

From: "Matthieu Moy" "Philip Oakley" writes: From: "Matthieu Moy" But then the maintainer is not the one picking changes from it (you're sending them by email), so the "maintainer" label is not really

[PATCH 4/4] bisect--helper: `bisect_reset` shell function in C

Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `bisect_reset` subcommand is a temporary measure to port shell functions to C so as to use the existing test suite. As more functions are ported, this

[PATCH 3/4] dir: introduce file_size() to check the size of file

At times we require to see if the file is empty and get the size of the file. By using stat we can get the file size without actually having to open the file to check for its contents. Mentored-by: Lars Schneider Mentored-by: Christian Couder

[PATCH 2/4] t6030: explicitly test for bisection cleanup

This is not an improvement in the test coverage but it helps in making it explicit as to what exactly would be the error as other tests are focussed on testing other things. Mentored-by: Lars Schneider Mentored-by: Christian Couder

[PATCH 1/4] bisect--helper: `bisect_clean_state` shell function in C

Reimplement `bisect_clean_state` shell function in C and add a `bisect-clean-state` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `bisect_clean_state` subcommand is a measure to port shell function to C so as to use the existing test suite. As more functions are ported,

Re: [PATCH v2 4/4] bundle v3: the beginning

On Tue, Jun 07, 2016 at 03:19:46PM +0200, Christian Couder wrote: > > But there are lots of cases where the server might want to tell > > the client that don't involve bundles at all. > > The idea is also that anytime the server needs to send external ODB > data to the client, it would

Re: [PATCH v2 4/4] bundle v3: the beginning

On Tue, Jun 07, 2016 at 12:23:40PM -0700, Junio C Hamano wrote: > Christian Couder writes: > > > Git can store its objects only in the form of loose objects in > > separate files or packed objects in a pack file. > > To be able to better handle some kind of objects,

Re: `git help svn` missing description of `propset`

+Cc Alfred, David Joseph Pecoraro wrote: > `git help svn` does not mention `propset` but it does mention `proplist` and > `propget`. This seems like an oversight. > > > $ git help svn > ... > proplist > Lists the properties stored in the

[RFC/PATCH] verify-tag: add --check-name flag

From: Santiago Torres Hello everyone, In a previous thread [1] we discussed about the possibility of having a --check-name flag, for the tag-verify command (and possibly git tag -v). Although many points were in the table, I don't think that it was conclusive as to whether

Re: [PATCH 2/5] t1404: document function test_update_rejected

Johannes Sixt writes: > Am 07.06.2016 um 13:50 schrieb Michael Haggerty: >> test_update_rejected () { >> +local prefix before pack create error && > > Do we want to add more of unportable 'local' declarations? Not really ;-) Thanks for catching. >> prefix="$1" && >>

Re: [PATCH v2 4/4] bundle v3: the beginning

Christian Couder writes: > Git can store its objects only in the form of loose objects in > separate files or packed objects in a pack file. > To be able to better handle some kind of objects, for example big > blobs, it would be nice if Git could store its objects in

[BUG] gitk

Hello, I couldn’t find any documentation on submitting patches for gitk. I saw in Documentation/SubmittingPatches that gitk is maintained in its own repo. I can’t clone repo’s unless they’re http while on my corporate proxy. I’m hoping someone can help me out or just do it for me ;-) I’d like to

Re: [PATCH 4/8] Rename struct diff_filespec's sha1_valid member.

Jeff King writes: > On Tue, Jun 07, 2016 at 08:21:26AM +0200, Johannes Sixt wrote: > >> > diff --git a/combine-diff.c b/combine-diff.c >> > index f39be434..a20caa80 100644 >> > --- a/combine-diff.c >> > +++ b/combine-diff.c >> > @@ -1269,7 +1269,7 @@ static struct diff_filepair

Re: [PATCHv3] Documentation: triangular workflow

Jordan DE GEA writes: > diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt > index f16c414..3b5fd09 100644 > --- a/Documentation/gitworkflows.txt > +++ b/Documentation/gitworkflows.txt > @@ -463,6 +463,156 @@ if you get conflicts: `git am

Hello.......

-- Hello, Can i talk with you..? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

William Duclot writes: >> Perhaps I made it clearer by using a more exaggerated example e.g. a >> typical expected buffer size of 128 bytes, but the third line of >> 1000 line input file was an anomaly that is 200k bytes long. I do >> not want to keep

Re: [PATCH 02/38] rename_ref_available(): add docstring

Michael Haggerty writes: > From: David Turner > > Signed-off-by: David Turner > Signed-off-by: Junio C Hamano > Signed-off-by: Michael Haggerty > --- > refs/refs-internal.h | 5

Re: [PATCH 37/38] refs: make lock generic

Michael Haggerty writes: > From: David Turner > > Instead of including a files-backend-specific struct ref_lock, change > the generic ref_update struct to include a void pointer that backends > can use for their own arbitrary data. Hmph. > @@

Re: [PATCH 34/38] refs: add method for delete_refs

Michael Haggerty writes: > From: David Turner > > In the file-based backend, delete_refs has some special optimization > to deal with packed refs. In other backends, we might be able to make > ref deletion faster by putting all deletions into a

Re: [PATCH 23/38] refs: make peel_ref() virtual

Michael Haggerty writes: > For now it only supports the main reference store. Isn't this comment applicable to a handful of recent changes that made other things virtual, too? Just wondering if I am missing something very special with the peel_ref() thing to single it

Re: [PATCH 21/38] refs: make pack_refs() virtual

Michael Haggerty writes: > Signed-off-by: Michael Haggerty > --- > refs.c | 7 +++ > refs/files-backend.c | 6 -- > refs/refs-internal.h | 4 > 3 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/refs.c

Re: [PATCH 17/38] resolve_gitlink_ref(): avoid memory allocation in many cases

Michael Haggerty writes: > If we don't have to strip trailing '/' from the submodule path, then > don't allocate and copy the submodule name. Makes sense. > int resolve_gitlink_ref(const char *path, const char *refname, unsigned char > *sha1) > { > - int len =

Re: [PATCH 16/38] resolve_gitlink_ref(): implement using resolve_ref_recursively()

Michael Haggerty writes: > resolve_ref_recursively() can handle references in arbitrary files > reference stores, so use it to resolve "gitlink" (i.e., submodule) > references. Aside from removing redundant code, this allows submodule > lookups to benefit from the much more

Re: [PATCH 05/38] refs: create a base class "ref_store" for files_ref_store

Michael Haggerty writes: > We want ref_stores to be polymorphic, so invent a base class of which > files_ref_store is a derived class. For now there is a one-to-one > relationship between ref_stores and submodules. The mention of "submodules" made me go "Huh?" but thinking

Re: [PATCH 2/5] t1404: document function test_update_rejected

Am 07.06.2016 um 13:50 schrieb Michael Haggerty: test_update_rejected () { + local prefix before pack create error && Do we want to add more of unportable 'local' declarations? prefix="$1" && before="$2" && pack="$3" && -- Hannes -- To unsubscribe from this

Re: [PATCH 05/38] refs: create a base class "ref_store" for files_ref_store

This is a tangent, but your series that ends at 4aa2c475 (grep: -W: don't extend context to trailing empty lines, 2016-05-28) does not seem to have much effect when viewing the change to refs.c this patch makes (it modifies a function in an early part, and then adds bunch of new functions at the

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On 2016, ജൂൺ 7 9:16:01 PM IST, Stefan Beller wrote: >On Tue, Jun 7, 2016 at 8:43 AM, Stefan Beller >wrote: >> (Are you telling me that patch is faulty?) > >The patch is not part of v2.8.1 but part of v2.8.3, >so take a later version, or cherry-pick that

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On Tue, Jun 7, 2016 at 8:43 AM, Stefan Beller wrote: > (Are you telling me that patch is faulty?) The patch is not part of v2.8.1 but part of v2.8.3, so take a later version, or cherry-pick that patch manually. -- To unsubscribe from this list: send the line "unsubscribe git"

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

http://thread.gmane.org/gmane.comp.version-control.git/293025 TL;DR: don't run tests as root, or cherry-pick cadfbef98032fbc6874b5efd70d1e33dbeb4640d (Are you telling me that patch is faulty?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

[PATCH v2 1/3] convert: unify the "auto" handling of CRLF

From: Torsten Bögershausen Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this

[PATCH v2 3/3] Correct ce_compare_data() in a middle of a merge

From: Torsten Bögershausen The following didn't work as expected: - In a middle of a merge - merge.renormalize is true, - .gitattributes = "* text=auto" - core.eol = crlf Merge a blob with CRLF "first line\r\nsame line\r\n" and a blob with LF "first line\nsame line\n". The

[PATCH v2 2/3] read-cache: factor out get_sha1_from_index() helper

From: Torsten Bögershausen Factor out the retrieval of the sha1 for a given path in read_blob_data_from_index() into the function get_sha1_from_index(). This will be used in the next commit, when convert.c can do the analyze for "text=auto" without slurping the whole blob into

[PATCH v2 0/3] unified auto CRLF handling, V2

From: Torsten Bögershausen unified auto CRLF handling, V2 1/3 is 7/10 of the old 10/10 series 2/3 and 3/3 is a replacement for tb/convert-peek-in-index: Better commit message, added test case All in all we are getting closer. Most of the patches had been send &

Re: [PATCH v2] builtin/commit.c: memoize git-path for COMMIT_EDITMSG

On Wed, May 25, 2016 at 12:49 AM, Pranit Bauva wrote: > This is a follow up commit for f932729c (memoize common git-path > "constant" files, 10-Aug-2015). > > The many function calls to git_path() are replaced by > git_path_commit_editmsg() and which thus eliminates the

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 1, 2016 at 3:37 PM, Duy Nguyen wrote: > On Tue, May 31, 2016 at 8:18 PM, Christian Couder > wrote: I wonder if this mechanism could also be used or extended to clone and fetch an alternate object database. In [1], [2]

[PATCH v3 5/6] send-email: --in-reply-to= populates the fields

Take an email message file, parse it and fill the "From", "To", "Cc", "In-reply-to", "References" fields appropriately. If `--compose` option is set, it will also fill the subject field with `Re: ['s subject]` in the introductory message. Signed-off-by: Tom RUSSELLO

[PATCH v3 6/6] send-email: add option --cite to quote the message body

If used with `in-reply-to=`, cite the message body of the given email file. Otherwise, do nothing. If `--compose` is set, quote the message body in the cover letter. Else, imply `--annotate` by default and quote the message body below the triple-dash section in the first patch only.

[PATCH v3 0/6] send-email: cleaner tests and quote email

The purpose of this series of patches is to implement a new "quote-email" feature integrated in the current `--in-reply-to` option. * The first 2 patches make the tests less dependent to `git send-email`'s exact output. * Third patch makes `git send-email` a bit less verbose. * Fourth

[PATCH v3 1/6] t9001: non order-sensitive file comparison

Tests might fail if lines compared in text files don't have the same order. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO Signed-off-by: Matthieu MOY --- t/t9001-send-email.sh | 61

[PATCH v3 2/6] t9001: check email address is in Cc: field

Check if the given utf-8 email address is in the Cc: field. Signed-off-by: Tom RUSSELLO Signed-off-by: Samuel GROOT Signed-off-by: Matthieu MOY --- t/t9001-send-email.sh | 4 ++-- 1 file changed, 2

[PATCH v3 4/6] send-email: create email parser subroutine

We need a simple and generic way to parse an email file. Since it would be hard to include and maintain an external library, create an simple email parser subroutine to parse an email file. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO

[PATCH v3 3/6] t9001: shorten send-email's output

Messages displayed by `send-email` should be shortened to avoid displaying unnecesseray informations. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO Signed-off-by: Matthieu MOY ---

Re: [RFC/PATCH v2] pull: add --set-upstream

On 06/06/2016 18:29, Philip Oakley wrote: + that each one tracks the remote branch pulled from. If a configuration + already exists, it is overwriten. For example, with `git pull -u origin + branch` the current branch will track `branch` from `origin`. ++ +If two or more branches are pulled on

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 1, 2016 at 12:31 AM, Jeff King wrote: > On Fri, May 20, 2016 at 02:39:06PM +0200, Christian Couder wrote: > >> I wonder if this mechanism could also be used or extended to clone and >> fetch an alternate object database. >> >> In [1], [2] and [3], and this was also

Re: [RFC/PATCH v2] pull: add --set-upstream

On 06/06/2016 21:06, Junio C Hamano wrote: But I am unhappy with a more serious problem with the tests in this patch. They assume that "-u" option will forever be the only thing that is allowed to modify the configuration during "git pull -u". It should never make such an assumption. The

Re: Minor Bug in Renaming Branches

On Tue, Jun 7, 2016 at 12:40 AM, Eric Deplagne wrote: > On Tue, 07 Jun 2016 06:13:14 +0200, Torsten Bögershausen wrote: >> On 06/06/2016 09:35 PM, Stefan Beller wrote: >>> On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen wrote: >>> A limitation is

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On Tuesday 07 June 2016 04:00 PM, Johannes Schindelin wrote: > Hi Pirate Praveen, > > On Tue, 7 Jun 2016, Pirate Praveen wrote: > >> I'm trying to rebuild git 2.8.1 on debian jessie/stable and I get this >> error (tests upto this succeeds). >> >> not ok 32 - should avoid cleaning possible

[PATCH v4 34/38] i18n: init-db: join message pieces

Join message displayed during repository initialization in one entire sentence. That would improve translations since it's easier translate an entire sentence than translating each piece. Signed-off-by: Vasco Almeida --- builtin/init-db.c | 17 ++--- 1 file

[PATCH v4 37/38] i18n: unmark die messages for translation

These messages are relevant for the programmer only, not for the end user. Thus, they can be unmarked for translation, saving translator some work. Signed-off-by: Vasco Almeida --- git-bisect.sh | 2 +- wt-status.c | 4 ++-- 2 files changed, 3 insertions(+), 3

[PATCH v4 35/38] i18n: submodule: join strings marked for translation

Join strings marked for translation since that would facilitate and improve translations result. Signed-off-by: Vasco Almeida --- git-submodule.sh | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh

[PATCH v4 38/38] i18n: branch: mark comment when editing branch description for translation

When one issues git branch --edit-description branch_name, a edit with that message commented out is opened. Mark that message for translation in to order to be localized. Signed-off-by: Vasco Almeida --- builtin/branch.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v4 36/38] i18n: submodule: escape shell variables inside eval_gettext

According to the gettext manual [1], references to shell variables inside eval_gettext call must be escaped so that eval_gettext receives the translatable string before the variable values are substituted into it. [1]

Re: [RFC/PATCH v2] pull: add --set-upstream

On 07/06/2016 09:06, Matthieu Moy wrote: Junio C Hamano writes: Matthieu Moy writes: +test_config_unchanged () { + git config --list --local >original + "$@" + git config --list --local >modified + test_cmp original

Re: [RFC/PATCH v2] pull: add --set-upstream

On 06/06/2016 17:54, Matthieu Moy wrote: Erwan Mathoniere writes: @@ -497,6 +504,10 @@ static void NORETURN die_no_merge_candidates(const char *repo, const char **refs fprintf(stderr, "\n"); fprintf_ln(stderr, _("If you

Re: [PATCH 2/4] Resurrect "diff-lib.c: adjust position of i-t-a entries in diff"

On Tue, Jun 7, 2016 at 3:42 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +--shift-ita:: >> + By default entries added by "git add -N" appear as an existing >> + empty file in "git diff" and a new file in "git diff --cached". >> +

Re: [PATCH v2 00/13] Reference iterators

On 06/04/2016 01:40 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> On 06/03/2016 11:33 PM, Junio C Hamano wrote: >>> [...] >>> Ah, that reminds me. What's the doneness of the dependent topic? >> [...] > > What I meant was the doneness of mh/split-under-lock

[PATCH v4 17/38] i18n: setup: mark strings for translation

Update tests that compare the strings newly marked for translation to succeed when running under GETTEXT_POISON. Signed-off-by: Vasco Almeida --- setup.c| 16 t/t1506-rev-parse-diagnosis.sh | 2 +- t/t4208-log-magic-pathspec.sh |

[PATCH v4 07/38] i18n: merge-octopus: mark messages for translation

Mark messages in git-merge-octopus.sh for translation. Signed-off-by: Vasco Almeida --- git-merge-octopus.sh | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh index dc2fd1b..89e967a 100755

[PATCH v4 04/38] i18n: transport: mark strings for translation

Mark one printf string and one error string for translation. Signed-off-by: Vasco Almeida --- transport.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/transport.c b/transport.c index 095e61f..59b911e 100644 --- a/transport.c

[PATCH v4 27/38] i18n: config: unfold error messages marked for translation

Introduced in 473166b ("config: add 'origin_type' to config_source struct", 2016-02-19), Git can inform the user about the origin of a config error, but the implementation does not allow translators to translate the keywords 'file', 'blob, 'standard input', and 'submodule-blob'. Moreover, for the

[PATCH v4 18/38] tests: use test_i18n* functions to suppress false positives

The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from

[PATCH v4 32/38] i18n: remote: mark URL fallback text for translation

Marks fallback text for translation that may be displayed in git remote show output. Signed-off-by: Vasco Almeida --- builtin/remote.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/remote.c b/builtin/remote.c index ae74da6..9f934cb

[PATCH v4 09/38] i18n: rebase: fix marked string to use eval_gettext variant

The string message marked for translation should use eval_gettext variant instead of the gettext one, since we want to dollar-substitute $head_name in the result. Signed-off-by: Vasco Almeida --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v4 01/38] i18n: builtin/remote.c: fix mark for translation

The second string inside _() was not being extracted for translation by xgettext, meaning that, although the string was passed to gettext, there was no translation available. Mark each individual string instead of marking the result of ternary if. Signed-off-by: Vasco Almeida

[PATCH v4 25/38] i18n: notes: mark strings for translation

Mark strings of messages for the user as translatable. Update tests t3310-notes-merge-manual-resolve.sh and t3320-notes-merge-worktrees.sh to reflect new translatable messages. Tests that grep for .git/NOTES_MERGE_WORKTREE reflect the translatable string "Automatic notes merge failed. Fix

[PATCH v4 06/38] i18n: sequencer: mark string for translation

Mark informative string ": fast-forward" for translation. Signed-off-by: Vasco Almeida --- sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index 88a7c78..57b3671 100644 --- a/sequencer.c +++ b/sequencer.c @@ -225,7

[PATCH v4 05/38] i18n: sequencer: mark entire sentences for translation

Mark entire sentences of error message rather than assembling one using placeholders (e.g. "Cannot %s during a %s"). That would facilitate translation work because it is easier to translate a entire sentence than translating pieces. We would have better translations at the expense of source code

  1   2   >