Octave pattern is almost the same as matlab. Besides,
octave also uses '%%%' or '##' to begin code sections.
Signed-off-by: Boxuan Li
---
Update from v2: fix indentation
---
Documentation/gitattributes.txt | 2 ++
userdiff.c | 5 +
2 files changed, 7 insertions(+)
diff
Octave pattern is almost the same as matlab. Besides,
octave also uses '%%%' or '##' to begin code sections.
Signed-off-by: Boxuan Li
---
v1: use matlab pattern for octave language
---
Documentation/gitattributes.txt | 2 ++
userdiff.c | 5 +
2 files changed, 7 insertion
On Sat, May 11, 2019 at 7:26 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, May 10 2019, Boxuan Li wrote:
>
> > `matlab` pattern is also suitable for source code
> > in the GNU Octave language.
> >
> > Signed-off-by: Boxuan Li
> > ---
> > Documentation/gitattributes.txt | 2 +-
> > 1 file chang
Do not change the existing info/refs and objects/info/packs
files if they match the existing content on the filesystem.
This is intended to preserve mtime and make it easier for dumb
HTTP pollers to rely on the If-Modified-Since header.
Combined with stdio and kernel buffering; the kernel should b
For thoroughness when checking for one-shot environment variable
assignments at shell function call sites, check-non-portable-shell
stitches together incomplete lines (those ending with backslash). This
allows it to correctly flag such undesirable usage even when the
variable assignment and functio
Hey all
Thanks for welcoming me to the community. To inform more people about
the progress of my GSoC project and workings at Git, I am thinking of
starting a blog series on my website[1]. Please find time to read some
of the blogs and comment on them.
Thanks
Rohit
---
[1]: rashiwal.me
PS: comme
On Fri, May 10 2019, Boxuan Li wrote:
> `matlab` pattern is also suitable for source code
> in the GNU Octave language.
>
> Signed-off-by: Boxuan Li
> ---
> Documentation/gitattributes.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitattributes.txt
On 10/05/2019 01:47, Boxuan Li wrote:
`matlab` pattern is also suitable for source code
in the GNU Octave language.
Signed-off-by: Boxuan Li
---
Documentation/gitattributes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitattributes.txt b/Documentation
On Fri, May 10 2019, Jeff King wrote:
> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> As noted in TODOs in the script there's various stuff I'd like to do
>> better, and this also shows how we need a lot more trace regions to get
>> granular data.
>
> Hmm. My gut
On Fri, May 10, 2019 at 07:18:44PM +0200, René Scharfe wrote:
> Am 09.05.19 um 20:38 schrieb Jeff King:
> > I do dream of a world where we do not have a bunch of implicit
> > conversions (both signedness but also truncation) in our code base, and
> > can compile cleanly with -Wconversion We know t
Thanks for the quick turnaround.
On Fri, May 10, 2019 at 12:44:26PM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> Documentation/technical/api-trace2.txt contains the full details
> of the trace2 API and the GIT_TR2* environment variables. However,
> most environment
On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
> As noted in TODOs in the script there's various stuff I'd like to do
> better, and this also shows how we need a lot more trace regions to get
> granular data.
Hmm. My gut reaction was: doesn't "perf record -g make test" a
This test used an author with non-ascii characters in the name, but
no special commit message. It then grep'ed for those non-ascii
characters, but those are guaranteed to exist regardless of the
reencoding process since the reencoding only affects the commit message,
not the author or committer na
Since git supports commit messages with an encoding other than utf-8,
allow fast-import to import such commits. This may be useful for folks
who do not want to reencode commit messages from an external system, and
may also be useful to achieve reversible history rewrites (e.g. sha1sum
<-> sha256su
When fast-export encounters a commit with an 'encoding' header, it tries
to reencode in utf-8 and then drops the encoding header. However, if it
fails to reencode in utf-8 because e.g. one of the characters in the
commit message was invalid in the old encoding, then we need to retain
the original
The find_encoding() function returned the encoding used by a commit
message, returning a default of git_commit_encoding (usually utf-8).
Although the current code does not differentiate between a commit which
explicitly requested utf-8 and one where we just assume utf-8 because no
encoding is set,
Automatic re-encoding of commit messages (and dropping of the encoding
header) hurts attempts to do reversible history rewrites (e.g. sha1sum
<-> sha256sum transitions, some subtree rewrites), and seems
inconsistent with the general principle followed elsewhere in
fast-export of requiring explicit
While stress testing `git filter-repo`, I noticed an issue with
encoding; further digging led to the fixes and features in this series.
See the individual commit messages for details.
Changes since v2 (full range-diff below):
* Modified the testcases to pass on Windows[1], as verified via
gi
On Thu, May 9, 2019 at 8:33 AM Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 09 2019, Eric Sunshine wrote:
> > Although this implementation is well supported in reasonably modern Perl
> > versions (5.10 and later), it fails in a couple ways with older versions
> > (such as Perl 5.8 shipped with anc
Those label commands are currently displayed with their argument resolved as
abbreviated commit hash. Not really what we want. We really want the label
names instead.
Johannes Schindelin (1):
status: fix display of rebase -ir's `label` command
wt-status.c | 4 +++-
1 file changed, 3 insertions
From: Johannes Schindelin
The argument of a `label` command does *not* want to be turned into an
abbreviated SHA-1.
Signed-off-by: Johannes Schindelin
---
wt-status.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 1f564b12d2..5fc7de6027 1
On 5/10/2019 1:28 PM, SZEDER Gábor wrote:
> On Fri, Feb 22, 2019 at 02:25:01PM -0800, Jeff Hostetler via GitGitGadget
> wrote:
>> From: Jeff Hostetler
>>
>> * GIT_TR2_EVENT is a new structured format. It writes event data as a
>> series of JSON records.
>
> Please document these new environmen
Jeff is out this week, so I picked up this request from Szeder. I'm very
open to edit suggestions.
Thanks, -Stolee
In-Reply-To: 20190510172824.gr14...@szeder.dev
Derrick Stolee (1):
trace2: Add variable description to git.txt
Documentation/git.txt | 21 +
1 file changed,
From: Derrick Stolee
Documentation/technical/api-trace2.txt contains the full details
of the trace2 API and the GIT_TR2* environment variables. However,
most environment variables are included in Documentation/git.txt,
including the GIT_TRACE* variables.
Add a brief description of the GIT_TR2* v
Internally, git-format-patch uses the `handle_revision_opt` parser. The
parser handles the `--no-notes` option to negate an earlier `--notes`
option, but it isn't documented. Document this option so that users are
aware of it.
Signed-off-by: Denton Liu
---
Documentation/git-format-patch.txt | 4
Hi Beat, thanks for catching the style errors. This version fixes those.
Changes since v2:
* Fixed if-else code style
* Fixed typoed errors in 2/2 log message
Changes since v1:
* Made format.notes accept a notes ref instead of a boolean
Denton Liu (2):
git-format-patch.txt: document --no-no
In git-format-patch, notes can be appended with the `--notes` option.
However, this must be specified by the user on an
invocation-by-invocation basis. If a user is not careful, it's possible
that they may forget to include it and generate a patch series without
notes.
Teach git-format-patch the `
On Fri, Feb 22, 2019 at 02:25:01PM -0800, Jeff Hostetler via GitGitGadget wrote:
> From: Jeff Hostetler
>
> Create a new unified tracing facility for git. The eventual intent is to
> replace the current trace_printf* and trace_performance* routines with a
> unified set of git_trace2* routines.
>
Am 09.05.19 um 20:38 schrieb Jeff King:
> I do dream of a world where we do not have a bunch of implicit
> conversions (both signedness but also truncation) in our code base, and
> can compile cleanly with -Wconversion We know that this case is
> perfectly fine, but I am sure there are many that ar
On Fri, May 10, 2019 at 12:38:52PM -0400, Derrick Stolee wrote:
> export GIT_TR2_EVENT=~/git-tr2-event.txt
Hrm, better late than never, or at least better late than after it's
in a release...
Why does an environment variable that is supposed to be set by users
have this "TR2" abbreviation in its
On 07/05/2019 05:19, Junio C Hamano wrote:
The principle is "the bulk of the work was done in A, no matter what
is done incrementally by squashing in or amending small refinements;
the primary authorship date and time stays the same as the original".
When the person who is correcting other's cha
On 5/10/2019 11:09 AM, Ævar Arnfjörð Bjarmason wrote:
> Here's a flamegraph of where git's test suite spends its time on my box:
> https://vm.nix.is/~avar/noindex/git-tests.svg
>
> I hacked up a script for this today to plot trace2 production data, as
> noted there it's at:
> https://github.com/av
git p4 unshelve was failing with "fatal: Not a valid object name HEAD0" and
"Command failed: git cat-file commit HEAD^0" on certain systems e.g. git
version 2.21.0.windows.1 + python 2.7.16
It seems that certain python pOpen implementations drop the ^ character when
invoked using a string instead
From: Mike Mueller
git p4 unshelve was failing with these errors on Windows:
fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0
(git version 2.21.0.windows.1, python 2.7.16)
The pOpen call used by git-p4 to invoke the git command can take either a
string or an arra
Hi Torsten,
On 10/05/2019 15:05, Torsten Bögershausen wrote:
On Fri, May 10, 2019 at 12:23:28AM +0100, Philip Oakley wrote:
Hi,
Is there a mechanism for exchanging the rerere resolutions, so that future
fixups, e.g. future clashes on pu rather than master, can be sent with patch
series?
My cu
Here's a flamegraph of where git's test suite spends its time on my box:
https://vm.nix.is/~avar/noindex/git-tests.svg
I hacked up a script for this today to plot trace2 production data, as
noted there it's at:
https://github.com/avar/FlameGraph/tree/stackcollapse-git-tr2-event
What are flamegrap
On 10/05/2019 00:49, Ævar Arnfjörð Bjarmason wrote:
On Fri, May 10 2019, Philip Oakley wrote:
Is there a mechanism for exchanging the rerere resolutions, so that
future fixups, e.g. future clashes on pu rather than master, can be
sent with patch series?
My current use case that there is a larg
On Fri, May 10, 2019 at 12:23:28AM +0100, Philip Oakley wrote:
> Hi,
>
> Is there a mechanism for exchanging the rerere resolutions, so that future
> fixups, e.g. future clashes on pu rather than master, can be sent with patch
> series?
>
> My current use case that there is a large patch [1] for up
Hi Phillip,
On Thu, 9 May 2019, Phillip Wood wrote:
> On 08/05/2019 18:23, Junio C Hamano wrote:
> > * pw/rebase-abort-clean-rewritten (2019-05-08) 1 commit
> > - rebase --abort: cleanup refs/rewritten
> > (this branch uses pw/rebase-i-internal.)
> >
> > "git rebase --abort" used to leave r
Ævar Arnfjörð Bjarmason writes:
> This is a proposed replacement for Junio's version of the
> ... the
> root cause is that we're needlessly doing the config->cli parsing in
> the wrong order, so let's just fix that.
Yup, that's absolutely the right approach. I just wanted to avoid
restructurin
Hi Hannes & Elijah,
On Fri, 10 May 2019, Johannes Sixt wrote:
> Am 10.05.19 um 02:14 schrieb Elijah Newren:
> > Hi Johannes,
> >
> > On Thu, May 9, 2019 at 1:46 PM Johannes Schindelin
> > wrote:
> >>
> >> Hi Junio & Elijah,
> >>
> >> On Thu, 9 May 2019, Junio C Hamano wrote:
> >>
> >>> * en/fast
On 5/10/2019 9:37 AM, Ævar Arnfjörð Bjarmason wrote:
> Fix a trivial bug that's been here since the shared/do_write_index
> tracing was added in 42fee7a388 ("trace2:data: add trace2
> instrumentation to index read/write", 2019-02-22). We should have
> enter/leave points, not two enter/enter points.
Fix a trivial bug that's been here since the shared/do_write_index
tracing was added in 42fee7a388 ("trace2:data: add trace2
instrumentation to index read/write", 2019-02-22). We should have
enter/leave points, not two enter/enter points. This resulted in an
"enter" event without a corresponding "l
On 5/9/2019 5:45 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, May 09 2019, Derrick Stolee wrote:
>
>> How far apart can these concurrency issues happen in the file system?
>> One benefit to Option 0 is that there is only one file _write_ that matters.
>> The other options require at least two w
On 5/9/2019 5:32 PM, Jeff King wrote:
> Instead, let's do our type check by loading the object via
> parse_object(). That will attach the buffer to the struct so it can be
> used later by check_commit_signature(). And it ensures that
> lookup_commit() will return something sane.
This is a good ide
On 5/9/2019 5:25 PM, Jeff King wrote:
> This is a continuation of my efforts to get us compiling with
> -Wunused-parameter. This round finishes most of the cleanups and fixes
> I intend to do (though I have a handful of cleanup cases that I'm still
> poking at to make sure they're not in fact bugs
On 5/9/2019 5:28 PM, Jeff King wrote:
> If a builtin uses RUN_SETUP to request that git.c enter the repository
> directory, we'll get passed in a "prefix" variable with the path to the
> original directory. It's important to pass this to parse_options(),
> since we may use it to fix up relative OP
On 5/9/2019 5:27 PM, Jeff King wrote:
> I kind of hate "cmd_prefix"; I was tempted to just call it "prefix" so
> that all of the cmd_* functions were consistent, but I worried that it
> really would get confused with the local variables (even if those
> variables are renamed, as I do here).
cmd_pr
During git-init we chdir() to the target directory, but --template is
not adjusted. So it's relative to the target directory instead of
current directory.
It would be ok if it's documented, but --template in git-init.txt
mentions nothing about this behavior. Change it to be relative to $CWD,
which
On Fri, May 10, 2019 at 2:07 AM Jack Zylkin wrote:
>
> The “git init” documentation for the “Template Directory” states that:
>
>
> “Files and directories in the template directory whose name do not
> start with a dot will be copied to the $GIT_DIR after it is created.”
>
>
> However, I put a file
On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin
wrote:
>
> Hi Junio & Duy,
>
> On Thu, 9 May 2019, Junio C Hamano wrote:
>
> > * nd/merge-quit (2019-05-07) 2 commits
> > - merge: add --quit
> > - merge: remove drop_save() in favor of remove_merge_branch_state()
> >
> > "git merge" learned "
At a checkpoint, fast-import resets all branches and tags on disk to the
OID that we have in memory. If --force is not given, only branch resets
that result in fast forwards with respect to the state on disk are
allowed.
With this approach, even for refs that fast-import has not been
commanded to
On Fri, May 10, 2019 at 2:59 AM Carlo Marcelo Arenas Belón
wrote:
> In function 'finish_request',
> inlined from 'process_response' at http-push.c:248:2:
> http-push.c:587:4: warning: '%s' directive argument is null
> [-Wformat-overflow=]
> 587 |fprintf(stderr, "Unable to get pack file
53 matches
Mail list logo
