Alex Vandiver writes:
> ba1b9caca6 resolved the problem of the fsmonitor data being applied to
(from SubmittingPatches)
If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated sha1 (subject, date)",
with the subject enclosed in a pair of double-
Alex Vandiver writes:
This comment is only so that I do not keep editing them while queuing..
> Subject: Re: [PATCH 1/2] fsmonitor: Read from getcwd(), not the PWD
> environment variable
Downcase "Read" (or any word after ": " on the commit title).
> Though the process has chdir'd to the root
Stefan Beller writes:
> We have no worktree specific config yet, though patches for
> this were floated on the mailing list.
>
> Though recent versions of git learned to conditionally include
> config files. (look for includeIf in man git-config), which I think
> could be used to set the option g
Ben Peart writes:
> To make this work for V4 indexes, when writing the index, it periodically
> "resets" the prefix-compression by encoding the current entry as if the
> path name for the previous entry is completely different and saves the
> offset of that entry in the IEOT. Basically, with V4
On 09-11-17, 11:14, Stefan Beller wrote:
> The proposed approach above might be hacky but sounds as if
> it should work?
Yeah its hacky for sure, but it solved my problem. Thanks for your
help Stefan :)
--
viresh
On Thu, Nov 9, 2017 at 12:16 PM, Stefan Beller wrote:
> On Wed, Nov 8, 2017 at 10:54 PM, Jacob Keller wrote:
>> On Wed, Nov 8, 2017 at 4:10 PM, Stefan Beller wrote:
The relationship is indeed currently useful, but if the long term plan
is to strongly discourage detached submodule HEAD,
Eric Sunshine writes:
> or against the change:
>
> - synonym bloat; balloons documentation
> - steals command verbs from potential future features
> - ...
I tend to agree with these two (and if I were to replace the "..."
with something concrete, this change is not desirable because
"Philip Oakley" writes:
> From: "Stefan Beller"
>> Rereading this discussion, there is currently no urgent thing to address?
>
> True.
>
>> Then the state as announced by the last cooking email, to just cook
>> it, seems
>> about right and we'll wait for further feedback.
A shiny new toy that i
When using git-blame lots of lines contain redundant information, for
example in hunks that consist of multiple lines, the metadata (commit
name, author, date) are repeated. A reader may not be interested in those,
so offer an option to color the information that is repeated from the
previous line
Unlike the previous commit, this dims colors for each
metadata field individually.
Signed-off-by: Stefan Beller
---
builtin/blame.c | 82 +++--
t/t8012-blame-colors.sh | 38 +++
2 files changed, 111 insertions(+), 9 deletion
Choose a different color for dates and imitate a 'temperature cool down'
for the dates.
Signed-off-by: Stefan Beller
---
Documentation/config.txt | 20 +
builtin/blame.c | 74 +++-
2 files changed, 93 insertions(+), 1 deletion(-)
This is picking up [1], but presenting it in another approach,
as I realized these are orthogonal features:
* dimming repeated lines/fields of information
* giving a quick visual information how old (as a proxy for 'well tested')
a line of code is.
Both features are configurable.
Any feedback
Signed-off-by: Stefan Beller
---
color.c | 2 --
color.h | 48 +++-
2 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/color.c b/color.c
index 9a9261ac16..e43da3ce53 100644
--- a/color.c
+++ b/color.c
@@ -400,8 +400,6 @@ static int color_
Jeff King writes:
> Yeah, I think the original sin is using " -> " in the --porcelain output
> (which just got it from --short). That should have been a HT all along
> to match the rest of the diff code. The --porcelain=v2 format gets this
> right.
So we at lesat did something right, which is a
From: "Stefan Beller"
Rereading this discussion, there is currently no urgent thing to address?
True.
Then the state as announced by the last cooking email, to just cook it,
seems
about right and we'll wait for further feedback.
Possibly only checking the documenation aspects, so folks do
Torsten Bögershausen writes:
> Here is a somwhat shorter description:
>
> Apply the "clean" process freshly to all tracked files.
> This is useful after changing `core.autocrlf` or the `text`
> attributes in the `.gitattributes` file because
> Git may not consider these files as changed.
I think
From: "Junio C Hamano"
Sent: Wednesday, November 08, 2017 1:59 AM
"Philip Oakley" writes:
But...
...
This change causes quite a few tests to fall over; however, they
all have truncated-something-longer-ellipses in their
raw-diff-output expected sections, and removing the ellipses
from ther
Add the configuration option "jump.grepCmd" that allows to configure the
command that is used to search in grep mode. This allows the users of
git-jump to use ag(1) or ack(1) as search engines.
Signed-off-by: Beat Bolli
---
contrib/git-jump/README | 3 +++
contrib/git-jump/git-jump | 7 +--
Rereading this discussion, there is currently no urgent thing to address?
Then the state as announced by the last cooking email, to just cook it, seems
about right and we'll wait for further feedback.
Thanks,
Stefan
On Wed, Nov 8, 2017 at 10:54 PM, Jacob Keller wrote:
> On Wed, Nov 8, 2017 at 4:10 PM, Stefan Beller wrote:
>>> The relationship is indeed currently useful, but if the long term plan
>>> is to strongly discourage detached submodule HEAD, then I would think
>>> that these patches are in the wrong
A couple further patches for the fsmonitor branch, which ideally I'd
have noticed before my previous series landed.
In the first patch I believe I've found the underlying reason for the
PWD confusion in the previous go-around -- but I'm not sure I'm wholly
convinced about my solution to it. Speci
ba1b9caca6 resolved the problem of the fsmonitor data being applied to
the non-base index when reading; however, a similar problem exists
when writing the index. Specifically, writing of the fsmonitor
extension happens only after the work to split the index has been
applied -- as such, the informa
Though the process has chdir'd to the root of the working tree, the
PWD environment variable is only guaranteed to be updated accordingly
if a shell is involved -- which is not guaranteed to be the case.
That is, if `/usr/bin/perl` is a binary, $ENV{PWD} is unchanged from
whatever spawned `git` --
On Wed, Nov 8, 2017 at 9:08 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> The relationship is indeed currently useful, but if the long term plan
>>> is to strongly discourage detached submodule HEAD, then I would think
>>> that these patches are in the wrong direction. (If the long term
On Thu, Nov 9, 2017 at 2:58 AM, Viresh Kumar wrote:
> Hi,
>
> I have a typical use case, where I am using the same
> repository for both Android and Linux kernel branches.
>
> Android needs us to keep a special hook "commit-msg"
> which adds a "Change-Id" to every commit we create.
The standard h
Dear,
Please confirm back, can your account receive $7,500.000.00 Million? Reply so
we can discuss details and what will be your commission. The transaction is
genuine; I took the decision because of pressure on me I decided to leave my
country for the safety of my live and son.Remember to sen
[]
>
> If we had such a term in Documentation/glossary-contents.txt, we
> could even say
>
> Add contents of all paths to the index by freshly applying
> the "clean" process, even to the ones Git may think are
> unmodified in the working tree since they were added the
> la
On Thu, Nov 9, 2017 at 8:46 AM, Adam Dinwoodie wrote:
> Add `git notes rm` and `git notes delete` as alternative ways of saying
> `git notes remove`.
The justification for this change seems to be missing from the commit message.
One can formulate arguments for the change:
- "rm" & "delete"
On Thu, Nov 9, 2017 at 8:08 AM, Adam Dinwoodie wrote:
> The examples and common practice for adding markers such as "RFC" or
> "v2" to the subject of patch emails is to have them within the same
> brackets as the "PATCH" text, not after the closing bracket. Further,
> the practice of `git format-
Signed-off-by: Ramsay Jones
---
Hi Jeff,
If you need to re-roll your 'jh/fsck-promisors' branch, could you
please squash this into the relevant patch (commit 1a4b4ca4e9,
"introduce fetch-object: fetch one promisor object", 02-11-2017).
[This silences a sparse warning].
Also, I notice that par
This includes the core.fastindex setting, the update-index additions,
and the fastindex index extension.
Signed-off-by: Ben Peart
---
Documentation/config.txt | 8
Documentation/git-update-index.txt | 11 +++
Documentation/technical/index-format.txt | 26 +
This patch helps address the CPU cost of loading the index by adding
additional data to the index that will allow us to multi-thread the
loading and conversion of cache entries.
It accomplishes this by adding an (optional) index extension that is a
table of offsets to blocks of cache entries in th
Add support in update-index to manually add/remove the fastindex
extension via --[no-]fastindex flags.
Signed-off-by: Ben Peart
---
builtin/update-index.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index fefbe60167.
Add a test utility (test-dump-fast-index) that dumps the contents of the
IEOT to stdout. This enables checking the existance of the extension
and the ability to parse and output its contents.
Add a test utility (test-fast-index) that loads the index using the
fastindex logic then loads it using t
This patch will help address the CPU cost of loading the index by adding
a table of contents extension to the index that will allow us to
multi-thread the loading and conversion of cache entries from the on-disk
format, to the in-memory format. This is particularly beneficial
with large indexes an
Add `git notes rm` and `git notes delete` as alternative ways of saying
`git notes remove`.
Signed-off-by: Adam Dinwoodie
---
Documentation/git-notes.txt | 4 +++-
builtin/notes.c | 8 +---
t/t3301-notes.sh| 6 +++---
3 files changed, 11 insertions(+), 7 deletions(-)
On Thu, Nov 09, 2017 at 12:26:20PM +0900, Junio C Hamano wrote:
> The difference in d->head_path part is dealing about renames, which
> is irrelevant for showing unmerged paths, but the key difference is
> that the _unmerged() forgets to add the enclosing "" around the
> result of quote_path().
>
The examples and common practice for adding markers such as "RFC" or
"v2" to the subject of patch emails is to have them within the same
brackets as the "PATCH" text, not after the closing bracket. Further,
the practice of `git format-patch` and the like, as well as what appears
to be the more com
On Wednesday 08 November 2017 at 09:10 am -0500, Eric Sunshine wrote:
> On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie wrote:
> > +e-mail discussions. Use of markers in addition to PATCH within
> > +the brackets to describe the nature of the patch is also
> > +encouraged. E.g. [RFC PATCH] is oft
---
Documentation/howto/new-command.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/howto/new-command.txt
b/Documentation/howto/new-command.txt
index 15a4c8031f1f3..ac73c98be72de 100644
--- a/Documentation/howto/new-command.txt
+++ b/Documentation/howto
Hi,
I have a typical use case, where I am using the same
repository for both Android and Linux kernel branches.
Android needs us to keep a special hook "commit-msg"
which adds a "Change-Id" to every commit we create.
While this works fine with Android, the behavior doesn't change
by simply chang
I Will send the modification in the next patch, I prefer to refractor
a part of the code before.
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 2208dcc21..665c47d15 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -57,6 +57,7 @@ git send-email --dump-alias
42 matches
Mail list logo