Signed-off-by: Catalin Criste
---
Documentation/git-stash.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 7ef8c4791177b..b96ce2d02d149 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
Currenly the data rate in throughput_string(...) method is
output by simple strbuf_humanise_bytes(...) call and '/s' append.
But for proper translation of such string the translator needs
full context.
Add strbuf_humanise_rate(...) method to properly print out
localizable version of data rate ('3.
Jeff King writes:
> I do think that accessing the bisect/bad ref is a little intimate with
> the implementation (i.e., it implies knowing that there is only a single
> "bad" that we are moving around, unlike "good", where we may mark many
> such tips).
I actually do not think it is merely an imp
On Mon, Jun 24, 2019 at 09:16:13AM +0200, Christian Couder wrote:
> So you just need to parse stdout to detect that it found the first bad
> commit, and then you can use refs/bisect/bad.
>
> If the return code was used, how would you distinguish between a
> failure in the command (for example if y
On Mon, Jun 24, 2019 at 11:41:53AM -0700, Junio C Hamano wrote:
> > I think it might be nice for Git to write a well-known refname (like
> > BISECT_RESULT or similar) so that you can refer to that instead of
> > having to read stdout (whether by machine or by a user
> > cutting-and-pasting). And I
Hello,
I have $17.5M i want to transfer to your account if interested send me
your contact address your full name your contact phone number.
Yours faithfully,
Emmanuel Gibson.
On Tue, Jun 25, 2019 at 8:38 AM Felipe Contreras
wrote:
>
> On Mon, Jun 24, 2019 at 12:22 PM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > On Sat, Jun 22, 2019 at 5:31 AM Felipe Contreras
> > > wrote:
> > >>
> > >> Versions of Git older than v2.17 don't know about
> > >> --git-comp
Felipe Contreras writes:
> On Mon, Jun 24, 2019 at 12:24 PM Junio C Hamano wrote:
>>
>> Felipe Contreras writes:
>>
>> > In case the command fails.
>>
>> It is unclear what you wanted to say with this. What command?
>> After "git merge" fails?
>
> Yes. The command that __git_list_merge_strateg
On Mon, Jun 24, 2019 at 12:22 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Sat, Jun 22, 2019 at 5:31 AM Felipe Contreras
> > wrote:
> >>
> >> Versions of Git older than v2.17 don't know about
> >> --git-completion-helper, so provide some defaults for them.
> > ...
> >> +__gitcomp_bui
On Mon, Jun 24, 2019 at 12:24 PM Junio C Hamano wrote:
>
> Felipe Contreras writes:
>
> > In case the command fails.
>
> It is unclear what you wanted to say with this. What command?
> After "git merge" fails?
Yes. The command that __git_list_merge_strategies() uses.
% cd /tmp
% git merge -s
Signed-off-by: Andrew Yefanov <1134t...@gmail.com>
---
Documentation/git-p4.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 7436c64a9..aac95d0a0 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -345,6 +345,
Look at the listing:
git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .
git p4 clone is used with the last dot. It is easy to miss the dot, so I offer
to use git p4 sync instead. It has the same syntax, except does not need to
On Sat, Jun 15, 2019 at 12:26:18PM +0100, Thomas Gummerer wrote:
> On 06/14, Mike Hommey wrote:
> > Hi,
> >
> > `git stash ` where n is a number used to work until 2.21.*.
> > It doesn't work in 2.22.0.
> >
> > Bisection points to:
> >
> > dc7bd382b1063303f4f45d243bff371899285acb is the first b
Calling
git submodule foreach --recursive --
leads to an error stating that the option -- is unknown to
submodule--helper. That is of course only, when is not a valid
option for git submodule foreach.
The reason for this is, that above call is internally translated into a
call to submodule
Hi Junio,
thanks for your comments.
I fixed the type in the commit message and adapted my test case to the
required shell script style.
Best regards,
Morian
Junio C Hamano writes:
> > Calling
> >
> > git submodule foreach --recursive --
> >
> > leads to an error stating that the opti
On 6/24/2019 9:02 AM, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy
---
json-writer.c | 14 ++
json-writer.h | 3 +++
split-index.c | 9 -
t/t3011-ls-files-json.sh | 14 ++
t/t3011/split-index (new)
Jeff Hostetler writes:
> On 6/24/2019 9:02 AM, Nguyễn Thái Ngọc Duy wrote:
> ...
>> +void jw_object_stat_data(struct json_writer *jw, const char *name,
>> + const struct stat_data *sd)
>
> Should this be in json_writer.c or in read-cache.c ?
> Currently, json_writer.c is conce
On 6/24/2019 9:02 AM, Nguyễn Thái Ngọc Duy wrote:
The big part of UNTR extension is dumped at the end instead of dumping
as soon as we read it, because we actually "patch" some fields in
untracked_cache_dir with EWAH bitmaps at the end.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c
Johannes Schindelin writes:
> The other path category is the paths in the index, which _are_
> case-sensitive, no matter what core.ignoreCase says.
>
> So I'd rather keep the `fs`.
Sensible. Thanks.
On 6/24/2019 9:02 AM, Nguyễn Thái Ngọc Duy wrote:
So far we don't have a command to basically dump the index file out,
with all its glory details. Checking some info, for example, stat
time, usually involves either writing new code or firing up "xxd" and
decoding values by yourself.
This --js
Eric Wong wrote:
> Hopefully I didn't break anything, stress testing some stuff
> and my own Internet connection is intermittent :<
STARTTLS is now available on port 119, and NNTPS on 563.
I think it works... :x
No idea if it's actually secure or not; but it might help
get around firewalls or tr
On Mon, Jun 24, 2019 at 06:33:38AM -0600, Elijah Newren wrote:
> We should probably also make a corresponding improvement to
> fast-import; it also makes some attempts to be smart about handling
> order of modifies and deletes, but misses this case. See commit
> 253fb5f8897d ("fast-import: Improv
Johannes Schindelin writes:
> From: Johannes Schindelin
>
> On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
> that the idea Bash has of the current directory differs in case from
> what Git thinks it is. That's totally okay, though, and we should not
> expect otherwise.
>
robb...@gentoo.org writes:
> +.PHONY: dist-doc distclean contrib-doc
I do not think I want to do this.
Contrib are not part of the core because they are not. We do not
install their "executable" from the top-level Makefile and I prefer
to keep it that way. Why should we ship their documentatio
Jeff King writes:
> On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
>
>> Thanks for your answer.
>>
>> I was expecting the HEAD to point to the first bad commit.
>>
>> In mercurial, the exit status tells you information about the
>> bisection process: https://www.mercurial-scm.or
On Wed, Jun 12, 2019 at 09:14:40PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 11 Jun 2019, SZEDER Gábor wrote:
>
> > On Tue, Jun 11, 2019 at 01:36:16PM -0700, Junio C Hamano wrote:
> > > SZEDER Gábor writes:
> > >
> > > > -Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing
> > > > (
On 6/24/2019 2:00 PM, Johannes Schindelin wrote:
Hi Duy,
On Mon, 24 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
- json field names now use '_' instead of '.' to be friendlier to some
languages. I stick to underscore_name instead of camelCase because
the former is closer to what we use
Thi
Morian Sonnet writes:
> Calling
>
> git submodule foreach --recursive --
>
> leads to an error stating that the option -- is unknown to
> submodule--helper. That is of course only, when is not a valid
> option for git submodule foreach.
>
> The reason for this is, that above call is interna
When running a command with the 'exec' instruction during an
interactive rebase session, or for a range of commits using 'git
rebase -x', the output can be a bit garbled when the name of the
command is short enough:
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: tru
This series fixes some garbled progress display in 'git rebase' and
simplifies clearing up the progress display in general.
Only slight updates since the previous version to remove one of the
"Yuck"s by making the offending test in t3404 more focused, making
the first patch of the previous version
There are a couple of places where we want to clear the last line on
the terminal, e.g. when a progress bar line is overwritten by a
shorter line, then the end of that progress line would remain visible,
unless we cover it up.
In 'progress.c' we did this by always appending a fixed number of
space
In 't3404-rebase-interactive.sh' the expected output of several tests
is prepared from here documents, which are outside of
'test_expect_success' blocks and have spaces around redirection
operators.
Move these here documents into the corresponding 'test_expect_success'
block and avoid spaces betwe
The test 'rebase -i respects rebase.missingCommitsCheck = warn' is
mainly interested in the warning about the dropped commits, but it
checks the whole output of 'git rebase', including progress lines and
what not that are not at all relevant to 'rebase.missingCommitsCheck',
but make it necessary to
To make sure that the previously displayed progress line is completely
covered up when the new line is shorter, commit 545dc345eb (progress:
break too long progress bar lines, 2019-04-12) added a bunch of
calculations to figure out how many characters it needs to overwrite
with spaces.
Use the jus
Johannes Sixt writes:
> Thanks for educating me. Given your explanations, wouldn't it be much
> more natural to keep the prefix with the unit instead of separating
> them, as the patch does?
Yup, that "octet" comment was illuminating. Great discussion.
Also I am with Duy's message in the other
Dimitriy writes:
> I just moved 'B' out of else block so it will be prepended with
> 'Gi'/'Mi'/'Ki' when needed.
> Note: I changed 'bytes' to just 'B' unit.
That makes this change more than "localizable messages", doesn't it?
As an old timer, I do not mind MiB (I'd prefer the old-fashioned MB
m
Hi Duy,
On Mon, 24 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
> - json field names now use '_' instead of '.' to be friendlier to some
> languages. I stick to underscore_name instead of camelCase because
> the former is closer to what we use
This is not a good reason. People who are used to read
Hi Morian,
On Mon, 24 Jun 2019, Morian Sonnet wrote:
> Calling
>
> git submodule foreach --recursive --
>
> leads to an error stating that the option -- is unknown to
> submodule--helper. That is of course only, when is not a valid
> option for git submodule foreach.
>
> The reason for this
From: Johannes Schindelin
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
that the idea Bash has of the current directory differs in case from
what Git thinks it is. That's totally okay, though, and we should not
expect otherwise.
On Windows, for example, when you call
Hi Junio,
On Mon, 24 Jun 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I wonder if we want (possibly local) test_cmp_fspath that can be
> >> used more like
> >>
> >>test_cmp_fspath "$(pwd)/realgitdir" "$(sed -e "s/^gitdir: //"
> >> newdir/.git)"
> >>
> >> to compare two p
Felipe Contreras writes:
> In case the command fails.
It is unclear what you wanted to say with this. What command?
After "git merge" fails?
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/completion/git-completion.bash | 4 +++-
> t/t9902-completion.sh | 2 +-
> 2 files
Duy Nguyen writes:
> On Sat, Jun 22, 2019 at 5:31 AM Felipe Contreras
> wrote:
>>
>> Versions of Git older than v2.17 don't know about
>> --git-completion-helper, so provide some defaults for them.
> ...
>> +__gitcomp_builtin_add_default=" --dry-run --verbose --interactive --patch
>> --edit --f
Duy Nguyen writes:
>> Hpmh, if it is OK to assume that in all human languages it is OK to
>> express the reate as followed by translated "per second",
>> without allowing the order from getting changed, then ...
>
> Probably not (but I don't know any language that is not ok with this).
> I would
Johannes Schindelin writes:
>> I wonder if we want (possibly local) test_cmp_fspath that can be
>> used more like
>>
>> test_cmp_fspath "$(pwd)/realgitdir" "$(sed -e "s/^gitdir: //"
>> newdir/.git)"
>>
>> to compare two paths, honoring the case sensitivity of the
>> filesystem.
>
> I agree
Andrey writes:
> 20.06.2019, 00:35, "Junio C Hamano" :
>> * am/p4-branches-excludes (2019-04-02) 8 commits
>> - git-p4: respect excluded paths when detecting branches
>> - git-p4: add failing test for "git-p4: respect excluded paths when
>> detecting branches"
>> - git-p4: don't exclude other
Ævar Arnfjörð Bjarmason writes:
> diff --git a/config.c b/config.c
> index 374cb33005..b985d60fa4 100644
> --- a/config.c
> +++ b/config.c
> @@ -956,6 +956,15 @@ static void die_bad_number(const char *name, const char
> *value)
> if (!value)
> value = "";
>
> + if (!st
Hello,
I know —preserve-merges is deprecated now and —rebase-merges should be used
instead, however it is still possible to pass —preserve-merges flag, so the
issue seems worth reporting.
In git 2.22, —preserve-merges does not work when custom commentchar is used. It
shows the editor to select
Calling
git submodule foreach --recursive --
leads to an error stating that the option -- is unknown to
submodule--helper. That is of course only, when is not a valid
option for git submodule foreach.
The reason for this is, that above call is internally translated into a
call to submodule
Using the right testing git now.
here comes the next version.
> Johannes Schindelin wrote:
>
> Hi Morian,
>
> On Sat, 22 Jun 2019, Morian Sonnet wrote:
>
> > Johannes Schindelin wrote:
> >
> > > On Tue, 18 Jun 2019, Morian Sonnet wrote:
> > >
> > > > "Morian Sonnet via GitGitGadget" wrote:
> > > >
> > > > > Calling
> > > >
Calling
git submodule foreach --recursive --
leads to an error stating that the option -- is unknown to
submodule--helper. That is of course only, when is not a valid
option for git submodule foreach.
The reason for this is, that above call is internally translated into a
call to submodule
On Mon, Jun 24, 2019 at 5:52 PM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Sat, 22 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
>
> > An index entry serves two purposes: to keep the content to be committed,
> > and to mark that the same path on worktree is tracked. When
> >
> > git rm --cached foo
On Mon, Jun 24, 2019 at 9:20 PM Derrick Stolee wrote:
>
> On 6/24/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > archive.c | 4 +++-
> > blame.c| 4 ++--
> > builtin/rm.c | 2 +-
> > builtin/update-index.c |
On Mon, Jun 24, 2019 at 9:24 PM Derrick Stolee wrote:
>
> On 6/24/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> > There are a couple of places where 'struct repository' is already passed
> > around, but the_repository is still used. Use the right repo.
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy
>
On 6/24/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> There are a couple of places where 'struct repository' is already passed
> around, but the_repository is still used. Use the right repo.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
nit: the subject line doesn't use the standard "area: topic" format
On 6/24/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> archive.c | 4 +++-
> blame.c| 4 ++--
> builtin/rm.c | 2 +-
> builtin/update-index.c | 2 +-
> line-log.c | 7 ---
> match-trees.c
On 6/24/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> While at there, clean up the_repo usage in builtin/merge-tree.c a tiny
> bit.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/merge-tree.c | 22 +-
> builtin/rebase.c | 4 ++--
> builtin/reset.c | 4 ++--
>
On 6/24/2019 8:07 AM, Nathaniel Filardo wrote:
> If the user is careful to mark .pack files as kept only when they refer
> to (other) kept packs, then we can rely on this when walking the object
> graph in subsequent repack operations and reduce the time and memory
> spent building the object graph
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t3008-ls-files-lazy-init-name-hash.sh | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/t/t3008-ls-files-lazy-init-name-hash.sh
b/t/t3008-ls-files-lazy-init-name-hash.sh
index 64f047332b..7f918c05f6 100755
--- a/t/t3008-ls-files-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 8
t/t3011-ls-files-json.sh | 13 ++
t/t3011/eoie (new) | 96
t/test-lib.sh| 4 ++
4 files changed, 121 insertions(+)
diff --git a/read-cache.c b/read-cache.c
The big part of UNTR extension is dumped at the end instead of dumping
as soon as we read it, because we actually "patch" some fields in
untracked_cache_dir with EWAH bitmaps at the end.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c| 57 +++
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fsmonitor.c | 6 ++
t/t3011-ls-files-json.sh | 14 +-
t/t3011/fsmonitor (new) | 38 ++
3 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/fsmonitor.c b/fsmonitor.c
index 1dee0ade
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 2 +-
resolve-undo.c | 30 +-
resolve-undo.h | 4 ++-
t/t3011-ls-files-json.sh | 20
t/t3011/rerere (new) | 66
5 files changed, 119 i
So far we don't have a command to basically dump the index file out,
with all its glory details. Checking some info, for example, stat
time, usually involves either writing new code or firing up "xxd" and
decoding values by yourself.
This --json is supposed to help that. It dumps the index in a hu
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache-tree.c | 36 +++-
cache-tree.h | 5 -
read-cache.c | 2 +-
t/t3011-ls-files-json.sh | 4 +++-
t/t3011/basic| 20 +++-
5 files changed, 58 insertions
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 43 ---
t/t3011/eoie | 13 -
2 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 37491dd03d..c26edcc9d9 100644
--- a/read-cache.c
+++ b/read-cac
On 6/24/2019 8:07 AM, Nathaniel Filardo wrote:
> The sparse connectivity algorithm saves a whole lot of time when there
> are UNINTERESTING trees around.
Neat! Any chance for some example performance stats?
> ---
Looks like you forgot your Signed-off-by here.
> +# repack --sparse invokes pack-o
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 49 +++--
1 file changed, 35 insertions(+), 14 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index db5147d088..4accd8bb08 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1694,8 +1694,26 @@
Signed-off-by: Nguyễn Thái Ngọc Duy
---
json-writer.c | 14 ++
json-writer.h | 3 +++
split-index.c | 9 -
t/t3011-ls-files-json.sh | 14 ++
t/t3011/split-index (new) | 39 +++
5 files chang
v2 main changes:
- --json is renamed --debug-json
- json field names now use '_' instead of '.' to be friendlier to some
languages. I stick to underscore_name instead of camelCase because
the former is closer to what we use
- extension location is printed, in case you need to decode the
exte
On Mon, Jun 24, 2019 at 5:05 AM Lars Schneider wrote:
>
> Hi folks,
>
> Is my understanding correct, that `git fast-export | git fast-import`
> should not modify the repository?
I forgot to respond to this part. The answer is mostly yes, but actually no:
* fast-export strips any extended commit
On 6/24/2019 8:07 AM, Nathaniel Filardo wrote:
> Add another bit flag to the struct rev_info.
>
> The only caller that uses this after this patch is builtin/pack-objects.
> Without this, sparsity seems to do little good therein, as
> prepare_revision_walk will densely propagate UNINTERESTING flags
On 6/24/2019 8:07 AM, Nathaniel Filardo wrote:
> Signed-off-by: Nathaniel Filardo
>
> update count-objects
> ---
This post-signoff text looks like cruft from a rebase.
-Stolee
On Wed, Jun 19, 2019 at 8:03 PM Derrick Stolee wrote:
> > - show_files(the_repository, &dir);
> > -
> > - if (show_resolve_undo)
> > - show_ru_info(the_repository->index);
> > + if (!show_json) {
> > + show_files(the_repository, &dir);
> > +
> > + if
The two tests 'invalid Content-Type rejected' and 'server-side error
detected' in 't5551-http-fetch-smart.sh' use "plain" 'grep' to check
that 'git clone' failed with the expected error message, but the
messages they are checking are translated, and, consequently, these
tests fail when the test scr
On Mon, Jun 24, 2019 at 5:05 AM Lars Schneider wrote:
>
> Hi folks,
>
> Is my understanding correct, that `git fast-export | git fast-import`
> should not modify the repository? If yes, then we might have a bug in
> `git fast-export` if symbolic directory links are removed and converted
> to a rea
Just pass it on down to builtin/repack.
Signed-off-by: Nathaniel Filardo
---
Documentation/git-gc.txt | 4
builtin/gc.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 247f765604..6f9f15ef19 100644
--- a/Documen
Specifically: number of kept packs, size of kept packs (and indexes),
and number of objects in kept packs.
Add documentation of resulting fields. While here, correct the omission
from ae72f68541 ("count-objects -v: show number of packs as well.",
2006-12-27) of the "packs" field.
Update tests wh
Add another bit flag to the struct rev_info.
The only caller that uses this after this patch is builtin/pack-objects.
Without this, sparsity seems to do little good therein, as
prepare_revision_walk will densely propagate UNINTERESTING flags from
trees to tree contents, before mark_edges_uninteres
This patch series improves handling of very large repositories, as generated
by, for example, bup (https://github.com/bup/bup). Prolonged operation
thereof creates quite a lot of small pack files; repacking improves
filesystem performance of the objects/pack directory, but is quite
expensive, in t
If the user is careful to mark .pack files as kept only when they refer
to (other) kept packs, then we can rely on this when walking the object
graph in subsequent repack operations and reduce the time and memory
spent building the object graph.
Towards that end, then, teach git repack to enumerat
The sparse connectivity algorithm saves a whole lot of time when there
are UNINTERESTING trees around.
---
Documentation/git-repack.txt | 4
builtin/repack.c | 5 +
t/t5322-pack-objects-sparse.sh | 6 ++
3 files changed, 15 insertions(+)
diff --git a/Documentation/git
Hi folks,
Is my understanding correct, that `git fast-export | git fast-import`
should not modify the repository? If yes, then we might have a bug in
`git fast-export` if symbolic directory links are removed and converted
to a real directory.
Consider this test case:
# Create test repo
Hi Duy,
On Sat, 22 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
> An index entry serves two purposes: to keep the content to be committed,
> and to mark that the same path on worktree is tracked. When
>
> git rm --cached foo
>
> is called and there is "foo" in worktree, its status is changed from
>
Hi Morian,
On Sat, 22 Jun 2019, Morian Sonnet wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 18 Jun 2019, Morian Sonnet wrote:
> >
> > > "Morian Sonnet via GitGitGadget" wrote:
> > >
> > > > Calling
> > > >
> > > > git submodule foreach --recursive git reset --hard
> > > >
> > > > leads
Hi Philip,
On Sat, 22 Jun 2019, Philip Oakley wrote:
> On 18/06/2019 18:01, Eric Sunshine wrote:
> > On Tue, Jun 18, 2019 at 12:39 PM Anthony Sottile wrote:
> > > + git fetch origin --tags
> > > Unpacking objects: 100% (10/10), done.
> > > From https://github.com/asottile-archive/git-windows-br
Hi Junio,
On Fri, 21 Jun 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > [Re-sending, as the Git mailing list seems to have decided to silently
> > drop this patch, I cannot see it on public-inbox.org, at least]
>
> Move that below the three-dash lines; otherwise the above two li
There are a couple of places where 'struct repository' is already passed
around, but the_repository is still used. Use the right repo.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
merge-recursive.c | 35 ---
sequencer.c | 4 ++--
sha1-name.c | 6 ++
s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 4 ++--
match-trees.c | 12 +++-
merge-recursive.c | 4 ++--
t/helper/test-match-trees.c | 2 +-
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index cd84cc
This is the continuation of nd/sha1-name-c-wo-the-repository. In that
series I sealed off one place in sha1-name.c that cannot walk trees
from arbitrary repositories. With tree-walk.c taking 'struct
repository *' directly, that check in there can now be removed.
Nguyễn Thái Ngọc Duy (6):
sha1-fi
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/cat-file.c | 3 ++-
builtin/grep.c | 6 --
builtin/pack-objects.c | 3 ++-
cache.h| 3 ++-
fast-import.c | 9 ++---
sha1-file.c| 5 +++--
tree-walk.c| 7 ---
7 files changed, 2
Signed-off-by: Nguyễn Thái Ngọc Duy
---
sha1-name.c | 10 +-
tree-walk.c | 12
tree-walk.h | 2 +-
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/sha1-name.c b/sha1-name.c
index e8fb215e5c..3c9fa10af8 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1890,16 +
While at there, clean up the_repo usage in builtin/merge-tree.c a tiny
bit.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/merge-tree.c | 22 +-
builtin/rebase.c | 4 ++--
builtin/reset.c | 4 ++--
notes.c | 2 +-
sequencer.c | 2 +-
tree-d
Signed-off-by: Nguyễn Thái Ngọc Duy
---
archive.c | 4 +++-
blame.c| 4 ++--
builtin/rm.c | 2 +-
builtin/update-index.c | 2 +-
line-log.c | 7 ---
match-trees.c | 6 +++---
merge-recursive.c | 8 +---
notes.c
Hi Peff,
On Fri, 21 Jun 2019, Jeff King wrote:
> On Fri, Jun 21, 2019 at 03:16:52PM +0200, Johannes Schindelin wrote:
>
> > > I think your warning in the manpage that this is for debugging is fine,
> > > as it does not put us on the hook for maintaining the feature nor its
> > > format forever. W
On Mon, Jun 24, 2019 at 4:32 PM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Fri, 21 Jun 2019, Duy Nguyen wrote:
>
> > On Fri, Jun 21, 2019 at 8:16 PM Johannes Schindelin
> > wrote:
> >
> > > > I think your warning in the manpage that this is for debugging is fine,
> > > > as it does not put us
Hi Peff & Junio,
On Fri, 21 Jun 2019, Jeff King wrote:
> On Fri, Jun 21, 2019 at 08:10:58AM -0700, Junio C Hamano wrote:
>
> > Duy Nguyen writes:
> >
> > > Considering the amount of code to output these, supporting multiple
> > > formats would be a nightmare. I may be ok with versioning the outp
Hi Duy,
On Fri, 21 Jun 2019, Duy Nguyen wrote:
> On Fri, Jun 21, 2019 at 8:16 PM Johannes Schindelin
> wrote:
>
> > > I think your warning in the manpage that this is for debugging is fine,
> > > as it does not put us on the hook for maintaining the feature nor its
> > > format forever. We might
On Mon, Jun 24 2019, Jeff King wrote:
> On Sun, Jun 23, 2019 at 06:08:25PM +, Eric Wong wrote:
>
>> > I'm not sure of the right solution. For maximal backwards-compatibility,
>> > the default for bitmaps could become "if not bare and if there are no
>> > .keep files". But that would mean bit
On Mon, Jun 24, 2019 at 4:51 AM Jeff King wrote:
>
> On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
>
> > Thanks for your answer.
> >
> > I was expecting the HEAD to point to the first bad commit.
> >
> > In mercurial, the exit status tells you information about the
> > bisection pr
1 - 100 of 101 matches
Mail list logo
