On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:
> How about
>
> GIT_EDITOR=echo git config --system -e 2>/dev/null
>
> It will error out if the directory does not exist, for some reason, e.g.
> when you installed Git in your home directory via `make install` from a
> f
unsubscribe git
Having --pretty=medium as the default almost always makes the graph too
difficult to follow.
Signed-off-by: Alex Henrie
---
builtin/log.c | 5 +
t/t4052-stat-output.sh | 14 +++---
t/t4202-log.sh | 14 ++
3 files changed, 26 insertions(+), 7 deletions(-)
The current wildmatch() call for includeIf's gitdir pattern does not
pass the WM_PATHNAME flag. Without this flag, '*' is treated _almost_
the same as '**' (because '*' also matches slashes) with one exception:
'/**/' can match a single slash. The pattern 'foo/**/bar' matches
'foo/bar'.
But '/*/'
Signed-off-by: Ramsay Jones
---
Hi Ævar,
If you need to re-roll your 'ab/commit-graph-fixes' branch, could you
please squash this into the relevant patch (commit aeb244adbc
("commit-graph: don't early exit(1) on e.g. \"git status\"", 2019-02-21).
This same commit (aeb244adbc) also removes the
Make the copy_or_link_directory function no longer skip hidden
directories. This function, used to copy .git/objects, currently skips
all hidden directories but not hidden files, which is an odd behaviour.
The reason for that could be unintentional: probably the intention was
to skip '.' and '..' o
Extract dir creation code snippet from copy_or_link_directory to its own
function named mkdir_if_missing. This change will help removing
copy_or_link_directory's explicit recursion, which will be done in a
following patch. Also makes code more readable.
Signed-off-by: Matheus Tavares
---
builtin
There is currently an odd behaviour when locally clonning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
From: Ævar Arnfjörð Bjarmason
Add tests for what happens when we perform a local clone on a repo
containing odd files at .git/object directory, such as symlinks to other
dirs, or unknown files.
I'm bending over backwards here to avoid a SHA1 dependency. See [1]
for an earlier and simpler version
This patchset contains:
- a replacement of explicit recursive dir iteration at
copy_or_link_directory for the dir-iterator API;
- some refactoring and behaviour changes at local clone, mainly to
take care of symlinks and hidden files at .git/objects; and
- tests for this type of files
Changes
Add the possibility of giving flags to dir_iterator_begin to initialize
a dir-iterator with special options.
Currently possible flags are DIR_ITERATOR_PEDANTIC, which makes
dir_iterator_advance abort imediatelly in the case of an error while
trying to fetch next entry; and DIR_ITERATOR_FOLLOW_SYML
Replace the use of strcmp by fspathcmp at copy_or_link_directory, which
is more permissive/friendly to case-insensitive file systems.
Signed-off-by: Matheus Tavares
Suggested-by: Nguyễn Thái Ngọc Duy
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin
Replace usage of opendir/readdir/closedir API to traverse directories
recursively, at copy_or_link_directory function, by the dir-iterator
API. This simplifies the code and avoid recursive calls to
copy_or_link_directory.
This process also makes copy_or_link_directory call die() in case of an
erro
In the case there are no files to stash, but the user asked to stash, we
should exit 1 since the stashing failed.
---
git-stash.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-stash.sh b/git-stash.sh
index 789ce2f41d4a3..ca362b1a31277 100755
--- a/git-stash.sh
+++ b/git-
> -Original Message-
> From: Fabio Aiuto
> Sent: March 22, 2019 17:41
> To: Randall S. Becker ; git@vger.kernel.org
> Subject: Re: Semantic errors
>
> Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha
> scritto:
> > On March 22, 2019 17:25, Fabio Aiuto
> > > Il giorno gi
Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha
scritto:
> On March 22, 2019 17:25, Fabio Aiuto
> > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
> > scritto:
> > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > > > Il giorno gio, 21/03/2019 alle 15.16 -040
On March 22, 2019 17:25, Fabio Aiuto
> Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
> scritto:
> > > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha
> > > scritto:
> > > > On March 21, 2019 15:06, Fabio Aiuto
Il giorno ven, 22/03/2019 alle 22.25 +0100, Fabio Aiuto ha scritto:
> Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
> scritto:
> > > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha
> > > scritto:
> > > > On Mar
Hello again,
If I run a make inside the git working directory, this will just create
binaries in the working directory. But in my home/{myname}/bin/ I have
found the following files:
git git-cvsserver gitk git-receive-pack git-shell git-upload-archive
git-upload-pack
Maybe they are deployed by a
Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
scritto:
> > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha
> > scritto:
> > > On March 21, 2019 15:06, Fabio Aiuto wrote:
> > > > I'm browsins git code with Eclipse
> Of On March 22, 2019 16:25, Fabio Aiuto wrote:
> To: Randall S. Becker ; git@vger.kernel.org
> Subject: Re: Semantic errors
>
> Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
> scritto:
> > > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > > Il giorno gio, 21/03/2019 alle 15
On Wed, 20 Mar 2019 at 19:17, Todd Zullinger wrote:
> Martin Ågren wrote:
> > {litdd} now renders as --. We should find some other way to
> > produce '--'. This should then be a simple change, as we're already
> > providing this attribute inside an `ifdef USE_ASCIIDOCTOR`.
>
> I noticed that one a
Heinrich Schuchardt wrote:
> Yes, git HEAD + said patch works with this command:
> git -c http.followRedirects=true clone http://git.denx.de/u-boot-efi.git
>
> http.followRedirects is documented in man 1 git-config.
>
> Why would git prior to 17966c0a63d25b1cc2dd1e98d30873e643bd581f~1 work
> wi
Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha
scritto:
> > Of On March 21, 2019 15:32, Fabio Aiuto wrote:
> > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha
> > scritto:
> > > On March 21, 2019 15:06, Fabio Aiuto wrote:
> > > > I'm browsins git code with Eclipse
Our Perforce server experienced some kind of database corruption a few years
ago.
While the file data and revision history are mostly intact,
some metadata for several changesets got lost.
For example, inspecting certain changelists produces errors.
"""
$ p4 describe -s 12345
Date 2019/02/26 16:46
Labels in Perforce are not global, but can be placed on a particular
view/subdirectory.
This might pose difficulties when importing only parts of Perforce depot into a
git repository.
For example:
1. Depot layout is as follows:
//depot/metaproject/branch1/subprojectA/...
//depot/metaproj
This patch series introduces two experimental features to git-p4,
which unrelated to each other.
1. The first patch adds support for so-called "alien" branches.
The feature lets git-p4 create empty commits
to make the history or tags more accurate.
It is particularly useful when spli
When using protocol v0, upload-pack over HTTP permits a "half-auth"
configuration in which, at the web server layer, the info/refs path is
not protected by authentication but the git-upload-pack path is, so that
a user can perform fetches that do not download any objects without
authentication, but
Hi Jason,
On Thu, Mar 14, 2019 at 01:30:43PM -0400, Jason Karns wrote:
> Hello,
>
> I believe I've encountered a bug regarding the use of double asterisk
> ( /**/ ) within includeIf patterns.
>
> git-config man pages state that
>
> **/ and /**, that can match multiple path components
>
> They
Hi Johannes,
On Wed, Mar 13, 2019 at 04:56:53AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> On Windows, for example, executables (must) have the extension `.exe`.
> Our `check-docs` target was not prepared for that.
>
> Signed-off-by: Johannes Schindelin
>
On 3/22/19 7:09 PM, Eric Wong wrote:
> Heinrich Schuchardt wrote:
>> On 3/22/19 5:50 PM, Eric Wong wrote:
>>> I couldn't reproduce an error after porting your patch to
>>> master (commit 041f5ea1cf987a40 "The third batch"):
>>> https://80x24.org/spew/20190322163449.25362-...@80x24.org/raw
>>>
>>>
Thank you everyone for the comments!
Confirming Sergey's summary: at this point, I think my only residual
opinion is that requiring `-m 1` or `--mainline 1` is a little cryptic
for someone who's just cherry-picking a single commit, which happens
to be a merge commit. `--no-forbid-merges` would be
Heinrich Schuchardt wrote:
> On 3/22/19 5:50 PM, Eric Wong wrote:
> > I couldn't reproduce an error after porting your patch to
> > master (commit 041f5ea1cf987a40 "The third batch"):
> > https://80x24.org/spew/20190322163449.25362-...@80x24.org/raw
> >
> > So you might've hit an ephemeral error (
On 3/22/19 5:50 PM, Eric Wong wrote:
> Jeff King wrote:
>> On Fri, Mar 22, 2019 at 09:21:14AM +0100, Wolfgang Denk wrote:
>>
>>> Dear Jeff,
>>>
>>> In message <20190322071231.ga26...@sigill.intra.peff.net> you wrote:
However, so does the parent of 17966c0a63d. So I don't know if the
On Wed 2019-03-20 23:35:48 +0100, Ævar Arnfjörð Bjarmason wrote:
> But e.g. if you've signed a v1.00 in foo.git, but also maintain bar.git
> and have a v2.00 there, I can be fooled in foo.git with your proposed
> change by having the v2.00 bar.git tag pushed to it (just, with the
> proposed change,
On Fri, Mar 22 2019, SZEDER Gábor wrote:
> On Fri, Mar 22, 2019 at 04:11:24PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>>
>> > On Fri, Mar 22, 2019 at 03:28:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >>
>> >> On Fri, Mar 22 2019, SZEDER Gábor wrote:
Thanks for the thoughtful feedback, Junio!
On Thu 2019-03-21 10:31:59 +0900, Junio C Hamano wrote:
> The other point still stands; there are legitimate reasons people
> would want to have a tag with v1.0.0 tagname in somewhere that is
> not refs/tags/v1.0.0 and an extra validation must need to mak
> Jonathan Tan writes:
>
> > Because this configuration is not supported by all protocol versions,
> > and because this configuration seems to be of limited usefulness (only
> > useful for people who use manual credential entry and on servers that
> > are OK with exposing refs but not objects, an
On 22/03/2019 09:31, Nguyễn Thái Ngọc Duy wrote:
read-tree is basically the front end of unpack-trees code and shoud
s/shoud/should/
Philip
expose all of its functionality (unless it's designed for internal
use). This "opts.quiet" (formerly "opts.gently") was added for
builtin/checkout.c but
On Fri, Mar 22, 2019 at 04:49:43PM +0100, SZEDER Gábor wrote:
> On Fri, Mar 22, 2019 at 04:11:24PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Fri, Mar 22 2019, SZEDER Gábor wrote:
> >
> > > On Fri, Mar 22, 2019 at 03:28:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > >>
> > >> On Fri, Mar 22
Jeff King wrote:
> On Fri, Mar 22, 2019 at 09:21:14AM +0100, Wolfgang Denk wrote:
>
> > Dear Jeff,
> >
> > In message <20190322071231.ga26...@sigill.intra.peff.net> you wrote:
> > >
> > > However, so does the parent of 17966c0a63d. So I don't know if the
> > > u-boot-efi repo is just broken, or
Signed-off-by: Kapil Jain
---
The test written does not pass, imo there's some problem with the regex part.
please let me know about the fault.
t/t4034-diff-words.sh | 2 ++
t/t4034/shell/expect | 6 ++
t/t4034/shell/post| 1 +
t/t4034/shell/pre | 1 +
userdiff.c| 7 +++
On Fri, Mar 22, 2019 at 04:11:24PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>
> > On Fri, Mar 22, 2019 at 03:28:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Fri, Mar 22 2019, SZEDER Gábor wrote:
> >>
> >> > On Fri, Mar 22, 2019 at 12:11:26PM +0
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> With it reverted, "[alias] cp = cherry-pick -m1" can be used to train
>>> the user to blindly pick a range that has a merge without thinking,
>>> which is what I meant by "ship has already sailed".
>>
>> Did you mean "With it *not* reverted"
On 3/22/2019 10:53 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Mar 22 2019, Jeff Hostetler wrote:
On 3/22/2019 9:17 AM, Johannes Schindelin wrote:
Hi Ævar,
On Thu, 21 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
On Thu, Mar 21 2019, Johannes Schindelin wrote:
On Sun, 17 Mar 2019, Ævar Arnf
Hey People
I am Rohit Ashiwal and here my first draft of the proposal for the project
titled: `Improve consistency of sequencer commands' this summer. I need your
feedback and more than that I need help to improve the timeline of this
proposal since it looks very weak. Basically, it lacks the "how
On Fri, Mar 22 2019, SZEDER Gábor wrote:
> On Fri, Mar 22, 2019 at 03:28:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>>
>> > On Fri, Mar 22, 2019 at 12:11:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >>
>> >> On Fri, Mar 22 2019, SZEDER Gábor wrote:
On Fri, Mar 22, 2019 at 03:28:34PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>
> > On Fri, Mar 22, 2019 at 12:11:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Fri, Mar 22 2019, SZEDER Gábor wrote:
> >>
> >> > Commit 49bbc57a57 (commit-graph write
On Fri, Mar 22 2019, Jeff Hostetler wrote:
> On 3/22/2019 9:17 AM, Johannes Schindelin wrote:
>> Hi Ævar,
>>
>> On Thu, 21 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>>
>>> On Thu, Mar 21 2019, Johannes Schindelin wrote:
>>>
On Sun, 17 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
>
On Fri, Mar 22 2019, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>
>> On Fri, Mar 22, 2019 at 12:11:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>>>
>>> > Commit 49bbc57a57 (commit-graph write: emit a percentage for all
On Thu, Mar 21, 2019 at 08:06:01PM -0400, Jeff King wrote:
> On Thu, Mar 21, 2019 at 05:28:44AM -0400, Jeff King wrote:
>
> > - instead of disconnecting backend_data->packed_transaction on error,
> > we could wait to install it until we successfully prepare. That
> > might make the flow a
On Fri, Mar 22 2019, SZEDER Gábor wrote:
> On Fri, Mar 22, 2019 at 12:11:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>>
>> > Commit 49bbc57a57 (commit-graph write: emit a percentage for all
>> > progress, 2019-01-19) was a bit overeager when it added
This is a remnant from early versions of the commit-graph patch series
[1], when 'git commit-graph --write' printed the hash of the created
commit-graph file, and tests did look at the command's output, because
the commit-graph file's name included that hash as well.
[1]
https://public-inbox.org/
On 3/21/2019 11:30 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
+ for (attempt_count = 0; attempt_count < MAX_RANDOM_ATTEMPTS;
attempt_count++) {
+ strbuf_reset(&final_path);
+ strbuf_addbuf(&final_path, &base_path);
+ strbuf_addf(&final_
On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:
> Hi Peff & Mike,
>
> On Fri, 22 Mar 2019, Jeff King wrote:
>
> > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
> >
> > > I thought of a few options (it's worth noting the helper is invoked in a
> > > way that mak
Hi,
On Thu, 13 Sep 2018, Phillip Wood wrote:
> On 03/09/2018 20:01, Jochen Sprickerhof wrote:
>
> > * Phillip Wood [2018-08-30 14:47]:
> >> When $newhunk is created it is marked as dirty to prevent
> >> coalesce_overlapping_hunks() from coalescing it. This patch does not
> >> change that. What i
On 3/22/2019 9:17 AM, Johannes Schindelin wrote:
Hi Ævar,
On Thu, 21 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
On Thu, Mar 21 2019, Johannes Schindelin wrote:
On Sun, 17 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
On Fri, Feb 15 2019, Jeff Hostetler wrote:
I could see having a "~/.git_tr
Hi Peff & Mike,
On Fri, 22 Mar 2019, Jeff King wrote:
> On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
>
> > I thought of a few options (it's worth noting the helper is invoked in a
> > way that makes $GIT_EXEC_PATH set, which can help a little):
> > - spawn `$GIT_EXEC_PATH/git-conf
On 3/22/2019 8:46 AM, Johannes Schindelin wrote:
Hi Balaji,
On Tue, 19 Mar 2019, balaji marisetti wrote:
Can anyone please tell me if there is way to see the command history
of a local git repo?
If you really are only interested in the *Git* commands, you will be able
to implement somethi
Hi Ævar,
On Thu, 21 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Mar 21 2019, Johannes Schindelin wrote:
>
> > On Sun, 17 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> >
> >>
> >> On Fri, Feb 15 2019, Jeff Hostetler wrote:
> >>
> >> > I could see having a "~/.git_tr2_config" or something simil
Hi Balaji,
On Tue, 19 Mar 2019, balaji marisetti wrote:
> Can anyone please tell me if there is way to see the command history
> of a local git repo?
If you really are only interested in the *Git* commands, you will be able
to implement something on top of the Trace2 feature (which just made it
On Fri, Mar 22, 2019 at 12:11:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Mar 22 2019, SZEDER Gábor wrote:
>
> > Commit 49bbc57a57 (commit-graph write: emit a percentage for all
> > progress, 2019-01-19) was a bit overeager when it added progress
> > percentages to the "Expanding reach
On Fri, Mar 22 2019, SZEDER Gábor wrote:
> Commit 49bbc57a57 (commit-graph write: emit a percentage for all
> progress, 2019-01-19) was a bit overeager when it added progress
> percentages to the "Expanding reachable commits in commit graph" phase
> as well, because most of the time the number o
On Thu, Mar 21, 2019 at 06:57:34AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> With this change, the `index_state` struct becomes the new home for the
> flag that says whether the fsmonitor hook has been run, i.e. it is now
> per-index.
>
> It also gets re
Commit 49bbc57a57 (commit-graph write: emit a percentage for all
progress, 2019-01-19) was a bit overeager when it added progress
percentages to the "Expanding reachable commits in commit graph" phase
as well, because most of the time the number of commits that phase has
to iterate over is not know
Hi Junio,
On Thu, 21 Mar 2019, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > This worries me that it'll lead to bad surprises. Perhaps some folks
> > cherry-pick merges around intentionally, but I would want that to be a
> > rare occurrence at most. There are lots of folks at $DAYJOB tha
Hi Elijah,
On Wed, 20 Mar 2019, Elijah Newren wrote:
> On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov wrote:
> >
> > Junio C Hamano writes:
> >
> > [...]
> >
> > > But I do have a very strong opinion against adding yet another
> > > option that takes an optional argument. If we want to allow
>
Amend the "NOTES" section to fix up wording that's been with us since
3ffb58be0a ("doc/git-gc: add a note about what is collected",
2008-04-23).
I can't remember when/where anymore (I think Freenode #Git), but at
some point I was having a conversation with someone who was convinced
that "gc" would
Re-flow the "gc.*" section in "config". A previous commit moved this
over from the "gc" docs, but tried to keep as many of the lines
identical to benefit from diff's move detection.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config/gc.txt | 17 -
1 file changed, 8 i
The chance of a repository being corrupted due to a "gc" has nothing
to do with whether or not that "gc" was invoked via "gc --auto", but
whether there's other concurrent operations happening.
This is already noted earlier in the paragraph, so there's no reason
to suggest this here. The user can i
Since 07e7dbf0db (gc: default aggressive depth to 50, 2016-08-11) we
somewhat confusingly use the same depth under --aggressive as we do by
default.
As noted in that commit that makes sense, it was wrong to make more
depth the default for "aggressive", and thus save disk space at the
expense of ru
The docs have been recommending that users need to run this manually,
but that hasn't been needed in practice for a long time except in
exceptional circumstances.
Let's instead have this reflect reality and say that most users don't
need to run this manually at all, while briefly describing the so
The existing "gc --aggressive" docs come just short of recommending to
users that they run it regularly. I've personally talked to many users
who've taken these docs as an advice to use this option, and have,
usually it's (mostly) a waste of time.
So let's clarify what it really does, and let the
Amend the "PACKFILE OPTIMIZATION" section in "fast-import" to explain
that simply running "git gc --aggressive" after a "fast-import" should
properly optimize the repository. This is simpler and more effective
than the existing "repack" advice (which I'm keeping as it helps
explain things) because
Change the AsciiDoc formatting so that an example of "gc --auto" isn't
rendered as "git-gc(1) --auto", but as "git gc --auto". This is
consistent with the rest of the links and command examples in this
documentation.
The formatting I'm changing was initially introduced in
d5d5d7b641 ("gc: automati
Patch v3 fixes a minor grammar issue noted by Junio in
, and another "while I'm
at it" formatting error.
Ævar Arnfjörð Bjarmason (11):
gc docs: modernize the advice for manually running "gc"
gc docs: stop noting "repack" flags
gc docs: clean grammar for "gc.bigPackThreshold"
gc docs: inclu
Remove the mention of specific flags from the "gc" documentation, and
leave it at describing what we'll do instead. As seen in builtin/gc.c
we'll use various repack flags depending on what we detect we need to
do, so this isn't always accurate.
More importantly, a subsequent change is about to rem
Clean up the grammar in the documentation for
"gc.bigPackThreshold". This documentation was added in 9806f5a7bf ("gc
--auto: exclude base pack if not enough mem to "repack -ad"",
2018-04-15).
Saying "the amount of memory estimated for" flows more smoothly than
the previous "the amount of memory is
Rather than duplicating the documentation for the various "gc" options
let's include the "gc" docs from git-config. They were mostly better
already, and now we don't have the same docs in two places with subtly
different wording.
In the cases where the git-gc(1) docs were saying something the "gc"
When --merge is specified, we may need to do a real merge (instead of
three-way tree unpacking), the steps are best seen in git-checkout.sh
version before it's removed:
# Match the index to the working tree, and do a three-way.
git diff-files --name-only | git update-index --remove --stdin
During the 'git switch' discusion, Phillip found out that staged changes
could be silently lost when doing 'git checkout -m'. The first attempt
[2] tries to fix it by warning and moving on, because t7201.10 would
fail if we simply die() when there are staged changes.
This round, I update read-tree
read-tree is basically the front end of unpack-trees code and shoud
expose all of its functionality (unless it's designed for internal
use). This "opts.quiet" (formerly "opts.gently") was added for
builtin/checkout.c but there is no reason why other read-tree users
won't find this useful.
The test
The gently flag was added in 17e4642667 (Add flag to make unpack_trees()
not print errors. - 2008-02-07) to suppress error messages. The name
"gently" does not quite express that. Granted, being quiet is gentle but
it could mean not performing some other actions. Rename the flag to
"quiet" to be mo
This basically follows the footsteps of 6a143aa2b2 (checkout -m:
attempt merge when deletion of path was staged - 2014-08-12) where
there gently check is moved inside reject_merge() so that callers do
not accidentally forget it.
add_rejected_path() has the same usage pattern. All call sites check
On Fri, Mar 22, 2019 at 09:21:14AM +0100, Wolfgang Denk wrote:
> Dear Jeff,
>
> In message <20190322071231.ga26...@sigill.intra.peff.net> you wrote:
> >
> > However, so does the parent of 17966c0a63d. So I don't know if the
> > u-boot-efi repo is just broken, or if there's some other different bu
On Fri, Mar 22, 2019 at 3:00 PM Andrei Rybak wrote:
>
> On 3/21/19 2:16 PM, Nguyễn Thái Ngọc Duy wrote:
> > ...
> >
> > diff --git a/advice.c b/advice.c
> > index b224825637..27e39e6514 100644
> > --- a/advice.c
> > +++ b/advice.c
> > @@ -191,20 +191,20 @@ void NORETURN die_conclude_merge(void)
>
On Fri, Mar 22, 2019 at 03:14:37AM +0530, Aaryan Kapur wrote:
> Hey, I would like to work with your organisation for the upcoming
> Google summer of code program , please guide me on how to go ahead
Please start from [1] which links to [2].
For future reference, this list is archived at [3], so
Dear Jeff,
In message <20190322071231.ga26...@sigill.intra.peff.net> you wrote:
>
> However, so does the parent of 17966c0a63d. So I don't know if the
> u-boot-efi repo is just broken, or if there's some other different bug
> at play.
git fsck reports a number of dangling tags, but no other issue
On 3/21/19 2:16 PM, Nguyễn Thái Ngọc Duy wrote:
> ...
>
> diff --git a/advice.c b/advice.c
> index b224825637..27e39e6514 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -191,20 +191,20 @@ void NORETURN die_conclude_merge(void)
> void detach_advice(const char *new_name)
> {
> const char *fmt
On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
> I thought of a few options (it's worth noting the helper is invoked in a
> way that makes $GIT_EXEC_PATH set, which can help a little):
> - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the
> internal config from
On Fri, Mar 22, 2019 at 11:26 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This adds a new command 'git-switch' as the half-replacement for
> > 'git-checkout'. Jump to 12/26 as the starting point. The other half is
> > git-restore, which is dealt with separately.
> >
> > The d
On Fri, Mar 22, 2019 at 07:02:41AM +0100, Heinrich Schuchardt wrote:
> Initial cloning via
>
> git clone http://git.denx.de/u-boot-efi.git
>
> fails with git version 2.21.0.196.g041f5ea1cf
>
> git version 2.1.4 works fine.
>
> Bisection points to this first bad commit:
> 17966c0a63d25b1cc2
92 matches
Mail list logo
