On Mon, Sep 16, 2019 at 04:13:49PM -0700, Jonathan Nieder wrote:
> Most tests use "setup" or "set up" in the names of test assertions
> that are required by later tests. It's very helpful for debugging and
> maintenance to be able to skip or reorder some tests, so I've been
> able to rely on this
Jonathan Tan wrote:
> This was raised by a coworker at $DAYJOB. I run the following script:
[reproduction recipe from (*) snipped]
> The cherry-pick must be manually resolved, when I would expect it to
> happen without needing user intervention.
>
> You can see that at the point of the cherry-pick
Hello all,
I just wanted to report that t7030 is flaky. I first noticed this on
Szeder's Travis job[1]. I was also able to reproduce this on my Macbook
with gpg (GnuPG) 2.2.17 and git version 2.23.0.248.g3a9dd8fb08 (latest
master) by running `./t7030-verify-tag.sh --stress`.
I'll try to investiga
SZEDER Gábor wrote:
> On Mon, Sep 16, 2019 at 11:42:08AM -0700, Emily Shaffer wrote:
>> - try and make progress towards running many tests from a single test
>>file in parallel - maybe this is too big, I'm not sure if we know how
>>many of our tests are order-dependent within a file for n
On Mon, Aug 26, 2019 at 09:29:58AM -0700, Garima Singh via GitGitGadget wrote:
> From: Garima Singh
>
> Add --[no-]progress to git commit-graph write and verify.
> The progress feature was introduced in 7b0f229
> ("commit-graph write: add progress output", 2018-09-17) but
> the ability to opt-out
On Mon, Sep 16, 2019 at 02:47:07PM -0700, Jonathan Tan wrote:
> This was raised by a coworker at $DAYJOB. I run the following script:
>
> $GIT init test && cd test
> ln -s . foo
> mkdir bar && touch bar/file
> $GIT add foo bar/file
> $GIT commit -m "foo symlink"
>
> $GIT checkout -b
* expand the comment to show what it's used for
* alphabetical ordering fix
Signed-off-by: Denton Liu
---
Makefile | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 522342a46c..617c25d16b 100644
--- a/Makefile
+++ b/Makefile
@@ -1147,12 +1147
It looks like git-svn has mostly killed SVN(*), but commands like
"git svn find-rev" and maybe "git svn log" will continue to be
useful for projects that already migrated to git.
So I'm hoping to find time at some point in the future to port
some non-libsvn-dependent parts over to C, and maybe imp
This was raised by a coworker at $DAYJOB. I run the following script:
$GIT init test && cd test
ln -s . foo
mkdir bar && touch bar/file
$GIT add foo bar/file
$GIT commit -m "foo symlink"
$GIT checkout -b branch1
$GIT commit --allow-empty -m "empty commit"
$GIT checkout master
On Mon, Sep 16, 2019 at 11:42:08AM -0700, Emily Shaffer wrote:
> - try and make progress towards running many tests from a single test
>file in parallel - maybe this is too big, I'm not sure if we know how
>many of our tests are order-dependent within a file for now...
Forget it, too many
Emily Shaffer wrote:
> Jonathan Tan, Jonathan Nieder, Josh Steadmon and I met on Friday to talk
> about projects and we came up with a trimmed list; not sure what more
> needs to be done to make them into fully-fledged proposals.
> For the longer projects, we came up with a few more:
> - ad
Queued; thanks.
Denton Liu writes:
> +# THIRD_PARTY_SOURCES is a list of patterns compatible with
> +# the $(filter) and $(filter-out) family of functions
That defines the format, but does it convey what they want to
achieve to the readers? "... to catch the list of source files
we borrowed from elsewhere" or
This reverts commit 5b12e3123b (progress: use term_clear_line(),
2019-06-24), because covering up the entire last line while refreshing
the progress line caused unexpected problems during 'git
clone/fetch/push':
$ git clone ssh://localhost/home/szeder/src/tmp/linux.git/
Cloning into 'linux'...
On Thu, Aug 22, 2019 at 12:29:08PM -0400, Jeff King wrote:
> On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
>
> > On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> > > By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> > > problem with the display of pro
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading inst
Am 16.09.19 um 21:58 schrieb Junio C Hamano:
> I wonder if the result becomes even clearer if we dropped "instead
> of the usual output". It is a given that presence of an option
> would change the behaviour, so "instead of the usual" does not add
> any value in the context of the explanation we a
On Mon, 16 Sep 2019 10:43:28 PDT (-0700), gits...@pobox.com wrote:
Palmer Dabbelt writes:
... It looks
like there are some test failures when I rebase to the latest master,
which I'm happy to fix. Just let me know if I should:
* Send just the first 4 patches, holding onto the last one for
Hello all,
Many of you must be disappointed by the recent revelations.
However, we just figured "Glück auf" ("Joy on top") makes "Ruhrpott" a
safe bet for unsafe sex.
Cheers,
The GCHQ
On Mon, Sep 16, 2019 at 7:16 PM Klaus Sembritzki wrote:
>
> Hello all,
>
> We know that this is for a technical
On Monday, 16 September 2019 14:50:17 CEST Alicenab wrote:
> Hello,
> As far as I know Git documentation does not have Azerbaijan language
> translation. I have started to work around it. Are you open for this
> commitment?
>
> Best regards
> Ali
>
Hello and welcome,
There are different thing
Masaya Suzuki writes:
> Debugging this, it seems most of the time is spent on iterating the want refs
> to
> see OIDs are included there. This patch speeds up this process by using
> oid_set.
> Now the client can send a fetch request almost immediately.
Wonderful. Thanks.
On 09/16, Jonathan Nieder wrote:
> > (In case it was not clear: those standups are meant to offer a really
> > informal venue to talk about patches you are working (or planning to
> > work) on, _especially_ for people who feel intimidated by this here
> > mailing list...)
>
> Thanks to Thomas for
Martin Ågren writes:
> On Sun, 15 Sep 2019 at 21:26, Johannes Sixt wrote:
>> I do not have the toolchain to check that a correct result is produced.
>
> But I do. I've tested this patch and 2/2 with AsciiDoc 8.6.10 and
> Asciidoctor 1.5.5, as well as with Asciidoctor 2.0.10 (on top of brian's
>
(+cc: Thomas Gummerer)
Hi Johannes,
Johannes Schindelin wrote:
> On Fri, 13 Jul 2018, Jonathan Nieder wrote:
>> Some of us have been informally doing a "git standup" on #git-devel on
>> irc.freenode.net on IRC every two weeks at 17:00-17:30 UTC. It's a
>> way for people to say what they're worki
On 9/13/19 1:26 PM, Junio C Hamano wrote:
> Compare the ways how dispatching and command line option parsing of
> subcommands in "multi-pack-index" and "commit-graph" are
> implemented. When a command (e.g. "commit-graph") takes common
> options and also has subcommands (e.g. "read" and "write")
Denton Liu writes:
> Break `--default` and `--branch` into their own separate invocations to
> make it obvious that these options are mutually exclusive.
That sounds even clearer than what the original wanted to do. Very
good idea.
> diff --git a/Documentation/git-submodule.txt b/Documentation
Before, when running the "coccicheck" target, only the source files
which were being compiled would have been checked by Coccinelle.
However, just because we aren't compiling a source file doesn't mean we
have to exclude it from analysis. This will allow us to catch more
mistakes, in particular one
Hi all, I spent the weekend brooding over this and I opted to not
convert $(FIND_SOURCE_FILES) into a list of filenames. I put the
justification for it in 4/4 so, hopefully, it'll make sense for someone
who might want to do the same change in the future.
Before, when we ran coccicheck, it would o
Currently, $(FIND_SOURCE_FILES) has two modes: if `git ls-files` is
present, it will use that to enumerate the files in the repository; else
it will use `$(FIND) .` to enumerate the files in the directory.
There is a subtle difference between these two methods, however. With
ls-files, filenames do
Some files in our codebase are borrowed from other projects, and
minimally updated to suit our own needs. We'd sometimes need to tell
our own sources and these third-party sources apart for management
purposes (e.g. we may want to be less strict about coding style and
other issues on third-party fi
Currently, $(LIB_H) is generated from two modes: if `git ls-files` is
present, it will use that to enumerate the files in the repository; else
it will use `$(FIND) .` to enumerate the files in the directory.
There is a subtle difference between these two methods, however. With
ls-files, filenames
After the previous commit, AsciiDoc and Asciidoctor render the manpage
headers identically, so we no longer need the "cut the header" part of
our `--cut-header-footer` option. We do still need the "cut the footer"
part, though. The previous commits improved the rendering of the footer
in Asciidocto
Here's v3 of ma/asciidoctor-refmiscinfo to align the headers and footers
of Asciidoctor-rendered manpages with those from AsciiDoc. Patch 1 is
new.
It turns out that with newer (>=1.5.7) versions of Asciidoctor, we get
default values of these refmiscinfo attributes put into the xml. The
hack in pa
Rather than hardcoding "Git Manual" and "Git" as the manual and source
in asciidoc.conf, provide them as attributes `manmanual` and
`mansource`. Rename the `git_version` attribute to `manversion`.
These new attribute names are not arbitrary, see, e.g., [1].
For AsciiDoc (8.6.10) and Asciidoctor <
As can be seen from the previous commit, there are three attributes that
we provide to AsciiDoc through asciidoc.conf. Asciidoctor ignores that
file. After that patch, newer versions of Asciidoctor pick up the
`manmanual` and `mansource` attributes as we invoke `asciidoctor`, but
they don't pick up
On Fri, Sep 13, 2019 at 04:51:49PM -0400, Jeff King wrote:
> On Fri, Sep 13, 2019 at 01:03:17PM -0700, Jonathan Tan wrote:
>
> > > Do we have interested mentors for the next round of Outreachy?
> > >
> > > The deadline for Git to apply to the program is September 5th. The
> > > deadline for mento
On 2019.09.16 10:11, Jeff Hostetler wrote:
>
>
> On 9/16/2019 8:07 AM, Derrick Stolee wrote:
> > On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> > > Add a new "overload" event type for trace2 event destinations. Write
> > > this event into the sentinel file created by the trace2.maxFiles
> > > featu
In b57e8119e6 (submodule: teach set-branch subcommand, 2019-02-08), the
`set-branch` subcommand was added for submodules. When the documentation
was written, the syntax for a "index term" in AsciiDoc was
accidentally used. This caused the documentation to be rendered as
set-branch -d|--def
On 2019.09.16 08:07, Derrick Stolee wrote:
> On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> > Add a new "overload" event type for trace2 event destinations. Write
> > this event into the sentinel file created by the trace2.maxFiles
> > feature. Bump up the event format version since we've added a new
Robert Schmidt-Cisternas writes:
> However, when cloning a repo with submodules, the variable is cleared
GIT_OBJECT_DIRECTORY applies to the source object store, not the
target object store---clearing is very much intentional, I think.
An operation like clone, fetch and push can involve two obj
On 15/09/19 09:55AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Sat, Sep 14, 2019 at 11:15 PM Pratyush Yadav
> wrote:
> > Why should it only happen when the commit message widget is selected?
> > What's wrong with directly switching focus when all the files are
> > staged?
> >
> > What
On 15/09/19 01:41PM, David wrote:
> On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav wrote:
> > On 15/09/19 02:07AM, David wrote:
> > > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg
> > > wrote:
>
> > > > I consider adding a second way as not not acceptable. I also consider
> > > > double-click on a fi
Martin Ågren writes:
>> -Git omitted 01/01/1970
>> GIT-ADD(1)
>> + omitted 1970-01-01
>> GIT-ADD(1)
>
> Yeah, I should be able to post v3 of my refmiscinfo-series this evening,
> which should fix th
Palmer Dabbelt writes:
> ... It looks
> like there are some test failures when I rebase to the latest master,
> which I'm happy to fix. Just let me know if I should:
> * Send just the first 4 patches, holding onto the last one for later.
> ...
> * Send just a single patch, which wouldn't add t
Jeff King writes:
> - a way to independently specify the source pathspec and the
> output-limiting pathspec. This is a cheaper version of the one
> above, where you could look at a subset of the tree a sources, but
> limit the set of shown paths even further. It's not conceptually
>
On Sun, 15 Sep 2019 at 21:26, Johannes Sixt wrote:
> I do not have the toolchain to check that a correct result is produced.
But I do. I've tested this patch and 2/2 with AsciiDoc 8.6.10 and
Asciidoctor 1.5.5, as well as with Asciidoctor 2.0.10 (on top of brian's
recent patch so that it builds t
Paul Mackerras writes:
> Hi Junio,
>
> Whenever it's convenient, please do a pull from my gitk repository at
> git://ozlabs.org/~paulus/gitk.git to get four commits updating gitk.
>
> Thanks,
> Paul.
Will do. Thanks.
Hello all,
We know that this is for a technical-savvy audience, but as we are all
people with a soul, here comes a combination of both, the logical and
the emotional first waves of the GCHQ-propaganda-war.
First waves of the GCHQ-propaganda-war:
- Logic: This is the first wave of a propaganda-wa
Hi -
On 8/28/19 1:07 PM, Terry Davis wrote:
The new blame options (--ignore-rev, --ignore-revs-file) and config options
(blame.markIgnoredLines, blame.markUnblamables, blame.ignoreRevsFile) are
great, and much appreciated. However, for my primary use (one-time
automated reformatting of an enti
On 9/14/2019 9:09 PM, Jeff King wrote:
On Mon, Sep 09, 2019 at 01:08:24PM -0400, Jeff King wrote:
I'll work up what I sent earlier into a real patch, and include some of
this discussion.
Here it is. I pulled Jon's tests out into their own patch (mostly
because it makes it easier to give cr
On Fri, Sep 13, 2019 at 10:30 PM Jeff King wrote:
> SNIP
>
> > Now this looks more like it. I can actually see a useful diff here,
> > instead of everything looking like a new file. But there is a lot of
> > confusion here:
> >
> > 1. `diff --follow` is not a documented[1] option. Why does it work
On 9/16/2019 8:07 AM, Derrick Stolee wrote:
On 9/13/2019 8:26 PM, Josh Steadmon wrote:
Add a new "overload" event type for trace2 event destinations. Write
this event into the sentinel file created by the trace2.maxFiles
feature. Bump up the event format version since we've added a new event
Dear all,
We texted a README.md on a new project hosted on GitHub, promoting but
not yet implementing a "friends-based search-engine", hosting the
complete WWW in the future, thereby reshaping GIT and HG also. Now we
figured we'd like to advertise the project to you directly.
https://github.com/k
Hello,
As far as I know Git documentation does not have Azerbaijan language
translation. I have started to work around it. Are you open for this
commitment?
Best regards
Ali
Bonjour Bien Aimé en Christ.
J'espère que avec prière tout va bien dans votre famille. Je suis Mme SYLVIE
BERNADETTE de nationalité Française mariée au feu Mr David AGOSSOU de
nationalité Béninoise ; de mémoire glorieuse et bénie qui fut ingénieur
consultant au Bénin pendant 9 ans dans la soci
Hi,
On Sat, Sep 14, 2019 at 7:48 PM Pratyush Yadav wrote:
> You missed labelling the menu item of "Amend Last Commit" with the
> shortcut, like we do for other menu items bound to a hotkey like F5 for
> rescan, Ctrl-T for stage, etc. I added that locally.
Sorry about that. Thanks!
Birger
On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> Add a new "overload" event type for trace2 event destinations. Write
> this event into the sentinel file created by the trace2.maxFiles
> feature. Bump up the event format version since we've added a new event
> type.
>
> Writing this message into the s
Am 16.09.19 um 12:45 schrieb Pratyush Yadav:
On 16/09/19 11:02AM, Stefanie Leisestreichler wrote:
Hi.
I am far from being a pro in git.
There is something I do not understand.
This is my git config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
On Sun, 15 Sep 2019 at 23:26, brian m. carlson
wrote:
>
> On 2019-09-15 at 09:59:52, SZEDER Gábor wrote:
> > On Sat, Sep 14, 2019 at 07:49:19PM +, brian m. carlson wrote:
> > > test -n "$ALREADY_HAVE_ASCIIDOCTOR" ||
> > > gem install --version 1.5.8 asciidoctor
> >
> > So, since the do
On Fri, 13 Sep 2019 at 07:06, Jeff King wrote:
>
> On Fri, Sep 13, 2019 at 01:52:40AM +, brian m. carlson wrote:
>
>
> > Documentation/Makefile| 4 +++-
> > Documentation/manpage.xsl | 3 +++
> > ci/test-documentation.sh | 2 ++
> > 3 files changed, 8 insertions(+), 1 deletion(-)
> > cr
On 16/09/19 11:02AM, Stefanie Leisestreichler wrote:
> Hi.
>
> I am far from being a pro in git.
> There is something I do not understand.
>
> This is my git config:
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
>
Hi.
I am far from being a pro in git.
There is something I do not understand.
This is my git config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://git@192.168.2.2:/home/git/PROJECT.git
62 matches
Mail list logo
