Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

>> Between the init and the update step you can modify the URLs. >> These commands are just a repetition from the first email, but the >> git commands can be viewed as moving from one state to another >> for submodules; submodules itself can be seen as a state machine >> according to that proposed

Re: [PATCH] git-prompt.sh: add submodule indicator

On Thu, Jan 19, 2017 at 4:07 PM, Benjamin Fuchs wrote: > I expirienced that working with submodules can be confusing. This indicator > will make you notice very easy when you switch into a submodule. > The new prompt will look like this: (sub:master) > Adding a new

Re: Git: new feature suggestion

On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski wrote: > W dniu 19.01.2017 o 19:39, Linus Torvalds pisze: >> >> You can do it in tig, but I suspect a more graphical tool might be better. > > Well, we do have "git gui blame". Does that actually work for people? Because it really

[PATCH] git-prompt.sh: add submodule indicator

I expirienced that working with submodules can be confusing. This indicator will make you notice very easy when you switch into a submodule. The new prompt will look like this: (sub:master) Adding a new optional env variable for the new feature. Signed-off-by: Benjamin Fuchs

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 4:06 PM, Joe Perches wrote:>> This sounds interesting to me! When I have some more time to take a >> look at this i might see if I can revive it. > > Can the terminology please be standardized to what > was once called bylines? > >

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, 2017-01-19 at 15:42 -0800, Jacob Keller wrote: > On Thu, Jan 19, 2017 at 1:20 PM, Jeff King wrote: > > On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote: > > > > > > As to the implementation, I am wondering if we can make this somehow > > > > work well with the

Post-merge hook

Hello I have been looking around for this, but I can't seem to find any examples of how to use the git post-merge hook. Can you help me please? I want to do something really simple in the sense of pulling locally and once pulled and merged any conflicts (if any) then run a command line code.

Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns

On Thu, Jan 19, 2017 at 1:06 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> From: Jacob Keller >> >> Teach git name-rev to take multiple --refs stored as a string list of >> patterns. The list of patterns will be

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 1:20 PM, Jeff King wrote: > On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote: > >> > As to the implementation, I am wondering if we can make this somehow >> > work well with the "trailers" code we already have, instead of >> > inventing yet

What's cooking in git.git (Jan 2017, #03; Thu, 19)

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. The sixth batch of topics have

Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns

On Thu, Jan 19, 2017 at 1:06 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> From: Jacob Keller >> >> Teach git name-rev to take multiple --refs stored as a string list of >> patterns. The list of patterns will be

Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

On 1/17/2017 12:43 PM, Stefan Beller wrote: On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis wrote: Technically it is submodule..url instead of submodule..url. The name is usually the path initially, and once you move the submodule, only the path changes, the name is

Re: grep open pull requests

On Thu, Jan 19, 2017 at 03:12:53PM -0700, Jack Bates wrote: > Cool, thanks for all your help! "git log --cherry-pick" works quite well. > One thing: I expected the following to be equivalent, but found that they're > not. Is that by accident or design? > > $ git rev-list --cherry-pick

Re: grep open pull requests

On 19/01/17 12:02 PM, Jeff King wrote: It's much trickier to find from the git topology whether a particular history contains rebased versions of commits. You can look at the --cherry options to "git log", which use patch-ids to try to equate commits. Something like: git for-each-ref

Re: [RESEND PATCHv2] contrib: remove git-convert-objects

On Thu, Jan 19, 2017 at 12:57 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> git-convert-objects, originally named git-convert-cache was used in >> early 2005 to convert to a new repository format, e.g. adding an author >> date. > > I think this

Re: [RFC for GIT] pull-request: add praise to people doing QA

> > I didn't know about trailers before. As I undestand it, I could use > > "Tested-by" as the key, and the commit subject as the value. This list > > then could be parsed and brought into proper output shape. It would > > simplify the subject parsing, but most things my AWK script currently > >

Re: Git: new feature suggestion

On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto wrote: > Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu: >> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto wrote: >>> >>> I am currently facing some challenges in one of Linux subsystems where a >>>

Re: merge maintaining history

From: "David J. Bakeman" On 01/14/2017 10:24 PM, Jacob Keller wrote: On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman wrote: History git cloned a remote repository and made many changes pushing them all to said repository over many months. The

