>> 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 optional env variable for the ne
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 doesn't for me.
A
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
---
contrib/completi
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?
>
> https://patchwork.kernel.org/patch/9307703
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 "trailers" code
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. Bu
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 matched inclusively, and each ref
>> only needs to match one pattern to be i
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 another parser of tra
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 bee
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 matched inclusively, and each ref
>> only needs to match one pattern to be i
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 supposed to
be constant an
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 --right-o
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 --format
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 description is not wrong per-se but misses
> > 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
> > d
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
>>> rename
>>> of a set of folders and files would be the
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 powers that be then required me to move projec
À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
>> development, but the sugges
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 just writing to
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 in Git.
>
> It's worth
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 probably a tang
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)
> git_con
"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 push that to both
>>
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 G
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 that
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, "interpret-traile
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 things my AWK script c
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, 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 --exclude patterns. A ref
> will only be used for naming
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 ref will only be
> excluded if it does not match any
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, &data->ref_filters) {
> + /* Che
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 early days of Git, the
> 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 actua
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 -
builtin/difftool.c
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 message of either 2/3 or 3/3 t
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 'jc/latin-1'.
The "almost ready" pushou
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: Stef
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 insta
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, Perl
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 changing the one
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 @@ extern int verify_path(const char *pa
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 there.
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, file
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 because it's half
>>> a year since v4 [1], this is about lettin
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 di
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 have per-worktree ref-s
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", &string)) {
>> ... parse, etc ...
>> graph_set_column_colors(colors.argv, colors.argc - 1);
>>
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
i
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
>> implemented in Git.
>
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:
> So what should we do if freshen_file() returns 0 which means that the
> freshening failed?
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 because it's not correct,
> but
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
> various confusing e
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 't:
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
> fatal: Path 't:test-lib
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 some _very_ early days
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 patch avoids emitting the
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
>> a new log is created for
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 wrote
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, but that is ugly.
>
> To be fair, this is ex
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 + strlen(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".
>
> Let
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 (we already trim t
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 s
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 mechanically learning how to
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?
Th
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 course as an opt-in feature.
>>
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.
> >
> > Still downloadi
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 indi
Hi Junio,
On Wed, 18 Jan 2017, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
> >>> +`OPT_STRING_LIST(short, long, &list, arg_str, description)`::
> >>> + Introduce an option with string argument.
> >>> + The string argument is stored as an element in `&list` which must be a
> >>> + struct s
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
> co
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
som
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 have a builtin difftool. Time for the
> >> > Perl script to
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
> > order).
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 will be a proble
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 com
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-
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
al
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 a
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.
Th
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 move project to new rep
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 freshen_file() returns 0 which means that the
freshening failed?
>>>
>>> You tell me ;-) as y
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 multi
>> worktree setup has their own c
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 configuration in place, core.bare is mov
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 col
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 | 7 ++-
1 file ch
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 81c2676..a9eadd1 10064
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 color_pa
1 - 100 of 104 matches
Mail list logo
