Re: [PATCH] Falis on commit --amend when already pushed

Tomohiro Koana writes: > Hello all, > > I'm a third year student at the University of Tokyo and, in our > "Diving into open-source software" class, my friends and I decided to > work with git. Our final, hopefully, is contributing to git. Welcome on board :-). I give the same class to my student

[PATCH] Falis on commit --amend when already pushed

Hello all, I'm a third year student at the University of Tokyo and, in our "Diving into open-source software" class, my friends and I decided to work with git. Our final, hopefully, is contributing to git. One improvement that we thought of was not letting users to amend commit when the commit is

Re: [PATCH v3] merge: fix cache_entry use-after-free

Am 15.10.2015 um 00:07 schrieb David Turner: From: Keith McGuigan During merges, we would previously free entries that we no longer need in the destination index. But those entries might also be stored in the dir_entry cache, and when a later call to add_to_index found them, they would be used

Captain Kelvin Ken Miller

Am Captain Kelvin Ken Miller i am with the us army in Camp Abu Naji / FOB Garry Owen (Al Amarah)I need you assistant to move some funds out of Iraq. Kindly respond for more details. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel

Re: Alternative to manual editing with git add --patch

Am 14.10.2015 um 19:50 schrieb Junio C Hamano: > Sven Helmberger writes: > > As a quick-and-dirty change, you could invent a new variant of > 's'plit that breaks a N-line hunk into N hunks with 1-line each, but > obviously that would not be a pleasant-enough UI to be called usable > when you have

Re: [PATCH v2 21/31] mailinfo: move [ps]_hdr_data to struct mailinfo

Junio C Hamano writes: > @@ -995,10 +995,10 @@ static int mailinfo(struct mailinfo *mi, const char > *msg, const char *patch) > > /* process the email header */ > while (read_one_header_line(&line, mi->input)) > - check_header(mi, &line, p_hdr_data, 1); > +

Re: [PATCH v2 20/31] mailinfo: move cmitmsg and patchfile to struct mailinfo

This step does not compile correctly; will be fixed in v3. -- 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 v3 1/3] Add Travis CI support

On 12 Oct 2015, at 22:20, Matthieu Moy wrote: > larsxschnei...@gmail.com writes: > >> --- /dev/null >> +++ b/.travis.yml >> @@ -0,0 +1,46 @@ >> +language: c >> + >> +os: >> + - linux >> + - osx >> + >> +compiler: >> + - clang >> + - gcc >> + >> +before_install: >> + - > >> +export GIT_

What's cooking in git.git (Oct 2015, #03; Wed, 14)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. With somewhat reduced review bandwidth, I'd expect that the upcoming cycle would be slower than usual. At tinyurl.com/gitCal, I tentatively dre

[PATCH v3] merge: fix cache_entry use-after-free

From: Keith McGuigan During merges, we would previously free entries that we no longer need in the destination index. But those entries might also be stored in the dir_entry cache, and when a later call to add_to_index found them, they would be used after being freed. To prevent this, add a ref

Re: [PATCH v2] merge: fix cache_entry use-after-free