Re: Git: new feature suggestion

Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu: > On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto wrote: >> >> I am currently facing some challenges in one of Linux subsystems where a >> rename >> of a set of folders and files would be the perfect scenario for future >>

Re: [PATCH v2 2/2] Be more careful when determining whether a remote was configured

On Thu, Jan 19, 2017 at 01:45:29PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I'm trying to figure out why "fetch --multiple" wouldn't just take a url > > in the first place. I guess it is because multiple fetch is useless > > without refspecs (since otherwise you're

Re: Git: new feature suggestion

W dniu 19.01.2017 o 19:39, Linus Torvalds pisze: > On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov > wrote: >> >> Still, I welcome you to read the sort-of "reference" post by Linus >> Torvalds [1] in which he explains the reasoning behind this approach >> implemented

Re: [PATCH v2 2/2] Be more careful when determining whether a remote was configured

Jeff King writes: > I'm trying to figure out why "fetch --multiple" wouldn't just take a url > in the first place. I guess it is because multiple fetch is useless > without refspecs (since otherwise you're just writing to FETCH_HEAD, > which gets immediately overwritten). This is

Re: [PATCH v2 2/2] Be more careful when determining whether a remote was configured

Hi Peff, On Thu, 19 Jan 2017, Jeff King wrote: > diff --git a/builtin/fetch.c b/builtin/fetch.c > index c85f3471d..9024cfffa 100644 > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -1014,9 +1014,9 @@ static int add_remote_or_group(const char *name, struct > string_list *list) >

Re: merge maintaining history

"David J. Bakeman" writes: >> So you want to merge the "new" history into the original tree now, so >> you checkout the original tree, then "git merge /" >> and then fix up any conflicts, and then git commit to create a merge >> commit that has the new history. Then you could

[PATCH v2 2/2] Be more careful when determining whether a remote was configured

One of the really nice features of the ~/.gitconfig file is that users can override defaults by their own preferred settings for all of their repositories. One such default that some users like to override is whether the "origin" remote gets auto-pruned or not. The user would simply call

Re: [PATCH v2 2/2] Be more careful when determining whether a remote was configured

On Thu, Jan 19, 2017 at 10:20:02PM +0100, Johannes Schindelin wrote: > There is only one caller of remote_is_configured() (in `git fetch`) that > may want to take remotes into account even if they were configured > outside the repository config; all other callers essentially try to > prevent the

Re: [RFC] stash --continue

Hi Marc, On Thu, 19 Jan 2017, Marc Branchaud wrote: > On 2017-01-19 10:49 AM, Johannes Schindelin wrote: > > > > On Wed, 18 Jan 2017, Marc Branchaud wrote: > > > > > On 2017-01-18 11:34 AM, Johannes Schindelin wrote: > > > > > > > > On Wed, 18 Jan 2017, Marc Branchaud wrote: > > > > > > > > > On

[PATCH v2 0/2] Fix remote_is_configured()

A surprising behavior triggered the bug report in https://github.com/git-for-windows/git/issues/888: the mere existence of the config setting "remote.origin.prune" (in this instance, configured via ~/.gitconfig so that it applies to all repositories) fooled `git remote rename ` into believing

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote: > > As to the implementation, I am wondering if we can make this somehow > > work well with the "trailers" code we already have, instead of > > inventing yet another parser of trailers. > > > > In its current shape,

Re: [RFC for GIT] pull-request: add praise to people doing QA

Wolfram Sang writes: > I didn't know about trailers before. As I undestand it, I could use > "Tested-by" as the key, and the commit subject as the value. This list > then could be parsed and brought into proper output shape. It would > simplify the subject parsing, but most

[PATCH v2 1/2] remote rename: demonstrate a bogus "remote exists" bug

Some users like to set `remote.origin.prune = true` in their ~/.gitconfig so that all of their repositories use that default. However, our code is ill-prepared for this, mistaking that single entry to mean that there is already a remote of the name "origin", even if there is not. This patch adds

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

Hi Peff, On Thu, 19 Jan 2017, Jeff King wrote: > diff --git a/remote.c b/remote.c > index 298f2f93f..720d616be 100644 > --- a/remote.c > +++ b/remote.c > @@ -373,6 +373,8 @@ static int handle_config(const char *key, const char > *value, void *cb) > } > remote = make_remote(name,

Re: [PATCH v4 3/5] name-rev: add support to exclude refs by pattern match

Jacob Keller writes: > From: Jacob Keller > > Extend git-name-rev to support excluding refs which match shell patterns > using --exclude. These patterns can be used to limit the scope of refs > by excluding any ref that matches one of the

Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns

Jacob Keller writes: > From: Jacob Keller > > Teach git name-rev to take multiple --refs stored as a string list of > patterns. The list of patterns will be matched inclusively, and each ref > only needs to match one pattern to be included. A

Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns

Jacob Keller writes: > + if (data->ref_filters.nr) { > + struct string_list_item *item; > + int matched = 0; > + > + /* See if any of the patterns match. */ > + for_each_string_list_item(item, >ref_filters) { > +

Re: [RESEND PATCHv2] contrib: remove git-convert-objects

Stefan Beller writes: > git-convert-objects, originally named git-convert-cache was used in > early 2005 to convert to a new repository format, e.g. adding an author > date. I think this description is not wrong per-se but misses the much more important point. In the very

Re: [RFC for GIT] pull-request: add praise to people doing QA

> So the idea is to have list of those whose names appear on > Reviewed-by: and Tested-by: collected and listed after the list of > commit titles and author names. I personally do not see much > downsides in doing so, but I do not consume that many PRs myself, so > let's hear from those who

[PATCH v6 3/3] Retire the scripted difftool

It served its purpose, but now we have a builtin difftool. Time for the Perl script to enjoy Florida. Signed-off-by: Johannes Schindelin --- .gitignore | 1 - Makefile | 1 -

Re: [PATCH v5 3/3] Retire the scripted difftool

Hi Junio, On Thu, 19 Jan 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Yep, as Git for Windows v2.11.0 is yesteryear's news, it was probably > > obvious to you that I simply failed to spot and fix that oversight. > > OK, if you want to tweak log

Re: problem with insider build for windows and git

Johannes Schindelin writes: >> are there any other topic that are already in 'master' that should go to >> 2.11.x track? > > Personally, I would have merged 'nd/config-misc-fixes' into `maint`, I > guess, and 'jc/abbrev-autoscale-config', and probably also

[RESEND PATCHv2] contrib: remove git-convert-objects

git-convert-objects, originally named git-convert-cache was used in early 2005 to convert to a new repository format, e.g. adding an author date. By now the need for conversion of the very early repositories is less relevant, we no longer need to keep it in contrib; remove it. Signed-off-by:

[PATCH v6 1/3] difftool: add a skeleton for the upcoming builtin

This adds a builtin difftool that still falls back to the legacy Perl version, which has been renamed to `legacy-difftool`. The idea is that the new, experimental, builtin difftool immediately hands off to the legacy difftool for now, unless the config variable difftool.useBuiltin is set to true.

[PATCH v6 0/3] Turn the difftool into a builtin

This patch series converts the difftool from a Perl script into a builtin, for three reasons: 1. Perl is really not native on Windows. Not only is there a performance penalty to be paid just for running Perl scripts, we also have to deal with the fact that users may have different Perl

[PATCH v6 2/3] difftool: implement the functionality in the builtin

This patch gives life to the skeleton added in the previous patch. The motivation for converting the difftool is that Perl scripts are not at all native on Windows, and that `git difftool` therefore is pretty slow on that platform, when there is no good reason for it to be slow. In addition,

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

Jeff King writes: > On Wed, Jan 18, 2017 at 05:22:40PM +0100, Johannes Schindelin wrote: > >> > > I want to err on the side of caution. That's why. >> > >> > I guess I just don't see why changing the behavior with respect to >> > "prune" or "proxy" is any less conservative than

Re: [PATCHv3 1/4] cache.h: document index_name_pos

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > cache.h | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/cache.h b/cache.h > index 1b67f078dd..1469ddeafe 100644 > --- a/cache.h > +++ b/cache.h > @@ -575,7 +575,26

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

On Thu, Jan 19, 2017 at 12:12:47PM -0800, Junio C Hamano wrote: > > The config-scope thing above would allow "remote.svn.vcs" in > > ~/.gitconfig. But I don't think the test script actually checks that; it > > checks for the repo-level config. And we would continue to do the right > > thing

Re: The design of refs backends, linked worktrees and submodules

Hi, On Thu, 19 Jan 2017, Michael Haggerty wrote: > On 01/19/2017 12:55 PM, Duy Nguyen wrote: > > I've started working on fixing the "git gc" issue with multiple > > worktrees, which brings me back to this. Just some thoughts. Comments > > are really appreciated. > > > > In the current code,

Re: [PATCH v5 0/4] Per-worktree config file support

On Thu, Jan 19, 2017 at 4:09 AM, Duy Nguyen wrote: > On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller wrote: >> On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> Let's get this rolling again. To refresh your memory

Re: problem with insider build for windows and git

Hi Junio, On Wed, 18 Jan 2017, Junio C Hamano wrote: > Aside from the "ouch, one topic has merged earlier iteration, that > was merged to 'master', also now merged to 'maint', and we need to > follow up on both" you sent out earlier, I know of one more "ouch" moment where my latest iterations

Re: The design of refs backends, linked worktrees and submodules

Duy Nguyen writes: > ... A bit worried about transactions though, > because I think per-repo and per-worktree updates will be separated in > two transactions. But that's probably ok because future backends, like > lmdb, will have to go through the same route anyway. If we

Re: [PATCH v5 3/3] log --graph: customize the graph lines with config log.graphColors

Junio C Hamano writes: >> Since there's only one line that cares about the result of "colors", >> maybe it would be less confusing to do: >> >> if (!git_config_get-string("log.graphcolors", )) { >> ... parse, etc ... >> graph_set_column_colors(colors.argv,

[RFC/PATCH] Disallow commands from within unpopulated submodules.

Consider you have a submodule at path "sub". What should happen in case you run a command such as "git -C sub add ." ? Here is what currently happens: 1) The submodule is populated, i.e. there is a .git (file/dir) inside "sub". This is equivalent of running "git add ." in the submodule and

Re: Git: new feature suggestion

Hi Linus, Às 6:39 PM de 1/19/2017, Linus Torvalds escreveu: > On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov > wrote: >> >> Still, I welcome you to read the sort-of "reference" post by Linus >> Torvalds [1] in which he explains the reasoning behind this approach >>

Re: [PATCH v3 14/21] read-cache: touch shared index files when used

Duy Nguyen writes: > On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote: Christian Couder writes:

Re: Git: new feature suggestion

On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto wrote: > > I am currently facing some challenges in one of Linux subsystems where a > rename > of a set of folders and files would be the perfect scenario for future > development, but the suggestion is not accepted, not

Re: [PATCH] clear_delta_base_cache(): don't modify hashmap while iterating

Jeff King writes: > Thanks. Here it is rolled up with a commit message. > > -- >8 -- > Subject: clear_delta_base_cache(): don't modify hashmap while iterating > > Removing entries while iterating causes fast-import to > access an already-freed `struct packed_git`, leading to >

Re: grep open pull requests

On Thu, Jan 19, 2017 at 11:12:03AM -0700, Jack Bates wrote: > I have a couple questions around grepping among open pull requests. > > First, "git for-each-ref --no-merged": When I run the following, > it lists refs/pull/1112/head, even though #1112 was merged in commit > ced4da1. I guess this is

Re: [RFC 2/2] grep: use '/' delimiter for paths

On 01/19, Stefan Hajnoczi wrote: > If the tree contains a sub-directory then git-grep(1) output contains a > colon character instead of a path separator: > > $ git grep malloc v2.9.3:t > v2.9.3:t:test-lib.sh: setup_malloc_check () { > $ git show v2.9.3:t:test-lib.sh > fatal: Path

Re: [RFC 2/2] grep: use '/' delimiter for paths

Stefan Hajnoczi writes: > If the tree contains a sub-directory then git-grep(1) output contains a > colon character instead of a path separator: > > $ git grep malloc v2.9.3:t > v2.9.3:t:test-lib.sh: setup_malloc_check () { > $ git show v2.9.3:t:test-lib.sh >

Re: Git: new feature suggestion

On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov wrote: > > Still, I welcome you to read the sort-of "reference" post by Linus > Torvalds [1] in which he explains the reasoning behind this approach > implemented in Git. It's worth noting that that discussion was from

Re: [RFC 1/2] grep: only add delimiter if there isn't one already

Stefan Hajnoczi writes: > git-grep(1) output does not follow git's own syntax: > > $ git grep malloc v2.9.3: > v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc > $ git show v2.9.3::Makefile > fatal: Path ':Makefile' does not exist in 'v2.9.3' > > This

Re: Git: new feature suggestion

Hi, Às 6:33 AM de 1/19/2017, Konstantin Khomoutov escreveu: > On Wed, 18 Jan 2017 10:40:52 + > Joao Pinto wrote: > > [...] >> I have seen a lot of Linux developers avoid this re-organization >> operations because they would lose the renamed file history, because >>

Re: [RFC] stash --continue

On 2017-01-19 10:49 AM, Johannes Schindelin wrote: Hi Marc, On Wed, 18 Jan 2017, Marc Branchaud wrote: On 2017-01-18 11:34 AM, Johannes Schindelin wrote: On Wed, 18 Jan 2017, Marc Branchaud wrote: On 2017-01-16 05:54 AM, Johannes Schindelin wrote: On Mon, 16 Jan 2017, Stephan Beyer

Re: [PATCH v3 1/5] doc: add documentation for OPT_STRING_LIST

Jacob Keller writes: > On Wed, Jan 18, 2017 at 11:45 AM, Junio C Hamano wrote: >> >> I do not know if it is clear enough that 'option' in the last >> sentence is a placeholder. I then wondered if spelling it as >> `--no-` would make it a bit clearer,

Re: [PATCH v5 3/3] log --graph: customize the graph lines with config log.graphColors

Jeff King writes: > On Thu, Jan 19, 2017 at 06:41:23PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> +static void parse_graph_colors_config(struct argv_array *colors, const char >> *string) >> +{ >> +const char *end, *start; >> + >> +start = string; >> +end = string +

Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

On Wed, Jan 18, 2017 at 05:22:40PM +0100, Johannes Schindelin wrote: > > > I want to err on the side of caution. That's why. > > > > I guess I just don't see why changing the behavior with respect to > > "prune" or "proxy" is any less conservative than changing the one for > > "refspec". > >

Re: [PATCH v5 2/3] color.c: trim leading spaces in color_parse_mem()

Jeff King writes: > On Thu, Jan 19, 2017 at 06:41:22PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> Normally color_parse_mem() is called from config parser which trims the >> leading spaces already. The new caller in the next patch won't. Let's be >> tidy and trim leading spaces too

Re: [RFC 0/2] grep: make output consistent with revision syntax

On 01/19, Jeff King wrote: > On Thu, Jan 19, 2017 at 03:03:45PM +, Stefan Hajnoczi wrote: > > > git-grep(1)'s output is not consistent with git-rev-parse(1) revision > > syntax. > > > > This means you cannot take "rev:path/to/file.c: foo();" output from > > git-grep(1) > > and expect "git

Re: Git: new feature suggestion

Konstantin Khomoutov writes: > Still, I welcome you to read the sort-of "reference" post by Linus > Torvalds [1] in which he explains the reasoning behind this approach > implemented in Git. IMO, understanding the reasoning behind the idea > is much better than just

grep open pull requests

I have a couple questions around grepping among open pull requests. First, "git for-each-ref --no-merged": When I run the following, it lists refs/pull/1112/head, even though #1112 was merged in commit ced4da1. I guess this is because the tip of refs/pull/1112/head is 107fc59, not ced4da1?

Re: [PATCH v5 3/3] Retire the scripted difftool

Johannes Schindelin writes: >> Ok, I was mostly reacting to 2/3 while I am reading it: >> >> The reason: this new, experimental, builtin difftool will be shipped as >> part of Git for Windows v2.11.0, to allow for easier large-scale >> testing, but of

Re: [PATCH] log: new option decorate reflog of remote refs

On Thu, Jan 19, 2017 at 07:26:30PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is most useful when you fork your branches off a remote ref and > rely on ref decoration to show your fork points in `git log`. Then you > do a "git fetch" and suddenly the remote decoration is gone because > remote refs

Re: git fast-import crashing on big imports

2017-01-18 22:51 GMT+01:00 Jeff King : > > On Wed, Jan 18, 2017 at 03:27:04PM -0500, Jeff King wrote: > > > On Wed, Jan 18, 2017 at 09:20:07PM +0100, Ulrich Spörlein wrote: > > > > > I found your commit via bisect in case you were wondering. Thanks for > > > picking this up. > > > >

Re: [RFC 0/2] grep: make output consistent with revision syntax

On Thu, Jan 19, 2017 at 03:03:45PM +, Stefan Hajnoczi wrote: > git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax. > > This means you cannot take "rev:path/to/file.c: foo();" output from > git-grep(1) > and expect "git show rev:path/to/file.c" to work. See the

Re: [PATCH v3 1/5] doc: add documentation for OPT_STRING_LIST

Hi Junio, On Wed, 18 Jan 2017, Junio C Hamano wrote: > "Philip Oakley" writes: > > >>> +`OPT_STRING_LIST(short, long, , arg_str, description)`:: > >>> + Introduce an option with string argument. > >>> + The string argument is stored as an element in `` which must be a >

Re: [PATCH v5 3/3] log --graph: customize the graph lines with config log.graphColors

On Thu, Jan 19, 2017 at 06:41:23PM +0700, Nguyễn Thái Ngọc Duy wrote: > +static void parse_graph_colors_config(struct argv_array *colors, const char > *string) > +{ > + const char *end, *start; > + > + start = string; > + end = string + strlen(string); > + while (start < end) { >

Re: [PATCH v5 2/3] color.c: trim leading spaces in color_parse_mem()

On Thu, Jan 19, 2017 at 06:41:22PM +0700, Nguyễn Thái Ngọc Duy wrote: > Normally color_parse_mem() is called from config parser which trims the > leading spaces already. The new caller in the next patch won't. Let's be > tidy and trim leading spaces too (we already trim trailing spaces before >

GOOD NEWS

You are a recipient to Mrs Julie Leach Donation of $2 million USD. Contact (julieleach...@gmail.com) for claims.

Did you get my message this time?

-- Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies

Re: [PATCH v5 1/3] color.c: fix color_parse_mem() with value_len == 0

On Thu, Jan 19, 2017 at 06:41:21PM +0700, Nguyễn Thái Ngọc Duy wrote: > In this code we want to match the word "reset". If len is zero, > strncasecmp() will return zero and we incorrectly assume it's "reset" as > a result. This is probably a good idea. This _is_ user-visible, so it's possible

Re: [PATCH v5 3/3] Retire the scripted difftool

Hi Junio, On Wed, 18 Jan 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Hi Junio, > > > > On Tue, 17 Jan 2017, Junio C Hamano wrote: > > > >> Johannes Schindelin writes: > >> > >> > It served its purpose, but now we

[PATCH] clear_delta_base_cache(): don't modify hashmap while iterating

On Thu, Jan 19, 2017 at 03:03:46PM +0100, Ulrich Spörlein wrote: > > I suspect the patch below may fix things for you. It works around it by > > walking over the lru list (either is fine, as they both contain all > > entries, and since we're clearing everything, we don't care about the > >

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

Hi Junio, On Wed, 18 Jan 2017, Junio C Hamano wrote: > Johannes Sixt writes: > > > Am 17.01.2017 um 20:17 schrieb Junio C Hamano: > >> So... can we move this forward? > > > > I have no objects anymore. > > Alright, thanks. > > Dscho what's your assessment? I still think it

Re: [RFC] stash --continue

Hi Stephan, On Wed, 18 Jan 2017, Stephan Beyer wrote: > PPS: Any opinions about the mentioned "backwards-compatibility" issue > that people are then forced to finish their commits with "--continue" > instead of "git reset" or "git commit"? Maybe you could make it so that "git reset" and "git

Re: [RFC] stash --continue

Hi Marc, On Wed, 18 Jan 2017, Marc Branchaud wrote: > On 2017-01-18 11:34 AM, Johannes Schindelin wrote: > > > > On Wed, 18 Jan 2017, Marc Branchaud wrote: > > > > > On 2017-01-16 05:54 AM, Johannes Schindelin wrote: > > > > > > > On Mon, 16 Jan 2017, Stephan Beyer wrote: > > > > > > > > > a

[RFC 1/2] grep: only add delimiter if there isn't one already

git-grep(1) output does not follow git's own syntax: $ git grep malloc v2.9.3: v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc $ git show v2.9.3::Makefile fatal: Path ':Makefile' does not exist in 'v2.9.3' This patch avoids emitting the unnecessary ':' delimiter if the name

[RFC 2/2] grep: use '/' delimiter for paths

If the tree contains a sub-directory then git-grep(1) output contains a colon character instead of a path separator: $ git grep malloc v2.9.3:t v2.9.3:t:test-lib.sh: setup_malloc_check () { $ git show v2.9.3:t:test-lib.sh fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3' This patch

[RFC 0/2] grep: make output consistent with revision syntax

git-grep(1)'s output is not consistent with git-rev-parse(1) revision syntax. This means you cannot take "rev:path/to/file.c: foo();" output from git-grep(1) and expect "git show rev:path/to/file.c" to work. See the individual patches for examples of command-lines that produce invalid output.

Re: The design of refs backends, linked worktrees and submodules

On 01/19/2017 12:55 PM, Duy Nguyen wrote: > I've started working on fixing the "git gc" issue with multiple > worktrees, which brings me back to this. Just some thoughts. Comments > are really appreciated. > > In the current code, files backend has special cases for both > submodules (explicitly)

Re: merge maintaining history

On 01/14/2017 10:24 PM, Jacob Keller wrote: > On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman wrote: >> History >> >> git cloned a remote repository and made many changes pushing them all to >> said repository over many months. >> >> The powers that be then required me to

[PATCH] log: new option decorate reflog of remote refs

This is most useful when you fork your branches off a remote ref and rely on ref decoration to show your fork points in `git log`. Then you do a "git fetch" and suddenly the remote decoration is gone because remote refs are moved forward. With this, we can still see something like "origin/foo@{1}"

Re: [PATCH v3 14/21] read-cache: touch shared index files when used

On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote: >>> Christian Couder writes: >>> So what should we do if

Re: [PATCH v5 0/4] Per-worktree config file support

On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller wrote: > On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy > wrote: >> Let's get this rolling again. To refresh your memory because it's half >> a year since v4 [1], this is about letting each worktree in

Re: [PATCH/RFC 5/4] Redefine core.bare in multiple working tree setting

Thanks. I'll shelve this for now, maybe sleep on it for a while. The series is complete without this patch by the way, if you want to pick it up. On Fri, Jan 13, 2017 at 6:08 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> With per-worktree

The design of refs backends, linked worktrees and submodules

I've started working on fixing the "git gc" issue with multiple worktrees, which brings me back to this. Just some thoughts. Comments are really appreciated. In the current code, files backend has special cases for both submodules (explicitly) and linked worktrees (hidden behind git_path). But if

[PATCH v5 3/3] log --graph: customize the graph lines with config log.graphColors

If you have a 256 colors terminal (or one with true color support), then the predefined 12 colors seem limited. On the other hand, you don't want to draw graph lines with every single color in this mode because the two colors could look extremely similar. This option allows you to hand pick the

[PATCH v5 2/3] color.c: trim leading spaces in color_parse_mem()

Normally color_parse_mem() is called from config parser which trims the leading spaces already. The new caller in the next patch won't. Let's be tidy and trim leading spaces too (we already trim trailing spaces before comma). Signed-off-by: Nguyễn Thái Ngọc Duy --- color.c |

[PATCH v5 1/3] color.c: fix color_parse_mem() with value_len == 0

In this code we want to match the word "reset". If len is zero, strncasecmp() will return zero and we incorrectly assume it's "reset" as a result. Signed-off-by: Nguyễn Thái Ngọc Duy --- color.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/color.c b/color.c index

[PATCH v5 0/3] nd/log-graph-configurable-colors

v5 moves space trimming to color_parse_mem() from read_graph_colors_config, which is renamed to parse_graph... because the config reading is moved back to graph_init. I think it looks better, but we may be pushing the limits of argv_array's abuse. Nguyễn Thái Ngọc Duy (3): color.c: fix

  1   2   >