[PATCH 2/3] subtree: fix "git subtree split --rejoin"

"git merge" in v2.9 prevents merging unrelated histories. "git subtree split --rejoin" creates unrelated histories when creating a split repo from a raw sub-directory that did not originate from an invocation of "git subtree add". Restore the original behavior by passing

[PATCH 1/3] t7900-subtree.sh: fix quoting and broken && chains

Allow whitespace in arguments to subtree_test_create_repo. Add missing && chains. Signed-off-by: David Aguilar --- contrib/subtree/t/t7900-subtree.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/contrib/subtree/t/t7900-subtree.sh

[PATCH 3/3] subtree: adjust style to match CodingGuidelines

Prefer "test" over "[ ... ]", use double-quotes around variables, break long lines, and properly indent "case" statements. Signed-off-by: David Aguilar --- contrib/subtree/git-subtree.sh | 544 ++--- 1 file changed, 341 insertions(+), 203

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On 07/25/2016 06:53 PM, Junio C Hamano wrote: Pranit Bauva writes: >>> +enum terms_defined { >>> + TERM_BAD = 1, >>> + TERM_GOOD = 2, >>> + TERM_NEW = 4, >>> + TERM_OLD = 8 >>> +}; >>> + >> >> What does TERM stand for ? The terms (words)

[Bug] [Git Gui] git-gui commit gpg signing problem

It seems that git gui does not adhere to the config settings git config commit.gpgsign true git config --global user.signingkey Commits done through git gui are not signed while done through cli they are signed Peter van der Does -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v4 1/4] worktree: add per-worktree config files

On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy wrote: > A new repo extension is added, worktreeConfig. When it is present: > > - Repository config reading by default includes $GIT_DIR/config _and_ >$GIT_DIR/config.worktree. "config" file remains shared in multiple

Re: [PATCH] Documentation, git submodule: Note about --reference

On Mon, Jul 25, 2016 at 5:43 PM, Junio C Hamano wrote: > On Mon, Jul 25, 2016 at 5:38 PM, Stefan Beller wrote: >> On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote: >>> Signed-off-by: Stefan Beller >>> --- >> >>

Re: [PATCH] Documentation, git submodule: Note about --reference

On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote: > Signed-off-by: Stefan Beller > --- Any comment here? > > Is it too obvious? > I was approached off list and this was only obvious after some discussion, > so I think it is a valid warning. > >

Re: [PATCH] Documentation, git submodule: Note about --reference

On Mon, Jul 25, 2016 at 5:38 PM, Stefan Beller wrote: > On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote: >> Signed-off-by: Stefan Beller >> --- > > Any comment here? I personally found it Meh in the sense that those who read and

[PATCH]submodule deinit: remove outdated comment

Signed-off-by: Stefan Beller --- This is logically part of origin/sb/submodule-deinit-all, but this change failed to be there on time. As I am touching code in the near vincinity, I noticed. I do not include this in that series to come as I want to keep that

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Fri, Jul 22, 2016 at 10:42 AM, Duy Nguyen wrote: > On Fri, Jul 22, 2016 at 7:25 PM, Stefan Beller wrote: >> On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote: >>> >>> I just quickly glanced through the rest of this mail because, as a

What's cooking in git.git (Jul 2016, #07; Mon, 25)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [PATCH v2 7/8] status: update git-status.txt for --porcelain=v2

W dniu 2016-07-25 o 21:25, Jeff Hostetler pisze: > +Porcelain Format Version 2 > +~~ > + > +Version 2 format adds more detailed information about the state of > +the worktree and the changed items. I think it should be "and changed items", but I am not a native speaker.

Re: [PATCH v4 02/16] Report bugs consistently

Jeff King writes: > On Mon, Jul 25, 2016 at 02:44:25PM -0700, Junio C Hamano wrote: > >> > diff --git a/imap-send.c b/imap-send.c >> > index db0fafe..67d67f8 100644 >> > --- a/imap-send.c >> > +++ b/imap-send.c >> > @@ -506,12 +506,12 @@ static char *next_arg(char **s) >> > >> >