On Wed, 2015-10-14 at 14:17 -0700, Junio C Hamano wrote: > David Turner writes: > > > + unsigned int ref_count; /* count the number of refs to this in dir_hash > > */ > > Me makes a mental note of the type used... > > > @@ -213,6 +214,32 @@ struct cache_entry { > > struct pathspec; > > >

Re: [PATCH] Tracing commands includes its working directory

Stefan Beller writes: > Specially when having concurrent flows of command execution, > the order of commands printed cannot be relied upon. To aid > the poor developer follow the flow of commands include the > current working directory in which the command is carried out. > > Signed-off-by: Stefa

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > Junio C Hamano writes: > >> Matthieu Moy writes: >> >>> Looks good to me. I think the same should be added to git-prune.txt >>> under --expire. >> >> I thought about it, but decided against it, as the command is not >> even recommended to end users. > > Even non-"end user

[PATCH] Tracing commands includes its working directory

Specially when having concurrent flows of command execution, the order of commands printed cannot be relied upon. To aid the poor developer follow the flow of commands include the current working directory in which the command is carried out. Signed-off-by: Stefan Beller --- exec_cmd.c| 2 +-

Re: [PATCH v2] merge: fix cache_entry use-after-free

David Turner writes: > + unsigned int ref_count; /* count the number of refs to this in dir_hash > */ Me makes a mental note of the type used... > @@ -213,6 +214,32 @@ struct cache_entry { > struct pathspec; > > /* > + * Increment the cache_entry reference count. Should be called > +

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > Matthieu Moy writes: > >> Looks good to me. I think the same should be added to git-prune.txt >> under --expire. > > I thought about it, but decided against it, as the command is not > even recommended to end users. Even non-"end users" can shoot themselves in the foot.

[PATCH v2 04/31] mailinfo: fold decode_header_bq() into decode_header()

In olden days we might have wanted to behave differently in decode_header() if the header line was encoded with RFC2047, but we apparently do not do so, hence this helper function can go, together with its return value. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 23 +++---

[PATCH v2 23/31] mailinfo: move content/content_top to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 45 ++--- 1 file changed, 26 insertions(+), 19 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 72668c9..138ca3b 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -7,6

[PATCH v2 07/31] mailinfo: always pass "line" as an argument

Some functions in this module accessed the global "struct strbuf line" while many others used a strbuf passed as an argument. Convert the former to ensure that nobody deeper in the callchains relies on the global one. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 48

[PATCH v2 19/31] mailinfo: handle_commit_msg() shouldn't be called after finding patchbreak

There is a strange "if (!cmitmsg) return 0" at the very beginning of handle_commit_msg(), but the condition should never trigger, because: * The only place cmitmsg is set to NULL is after this function sees a patch break, closes the FILE * to write the commit log message and returns 1. Thi

[PATCH v2 20/31] mailinfo: move cmitmsg and patchfile to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index f48a260..5809e13 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -7,11 +7,11 @@ #inclu

[PATCH v2 00/31] libify mailinfo and call it directly from am

During the discussion on the recent "git am" regression, I noticed that the command reimplemented in C spawns one "mailsplit" and then spawns "mailinfo" followed by "apply --index" to commit the changes described in each message. As there are platforms where spawning subprocess via run_command() i

[PATCH v2 02/31] mailinfo: fix for off-by-one error in boundary stack

We pre-increment the pointer that we will use to store something at, so the pointer is already beyond the end of the array if it points at content[MAX_BOUNDARIES]. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/mai

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > Looks good to me. I think the same should be added to git-prune.txt > under --expire. I thought about it, but decided against it, as the command is not even recommended to end users. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message

[PATCH v2 01/31] mailinfo: remove a no-op call convert_to_utf8(it, "")

The called function checks if the second parameter is either a NULL or an empty string at the very beginning and returns without doing anything. Remove the useless call. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 5 - 1 file changed, 5 deletions(-) diff --git a/builtin/mailinfo

[PATCH v2 21/31] mailinfo: move [ps]_hdr_data to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 5809e13..aa17c77 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -30,10 +30,10 @@ str

[PATCH v2 18/31] mailinfo: move charset to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 140b31ee..41f659d 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -22,6 +22,7 @@ struct mailinfo {

[PATCH v2 05/31] mailinfo: move handle_boundary() lower

This function wants to call find_boundary() and is called only from one place without any recursing, so it becomes easier to read if it appears after the called function. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 114 ++--- 1 file chan

[PATCH v2 24/31] mailinfo: move read_one_header_line() closer to its callers

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 132 ++--- 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 138ca3b..0b083d0 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c

[PATCH v2 06/31] mailinfo: get rid of function-local static states

Two helper functions use "static int" in their scope to keep track of the state while repeatedly getting called once for each input line. Move these state variables their ultimate caller and pass down pointers to them, as a small step in preparation for making this entire callchain more reentrant.

[PATCH v2 27/31] mailinfo: move definition of MAX_HDR_PARSED to closer to its use

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index f4771ee..de446ec 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -39,8 +39,6 @@ struct mailinfo { struct str

[PATCH v2 10/31] mailinfo: move keep_subject & keep_non_patch_bracket to struct mailinfo

These two are the only easy ones that do not require passing the structure around to deep corners of the callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c in

[PATCH v2 22/31] mailinfo: keep the parsed log message in a strbuf

When mailinfo() is eventually libified, the calling "git am" still will have to write out the log message in the "msg" file for hooks and other users of the information, but at least it does not have to reopen and reread what was written back if the function kept it in a strbuf so that the caller c

[PATCH v2 30/31] mailinfo: remove calls to exit() and die() deep in the callchain

The top-level mailinfo() would instead punt when the code in the deeper part of the callchain detects an unrecoverable error in the input. Signed-off-by: Junio C Hamano --- mailinfo.c | 30 ++ mailinfo.h | 1 + 2 files changed, 23 insertions(+), 8 deletions(-) diff

[PATCH v2 25/31] mailinfo: move check_header() after the helpers it uses

This way, we can lose a forward decl for decode_header(). Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 139 ++--- 1 file changed, 69 insertions(+), 70 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 0b083d0..ee669

[PATCH v2 31/31] am: make direct call to mailinfo

And finally the endgame. Instead of spawning "git mailinfo" via the run_command() API the same number of times as there are incoming patches, make direct internal call to the libified mailinfo() from "git am" to reduce the spawning overhead, which would matter on some platforms. Signed-off-by: Ju

[PATCH v2 14/31] mailinfo: move add_message_id and message_id to struct mailinfo

This requires us to pass the structure into check_header() codepath. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index f451ba4..6703453 100644 ---

[PATCH v2 17/31] mailinfo: move transfer_encoding to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 00b8b4b..140b31ee 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -23,14 +23,14 @@ struc

[PATCH v2 12/31] mailinfo: move filter/header stage to struct mailinfo

Earlier we got rid of two function-scope static variables that kept track of the states of helper functions by making them extra arguments that are passed throughout the callchain. Now we have a convenient place to store and pass them around in the form of "struct mailinfo", change them into two f

[PATCH v2 28/31] mailinfo: libify

Move the bulk of the code from builtin/mailinfo.c to mailinfo.c so that new callers can start calling mailinfo() directly. Note that a few calls to exit() and die() need to be cleaned up for the API to be truly useful, which will come in later steps. Signed-off-by: Junio C Hamano --- Makefile

[PATCH v2 26/31] mailinfo: move cleanup_space() before its users

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index ee669b9..f4771ee 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -41,8 +41,17 @@ struct ma

[PATCH v2 15/31] mailinfo: move use_scissors and use_inbody_headers to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 6703453..80034a2 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -20,6 +20,8 @@ struct maili

[PATCH v2 11/31] mailinfo: move global "FILE *fin, *fout" to struct mailinfo

This requires us to pass "struct mailinfo" to more functions throughout the codepath that read input lines, which makes later steps easier. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 54 -- 1 file changed, 28 insertions(+), 26 delet

[PATCH v2 09/31] mailinfo: introduce "struct mailinfo" to hold globals

Initially have only 'email' and 'name' fields in there and remove the corresponding globals. In subsequent patches, more globals will be moved to this and the structure will be passed around as a new parameter to more functions. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 61

[PATCH v2 08/31] mailinfo: move global "line" into mailinfo() function

With the pregvious step, it becomes clear that the mailinfo() function is the only one that wants the "line_global" to be directly touchable. Logically, this strbuf belongs to handle_body(). It passes the line to its helper functions for processing, and keeps one line at a time into the variable

[PATCH v2 29/31] mailinfo: handle charset conversion errors in the caller

Instead of dying in convert_to_utf8(), just report an error and let the callers handle it. Between the two callers: - decode_header() silently punts when it cannot parse a broken RFC2047 encoded text (e.g. when it sees anything other than B or Q after it sees "=?") by jumping to release_re

[PATCH v2 13/31] mailinfo: move patch_lines to struct mailinfo

This one is trivial thanks to previous steps that started passing the structure throughout the input codepaths. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 5d2d88

[PATCH v2 16/31] mailinfo: move metainfo_charset to struct mailinfo

This requires us to pass the struct down to decode_header() and convert_to_utf8() callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c

[PATCH v2 03/31] mailinfo: explicitly close file handle to the patch output

This does not make a difference within the context of "git mailinfo" that runs once and exits, as flushing and closing would happen upon process completion. It however will matter when we eventually make this function callable as an API function. Besides, cleaning after yourself once you are done

Re: [PATCH 02/26] mailinfo: fix for off-by-one error in boundary stack

I'll be sending out v2 very soon, so you might want to hold off for a few minutes. -- 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 07/26] mailinfo: move global "line" into mailinfo() function

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > The mailinfo() function is the only one that wants the "line_global" > to be directly touchable. Note that handle_body() has to be passed > this strbuf so that it sees the "first line of the input" after the > loop in this function processe

Re: [PATCH 06/26] mailinfo: always pass "line" as an argument

Stefan Beller writes: >> @@ -1019,10 +1019,10 @@ static int mailinfo(FILE *in, FILE *out, const char >> *msg, const char *patch) >> ungetc(peek, in); >> >> /* process the email header */ >> - while (read_one_header_line(&line, fin)) >> - check_header(&line, p_

Re: [PATCH 06/26] mailinfo: always pass "line" as an argument

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > Some functions in this module accessed the global "struct strbuf > line" while many others used a strbuf passed as an argument. > Convert the former to ensure that nobody deeper in the callchains > relies on the global one. > > Signed-off-by

Re: [PATCH 02/26] mailinfo: fix for off-by-one error in boundary stack

On Tue, Oct 13, 2015 at 4:16 PM, Junio C Hamano wrote: > We pre-increment the pointer that we will use to store something at, > so the pointer is already beyond the end of the array if it points > at content[MAX_BOUNDARIES]. > > Signed-off-by: Junio C Hamano > --- > > As always, I am very bad at

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > Matthieu Moy writes: > >> This looks like a race between deleting objects/05/ and creating >> objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed. >> >> I don't understand how this is possible, since the temporary file and >> the final one are in the same directory, so del

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > This looks like a race between deleting objects/05/ and creating > objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed. > > I don't understand how this is possible, since the temporary file and > the final one are in the same directory, so deleting the directory > should fail

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Jan Smets writes: > 2) > > remote: error: unable to write sha1 filename > objects/05/cdb51bb0ea3e229734a4b1bddd5ec70fbc65ed: No such file or > directory > remote: fatal: failed to write object If I read correctly, this happens when we move the temp file to its permanent position. This looks lik

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Junio C Hamano writes: > diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt > index 5223498..fa15104 100644 > --- a/Documentation/git-gc.txt > +++ b/Documentation/git-gc.txt > @@ -63,8 +63,11 @@ automatic consolidation of packs. > --prune=:: > Prune loose objects older than d

Re: Alternative to manual editing with git add --patch

Sven Helmberger writes: > I hope this hasn't been discussed before. > > I'm a big fan of cleanliness in commits and therefore often use git add > --patch to sort code changes I made into the right commits etc. > > What I then often encountered was the situation where I happened to have > inserted

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Matthieu Moy writes: > I think this is the expected behavior. push will create new objects that > are not referenced until the ref is updated (at the very end). prune can > run concurrently since creating and deleting objects is done in a > lockless way (only the ref update needs a lock). > > Sti

[PATCH 1/2] contrib: Add git-candidate subcommand

git-candidate provides candidate review and patch tracking, allowing distributed comment and review facilities with all content stored in git. Signed-off-by: Richard Ipsum --- contrib/git-candidate/GitUtils.pm| 215 +++ contrib/git-candidate/git-candidate.perl | 2602 +++

[PATCH 2/2] contrib/git-candidate: Add README

Describes motivation for git-candidate and shows an example workflow. Signed-off-by: Richard Ipsum --- contrib/git-candidate/README.md | 153 1 file changed, 153 insertions(+) create mode 100644 contrib/git-candidate/README.md diff --git a/contrib/git-c

[RFC] Git based patch tracking and review

Hi, I've been working to add patch tracking and candidate review to git. The motivation for this is simply that most patch tracking systems are centralised, since git is a distributed vcs it seems appropriate that patches, reviews and comments should also be distributed. The system aims to be fai

Re: Alternative to manual editing with git add --patch

Hi Sven, On 2015-10-14 17:07, Sven Helmberger wrote: > What I then often encountered was the situation where I happened to have > inserted consecutive lines of code that conceptually belong to different > commits. Normally I can nicely split patches, but not in this case, > making manually editin

Re: Alternative to manual editing with git add --patch

Sven Helmberger writes: > Hello, > > I hope this hasn't been discussed before. > > I'm a big fan of cleanliness in commits and therefore often use git add > --patch to sort code changes I made into the right commits etc. > > What I then often encountered was the situation where I happened to have

Alternative to manual editing with git add --patch

Hello, I hope this hasn't been discussed before. I'm a big fan of cleanliness in commits and therefore often use git add --patch to sort code changes I made into the right commits etc. What I then often encountered was the situation where I happened to have inserted consecutive lines of code tha

Re: repository corruption when pushing commits to a repository running 'git gc --prune='

Jan Smets writes: > Hi > > I've recently expired my reflog to prune loose objects. On a live, > bare, repository I ran 'git gc --prune=now' > > All clients ended up having problems, they would report: > error: refs/heads/master does not point to a valid object! > Running 'git log' on the bare re

Re: [BUG] Broken links in Git Documentation/user-manual.txt

John Keeping writes: > On Wed, Oct 14, 2015 at 09:37:05AM +0200, Matthieu Moy wrote: >> Xue Fuqiao writes: >> >> > Hi list, >> > >> > In https://git-scm.com/docs/user-manual.html , all links to the >> > glossary[1] are broken. >> >> Actually, the links themselves are fine, but the destimation

repository corruption when pushing commits to a repository running 'git gc --prune='

Hi I've recently expired my reflog to prune loose objects. On a live, bare, repository I ran 'git gc --prune=now' All clients ended up having problems, they would report: error: refs/heads/master does not point to a valid object! Running 'git log' on the bare repo gave : fatal: bad object HEA

Re: [BUG] Broken links in Git Documentation/user-manual.txt

On Wed, Oct 14, 2015 at 09:37:05AM +0200, Matthieu Moy wrote: > Xue Fuqiao writes: > > > Hi list, > > > > In https://git-scm.com/docs/user-manual.html , all links to the > > glossary[1] are broken. > > Actually, the links themselves are fine, but the destimation is broken. > > The doc is suppos

[Bug?] .git visible in git-status

I've recently stumbled upon interesting issue - .git/* files occurring in the git-status output. Let me elaborate: 1. When running > git status -s no .git/* files are displayed 2. When running: > git status -s .git only an empty line is printed out 3. But when I run (for example): > git status -s .

[PATCH v2] git-gui: Update Russian translation

>This section seems wrong as it replaces the existing copyright notice >with some auto-generated junk. As it is a translation I should think the >copyright is with the translators but it should not be using default >placeholders. Sorry for that. It seems that a Transifex bug, I uploaded po with cop

RE: thread-utils: build with NO_PTHREADS fails

Hello Junio, sorry that was my fault, I was building it wrong way (defined NO_PTHREADS in CFLAGS variable, not as separate make variable). Sorry for the false alarm. -- Best Regards, Victor From: Junio C Hamano [jch2...@gmail.com] On Behalf Of Junio C Ha

Re: [PATCH] git-gui: Update Russian translation

Dimitriy Ryazantcev writes: >Signed-off-by: Dimitriy Ryazantcev >--- > po/ru.po | 675 +++ > 1 file changed, 247 insertions(+), 428 deletions(-) > >diff --git a/po/ru.po b/po/ru.po >index ca4343b..8ebc98f 100644 >--- a/po/ru.po >+++ b/po

[ANNOUNCE] Git Rev News edition 8

Hi everyone, I'm happy announce that the 8th edition of Git Rev News is now published: https://git.github.io/rev_news/2015/10/14/edition-8/ Thanks a lot to all the contributors! Enjoy, Christian, Thomas and Nicola. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of

Re: [PATCH 1/1] send-email: allow to compose only prepared cover letter

On Tue, 2015-10-13 at 14:11 -0700, Junio C Hamano wrote: > Andy Shevchenko writes: > > > My often use case is to do: > > % git format-patch --cover-letter --subject-prefix="PATCH > > vN" rev1^..revXYZ > > % $GIT_EDITOR -* > > % git send-email 00* # assumes series less than 100 >

Captain Kelvin Ken Miller

Am Captain Kelvin Ken Miller currently I need you assistant to move some funds out of Iraq. Kindly respond for more details. -- 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/majord

Re: [BUG] Broken links in Git Documentation/user-manual.txt

Xue Fuqiao writes: > Hi list, > > In https://git-scm.com/docs/user-manual.html , all links to the > glossary[1] are broken. Actually, the links themselves are fine, but the destimation is broken. The doc is supposed to look like this : https://www.kernel.org/pub/software/scm/git/docs/user-ma