>> 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
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
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
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
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?
>
>
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
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.
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
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
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
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
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
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
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
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
> > 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
> >
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
>>>
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
À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
>>
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
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
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
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)
>
"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
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
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
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
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
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,
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
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
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,
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
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
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) {
> +
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
> 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
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 -
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
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
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:
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.
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
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,
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
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
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
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,
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
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
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
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,
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
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
>>
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:
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
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
>
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
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
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
>
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
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
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
>>
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
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,
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 +
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".
>
>
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
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
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
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?
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
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
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.
> >
> >
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
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
>
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) {
>
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
>
You are a recipient to Mrs Julie Leach Donation of $2 million USD.
Contact (julieleach...@gmail.com) for claims.
--
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
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
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
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
> >
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
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
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
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
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
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.
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)
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
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}"
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
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
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
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
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
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 |
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
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 - 100 of 104 matches
Mail list logo