Re: [PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

John Keeping writes: > Allow the empty string to stand in for the null SHA-1 when pushing a new > branch, like we do when deleting branches. > > This means that the following command ensures that `new-branch` is > created on the remote (that is, is must not already exist): >

Re: Client exit whilst running pre-receive hook : commit accepted but no post-receive hook ran

On Mon, Jul 25, 2016 at 12:34:04PM +0200, Jan Smets wrote: > I have always assumed the post-receive hook to be executed whenever a commit > is "accepted" by the (gitolite) server. That does not seem to be true any > more. Generally, yeah, I would expect that to be the case, too. > Since 9658846

Re: [PATCH v2 0/3] push: allow pushing new branches with --force-with-lease

John Keeping writes: > On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote: >> John Keeping writes: >> >> > If there is no upstream information for a branch, it is likely that it >> > is newly created and can safely be pushed under the normal

Re: [PATCH v4 11/16] am -3: use merge_recursive() directly again

Johannes Schindelin writes: > Note: the code now calls merge_recursive_generic() again. Unlike > merge_trees() and merge_recursive(), this function returns 0 upon success, > as most of Git's functions. Therefore, the error value -1 naturally is > handled correctly,

Re: [PATCH v4 02/16] Report bugs consistently

On Mon, Jul 25, 2016 at 02:44:25PM -0700, Junio C Hamano wrote: > > diff --git a/imap-send.c b/imap-send.c > > index db0fafe..67d67f8 100644 > > --- a/imap-send.c > > +++ b/imap-send.c > > @@ -506,12 +506,12 @@ static char *next_arg(char **s) > > > > static int nfsnprintf(char *buf, int blen,

Re: [PATCH] push: allow pushing new branches with --force-with-lease

Junio C Hamano writes: > I suspect that the if/else cascade in the loop in apply_cas() can > also be taught that ':' followed by an empty string asks to check > that the target ref does not exist, in order to make it a bit more > useful for folks who do not rely on the "use

Re: [PATCH 1/2] pack-objects: break out of want_object loop early

On Mon, Jul 25, 2016 at 02:52:24PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > if (!*found_pack) { > > ... first find! fill in found pack, etc ... > > } > > if (exclude) > > return 1; > > if (incremental) > > return 0; > > if (!ignore_packed_keep

Re: [PATCH v4 06/16] merge_recursive: abort properly upon errors

Johannes Schindelin writes: > There are a couple of places where return values indicating errors > are ignored. Let's teach them manners. That is because the return value never indicated errors before this series, isn't it? A true error used to be expressed by

Re: [PATCH 1/2] pack-objects: break out of want_object loop early

On Mon, Jul 25, 2016 at 12:56:23PM -0700, Junio C Hamano wrote: > > This function loops through each existing packfile, looking > > for the object. When we find it, we mark the pack/offset > > combo for later use. However, we can't just return "yes, we > > want it" at that point. If

[PATCH v2 0/3] push: allow pushing new branches with --force-with-lease

On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote: > John Keeping writes: > > > If there is no upstream information for a branch, it is likely that it > > is newly created and can safely be pushed under the normal fast-forward > > rules. Relax the

[PATCH v2 1/3] Documentation/git-push: fix placeholder formatting

Format the placeholder as monospace to match other occurrences in this file and obey CodingGuidelines. Signed-off-by: John Keeping --- New in v2. Documentation/git-push.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-push.txt

[PATCH v2 2/3] push: add shorthand for --force-with-lease branch creation

Allow the empty string to stand in for the null SHA-1 when pushing a new branch, like we do when deleting branches. This means that the following command ensures that `new-branch` is created on the remote (that is, is must not already exist): git push --force-with-lease=new-branch:

[PATCH v2 3/3] push: allow pushing new branches with --force-with-lease

If there is no upstream information for a branch, it is likely that it is newly created and can safely be pushed under the normal fast-forward rules. Relax the --force-with-lease check so that we do not reject these branches immediately but rather attempt to push them as new branches, using the

Re: [PATCH 1/2] pack-objects: break out of want_object loop early

Jeff King writes: > if (!*found_pack) { > ... first find! fill in found pack, etc ... > } > if (exclude) > return 1; > if (incremental) > return 0; > if (!ignore_packed_keep && !local) > break; /* effectively return 1, but I think the break is more

Re: [PATCH v4 02/16] Report bugs consistently

Johannes Schindelin writes: > diff --git a/imap-send.c b/imap-send.c > index db0fafe..67d67f8 100644 > --- a/imap-send.c > +++ b/imap-send.c > @@ -506,12 +506,12 @@ static char *next_arg(char **s) > > static int nfsnprintf(char *buf, int blen, const char *fmt, ...)

Re: [PATCH v4 01/16] Verify that `git pull --rebase` shows the helpful advice when failing

Johannes Schindelin writes: > +test_expect_success '--rebase with conflicts shows advice' ' > + test_when_finished "git rebase --abort; git checkout -f to-rebase" && > + git checkout -b seq && > + printf "1\\n2\\n3\\n4\\n5\\n" >seq.txt && Make this more

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

On Mon, Jul 25, 2016 at 6:53 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >>> And why are the defines 1,2,4,8 ? >>> It looks as if a #define bitmap may be a better choice here ? >>> How do we do these kind of bit-wise opions otherwise ? > > We

Re: [RFC/PATCH 0/8] Add configuration options for split-index

On Mon, Jul 25, 2016 at 6:04 PM, Duy Nguyen wrote: > > Hmm.. can you do the counting separately? A shared cache_entry must > have its field "index" greater than zero. By counting the number of > entries whose index is zero (i.e. not shared) against the total number > of real

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

Junio C Hamano wrote: > Eric Wong writes: > > >> Also, doesn't it break "git rebase" (non-interactive), or anything > >> that internally runs format-patch to individual files and then runs > >> am on each of them, anything that knows that each output file from

Re: [PATCH] config.mak.uname: correct perl path on FreeBSD

Eric Wong writes: > Junio C Hamano wrote: >> Duy Nguyen writes: >> >> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote: >> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy >> >>

Re: [PATCH] config.mak.uname: correct perl path on FreeBSD

Junio C Hamano wrote: > Duy Nguyen writes: > > > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote: > >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy > >> wrote: > >>> It looks the the symlink

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 25 Jul 2016, at 01:22, Jakub Narębski wrote: > W dniu 2016-07-25 o 00:36, Ramsay Jones pisze: >> On 24/07/16 18:16, Lars Schneider wrote: >>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote: On 22/07/16 16:49, larsxschnei...@gmail.com wrote:

Re: [PATCH v2 6/8] status: print branch info with --porcelain=v2 --branch

Jeff Hostetler writes: > /* > + * Print branch and tracking header for porcelain v2 output. > + * This is printed when the '--branch' parameter is given. > + * > + *"## branch: [ [ + -]]" Just FYI, the only reason why the original "short" output gives this

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 25 Jul 2016, at 00:36, Ramsay Jones wrote: > On 24/07/16 18:16, Lars Schneider wrote: >> >> On 23 Jul 2016, at 01:19, Ramsay Jones wrote: >> >>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote: From: Lars Schneider

Re: [PATCH v2 5/8] status: print per-file porcelain v2 status data

Jeff Hostetler writes: > +static void wt_porcelain_v2_print(struct wt_status *s); > + There is no point in this forward declaration, if you just place the implementation of these functions here, no? > +/* > + * Print porcelain v2 info for tracked entries with changes. >

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 24 Jul 2016, at 23:30, Jakub Narębski wrote: > W dniu 2016-07-24 o 22:14, Jakub Narębski pisze: >> W dniu 2016-07-24 o 20:36, Lars Schneider pisze: > >>> I agree that the name is not ideal. "UseProtocol" as it is would be a >>> boolean. >>> I thought about "persistent"

Re: [PATCH v2 4/8] status: per-file data collection for --porcelain=v2

Jeff Hostetler writes: > +static void aux_updated_entry_porcelain_v2( > + struct wt_status *s, > + struct wt_status_change_data *d, > + struct diff_filepair *p) > +{ > + switch (p->status) { > + case DIFF_STATUS_ADDED: > + /*

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 24 Jul 2016, at 22:14, Jakub Narębski wrote: > W dniu 2016-07-24 o 20:36, Lars Schneider pisze: >> On 23 Jul 2016, at 02:11, Jakub Narębski wrote: >>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze: From: Lars Schneider

Re: [PATCH v2 2/8] status: cleanup API to wt_status_print

Jeff Hostetler writes: > Refactor the API between builtin/commit.c and wt-status.[ch]. > Hide details of the various wt_*status_print() routines inside > wt-status.c behind a single (new) wt_status_print() routine > and eliminate the switch statements from

Re: [PATCH 1/2] pack-objects: break out of want_object loop early

Jeff King writes: > When pack-objects collects the list of objects to pack > (either from stdin, or via its internal rev-list), it > filters each one through want_object_in_pack(). > > This function loops through each existing packfile, looking > for the object. When we find it,

Re: [PATCH v2 3/8] status: support --porcelain[=]

W dniu 2016-07-25 o 21:25, Jeff Hostetler pisze: > --- a/builtin/commit.c > +++ b/builtin/commit.c > @@ -144,6 +144,21 @@ static struct strbuf message = STRBUF_INIT; > > static enum wt_status_format status_format = STATUS_FORMAT_UNSPECIFIED; > > +static int opt_parse_porcelain(const struct

[PATCH v2 2/8] status: cleanup API to wt_status_print

Refactor the API between builtin/commit.c and wt-status.[ch]. Hide details of the various wt_*status_print() routines inside wt-status.c behind a single (new) wt_status_print() routine and eliminate the switch statements from builtin/commit.c This will allow us to more easily add new status

[PATCH v2 3/8] status: support --porcelain[=]

Update --porcelain argument to take optional version parameter to allow multiple porcelain formats to be supported in the future. The token "v1" is the default value and indicates the traditional porcelain format. Signed-off-by: Jeff Hostetler ---

[PATCH v2 8/8] status: tests for --porcelain=v2

Unit tests for porcelain v2 status format. Signed-off-by: Jeff Hostetler --- t/t7064-wtstatus-pv2.sh | 542 1 file changed, 542 insertions(+) create mode 100755 t/t7064-wtstatus-pv2.sh diff --git

[PATCH v2 5/8] status: print per-file porcelain v2 status data

Print per-file information in porcelain v2 format. Signed-off-by: Jeff Hostetler --- wt-status.c | 285 +++- 1 file changed, 284 insertions(+), 1 deletion(-) diff --git a/wt-status.c b/wt-status.c index

[PATCH v2 1/8] status: rename long-format print routines

Renamed the various wt_status_print*() routines to be wt_longstatus_print*() to make it clear that these routines are only concerned with the normal/long status output. This will hopefully reduce confusion as other status formats are added in the future. Signed-off-by: Jeff Hostetler

[PATCH v2 6/8] status: print branch info with --porcelain=v2 --branch

Expand porcelain v2 output to include branch and tracking branch information. This includes the commit SHA, the branch, the upstream branch, and the ahead and behind counts. Signed-off-by: Jeff Hostetler --- builtin/commit.c | 5 wt-status.c | 86

[PATCH v2 4/8] status: per-file data collection for --porcelain=v2

The output of `git status --porcelain` leaves out many details about the current status that clients might like to have. This can force them to be less efficient as they may need to launch secondary commands (and try to match the logic within git) to accumulate this extra information. For

[PATCH v2 7/8] status: update git-status.txt for --porcelain=v2

Update status manpage to include information about porcelain v2 format. Signed-off-by: Jeff Hostetler --- Documentation/git-status.txt | 83 ++-- 1 file changed, 80 insertions(+), 3 deletions(-) diff --git

[PATCH v2 0/8] status: V2 porcelain status

This patch series adds porcelain V2 format to status. This provides detailed information about file changes and about the current branch. The new output is accessed via: git status --porcelain=v2 [--branch] This patch series hopefully addresses all of the comments from the previous series.

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Mon, Jul 25, 2016 at 02:40:25PM -0400, Jeff King wrote: > > @@ -1052,6 +1053,9 @@ static int add_object_entry_from_bitmap(const > > unsigned char *sha1, > > { > > uint32_t index_pos; > > > > + if (local && has_loose_object_nonlocal(sha1)) > > + return 0; > > + > > if

[PATCH 2/2] pack-objects: compute local/ignore_pack_keep early

In want_object_in_pack(), we can exit early from our loop if neither "local" nor "ignore_pack_keep" are set. If they are, however, we must examine each pack to see if it has the object and is non-local or has a ".keep". It's quite common for there to be no non-local or .keep packs at all, in

[PATCH 1/2] pack-objects: break out of want_object loop early

When pack-objects collects the list of objects to pack (either from stdin, or via its internal rev-list), it filters each one through want_object_in_pack(). This function loops through each existing packfile, looking for the object. When we find it, we mark the pack/offset combo for later use.

[PATCH 0/2] speed up "Counting objects" when there are many packs

We sometimes see cases at GitHub where repository maintenance has fallen behind, and you get a large number of packs. The solution is to repack, but that process is itself made a lot slower by the number of packs. We've experimented a bit with fast "just cat all the packfiles together" type

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Wed, Jul 13, 2016 at 01:52:17PM +0300, Kirill Smelkov wrote: > > So I think if you were to repeatedly "git repack -adb" over time, you > > would get worse and worse ordering as objects are added to the > > repository. > > Jeff, first of all thanks for clarifying. > > So it is

Re: [PATCH] config.mak.uname: correct perl path on FreeBSD

Duy Nguyen writes: > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote: >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has >>> been removed at

Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit

Andreas Schwab writes: >> +colon = line + len - 2; >> +line += 5; >> +for (;;) { >> +if (colon < line) >> +return 0; >> +if (*--colon == ':') >> +break; >> +} >> + >> +if

Re: [PATCH v2] i18n: notes: mark comment for translation

Vasco Almeida writes: > static const char note_template[] = > - "\nWrite/edit the notes for the following object:\n"; > + N_("Write/edit the notes for the following object:"); > > struct note_data { > int given; > @@ -179,7 +179,8 @@ static void

Re: [PATCH 2/2] git svn: migrate tests to use lib-httpd

Eric Wong writes: > This allows us to use common test infrastructure and parallelize > the tests. For now, GIT_SVN_TEST_HTTPD=true needs to be set to > enable the SVN HTTP tests because we reuse the same test cases > for both file:// and http:// SVN repositories. SVN_HTTPD_PORT

Re: [RFC] git subcommand to check if branch is up-to-date with upstream

W dniu 2016-07-25 o 18:58, Junio C Hamano pisze: > Sidhant Sharma writes: > >> I was wondering if it would be a good idea to have a command to check if a >> push or pull is required. Perhaps it can also suggest if changes are >> fast-forward or the branches (local and

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

Eric Wong writes: >> Also, doesn't it break "git rebase" (non-interactive), or anything >> that internally runs format-patch to individual files and then runs >> am on each of them, anything that knows that each output file from >> format-patch corresponds to a single change and

Re: Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

W dniu 2016-07-25 o 09:33, Johannes Schindelin pisze: > Therefore "%s%n%+b" *might* do what you intended (I would not > know, because that information was missing from the report). Shouldn't it be "%s%n%n%-b" or "%s%n%-b"? -- Jakub Narębski -- To unsubscribe from this list: send the line

Re: [PATCH] config.mak.uname: correct perl path on FreeBSD

On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote: > On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy > wrote: >> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has >> been removed at least on FreeBSD 10.3. See [1] for more

Re: [PATCH] push: allow pushing new branches with --force-with-lease

John Keeping writes: > If there is no upstream information for a branch, it is likely that it > is newly created and can safely be pushed under the normal fast-forward > rules. Relax the --force-with-lease check so that we do not reject > these branches immediately but

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

Junio C Hamano writes: > Jon Forrest writes: > >> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd >> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see >> lots of output showing 'git commit' commands and the commit IDs

Re: [RFC] git subcommand to check if branch is up-to-date with upstream

Sidhant Sharma writes: > I was wondering if it would be a good idea to have a command to check if a > push or pull is required. Perhaps it can also suggest if changes are > fast-forward or the branches (local and remote) have diverged. Doesn't "branch -v" give that

Re: [PATCH] config.mak.uname: correct perl path on FreeBSD

On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy wrote: > It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has > been removed at least on FreeBSD 10.3. See [1] for more information. > > [1] >

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

Pranit Bauva writes: >>> +enum terms_defined { >>> + TERM_BAD = 1, >>> + TERM_GOOD = 2, >>> + TERM_NEW = 4, >>> + TERM_OLD = 8 >>> +}; >>> + >> >> What does TERM stand for ? The terms (words) used to denote the newer and the older parts of the

Re: Complex gitweb URL

Jakub Narębski writes: > Subject: [PATCH] gitweb(1): Document query parameters > > The gitweb manpage includes description of gitweb URL structure, > but it was limited to passing parameters in the path part of URL > ('path info'), and it didn't include explanation of query

[PATCH] config.mak.uname: correct perl path on FreeBSD

It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has been removed at least on FreeBSD 10.3. See [1] for more information. [1] https://svnweb.freebsd.org/ports/head/UPDATING?r1=386270=386269=386270_format=c Signed-off-by: Nguyễn Thái Ngọc Duy --- Tested with

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Eric Sunshine writes: >> Later when the grep API was used in revision graversal machinery, > > s/graversal/traversal/ Thanks. -- 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

Re: [PATCH] t5510: become resilient to GETTEXT_POISON

On Mon, Jul 25, 2016 at 5:16 PM, Junio C Hamano wrote: > On Mon, Jul 25, 2016 at 2:31 AM, Vasco Almeida wrote: >> Replace gettext poison text with appropriate values to be able to cut >> the right output of git fetch command for comparison. > > Hmm, as

Re: [RFC/PATCH 0/8] Add configuration options for split-index

On Sat, Jul 23, 2016 at 6:11 PM, Christian Couder wrote: > Ok, I started working on automatically pushing back all changes to the > shared index when the percentage of entries in linked vs shared > indexes is greater than 25% (maybe I will make it configurable later).

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On Sun, Jul 24, 2016 at 9:11 PM, Lars Schneider wrote: > > On 23 Jul 2016, at 10:14, Eric Wong wrote: > >> larsxschnei...@gmail.com wrote: >>> Please note that the protocol filters do not support stream processing >>> with this implemenatation because

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

Stefan Beller writes: > On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano wrote: >> >> * submodule.$name.update, submodule.$name.ignore, >>submodule.$name.branch, etc. would need to be all different among >>worktrees of the superproject, as that is

Re: [PATCH] t5510: become resilient to GETTEXT_POISON

On Mon, Jul 25, 2016 at 2:31 AM, Vasco Almeida wrote: > Replace gettext poison text with appropriate values to be able to cut > the right output of git fetch command for comparison. Hmm, as these tests are _all_ about human-readable output, it probably is sufficient to

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

Jon Forrest writes: > Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd > Edition (or just Pro Git 2nd Edition - it doesn't matter). You see > lots of output showing 'git commit' commands and the commit IDs that > result. I suspect you'd see the same in

Re: [PATCH] submodule-config: use explicit empty string instead of strbuf in config_from()

Heiko Voigt writes: > Thats a good idea. Can send a patch, but I noticed that your change is > already in next and my change has not been picked up. So I am unsure if > I should base my patches on next or if Junio wants to keep your change? When you noticed something you want

Re: [PATCH] submodule-config: use explicit empty string instead of strbuf in config_from()

Hi, On Thu, Jul 21, 2016 at 08:57:03PM +0200, René Scharfe wrote: > >diff --git a/submodule-config.c b/submodule-config.c > >index 077db40..dccea59 100644 > >--- a/submodule-config.c > >+++ b/submodule-config.c [...] > >@@ -431,14 +432,19 @@ static const struct submodule *config_from(struct >

[RFC] git subcommand to check if branch is up-to-date with upstream

Hi, I was wondering if it would be a good idea to have a command to check if a push or pull is required. Perhaps it can also suggest if changes are fast-forward or the branches (local and remote) have diverged. The reason I feel the need of such a command is when I need to check if my branch is

Re: Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

On Monday 25 July 2016 10:06:28 Johannes Schindelin wrote: > Hi Ilya, > > On Mon, 25 Jul 2016, Ilya Tumaykin wrote: > > On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote: > > > On Sun, 24 Jul 2016, Ilya Tumaykin wrote: > > > [...] > > > > > > > $ git --no-pager log -1

Client exit whilst running pre-receive hook : commit accepted but no post-receive hook ran

Hi I have always assumed the post-receive hook to be executed whenever a commit is "accepted" by the (gitolite) server. That does not seem to be true any more. Since 9658846 is appears that, when a client bails out, the pre-receive hook continues to run and the commit is written to the

[PATCH] t5510: become resilient to GETTEXT_POISON

Replace gettext poison text with appropriate values to be able to cut the right output of git fetch command for comparison. The first gettext poison falls from the previous line into the next because the poison does not add a newline, so we must replace it with nothing. Signed-off-by: Vasco

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

Junio C Hamano wrote: > Junio C Hamano writes: > > Eric Wong writes: > > > >> Users have mistakenly copied "From " lines into commit messages > >> in the past, and will certainly make the same mistakes in the > >> future. Since not everyone

[ANNOUNCE] git-cinnabar 0.4.0 beta 2

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Code on https://github.com/glandium/git-cinnabar This release on https://github.com/glandium/git-cinnabar/releases/tag/0.4.0b2 [

Re: Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

Hi Ilya, On Mon, 25 Jul 2016, Ilya Tumaykin wrote: > On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote: > > > > On Sun, 24 Jul 2016, Ilya Tumaykin wrote: > > [...] > > > $ git --no-pager log -1 --format='format:%+s%+b' > > > > > > Actual results: > > > ``` > > > > > > This is subject

Re: Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote: > Hi Ilya, > > On Sun, 24 Jul 2016, Ilya Tumaykin wrote: > > Steps to reproduce: > > $ git init > > $ >123 > > $ git add 123 > > $ git commit -v -m 'This is subject' -m 'And this is body' > > $ git --no-pager log -1

Re: Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

Hi Ilya, On Sun, 24 Jul 2016, Ilya Tumaykin wrote: > Steps to reproduce: > $ git init > $ >123 > $ git add 123 > $ git commit -v -m 'This is subject' -m 'And this is body' > $ git --no-pager log -1 --format='format:%+s%+b' > > Actual results: > ``` > > This is subject > And this is body > ```

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

Lars Schneider wrote: > On 23 Jul 2016, at 10:14, Eric Wong wrote: > > larsxschnei...@gmail.com wrote: > >> +static struct cmd2process *start_protocol_filter(const char *cmd) > >> +{ > >> + int ret = 1; > >> + struct cmd2process *entry = NULL; > >> +

Re: [ANN] Pro Git Reedited 2nd Edition

Hi Jon, On Sun, 24 Jul 2016, Jon Forrest wrote: > On 7/24/2016 11:27 AM, Jakub Narębski wrote: > > > All right. One issue I have after browsing through changes is that > > description of changes and their granularity is severely lacking. "A > > few more very minor changes.", "More piddly

Re: Bug:

Ilya Tumaykin gmail.com> writes: > $ git --no-pager log -1 --format='format:%+s%+b' > Please fix. Simply use `git --no-pager log -1 --format='format:%+s%n%+b'` The message body excludes the empty line preceding it. -- To unsubscribe from this list: send the line "unsubscribe git" in the