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

On Thu, May 26, 2016 at 11:41:12PM -0500, Edward Thomson wrote: > On Wed, May 25, 2016 at 12:36:55AM -0700, Junio C Hamano wrote: > > > > At the design level, I have a few comments. > > Thanks, I will submit a new patch that incorporates your (and dscho's) > comments. > > > * This is about a

Re: t7610-mergetool.sh test failure

On Thu, May 26, 2016 at 09:40:27PM -0700, David Aguilar wrote: > > BTW, one thing I happened to note while looking at this: running the > > test script will write into /tmp (or wherever your $TMPDIR points). > > Probably not a big deal, but I wonder if we should be setting $TMPDIR in > > our test

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

On Wed, May 25, 2016 at 12:36:55AM -0700, Junio C Hamano wrote: > > At the design level, I have a few comments. Thanks, I will submit a new patch that incorporates your (and dscho's) comments. > * This is about a repository with core.filemode=0; I wonder if >something for a repository with

Re: t7610-mergetool.sh test failure

On Wed, May 25, 2016 at 08:51:14PM -0500, Jeff King wrote: > On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote: > > > On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote: > > > > > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik > > > wrote: > > > >

Re: t7800 test failure

On Wed, May 25, 2016 at 11:33:33AM +0200, Armin Kunaschik wrote: > On Tue, May 24, 2016 at 7:36 PM, Junio C Hamano wrote: > > Armin Kunaschik writes: > >> > >> Ok, how can this be implemented within the test environment? > > > > I actually think an

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Hey Mehul, On Thu, May 26, 2016 at 8:34 PM, Mehul Jain wrote: > Hi Remi, > > Thanks for your input. > > On Thu, May 26, 2016 at 7:12 PM, Remi Galan Alfonso > wrote: >> Hi Mehul, >> >> Mehul Jain

Re: [PATCH 14/26] shallow.c: implement a generic shallow boundary finder based on rev-list

On Wed, Apr 13, 2016 at 8:54 AM, Nguyễn Thái Ngọc Duy wrote: > Instead of a custom commit walker like get_shallow_commits(), this new > function uses rev-list to mark NOT_SHALLOW to all reachable commits, > except borders. The definition of reachable is to be defined by the >

Re: RFC: dynamic "auto" date formats

On Thu, May 26, 2016 at 08:36:57PM -0700, Linus Torvalds wrote: > Note that this doesn't add any gitconfig setting to do this, which > would be part of the whole point if this is actually sensible. But I'm > not entirely convinced it's worth it in the first place, thus this > email to see how

Re: [PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

On Thu, May 26, 2016 at 10:46:10PM -0500, Edward Thomson wrote: > git-log(1) documents that when specifying the `%C(auto)` format > placeholder will "turn on auto coloring on the next %placeholders > until the color is switched again." > > However, when `%C(auto)` is used, the present

Re: [PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

On Wed, May 25, 2016 at 05:39:04PM -0500, Jeff King wrote: > Looks like we didn't have any tests at all for %C(auto). And the tests > for %C(auto,...) were labeled as %C(auto), making it all the more > confusing. Perhaps it is worth squashing this in: Thanks, peff. Indeed I did squash that into

[PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

git-log(1) documents that when specifying the `%C(auto)` format placeholder will "turn on auto coloring on the next %placeholders until the color is switched again." However, when `%C(auto)` is used, the present implementation will turn colors on unconditionally (even if the color configuration

RFC: dynamic "auto" date formats

This is a throw-away idea with a simple patch attached, which I don't think anybody should really take all that seriously per se, but I thought I'd throw it out and see if it generates any discussion. I almost never use anything but the default date format (DATE_NORMAL), but every once in a while

Re: [feature request] find git commit log before rebase

Indeed, specifying the branch name does the trick and this works with `git reflog` and/or `git log --walk-reflogs` Thank you very much! On 27 May 2016 at 01:58, Sebastian Staudt wrote: > Hi. > > I think what you want is `git reflog` (http://git-scm.com/man/reflog). > > git

Re: [RFC/PATCH 0/2] Introduce "log.showSignature" config variable

On Thu, May 26, 2016 at 8:06 AM, Mehul Jain wrote: > Add a new configuratation variable "log.showSignature" for git-log and > git-show. "log.showSignature=true" will enable user to see GPG signature > by default while using git-log and git-show. > > [Patch 1/2] introduce

[PATCH v8 7/9] connect: change the --diag-url output to separate user and host

Signed-off-by: Mike Hommey --- connect.c | 6 ++ t/t5500-fetch-pack.sh | 14 -- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/connect.c b/connect.c index 0819c25..0c4d23b 100644 --- a/connect.c +++ b/connect.c @@ -714,10 +714,8 @@

[PATCH v8 1/9] connect: document why we sometimes call get_port after get_host_and_port

Signed-off-by: Mike Hommey --- connect.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/connect.c b/connect.c index c53f3f1..6e520c3 100644 --- a/connect.c +++ b/connect.c @@ -742,6 +742,13 @@ struct child_process *git_connect(int fd[2], const char *url,

[PATCH v8 5/9] connect: group CONNECT_DIAG_URL handling code

Previous changes made both branches handling CONNECT_DIAG_URL identical. We can now remove one of those branches and have CONNECT_DIAG_URL be handled in one place. Signed-off-by: Mike Hommey --- connect.c | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-)

[PATCH v8 0/9] connect: various cleanups

Changes from v7: - Fixed comments. Mike Hommey (9): connect: document why we sometimes call get_port after get_host_and_port connect: call get_host_and_port() earlier connect: re-derive a host:port string from the separate host and port variables connect: make parse_connect_url()

[PATCH v8 4/9] connect: make parse_connect_url() return separated host and port

Now that nothing besides CONNECT_DIAG_URL is using hostandport, we can have parse_connect_url() itself do the host and port splitting. This still leaves "user@" part of the host, if there is one, which will be addressed in a subsequent change. This however does add /some/ handling of the "user@"

[PATCH v8 9/9] connect: move ssh command line preparation to a separate function

Signed-off-by: Mike Hommey --- connect.c | 108 +- 1 file changed, 58 insertions(+), 50 deletions(-) diff --git a/connect.c b/connect.c index 9aea3cd..076ae09 100644 --- a/connect.c +++ b/connect.c @@ -684,6 +684,61

[PATCH v8 8/9] connect: actively reject git:// urls with a user part

Currently, urls of the for git://user@host don't work because user@host is not resolving at the DNS level, but we shouldn't be relying on it being an invalid host name, and actively reject it for containing a username in the first place. Signed-off-by: Mike Hommey ---

[PATCH v8 6/9] connect: make parse_connect_url() return the user part of the url as a separate value

Signed-off-by: Mike Hommey --- connect.c | 54 -- 1 file changed, 36 insertions(+), 18 deletions(-) diff --git a/connect.c b/connect.c index 4be06f4..0819c25 100644 --- a/connect.c +++ b/connect.c @@ -588,11 +588,13 @@

[PATCH v8 2/9] connect: call get_host_and_port() earlier

Currently, get_host_and_port() is called in git_connect() for the ssh protocol, and in git_tcp_connect_sock() for the git protocol. Instead of doing this, just call it from a single place, right after parse_connect_url(), and pass the host and port separately to git_*_connect() functions. We

[PATCH v8 3/9] connect: re-derive a host:port string from the separate host and port variables

The last uses of the hostandport variable, besides being strdup'ed before being split into host and port, is to fill the host header in the git protocol and to test whether to proxy the request. Instead of relying on parse_connect_url() to return a host:port string that makes sense there,

Re: What's cooking in git.git (May 2016, #08; Thu, 26)

Jeff King writes: > I just sent a replacement for the fourth patch that avoids the t/helper > problem. It's probably worth dealing with before even hitting "next" so > as not to break bisection. > > You should probably hold off on merging the top one. The discussion > stalled

Re: [PATCH 4/6] config: return configset value for current_config_ functions

Jeff King writes: > I think the issue is that bin-wrappers serves two purposes. One is for > testing, but the other is for people who run git directly without > installing. Hmph. It may have been a useful way to "run without installing" once in the past, but with the "check and

Re: [PATCH 4/6] config: return configset value for current_config_ functions

On Thu, May 26, 2016 at 10:36:44AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The problem is running test-config inside of a git alias. The > > bin-wrappers will set the exec-path to the root-level of git's build > > directory, which the git binary will then stick at

Re: What's cooking in git.git (May 2016, #08; Thu, 26)

On Thu, May 26, 2016 at 03:50:14PM -0700, Junio C Hamano wrote: > * jk/upload-pack-hook (2016-05-24) 6 commits > - upload-pack: provide a hook for running pack-objects > - config: add a notion of "scope" > - config: return configset value for current_config_ functions > - config: set up

Re: [PATCH 4/6] config: return configset value for current_config_ functions

On Thu, May 26, 2016 at 12:50:33PM -0400, Jeff King wrote: > > Remind me why we end up running ./test-config instead of > > ./bin-wrappers/test-config? Should our tests be running > > bin-wrappers early in their $PATH, perhaps? > > The problem is running test-config inside of a git alias. The

What's cooking in git.git (May 2016, #08; Thu, 26)

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 13/22] i18n: git-sh-setup.sh: mark strings for translation

Vasco Almeida writes: > require_work_tree_exists () { > + program_name=$0 > if test "z$(git rev-parse --is-bare-repository)" != zfalse > then > - die "fatal: $0 cannot be used without a working tree." > + die "$(gettext "fatal:

Re: [PATCH v2 14/22] i18n: rebase-interactive: mark strings for translation

Vasco Almeida writes: > @@ -222,9 +223,10 @@ has_action () { > } > > is_empty_commit() { > - tree=$(git rev-parse -q --verify "$1"^{tree} 2>/dev/null || > - die "$1: not a commit that can be picked") > - ptree=$(git rev-parse -q --verify

Re: [PATCH v2 16/22] i18n: rebase-interactive: mark comments of squash for translation

Vasco Almeida writes: > Helper functions this_nth_commit_message and skip_nth_commit_message > replace the previous method of making the comment messages (such as > "This is the 2nd commit message:") aided by nth_string helper function. > This step was taken as a

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 03:31 PM, Junio C Hamano wrote: Marc Branchaud writes: The fact that something is buried in some odd part of the ref tree is less relevant, IMO. If I'm using custom fetch refspecs or other oddities, I'll have that in the back of my head. But what I really

[PATCH 2/2] submodule update: learn `--[no-]recommend-shallow` option

Sometimes the history of a submodule is not considered important by the projects upstream. To make it easier for downstream users, allow a boolean field 'submodule..shallow' in .gitmodules, which can be used to recommend whether upstream considers the history important. This field is honored in

[PATCHv3 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

v3: * fixed documentation to consistently mention recommend-shallow * realigned code in the config patch * Thanks Remi for reviewing! diff to v2: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index c928c0d..bf3bb37 100644 --- a/Documentation/git-submodule.txt +++

[PATCH 1/2] submodule-config: keep shallow recommendation around

The shallow field will be used in a later patch by `submodule update`. To differentiate between the actual depth (which may be different), we name it `recommend_shallow` as the field in the .gitmodules file is only a recommendation by the project. Signed-off-by: Stefan Beller

Re: [PATCHv2 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

On Thu, May 26, 2016 at 12:16 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Thu, May 26, 2016 at 11:13 AM, Junio C Hamano wrote: >>> Stefan Beller writes: >>> Sometimes the history of a submodule is

Re: [PATCHv3 0/2] Persistent submodule pathspec specification

Thanks; will replace. -- 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] userdiff: add built-in pattern for CSS

Am 24.05.2016 um 16:25 schrieb William Duclot: > +PATTERNS("css", > + "^([^,{}]+)((,[^}]*\\{)|([ \t]*\\{))$", This hunk header pattern is a bit too restrictive for my taste. Find below a few more test cases that you should squash in. One case fails because only the first CSS selector is

[PATCH 2/2] clone: add --init-submodule= switch

The new switch passes the pathspec to `git submodule update --init` which is called after the actual clone is done. Additionally this configures the submodule.defaultUpdatePath to be the given pathspec, such that any future invocation of `git submodule update --init-default-paths` will keep up

[PATCHv3 0/2] Persistent submodule pathspec specification

Changes since v2: * I replaced one 0 by NULL as pointed out by Ramsay, and reformatted the line to stay within 80 characters: --- a/builtin/clone.c +++ b/builtin/clone.c @@ -908,8 +908,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix) struct string_list_item

[PATCH 1/2] submodule update: add `--init-default-path` switch

The new switch `--init-default-path` initializes the submodules which are configured in `submodule.defaultUpdatePath` instead of those given as command line arguments before updating. In the first implementation this is made incompatible with further command line arguments as it is unclear what

Re: [feature request] find git commit log before rebase

Hi. I think what you want is `git reflog` (http://git-scm.com/man/reflog). git reflog b Will tell you the commits b pointed to in the past. Best regards, Sebastian 2016-05-26 18:55 GMT+02:00 ryenus : > Assuming I have branches master (m), and a side branch (b), with a >

Re: [PATCH] submodule operations: tighten pathspec errors

Stefan Beller writes: > It's a first initial version with no tests (and probably conflicting with > some topics in flight), but I was curious how involved this issue actually is, > so I took a stab at implementing it. I take it to mean "This is s/PATCH/RFC/". >

Re: [PATCH 1/2] fetch: better alignment in ref summary

Marc Branchaud writes: > The fact that something is buried in some odd part of the ref tree is > less relevant, IMO. If I'm using custom fetch refspecs or other > oddities, I'll have that in the back of my head. But what I really > care about is what ref I can use with

Re: [PATCHv2 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

Stefan Beller writes: > On Thu, May 26, 2016 at 11:13 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> Sometimes the history of a submodule is not considered important by >>> the projects upstream. To make it easier for

Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command

Jordan DE GEA writes: > From: Jordan DE GEA > > Since `git worktree add` uses `git checkout` when `[]` is used, > and `git checkout -` is already supported, it makes sense to allow the > same shortcut in `git worktree add`.

Re: [PATCHv2 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

On Thu, May 26, 2016 at 11:13 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Sometimes the history of a submodule is not considered important by >> the projects upstream. To make it easier for downstream users, allow >> a field 'submodule..depth' in

Re: [RFC] Triangular Workflow: user friendly full implementation

Jordan DE GEA writes: > We are working on full implementation of triangular workflow feature. > For now, the main options available are: >- branch..pushRemote >- remote.pushDefault > And only setable by hands. And once it is set, you do not have

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 01:42 PM, Junio C Hamano wrote: True. One of the entries in Marc's example is easily misread as "pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was fetched to its usual place", when Marc wanted to say "they had 2nd-index branch at refs/heads/2nd-index, and it was

Re: [PATCHv2 0/2] Submodule shallow recommendation [WAS: Submodules: have a depth field in the .gitmodules file]

Stefan Beller writes: > Sometimes the history of a submodule is not considered important by > the projects upstream. To make it easier for downstream users, allow > a field 'submodule..depth' in .gitmodules, which can be used > to indicate the recommended depth. I have a

Re: [PATCH 1/2] fetch: better alignment in ref summary

Jeff King writes: > On Thu, May 26, 2016 at 10:22:25AM -0400, Marc Branchaud wrote: > >> Why do we need any kind of "->" at all? How about simply (with an update to >> "old-branch" for comparison to probably-more-common output): >> >> From github.com:pclouds/git >>

Re: [PATCH 4/6] config: return configset value for current_config_ functions

Jeff King writes: > The problem is running test-config inside of a git alias. The > bin-wrappers will set the exec-path to the root-level of git's build > directory, which the git binary will then stick at the front of the > $PATH. I was wondering why exec-path does not point at

Re: [PATCH 2/2] submodule update: learn `--[no-]recommend-shallow` option

On Thu, May 26, 2016 at 2:07 AM, Remi Galan Alfonso wrote: > You forgot to update from recommend-depth to recommend-shallow > > Stefan Beller writes: >> [...] >> 'git submodule' [--quiet] init [--] [...] >> 'git submodule'

Re: [PATCH 1/2] submodule-config: keep shallow recommendation around

On Thu, May 26, 2016 at 2:02 AM, Remi Galan Alfonso wrote: > Hi Stefan, > > Stefan Beller writes: >> [...] >> @ -353,6 +354,15 @@ static int parse_config(const char *var, const char >> *value, void *data) >> else

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

Jeff King writes: > On Thu, May 26, 2016 at 06:36:47PM +0530, Mehul Jain wrote: > >> If "log.showsignature=true", then there is no way to override it using >> command line switch. >> >> Teach "git log" and "git show" about "--no-show-signature" command line >> option. > > I think

Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

René Scharfe writes: > Am 24.05.2016 um 20:16 schrieb Junio C Hamano: >> René Scharfe writes: >> >>>diff: factor out match_func_rec() >>>diff: handle appended chunks better with -W >>>diff: ignore empty lines before added functions with -W >>>diff:

[feature request] find git commit log before rebase

Assuming I have branches master (m), and a side branch (b), with a history tree like below: m0 --- m1 -- m2 -- m3 -- m4 --- master (m) \ / \ b1 -- b2 b3 -- b4 -- branch (b) (HEAD) | (tag:POINT_BEFORE_REBASE) The history of branch b

Re: [PATCH] mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)

Johannes Schindelin writes: > I do not see this patch in 'pu'... Anything I can do to get this into > 'master' eventually? The reason why I left it in my inbox was because I couldn't tell if this was a final submission with concensus among Git developers on Windows,

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

On Thu, May 26, 2016 at 10:12:30PM +0530, Mehul Jain wrote: > On Thu, May 26, 2016 at 10:02 PM, Jeff King wrote: > > On Thu, May 26, 2016 at 06:36:47PM +0530, Mehul Jain wrote: > >> diff --git a/t/t4202-log.sh b/t/t4202-log.sh > >> index 36be9a1..ea24259 100755 > >> ---

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

On Thu, May 26, 2016 at 06:36:46PM +0530, Mehul Jain wrote: > diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt > index 03f9580..f39f800 100644 > --- a/Documentation/git-log.txt > +++ b/Documentation/git-log.txt > @@ -196,6 +196,10 @@ log.showRoot:: > `git log -p` output

Re: [PATCH 4/6] config: return configset value for current_config_ functions

On Thu, May 26, 2016 at 09:42:48AM -0700, Junio C Hamano wrote: > Duy Nguyen writes: > > > On Thu, May 19, 2016 at 7:08 AM, Jeff King wrote: > >> On Wed, May 18, 2016 at 06:43:23PM -0400, Jeff King wrote: > >> > >>> cache.h| 1 + > >>>

Re: [RFC/PATCH] Formatting variables in the documentation

Jeff King writes: > On Thu, May 26, 2016 at 09:18:17AM -0700, Junio C Hamano wrote: > >> > 1. Somebody produces a patch flipping the default. The patch is >> > trivial, but the commit message should tell why, and try to dig up >> > any possible problems we might see

Re: [PATCH/RFC 0/6] pack-objects hook for upload-pack

Jeff King writes: > Yeah, I had the same thought while working on this, but just didn't want > to have to tweak every config callback. As you say, I don't think this > makes anything fundamentally worse, though. I'm inclined to go with this > strategy, especially with the extra

Re: [PATCH 4/6] config: return configset value for current_config_ functions

Duy Nguyen writes: > On Thu, May 19, 2016 at 7:08 AM, Jeff King wrote: >> On Wed, May 18, 2016 at 06:43:23PM -0400, Jeff King wrote: >> >>> cache.h| 1 + >>> config.c | 51 >>> +-

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

Hi, Thanks for your input. On Thu, May 26, 2016 at 10:02 PM, Jeff King wrote: > On Thu, May 26, 2016 at 06:36:47PM +0530, Mehul Jain wrote: >> diff --git a/t/t4202-log.sh b/t/t4202-log.sh >> index 36be9a1..ea24259 100755 >> --- a/t/t4202-log.sh >> +++ b/t/t4202-log.sh >> @@

Re: [RFC/PATCH] Formatting variables in the documentation

On Thu, May 26, 2016 at 09:37:19AM -0700, Junio C Hamano wrote: > >> There was no particular "caveat" raised there to recommend against > >> using this on particular versions of tools or platforms. It was > >> inertia that has kept the new optional feature "optional". > > > > Thanks for digging.

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

On Thu, May 26, 2016 at 06:36:47PM +0530, Mehul Jain wrote: > If "log.showsignature=true", then there is no way to override it using > command line switch. > > Teach "git log" and "git show" about "--no-show-signature" command line > option. I think this is teaching all of the revision

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Thu, May 26, 2016 at 10:22:25AM -0400, Marc Branchaud wrote: > Why do we need any kind of "->" at all? How about simply (with an update to > "old-branch" for comparison to probably-more-common output): > > From github.com:pclouds/git >cafed0c..badfeed pclouds/old-branch > * [new

Re: [RFC/PATCH] Formatting variables in the documentation

On Thu, May 26, 2016 at 09:18:17AM -0700, Junio C Hamano wrote: > > 1. Somebody produces a patch flipping the default. The patch is > > trivial, but the commit message should tell why, and try to dig up > > any possible problems we might see (e.g., why wasn't this the > >

Re: [RFC/PATCH] Formatting variables in the documentation

Jeff King writes: > On Mon, May 23, 2016 at 07:57:43PM +0200, Matthieu Moy wrote: > >> Samuel GROOT writes: >> >> > Since 2.8.3 was out recently, we could flip MAN_BOLD_LITERAL on by >> > default for this cycle to shake out problems as Jeff

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

On Thu, May 26, 2016 at 9:13 PM, Remi Galan Alfonso wrote: > Sorry, I should have made explicit what went through my mind. > "When log.showsignature set true" doesn't sound right to me, while > "When log.showsignature is set to true" sounds better,

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Mehul Jain writes: > Hi Remi, > > Thanks for your input. > > On Thu, May 26, 2016 at 7:12 PM, Remi Galan Alfonso > wrote: > > Hi Mehul, > > > > Mehul Jain writes: > >> When log.showsignature set

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Hi Remi, Thanks for your input. On Thu, May 26, 2016 at 7:12 PM, Remi Galan Alfonso wrote: > Hi Mehul, > > Mehul Jain writes: >> When log.showsignature set true, "git log" and "git show" will behave > > 'When

Re: [PATCH] transport, send-pack: append period to up-to-date message

On May 25, 2016, at 5:55 PM, Junio C Hamano wrote: > > Jeff King writes: > >> I think messages to stderr are generally fair game for changing, even in >> plumbing. In many cases they are also translated (and I would argue that >> these messages probably should

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-22 09:59 PM, Duy Nguyen wrote: On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote: That is, I wonder if the above can become something like: From github.com:pclouds/git * [new branch] { -> pclouds/}2nd-index * [new branch] { ->

Re: [RFC] fast-import: invalidate pack_id references after loosening

On Thu, May 26, 2016 at 08:02:36AM +, Eric Wong wrote: > > That's probably OK in practice, as I think the actual pack-write already > > does a linear walk of the object table to generate the pack index. So > > presumably nobody checkpoints often enough for it to be a problem. And > > the

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Hi Mehul, Mehul Jain writes: > People may want to always use "--show-signature" while using "git log" > or "git show". > > When log.showsignature set true, "git log" and "git show" will behave 'When log.showsignature is set to true' ? > as "--show-signature" was

Re: [PATCH] mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)

Hi Junio, On Wed, 27 Apr 2016, Johannes Schindelin wrote: > From: Karsten Blees > > MSYS2 emulates pseudo terminals via named pipes, and isatty() returns 0 > for such file descriptors. Therefore, some interactive functionality > (such as launching a pager, asking if a failed

Re: [PATCH v4 2/2] rev-parse: fix some options when executed from subpath of main tree

On Thu, May 26, 2016 at 07:19:16AM -0400, Michael Rappazzo wrote: > Executing `git-rev-parse` with `--git-common-dir`, `--git-path `, > or `--shared-index-path` from the root of the main worktree results in > a relative path to the git dir. > > When executed from a subdirectory of the main tree,

Re: [ANNOUNCE] Git v2.9.0-rc0

Hi all, On Thu, 26 May 2016, Johannes Schindelin wrote: > On Mon, 23 May 2016, Junio C Hamano wrote: > > > An early preview release Git v2.9.0-rc0 is now available for > > testing at the usual places. > > Thanks. I pushed out a tagged source-only Git for Windows v2.9.0-rc0 for > interested

[RFC/PATCH 2/2] log: add "--no-show-signature" command line option

If "log.showsignature=true", then there is no way to override it using command line switch. Teach "git log" and "git show" about "--no-show-signature" command line option. Signed-off-by: Mehul Jain --- revision.c | 2 ++ t/t4202-log.sh | 7 +++ 2 files

[RFC/PATCH 0/2] Introduce "log.showSignature" config variable

Add a new configuratation variable "log.showSignature" for git-log and git-show. "log.showSignature=true" will enable user to see GPG signature by default while using git-log and git-show. [Patch 1/2] introduce the config variable along with some tests. [Patch 2/2] tackles the problem: what if

[RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

People may want to always use "--show-signature" while using "git log" or "git show". When log.showsignature set true, "git log" and "git show" will behave as "--show-signature" was given to them. Signed-off-by: Mehul Jain --- Documentation/git-log.txt | 4

[PATCH] worktree: allow "-" short-hand for @{-1} in add command

From: Jordan DE GEA Since `git worktree add` uses `git checkout` when `[]` is used, and `git checkout -` is already supported, it makes sense to allow the same shortcut in `git worktree add`. Signed-off-by: Matthieu Moy

[PATCH v4 2/2] rev-parse: fix some options when executed from subpath of main tree

Executing `git-rev-parse` with `--git-common-dir`, `--git-path `, or `--shared-index-path` from the root of the main worktree results in a relative path to the git dir. When executed from a subdirectory of the main tree, it can incorrectly return a path which starts 'sub/path/.git'. Change this

[PATCH v4 0/2] rev-parse: fix some options when executed from subpath of main tree

Changes since v3 [1]: - Rebased onto 'pu' which includes the cleanup of t1500 by Eric Sunshine - Fixed a memory leak due to misusing xstrfmt() [1] http://thread.gmane.org/gmane.comp.version-control.git/293778 Michael Rappazzo (2): rev-parse tests: add tests executed from a subdirectory

[PATCH v4 1/2] rev-parse tests: add tests executed from a subdirectory

t2027-worktree-list has an incorrect expectation for --git-common-dir which has been adjusted and marked to expect failure. Some of the tests added have been marked to expect failure. These demonstrate a problem with the way that some options to git rev-parse behave when executed from a

[RFC] Triangular Workflow: user friendly full implementation

We are working on full implementation of triangular workflow feature. For now, the main options available are: - branch..pushRemote - remote.pushDefault And only setable by hands. As it can be difficult to understand, here is what we want to do. Context: - One main

Re: [ANNOUNCE] Git v2.9.0-rc0

Hi Junio, On Mon, 23 May 2016, Junio C Hamano wrote: > An early preview release Git v2.9.0-rc0 is now available for > testing at the usual places. Thanks. I pushed out a tagged source-only Git for Windows v2.9.0-rc0 for interested parties:

Re: [PATCH 2/2] submodule update: learn `--[no-]recommend-shallow` option

You forgot to update from recommend-depth to recommend-shallow Stefan Beller writes: > [...] > 'git submodule' [--quiet] init [--] [...] > 'git submodule' [--quiet] deinit [-f|--force] (--all|[--] ...) > 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]

Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

Am 24.05.2016 um 20:16 schrieb Junio C Hamano: René Scharfe writes: diff: factor out match_func_rec() diff: handle appended chunks better with -W diff: ignore empty lines before added functions with -W diff: don't include common trailing empty lines with -W grep:

Re: [PATCH 1/2] submodule-config: keep shallow recommendation around

Hi Stefan, Stefan Beller writes: > [...] > @ -353,6 +354,15 @@ static int parse_config(const char *var, const char > *value, void *data) > else if (parse_submodule_update_strategy(value, > >update_strategy) < 0) >

Re: [RFC] fast-import: invalidate pack_id references after loosening

Jeff King wrote: > On Wed, May 25, 2016 at 10:54:02PM +, Eric Wong wrote: > > + for (h = 0; h < ARRAY_SIZE(object_table); h++) { > > + struct object_entry *e; > > + > > + for (e = object_table[h]; e; e = e->next) > > + if (e->pack_id ==

Re: [PATCH 4/6] config: return configset value for current_config_ functions

On Thu, May 19, 2016 at 7:08 AM, Jeff King wrote: > On Wed, May 18, 2016 at 06:43:23PM -0400, Jeff King wrote: > >> cache.h| 1 + >> config.c | 51 >> +- >> t/helper/test-config.c | 20