On Tue, Apr 2, 2019 at 1:45 AM Eric Sunshine wrote:
> On Mon, Apr 1, 2019 at 7:52 AM SZEDER Gábor wrote:
> > + if (show_update) {
> > [...]
> > progress_update = 0;
> > - return;
> > }
>
> Removal of these two 'returns' is unrelated to t
On Mon, Apr 1, 2019 at 7:52 AM SZEDER Gábor wrote:
> [...]
> To prepare for those changes assemble the changing parts in a separate
> strbuf kept in 'struct progress' before printing.
>
> Signed-off-by: SZEDER Gábor
> ---
> diff --git a/progress.c b/progress.c
> @@ -80,36 +81,42 @@ static int is_
On Mon, Apr 1, 2019 at 7:52 AM SZEDER Gábor wrote:
> [...]
> Let's make display_progress() return void, too.
>
> Signed-off-by: SZEDER Gábor
> ---
> diff --git a/progress.c b/progress.c
> @@ -78,12 +78,12 @@ static int is_foreground_fd(int fd)
> -static int display(struct progress *progress, uint
Wrap usage line at ''. Also, wrap strings with '\n' at the end
of string fragments instead of at the beginning of the next string
fragment.
Convert a space-indent into a tab-indent for style.
Signed-off-by: Denton Liu
---
builtin/tag.c | 9 +
1 file changed, 5 insertions(+), 4 deletions
Earlier in the mailing list, Robert Dailey reported confusion over some
nested tags. [1]
Peff noted that he hasn't seen a tag-to-a-tag in the wild so in most cases,
it'd probably be a mistake on the part of a user. He also suggested we error
out on a nested tag unless "--allow-nested-tag" is provi
Robert Dailey reported confusion on the mailing list about a nested tag
which was most likely created by mistake. Jeff King noted that this
isn't a very common case so, most likely, creating a tag-to-a-tag is a
user-error.
Prevent mistakes by erroring and providing advice on nested tags, unless
"-
Before, when we had the following graph,
A---B---C (master)
\
D (side)
running 'git rebase --onto master... master side' would result in D
being always rebased, no matter what. However, the desired behavior is
that rebase should notice that this is fast-forwardabl
Hi Junio,
On Tue, Apr 02, 2019 at 10:48:08AM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Denton Liu writes:
> >
> >> Before, when we had the following graph,
> >>
> >>A---B---C (master)
> >>\
> >> D (side)
> >>
> >> running 'git rebase --onto master... master
Khalid Ali writes:
> The exit code of the upstream in a pipe is ignored thus we
> should avoid using it. By writing out the output of the git command to a
> file, we can test the exit codes of both the commands.
End the log message here by moving the next two paragraphs below the
three-dash line
Junio C Hamano writes:
> Denton Liu writes:
>
>> Before, when we had the following graph,
>>
>> A---B---C (master)
>> \
>> D (side)
>>
>> running 'git rebase --onto master... master side' would result in D
>> being always rebased, no matter what. However, the desired beha
The exit code of the upstream in a pipe is ignored thus we
should avoid using it. By writing out the output of the git command to a
file, we can test the exit codes of both the commands.
Aside from the commit message, I plan to apply for GSoC. Planning to
solve the rebase/cherry-pick issue or addi
Denton Liu writes:
> Before, when we had the following graph,
>
> A---B---C (master)
> \
>D (side)
>
> running 'git rebase --onto master... master side' would result in D
> being always rebased, no matter what. However, the desired behavior is
> that rebase should noti
On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares
wrote:
> I downloaded chromium to give it a try and got (on a machine with i7 and
> SSD, running Manjaro Linux):
>
> - 17s on blame for a file with long history[2]
> - 2m on blame for a huge file[3]
> - 15s on log for both [2] and [3]
> - 1s for git s
"Johannes Schindelin via GitGitGadget"
writes:
> We do not want to have tests that need to be changed by completely unrelated
> patch series, just because abbreviations that used to be unique are being
> made non-unique by said patch series.
Makes sense.
If we wanted to make sure that options i
Hi,
I am planning to work on making pack access thread-safe as my GSoC
project, and after that, parallelize git blame or checkout. Or even use
the thread-safe pack access to improve the already parallel grep or
pack-objects.
With this in mind, I would like to know if the problem discussed in this
Sam Lee writes:
> It brings up EDITOR twice and I end up with two commits.
> I can squash them. But, I don't know if this is a desired behavior.
It is my understanding that the users who do want a single revert of
multiple commits are expected to squash them (by choosing which ones
to squash int
Chanseok Oh writes:
> BROKEN: anything other than UTC reports wrong date.
>
> $ TZ=KST git log '--date=format-local:%Y%m%d %H%M%S %z (%Z)'
> --format=%cd -n1
> 20190401 210250 + (KST)
I think you are probably on a system where timezones can be given
on
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
This patch series introduces two experimental features to git-p4,
unrelated to each other.
1. The first patch adds support for "inexact" label detection.
The feature lets git-p4 find a git commit for a Perforce label
even if there is no git commit with exact same changelist number as in
P
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
Hello,
I'm using the latest version.
$ git version
git version 2.21.0.392.gf8f6787159e-goog
WORKS: the following prints out the date and time in my local timezone.
$ git log '--date=format-local:%Y%m%d %H%M%S %z (%Z)' --format=%cd -n1
20190401 170250 -0400 (EDT)
On Mon, 1 Apr 2019 16:27:02 +0700, Duy Nguyen wrote:
> On Mon, Apr 1, 2019 at 5:03 AM Andrei Rybak wrote:
>> Support UTF-8 encoding of '✂' in function is_scissors_line, for 'git am
>> --scissors' to be able to cut at Unicode perforation lines in emails.
>> Note, that Unicode character '✂' is three
Thank you all for review. Below is the second version of original patch,
addressing comments by Gábor and Peff.
While preparing v2 I found out that U+2702 was already suggested on the list
eight months before cutting at perforation lines was implemented:
https://public-inbox.org/git/200901181656.
Existing checks using memcmp(3) never read past the end of the line,
because all substrings we are interested in are two characters long, and
the outer loop guarantees we have at least one character. So at most we
will look at the NUL.
However, this is too subtle and may lead to bugs in code which
On 3/29/2019 6:12 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Mar 29 2019, Jeff Hostetler via GitGitGadget wrote:
From: Jeff Hostetler
Update SID component construction to use the current UTC datetime
and a portion of the SHA1 of the hostname.
Use an simplified date/time format to make it
On 4/1/2019 5:00 PM, Josh Steadmon wrote:
On 2019.03.29 10:04, Jeff Hostetler via GitGitGadget wrote:
[...]
diff --git a/Documentation/technical/api-trace2.txt
b/Documentation/technical/api-trace2.txt
index baaa1153bb..13ca595c69 100644
--- a/Documentation/technical/api-trace2.txt
+++ b/Docu
On 3/29/2019 6:16 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Mar 29 2019, Jeff Hostetler via GitGitGadget wrote:
From: Jeff Hostetler
Teach Windows version of git to report peak memory usage
during exit() processing.
Signed-off-by: Jeff Hostetler
---
common-main.c
On 2019.03.29 10:04, Jeff Hostetler via GitGitGadget wrote:
> Here is version 2. It addresses most the V1 comments WRT the system config
> changes.
>
> It also addresses the format and uniqueness of the SID as discussed in [1].
> The SID now containes: the UTC date/time, part of SHA1 of the hostna
On 2019.03.29 10:04, Jeff Hostetler via GitGitGadget wrote:
[...]
> diff --git a/Documentation/technical/api-trace2.txt
> b/Documentation/technical/api-trace2.txt
> index baaa1153bb..13ca595c69 100644
> --- a/Documentation/technical/api-trace2.txt
> +++ b/Documentation/technical/api-trace2.txt
> @
A common scenario is if a user is working on a topic branch and they
wish to make some changes to intermediate commits or autosquash, they
would run something such as
git rebase -i --onto master... master
in order to preserve the merge base. This is useful when contributing a
patch series
Signed-off-by: Denton Liu
---
t/t3431-rebase-fork-point.sh | 53
1 file changed, 53 insertions(+)
create mode 100755 t/t3431-rebase-fork-point.sh
diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-fork-point.sh
new file mode 100755
index 00..
When rebase is run on a branch that can be fast-forwarded, this should
automatically be done. Create test to ensure this behavior happens.
There is one case that currently does not pass. In the case where a
feature and master have diverged, running "git rebase master... master"
causes a full rebas
Before, when we had the following graph,
A---B---C (master)
\
D (side)
running 'git rebase --onto master... master side' would result in D
being always rebased, no matter what. However, the desired behavior is
that rebase should notice that this is fast-forwardabl
Thanks again for your feedback, Ævar! I think we're both on the same page now.
Hopefully I've addressed all of your high-level concerns with this patchset and
we can move into a discussion on implementation detail.
This patchset now depends "[PATCH 1/8] tests (rebase): spell out the
`--keep-empty`
Hi Jan,
On Mon, 1 Apr 2019, Jan Ziak wrote:
> Command-line "git commit" and graphical "git gui" commit are invoking
> different hooks if hooksPath is set in $HOME/.gitconfig.
>
> Namely, in my case command-line "git commit" runs
> "/home/atom/dev/git-hooks/post-commit" - while "git gui" commit ru
> This series fixes a few cases with branch detection
> and handling of excludes by git-p4.
>
> This is the third iteration of the patch series.
> Changes since v2 [2]:
> * Added new test cases for case-insensitive branch detection.
Forgot to add:
* Added a fix for case-insensitive branch detec
From: Jelle van der Waa
has_key was deprecated in Python 2 and finally removed in Python 3 in
favor of 'foo' in bar.
Signed-off-by: Jelle van der Waa
---
contrib/hg-to-git/hg-to-git.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/cont
From: Jelle van der Waa
Python 3 made print a function, keep Python 2 compatibility with a
future import of print_function.
Signed-off-by: Jelle van der Waa
---
contrib/hg-to-git/hg-to-git.py | 47 +-
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git
From: Jelle van der Waa
In Python 3 os.write wants bytes instead of a string, decode the str in
to bytes.
Signed-off-by: Jelle van der Waa
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/h
This patch series makes hg-to-git Python 3 compatible and was tested
that it still works with Python 2.7. I'm not sure which Python version
in minimally supported for these Git contrib scripts.
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files despite being told to
when handling multiple branches.
I.e., it should exclude //depot/branch2/file2 when run with
-//depot/branch2/file2,
but doesn't do this right now.
The test is based on 'git p4 clone
Currently, excluded paths are only handled in the following cases:
* no branch detection;
* branch detection with using clientspec.
However, excluded paths are not respected in case of
branch detection without using clientspec.
Fix this by consulting the list of excluded paths
when splitting fi
Make sure not to exclude files unintentionally
if exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
Do this by ensuring that paths without a trailing "/" are only matched
completely.
Also, abort path search on the first
git-p4 knows how to handle case insensitivity in file paths
if core.ignorecase is set.
However, when determining a branch for a file,
it still does a case-sensitive prefix match.
This may result in some file changes to be lost on import.
For example, given the following commits
1. add //depot/mai
Currently, `cloneExclude` array is being groomed (by removing trailing "...")
on every changeset.
(since `extractFilesFromCommit()` is called on every imported changeset)
As a micro-optimization, do it once while parsing arguments.
Also, prepend "/" and remove trailing "..." at the same time.
Sig
In preparation for a fix, add a failing test case to test that
git-p4 doesn't fold the case in file paths
when doing branch detection case insensitively.
(i.e. when core.ignorecase is set)
Signed-off-by: Andrey Mazo
---
t/t9801-git-p4-branch.sh | 92
1 fi
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files with the same prefix unintentionally
when exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
or don't exclude "//depot/discard_file
Under certain circumstances, gitCommitByP4Change() can enter an infinite
loop resulting in `git p4 sync` hanging forever.
The problem is that
`git rev-list --bisect ^` can return ``,
which would result in reinspecting and potentially an infinite loop.
This can happen when importing just a subse
This series fixes a few cases with branch detection
and handling of excludes by git-p4.
This is the third iteration of the patch series.
Changes since v2 [2]:
* Added new test cases for case-insensitive branch detection.
Changes since v1 [1]:
* Added new test case for excluded paths when detec
Christian Couder writes:
> On Wed, Mar 13, 2019 at 5:31 AM Junio C Hamano wrote:
>>
>> Christian Couder writes:
>>
>> > A remote specified using the extensions.partialClone config
>> > option should be considered a promisor remote too.
>> >
>> > This remote should be at the end of the promisor
Given:
A-B-C-D-E (HEAD)
I want to create a single commit that reverts A-B-C
So, I execute:
git revert --no-commit A~..C
which causes conflict (while reverting C, it seems).
I resolve conflicts and I continue:
git revert --continue --no-commit
And, it complains:
fatal: revert: --no
On Wed, Mar 13, 2019 at 5:31 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > A remote specified using the extensions.partialClone config
> > option should be considered a promisor remote too.
> >
> > This remote should be at the end of the promisor remote list,
> > so that it is used
On Wed, Mar 13, 2019 at 5:28 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > From: Christian Couder
> >
> > We will need to reinitialize the promisor remote configuration
> > as we will make some changes to it in a later commit.
> >
> > Signed-off-by: Christian Couder
> > ---
>
> At
On Wed, Mar 13, 2019 at 5:24 AM Junio C Hamano wrote:
>
> Christian Couder writes:
> > +int promisor_remote_get_direct(const struct object_id *oids, int oid_nr)
> > +{
> > + struct promisor_remote *o;
> > +
> > + promisor_remote_init();
> > +
> > + for (o = promisors; o; o = o->next)
Signed-off-by: Christian Couder
---
Documentation/config/remote.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt
index 6c4cad83a2..a8e6437a90 100644
--- a/Documentation/config/remote.txt
+++ b/Documentation/config/re
While at it, let's remove a reference to ODB effort as the ODB
effort has been replaced by directly enhancing partial clone
and promisor remote features.
Signed-off-by: Christian Couder
---
Documentation/technical/partial-clone.txt | 83 ---
1 file changed, 58 insertions(+),
On Wed, Mar 13, 2019 at 5:09 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > +struct promisor_remote *promisor_remote_new(const char *remote_name)
> > +{
>
> Shouldn't this be static? The config callback that calls this
> function is inside this file.
Yeah, I made it static.
> > +
From: Christian Couder
This shows that it is now possible to fetch objects from more
than one promisor remote, and that fetching from a new
promisor remote can configure it as one.
Signed-off-by: Christian Couder
---
t/t0410-partial-clone.sh | 47 +++-
1 fil
This makes it possible to specify a different partial clone
filter for each promisor remote.
Signed-off-by: Christian Couder
---
builtin/fetch.c | 2 +-
list-objects-filter-options.c | 27 +++
list-objects-filter-options.h | 3 ++-
promisor-remote.c
As the infrastructure for more than one promisor remote
has been introduced in previous patches, we can remove
code that forbids the registration of more than one
promisor remote.
Signed-off-by: Christian Couder
---
builtin/fetch.c | 20 +---
1 file changed, 5 insertions(+), 15 d
From: Christian Couder
This is implemented for now by calling fetch_objects(). It fetches
from all the promisor remotes.
Signed-off-by: Christian Couder
---
promisor-remote.c | 64 +++
promisor-remote.h | 1 +
2 files changed, 65 insertions(+)
diff
From: Christian Couder
We will need to reinitialize the promisor remote configuration
as we will make some changes to it in a later commit.
Signed-off-by: Christian Couder
---
promisor-remote.c | 22 --
promisor-remote.h | 1 +
2 files changed, 21 insertions(+), 2 deletion
Instead of using the repository_format_partial_clone global
and fetch_objects() directly, let's use has_promisor_remote()
and promisor_remote_get_direct().
This way all the configured promisor remotes will be taken
into account, not only the one specified by
extensions.partialClone.
Also when clo
A remote specified using the extensions.partialClone config
option should be considered a promisor remote too.
This remote should be at the end of the promisor remote list,
so that it is used only if objects have not been found in other
remotes.
If we are using promisor remotes other than the ori
This path series is a follow up from the "remote odb" patch series
that I sent last year, which were a follow up from previous
series. See the links section for more information.
The goal of this patch series is to make it possible to have and to
fetch missing objects from multiple remotes instead
From: Christian Couder
The promisor-remote.{c,h} files will contain functions to
manage many promisor remotes.
We expect that there will not be a lot of promisor remotes,
so it is ok to use a simple linked list to manage them.
Helped-by: Jeff King
Signed-off-by: Christian Couder
---
Makefile
From: Christian Couder
The callers of the fetch_object() and fetch_objects() might
be interested in knowing if these functions succeeded or not.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
fetch-object.c | 13 -
fetch-object.h | 4 ++--
sha1-file.c| 4 +
The docs claimed `ls` commands could appear almost anywhere, but the
code told a different story. Modify the docs to match the code.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast-
In commit 777f80d7429b ("fast-import: Allow cat-blob requests at
arbitrary points in stream", 2010-11-28), fast-import started allowing
cat-blob commands to appear on the start of any line except in the
middle of a "data" command. It could be in the middle of various
directives that were part of a
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 7 +-
t/t9300-fast-import.sh| 37 +++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index 43ab3
When get-mark was introduced in commit 28c7b1f7b7b7 ("fast-import: add a
get-mark command", 2015-07-01), it followed the precedent of the
cat-blob command to be allowed on any line other than in the middle of a
data directive; see commit 777f80d7429b ("fast-import: Allow cat-blob
requests at arbitr
This series fixes a few issues with parsing in fast-import, dating back to
git-2.6.0. The only change since v1 is removing the RFC label; sadly, no
one commented on the first round.
Text from my original submission:
The point behind this series is that fast-import somehow mishandled
get-mark dir
This is not a very important change, and one that I expect to have no
performance impact whatsoever, but reading the code bothered me. The
parsing of command types in cmd_main() mostly runs in order of most
common to least common commands; sure, it's hard to say for sure what
the most common are w
On Mon, Apr 1, 2019 at 3:44 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > On Wed, Feb 20, 2019 at 2:58 PM Elijah Newren wrote:
> >>
> >> I found a few issues with parsing in fast-import (dating back to
> >
> >> I've cc'ed the relevant folks, and have a few patches that fix the
>
On Sat, Mar 30, 2019 at 2:12 AM Ævar Arnfjörð Bjarmason
wrote:
> On Sat, Mar 30 2019, Elijah Newren wrote:
>
> I may have more, just quickly skimming this for the first time...
>
> > merge.renames::
> > - Whether and how Git detects renames. If set to "false",
> > - rename detection is d
Hi,
On Mon, 1 Apr 2019, Ævar Arnfjörð Bjarmason wrote:
> The culture shock of having a 'blameless' culture from day one might
> be too much for some, so let's allow for setting
> "blame.culture.enforcement=warning" to allow for easing into the
> default of "error".
>
> Also allow for excluding no
Hi David,
On Sat, 30 Mar 2019, David wrote:
> On Thu, 7 Mar 2019 at 09:00, Mike Hommey wrote:
> > On Wed, Mar 06, 2019 at 03:14:11PM +0100, Johannes Schindelin wrote:
> > >
> > > just wanted to express my gratitude for your idea to introduce the `break`
> > > command in `git rebase -i`'s todo li
Hi Stefan,
On Fri, 29 Mar 2019, Stefan Beller wrote:
> Am Mi., 6. März 2019 um 06:14 Uhr schrieb Johannes Schindelin
> :
> >
> > just wanted to express my gratitude for your idea to introduce the
> > `break` command in `git rebase -i`'s todo list. I use it *all* the
> > time now.
>
> You're welco
hi Junio,
On 01/04/2019 11:47, Junio C Hamano wrote:
Philip Oakley writes:
At the moment I'm using an extended _test_ case that starts by adding
a ~5.1Gb file and then using verify-pack, which aborts with an error.
dd if=/dev/zero of=file bs=1M count=5100 &&
git config core.
On Mon, Apr 01, 2019 at 09:30:00AM -0400, Jeff King wrote:
> On Mon, Apr 01, 2019 at 01:52:16PM +0200, SZEDER Gábor wrote:
>
> > diff --git a/progress.c b/progress.c
> > index 842db14b72..3149ecd460 100644
> > --- a/progress.c
> > +++ b/progress.c
> > @@ -84,6 +84,7 @@ static void display(struct p
Hello
If git commit executes .git/hooks/post-commit it will pass GIT_DIR env
variable to the script. However, if hooksPath is set in
$HOME/.gitconfig, git commit executes hooksPath/post-commit without
passing GIT_DIR env variable to the script.
Expected behavior: GIT_DIR is passed to hooksPath/po
Hello
Command-line "git commit" and graphical "git gui" commit are invoking
different hooks if hooksPath is set in $HOME/.gitconfig.
Namely, in my case command-line "git commit" runs
"/home/atom/dev/git-hooks/post-commit" - while "git gui" commit runs
".git/hooks/post-commit".
Please run the att
On Sun, Mar 31, 2019 at 3:16 PM Thomas Gummerer wrote:
>
> On 03/30, Matheus Tavares wrote:
> > 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, mai
On Mon, Apr 01, 2019 at 01:52:16PM +0200, SZEDER Gábor wrote:
> diff --git a/progress.c b/progress.c
> index 842db14b72..3149ecd460 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -84,6 +84,7 @@ static void display(struct progress *progress, uint64_t n,
> const char *done)
> const char *t
On Sat, Mar 30, 2019 at 02:30:01PM -0400, Todd Zullinger wrote:
> Asciidoc uses either one-line or two-line syntax for document/section
> titles[1]. The two-line form is used in git-status. Fix a few section
> titles in the porcelain v2 section which were inadvertently using
> markdown syntax.
On Sat, Mar 30, 2019 at 02:30:00PM -0400, Todd Zullinger wrote:
> Using "+" to continue multiple list items is more tedious and
> error-prone than wrapping the entire block with "--" block markers.
>
> When using asciidoctor, the list items after the --date=iso list items
> are incorrectly format
On Mon, Apr 1, 2019 at 12:19 AM Thomas Gummerer wrote:
>
> If you look at what userformat_find_requirements() does, calls
> strbuf_expand(), which in turn calls userformat_want_item(), which
> fills the 'userformat_want' struct based on the strbuf that has been
> passed.
>
> Now if we look at the
On Mon, 1 Apr 2019 at 08:40, Bert Wesarg wrote:
> Could you try to come up with a recipe from an empty repository?
$ cat a.sh
#!/bin/bash
set -e
git init
for((i=0; i<25; i++)); do
echo line1 > file$i
done
git add file*
git commit -m "initial commit"
for((i=0; i<25; i++)); do
echo line2 >>
The description of --reset stays true to the first implementation in
438195cced (git-read-tree: add "--reset" flag, 2005-06-09). That is,
--reset discards unmerged entries. Or at least true to the commit
message because I can't be sure about read-tree's behavior regarding
local changes.
But in fcc
On Mon, Apr 1, 2019 at 5:47 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > diff --git a/Documentation/git-read-tree.txt
> > b/Documentation/git-read-tree.txt
> > index 5c70bc2878..12a25bc954 100644
> > --- a/Documentation/git-read-tree.txt
> > +++ b/Documentation/git-read-tree.
This patch series fixes two progress display issues:
- When showing throughput, and the both the total and the throughput
change units in the same update, than the previously shown
progress bar is not cleaned up properly:
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 K
When the progress bar includes throughput, its length can shorten as
the unit of display changes from KiB to MiB. To cover up remnants of
the previous progress bar when such a change of units happens we
always print three spaces at the end of the progress bar.
Alas, covering only three characters
The following patches in this series want to handle the progress bar's
title and changing parts (i.e. the counter and the optional percentage
and throughput combined) differently, and need to know the length
of the changing parts of the previously displayed progress bar.
To prepare for those chang
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar e
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never b
Philip Oakley writes:
> At the moment I'm using an extended _test_ case that starts by adding
> a ~5.1Gb file and then using verify-pack, which aborts with an error.
>
> dd if=/dev/zero of=file bs=1M count=5100 &&
> git config core.compression 0 &&
> git config core.looseC
Eric Sunshine writes:
> I don't get why having a configuration option is better for defending
> scripts against this problem than a simple environment variable. It
> seems easier for the script prologue to contain:
>
> GIT_TEST_ABBREVIATED_OPTIONS=false
> export GIT_TEST_ABBREVIATED_OPTIO
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
> index 5c70bc2878..12a25bc954 100644
> --- a/Documentation/git-read-tree.txt
> +++ b/Documentation/git-read-tree.txt
> @@ -38,8 +38,9 @@ OPTIONS
> started.
>
> --reset::
> -
Johannes Schindelin writes:
> Hi Denton,
>
> On Thu, 28 Mar 2019, Denton Liu wrote:
>
>> A common scenario is if a user is working on a topic branch and they
>> wish to make some changes to intermediate commits or autosquash, they
>> would run something such as
>>
>> git rebase -i --onto mas
Denton Liu writes:
>> I suspect that such a rebase will become no-op without "-i". Am I
>> mistaken? I am not sure if "--keep-base" is useful without "-i".
>
> It's useful in the case of "-x", although that is a grey area since "-x"
> uses interactive machinery internally. Aside from "-x", I ca
1 - 100 of 116 matches
Mail list logo
