Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

Hello, As a heads up (and because I have been pulled into this thread :)), I wanted to bring to the notice of translators that the commit, b884244c8 commit-template: remove outdated notice about explicit paths *removes* a message ("Explicit paths specified without -i or -o; assuming --only

Re: reftable: new ref storage format

On Sun, Jul 16, 2017 at 12:43 PM, Shawn Pearce wrote: > On Sun, Jul 16, 2017 at 10:33 AM, Michael Haggerty > wrote: >> * Do you propose to store *all* references (i.e., including the >> references that we call pseudorefs, like `HEAD`, `FETCH_HEAD`,

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

2017-07-18 1:10 GMT+08:00 Junio C Hamano : > Jiang Xin writes: > >> Commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for >> timestamps", 2017-04-21) does not play well with i18n framework. The >> static string concatenation cannot be

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

2017-07-18 0:06 GMT+08:00 Johannes Schindelin : > Hi, > > On Mon, 17 Jul 2017, Jiang Xin wrote: > >> 2017-07-16 3:30 GMT+08:00 Jean-Noël Avila : >> > >> > >> > A few remarks on i18n: >> > >> > * commit cb71f8bdb5 ("PRItime: introduce a new "printf

[PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD' which should be future proof regardless of the hash function used. Signed-off-by: Stefan Beller --- t/t8008-blame-formats.sh | 28 +++- 1 file changed, 15 insertions(+), 13

Donation

Hello, My name is Gloria C. Mackenzie, i have a Monetary Donation to make for the less privilege, yourself and your organization, am writing you with a friend's email, please contact me on gmackenzie...@rogers.com

Re: [PATCH v2 1/1] sha1_file: Add support for downloading blobs on demand

On Mon, 17 Jul 2017 16:09:17 -0400 Ben Peart wrote: > > Is this change meant to ensure that Git code that operates on loose > > objects directly (bypassing storage-agnostic functions such as > > sha1_object_info_extended() and has_sha1_file()) still work? If yes, > > this

Re: [PATCH] RFC: A new type of symbolic refs

On Mon, Jul 17, 2017 at 2:48 PM, Junio C Hamano wrote: > I _think_ a symbolic HEAD that points upwards to the gitlink entry in > the superproject's index is the easiest to understand and it is > something we can define a clear and useful semantics for. ok, let's start with

Re: [PATCH] doc: reformat the paragraph containing the 'cut-line'

Kaartic Sivaraam writes: > The paragraph that describes the 'scissors' cleanup mode of > 'commit' had the 'cut-line' in the middle of a sentence. This > made it possible for the line to get wrapped on smaler windows. > This shouldn't be the case as it makes it

Re: [PATCH] doc: camelCase the i18n config variables to improve readability

Kaartic Sivaraam writes: > The i18n config variable used weren't readable as they were in > the crude form of how git stores/uses it's config variables. > > Improve it's readability by replacing them with camelCased versions > of config variables as it doesn't

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Santiago Torres writes: > Other projects such as notmuch opted for a solution that's simlar to > what I had suggested[1], but I wonder if it's even necessary to do. > There is already a fix on the master branch of gnupg[2], which I imagine > will show up to the next version of

Re: [PATCH] rebase: make resolve message clearer for inexperienced users

William Duclot writes: > -$(gettext 'When you have resolved this problem, run "git rebase --continue". > -If you prefer to skip this patch, run "git rebase --skip" instead. > -To check out the original branch and stop rebasing, run "git rebase > --abort".') >

Re: [PATCH] RFC: A new type of symbolic refs

Stefan Beller writes: > +int read_external_symref(struct strbuf *from, struct strbuf *out) > +{ > + struct child_process cp = CHILD_PROCESS_INIT; > + const char *repo, *gitlink; > + int hint, code; > + struct strbuf **split = strbuf_split(from, 0); > +

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> > I'll dig into this. This sounds a way more reasonable approach. > > Thanks. Another thing that may help, if it turns out that we do > want to let agent run when it wants to I did some digging on the reason as to why this was happening. It turns out there is a bug on gnupg. As of gpg 2.1.21,

Re: [PATCH] check-ref-format: require a repository for --branch

I guess that should only be about that it should not hit a (BUG). In my case in the example I gave I scan trough the directories to check repository status one of the tasks make use of check-ref-format. Since it may hit directory which is not a git repository it should not expose error (BUG)

Re: [PATCH v2 2/3] trailers: export action enums and corresponding lookup functions

Christian Couder writes: > On Thu, Jul 13, 2017 at 12:21 AM, Paolo Bonzini wrote: > >> diff --git a/trailer.h b/trailer.h >> index e90ba1270..f306bf059 100644 >> --- a/trailer.h >> +++ b/trailer.h >> @@ -1,11 +1,33 @@ >> #ifndef TRAILER_H >>

Re: [ANNOUNCE] Git v2.14.0-rc0

Ævar Arnfjörð Bjarmason writes: > On Thu, Jul 13 2017, Junio C. Hamano jotted: > > Proposed improvements for the release notes (is this a good way to > propose RelNotes changes?) Thanks. You could also throw a patch just like any bugfix/update to documentation, I would think.

Re: [PATCH] check for search permission

Hielke Christian Braun writes: > --- > gitweb/gitweb.perl | 2 ++ > 1 file changed, 2 insertions(+) Thanks for trying to help and welcome to Git development community. But (1) Please double-check the title of your change. Imagine that the title appears in a list of 600

Re: [PATCH] commit: check for empty message before the check for untouched template

Kaartic Sivaraam writes: > The check for whether the template given to 'git commit' is untouched > is done before the empty message check. This results in a wrong error > message being displayed in the following case. When the user removes > everything in template

[PATCH v2 10/10] git.c: ignore pager.* when launching builtin as dashed external

When running, e.g., `git -c alias.bar=foo bar`, we expand the alias and execute `git-foo` as a dashed external. This is true even if git foo is a builtin. That is on purpose, and is motivated in a comment which was added in commit 441981bc ("git: simplify environment save/restore logic",

[PATCH v2 08/10] tag: respect `pager.tag` in list-mode only

Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. A user who makes use of `git tag -a` and `git tag -l` will probably choose not to configure `pager.tag` or to set it to "no", so that `git tag -a` will

[PATCH v2 07/10] tag: handle `pager.tag`-configuration within the builtin

Use the mechanisms introduced in two earlier patches to ignore `pager.tag` in git.c and let the `git tag` builtin handle it on its own. This is in preparation for the next patch, where we will want to ignore `pager.tag` unless we run in list-mode. For this reason, place the call to

[PATCH v2 09/10] tag: change default of `pager.tag` to "on"

The previous patch taught `git tag` to only respect `pager.tag` in list-mode. That patch left the default value of `pager.tag` at "off". After that patch, it makes sense to let the default value be "on" instead, since it will help with listing many tags, but will not hurt users of `git tag -a` as

[PATCH v2 06/10] t7006: add tests for how git tag paginates

Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. A user who makes use of `git tag -a` and `git tag -l` will probably choose not to configure `pager.tag` or to set it to "no", so that `git tag -a` will

[PATCH v2 01/10] builtin.h: take over documentation from api-builtin.txt

Delete Documentation/technical/api-builtin.txt and move its content verbatim into builtin.h. Just wrap it in /* ... */. In order to make the move obviously correct, do not change any formatting, not even to format the comment into Git's preferred style. That will be done in a follow-up patch.

[PATCH v2 03/10] builtin.h: document SUPPORT_SUPER_PREFIX

Commit 74866d75 ("git: make super-prefix option", 2016-10-07) introduced SUPPORT_SUPER_PREFIX as a builtin flag without documenting it. The next patch will add another flag, so document SUPPORT_SUPER_PREFIX, thereby bringing the documentation up to date with the available flags. While at it,

[PATCH v2 05/10] git.c: provide setup_auto_pager()

The previous patch introduced a way for builtins to declare that they will take responsibility for handling the `pager.foo`-config item. (See the commit message of that patch for why that could be useful.) Provide setup_auto_pager(), which builtins can call in order to handle `pager.`, including

[PATCH v2 02/10] builtin.h: format documentation-comment properly

The previous commit moved technical documentation verbatim into builtin.h. Prefix all the lines with '*' to follow the coding guidelines. Remove a '+' which was needed when the information was formatted for AsciiDoc. Similarly, change "::" to ":". Signed-off-by: Martin Ågren

[PATCH v2 04/10] git.c: let builtins opt for handling `pager.foo` themselves

Before launching a builtin git foo and unless mechanisms with precedence are in use, we check for and handle the `pager.foo` config. This is done without considering exactly how git foo is being used, and indeed, git.c cannot (and should not) know what the arguments to git foo are supposed to

[PATCH v2 00/10] tag: only respect `pager.tag` in list-mode

This is the second version of "[PATCH 0/7] tag: more fine-grained pager-configuration" [1]. That series introduced `pager.tag.list` to address the fact that `pager.tag` can be useful with `git tag -l` but actively hostile with `git tag -a`. Thanks to Junio, Peff and Brandon for helpful feedback.

Re: [PATCH v2 1/1] sha1_file: Add support for downloading blobs on demand

On 7/17/2017 2:06 PM, Jonathan Tan wrote: About the difference between this patch and my patch set [1], besides the fact that this patch does not spawn separate processes for each missing object, which does seem like an improvement to me, this patch (i) does not use a list of promised objects

Re: reftable [v2]: new ref storage format

On Mon, Jul 17, 2017 at 12:04 PM, Shawn Pearce wrote: > A block must have at least one restart in it, the first ref_record > must be a restart. So number_of_restarts in the tail of the block can > be 0, which implies 1 restart (number_of_restarts + 1), and the first >

Re: reftable [v2]: new ref storage format

Shawn Pearce writes: > This is an updated draft after discussion on list with Peff, Michael > Haggerty, and Dave Borowitz. > > You can read a rendered version of this here: > https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md > >

Documentation lingering inconsistency between working directory and working tree

Hi all, I have been reading the git documentation for a while now and came to realize that in a lot of commands the documentation is ambiguous when it comes to the difference between "working directory" and "working tree". I'm aware of the changes to status in this commit for example: commit

[PATCH] check for search permission

--- gitweb/gitweb.perl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 3d4a8ee27c96a..9208f42ed1753 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -3071,6 +3071,8 @@ sub git_get_projects_list { return

Re: [PATCH] RFC: A new type of symbolic refs

On Sun, Jul 16, 2017 at 6:04 AM, Philip Oakley wrote: > > If I understand this correctly, the new type is the 'starts_with(buf, > "repo:"))'. > > It just wasn't obvious from the text that the new type is "repo:" as you > never spell it out in the commit message. Should it

Re: [PATCH/RFC] diff/read-cache: don't assume empty files will filter to empty

Andrei Purdea writes: > diff --git a/read-cache.c b/read-cache.c > index 2121b6e7b..ca306993c 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -262,9 +262,8 @@ static int ce_match_stat_basic(const struct > cache_entry *ce, struct stat *st) > changed |=

Re: reftable [v2]: new ref storage format

On Mon, Jul 17, 2017 at 11:53 AM, Stefan Beller wrote: > On Mon, Jul 17, 2017 at 8:01 AM, Shawn Pearce wrote: > >> A ref block is written as: >> >> 'r' >> uint24 ( block_len ) >> ref_record* >> uint32( restart_offset )* >> uint16(

Re: reftable [v2]: new ref storage format

On Mon, Jul 17, 2017 at 8:01 AM, Shawn Pearce wrote: > A ref block is written as: > > 'r' > uint24 ( block_len ) > ref_record* > uint32( restart_offset )* > uint16( number_of_restarts ) > padding? > ... > > The 2-byte `number_of_restarts + 1` stores

Re: Detect invalid submodule names from script?

Am 17.07.2017 um 19:49 schrieb Stefan Beller: On Mon, Jul 17, 2017 at 4:17 AM, Joachim Durchholz wrote: Hi all I'm hacking some script that calls into git, and I need to detect whether a repository was configured with a submodule name that will work on "git submodule init"

Re: [PATCH v2 1/1] sha1_file: Add support for downloading blobs on demand

About the difference between this patch and my patch set [1], besides the fact that this patch does not spawn separate processes for each missing object, which does seem like an improvement to me, this patch (i) does not use a list of promised objects (but instead communicates with the hook for

Re: [RFC PATCH 0/3] Partial clone: promised blobs (formerly "missing blobs")

Hi Philip, Philip Oakley wrote: > From: "Jonathan Tan" >> These patches are part of a set of patches implementing partial clone, >> as you can see here: >> >> https://github.com/jonathantanmy/git/tree/partialclone [...] > If I understand correctly, this method doesn't

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Ævar Arnfjörð Bjarmason writes: > Let's see what *nix does: > > $ rm -rf /tmp/{master,backup}; mkdir /tmp/master && cd /tmp/master && mv > /tmp/{master,backup} ; file /tmp/{master,backup} > > Similarly to that, when you're on "master" "git branch --move backup" > could

Re: Detect invalid submodule names from script?

On Mon, Jul 17, 2017 at 4:17 AM, Joachim Durchholz wrote: > Hi all > > I'm hacking some script that calls into git, and I need to detect whether a > repository was configured with a submodule name that will work on "git > submodule init" and friends. There is no such a thing

Re: [PATCH 04/33] notes: make get_note return pointer to struct object_id

On 07/15, René Scharfe wrote: > Am 30.05.2017 um 19:30 schrieb Brandon Williams: > > @@ -392,7 +392,7 @@ static int add(int argc, const char **argv, const char > > *prefix) > > const char *object_ref; > > struct notes_tree *t; > > unsigned char object[20], new_note[20]; > > - const

Re: [RFC PATCH 0/3] Partial clone: promised blobs (formerly "missing blobs")

On 7/16/2017 11:23 AM, Philip Oakley wrote: From: "Jonathan Tan" Sent: Tuesday, July 11, 2017 8:48 PM These patches are part of a set of patches implementing partial clone, as you can see here: https://github.com/jonathantanmy/git/tree/partialclone In that branch,

Re: [PATCH] push: disable lazy --force-with-lease by default

Ævar Arnfjörð Bjarmason writes: > Once Francesco's patch is also applied (or some version thereof) you can > then set push.AlwaysForceWithElease to make --force mean > --force-with-lease, which is disabled by default. > > I think this is really crappy UX design. Now in some

Re: [PATCH] check-ref-format: require a repository for --branch

Hi, Jeff King wrote: > On Fri, Jul 14, 2017 at 02:03:13PM -0400, Jeff King wrote: >> So I think the patch below is probably the right direction. > > And here it is with a real commit message, if this is what we want to > do. [...] > --- a/t/t1402-check-ref-format.sh > +++

Re: [PATCH] commit & merge: modularize the empty message validator

Christian Brabandt writes: > On Do, 13 Jul 2017, Junio C Hamano wrote: > >> I think many people know about and do use the "delete all lines" >> (i.e. ":1,$d" in vi, or \M-< \C-SPC \M-> \C-w in Emacs) to abort out >> of a commit or a merge. I just do not think it is likely for

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Jiang Xin writes: > Commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for > timestamps", 2017-04-21) does not play well with i18n framework. The > static string concatenation cannot be correctly interpreted by > gettext utilities, such as xgettext. > > Wrap

Re: [L10N] Kickoff of translation for Git 2.14.0 round 1

Hi, On Mon, 17 Jul 2017, Jiang Xin wrote: > 2017-07-16 3:30 GMT+08:00 Jean-Noël Avila : > > > > > > A few remarks on i18n: > > > > * commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for > > timestamps") does not play well with i18n framework. The static string > >

Re: [L10N] af.po: New translation workflow

2017-07-17 1:37 GMT+08:00 Jacques Viviers : > Hi all, > > I have started a new translation af.po at: > (https://github.com/jbviviers/git-po) > > The translation is far from complete. Should I wait until it is all > done before I submit the patch, or is it better to

[PATCH] doc: camelCase the i18n config variables to improve readability

The i18n config variable used weren't readable as they were in the crude form of how git stores/uses it's config variables. Improve it's readability by replacing them with camelCased versions of config variables as it doesn't have any impact on it's usage. Signed-off-by: Kaartic Sivaraam

[PATCH] doc: reformat the paragraph containing the 'cut-line'

The paragraph that describes the 'scissors' cleanup mode of 'commit' had the 'cut-line' in the middle of a sentence. This made it possible for the line to get wrapped on smaler windows. This shouldn't be the case as it makes it hard for the user to understand the structure of the cut-line.

[PATCH] commit: check for empty message before the check for untouched template

The check for whether the template given to 'git commit' is untouched is done before the empty message check. This results in a wrong error message being displayed in the following case. When the user removes everything in template completely to abort the commit he is shown the "template

[PATCH] PRItime: wrap PRItime for better l10n compatibility

Commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for timestamps", 2017-04-21) does not play well with i18n framework. The static string concatenation cannot be correctly interpreted by gettext utilities, such as xgettext. Wrap PRItime in format_raw_time() function, so that we can

reftable [v2]: new ref storage format

This is an updated draft after discussion on list with Peff, Michael Haggerty, and Dave Borowitz. You can read a rendered version of this here: https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md Biggest changes from the first proposal are: - reflog is now

Detect invalid submodule names from script?

Hi all I'm hacking some script that calls into git, and I need to detect whether a repository was configured with a submodule name that will work on "git submodule init" and friends. I *can* run a git init and see whether it works, but I need to be 100% sure that the error was due to an

Re: [PATCH] commit & merge: modularize the empty message validator

On Do, 13 Jul 2017, Junio C Hamano wrote: > I think many people know about and do use the "delete all lines" > (i.e. ":1,$d" in vi, or \M-< \C-SPC \M-> \C-w in Emacs) to abort out > of a commit or a merge. I just do not think it is likely for them > to leave Sign-off lines and remove everything

Re: Proposal

Hello, Compliment of the day to you. I am Mrs. Elodie, I am sending this brief letter to solicit your partnership to transfer $5.5 million US Dollars into your account for investment in your country. I shall send you more information and procedures when I receive positive response from you.

Can You Handle This For Me ?

Hello Friend, Greetings to you. I know that this message might come to you as surprise because we don't know each other nor have we ever met before but accept it with an open heart I'm Mrs. Suzan Permintel and I have been suffering from ovarian cancer disease and the doctor says that I have

Draft of Git Rev News edition 29

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-29.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub