Hi Phillip,
On Tue, Mar 19, 2019 at 11:13:37AM +, Phillip Wood wrote:
> Hi Denton
>
> On 17/03/2019 10:16, Denton Liu wrote:
> > This change allows git-merge messages to be cleaned up with the
> > commit.cleanup configuration or --cleanup option, just like how
> > git-commit does it.
> >
> >
On Tue, Mar 19, 2019 at 10:35:54AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > My guess is you forgot the tag? There's not a general solution there,
> > because the tags all get intermingled. Git has no idea which ones came
> > from which remote. However, if you have the commit id of an object you
>
On Wed, Mar 20, 2019 at 09:38:57AM +0900, Junio C Hamano wrote:
> "git log -p --first-parent" that requires "-m" to show the single
> ball of wax diff for a merge is a separate matter. When the user
> explicitly says "log --first-parent", it is a clear indication that
> the user does not want to
On Tue, Mar 19, 2019 at 11:18:26PM +, Thomas Gummerer wrote:
> From a quick search I couldn't find where 'git diff' actually parses
> the '-v' argument, but I wonder if we should actually disallow it, in
> case we want to use it for something else in the future? It's not
> documented anywhere
Junio C Hamano writes:
> * nb/branch-show-other-worktrees-head (2019-03-18) 3 commits
> - branch: add worktree info on verbose output
> - branch: update output to include worktree info
> - ref-filter: add worktreepath atom
>
> "git branch --list" learned to show branches that are checked out
"C.J. Jameson" writes:
> When cherry-picking from a standard merge commit, the parent should
> always be 1, as it has the meaningful new changes which were added to
> the mainline. If the source commit is unique in some way and a user
> wants to specify a value other than 1, they still can, but i
>From fbb0e1fef08a2abd7f1620134925788f7a0e011f Mon Sep 17 00:00:00 2001
From: "C.J. Jameson"
Date: Tue, 19 Mar 2019 17:57:31 -0700
Subject: [RFC PATCH] cherry-pick: set default `--mainline` parent to 1
When cherry-picking from a standard merge commit, the parent should
always be 1, as it has the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
Duy Nguyen writes:
> Kinda. But "--force --merge" makes no sense. --force discards all
> local changes by definition, which means you can't have conflicts and
> will not need --merge. I think this is the reason why we die() out
> when both are specified. So we need something like
> --discard-stag
On Wed, Mar 20, 2019 at 2:04 AM Phillip Wood wrote:
> It would perhaps be better to pass around the_index rather than
> the_repository
Not by a large margin. For sequencer.c most operations require more
than just the index and passing 'struct repository *' around has been
the norm. And as
Dear Friend,
I am Mrs Clara David. am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsclarad...@gmail.com)
as i wa
On Wed, Mar 20, 2019 at 8:19 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> I think "checkout -m " with a dirty index should refuse
> >> to run; there is nothing to "continue" after such a failure, so I am
> >> not sure what you mean by "an option to continue" (iow, I do not see
> >> a ne
Duy Nguyen writes:
>> I think "checkout -m " with a dirty index should refuse
>> to run; there is nothing to "continue" after such a failure, so I am
>> not sure what you mean by "an option to continue" (iow, I do not see
>> a need for such an option, and if that option makes the whole notion
>>
Dave Huseby writes:
> Fix the way GPG keyrings are imported during testing to prevent GPG from
> prompting for approval to change the default config. This appears to have no
> adverse affects on GPG users with "normal" configurations but fixes the
> always-interactive prompting I see with my mul
Thomas Gummerer writes:
> Subject: [PATCH] stash: setup default diff output format if necessary
>
> In the scripted 'git stash show' when no arguments are passed, we just
> pass '--stat' to 'git diff'. When any argument is passed to 'stash
> show', we no longer pass '--stat' to 'git diff', and p
Thomas Gummerer writes:
> Subject: [PATCH] stash: setup default diff output format if necessary
>
> In the scripted 'git stash show' when no arguments are passed, we just
> pass '--stat' to 'git diff'. When any argument is passed to 'stash
> show', we no longer pass '--stat' to 'git diff', and p
balaji marisetti writes:
> Can anyone please tell me if there is way to see the command history
> of a local git repo? If there isn't a way, why hasn't the
> command-history feature been implemented?
Another question may be why anybody would want to have such a per
repository command history, wa
On Wed, Mar 20, 2019 at 7:24 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > If you have staged changes in path A and perform 'checkout
> > --merge' (which could result in conflicts in a totally unrelated path
> > B), changes in A will be gone. Which is unexpected. We are suppose
Phillip Wood writes:
> Thanks for doing this, one minor comment - I try to use
> phillip.w...@dunelm.org.uk for git as it wont change if I change my
> email provider.
You mean something like this?
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 82cd0569d5
Sergey Organov writes:
> I think that "first-parent is special" is the way to go indeed for
> porcelain, as it does make many thing easier and more convenient[*].
Perhaps. However ...
> [*] One example that immediately comes to mind is "git log -p" for a
> merge commit. I doesn't currently (as
Nguyễn Thái Ngọc Duy writes:
> If you have staged changes in path A and perform 'checkout
> --merge' (which could result in conflicts in a totally unrelated path
> B), changes in A will be gone. Which is unexpected. We are supposed
> to keep all changes, or kick and scream otherwise.
>
> This is
Fix the way GPG keyrings are imported during testing to prevent GPG from
prompting for approval to change the default config. This appears to have no
adverse affects on GPG users with "normal" configurations but fixes the
always-interactive prompting I see with my multi-keyring setup.
v2: fixed t
On 03/19, Denton Liu wrote:
> Hi all,
>
> I've been using jch's branch and I discovered a regression in
> ps/stash-in-c.
>
> Here's a test-case on git.git:
>
> echo '/**/' >>abspath.c
> git stash
> git stash show -v
> # I am expecting the diff to show up here
>
> I am ex
Fix the way GPG keyrings are imported during testing to prevent GPG from
prompting for approval to change the default config. This appears to have no
adverse affects on GPG users with "normal" configurations but fixes the
always-interactive prompting I see with my multi-keyring setup.
Signed-off-
On 2019.03.08 13:55, Jonathan Tan wrote:
> Here's my current progress - the only thing that is lacking is more
> tests, maybe, so I think it's ready for review.
This series looks good to me.
Reviewed-by: Josh Steadmon
On Tue, Mar 19 2019, Phillip Wood wrote:
> From: Phillip Wood
>
> cmd_rebase() and cmd_rebase__interactive() used different enums to hold
> the current action. Change to using a common enum so the values are the
> same when we change `rebase -i` to avoid forking `rebase--interactive`.
>
> Signe
On 3/19/2019 10:37 AM, Jeff Hostetler via GitGitGadget wrote:
From: Jeff Hostetler
Fix "git multi-pack-index verify" to handle repos with thousands
of packfiles.
Midx verify adds the individual "packed_git" structures to the
multi_pack_index.packs array, but it does not add them to the
"rep
Hi all,
I've been using jch's branch and I discovered a regression in
ps/stash-in-c.
Here's a test-case on git.git:
echo '/**/' >>abspath.c
git stash
git stash show -v
# I am expecting the diff to show up here
I am expecting the diff to show up but in reality, I
From: Phillip Wood
When the builtin rebase starts an interactive rebase it parses the
options and then repackages them and forks
`rebase--interactive`. Separate the option parsing in
cmd_rebase__interactive() from the business logic to allow interactive
rebases can be run without forking `rebase_
From: Phillip Wood
As the checkout runs in a separate process our index will be out of date
so it should be discarded. The existing callers are not doing this
consistently so do it here to avoid the callers having to worry about
it.
This fixes some test failures that happen if do_interactive_reb
From: Phillip Wood
In order to run `rebase -i` without forking `rebase--interactive` it
will be convenient to use the same structure when parsing the options in
cmd_rebase() and cmd_rebase__interactive().
Signed-off-by: Phillip Wood
---
builtin/rebase.c | 203 ++
From: Phillip Wood
This is in preparation for using `struct rebase_options` when parsing
options in cmd_rebase__interactive(). Using a string for onto,
restrict_revision and upstream, was a hangover from the scripted version
of rebase. The functions that use these variables are updated to take a
From: Phillip Wood
cmd_rebase() and cmd_rebase__interactive() used different enums to hold
the current action. Change to using a common enum so the values are the
same when we change `rebase -i` to avoid forking `rebase--interactive`.
Signed-off-by: Phillip Wood
---
Notes:
I'm not sure wha
From: Phillip Wood
When the builtin rebase starts an interactive rebase it parses the
options and then repackages them and forks `rebase--interactive`. This
series refactors rebase--interactive so that interactive rebases can
be started by the builtin rebase without forking. My motivation was to
From: Phillip Wood
In order to run `rebase -i` without forking `rebase--interactive` it
will be convenient to have all the code from rebase--interactive.c in
rebase.c. This is a straight forward copy of the code from
rebase--interactive.c, it will be simplified slightly in the next
commit.
Signe
From: Phillip Wood
More preparation for using `struct rebase_options` in
cmd_rebase__interactive(). Using a string was a hangover from the
scripted version of rebase, update the functions that use `squash_onto`
to take a `sturct object_id`.
Signed-off-by: Phillip Wood
---
builtin/rebase.c |
From: Phillip Wood
All the parameters that are passed to do_interactive_rebase() apart from
`flags` are already in `struct rebase_options` so there is no need to
pass them separately.
Signed-off-by: Phillip Wood
---
builtin/rebase.c | 69 +---
1 file
From: Phillip Wood
As we have a macro for this it makes sense to use it. Having
cmd_rebase() and cmd_rebase__interactive() use the same values for
this option will be helpful when we start running interactive rebases
without forking rebase--interactive.
Signed-off-by: Phillip Wood
---
builtin/
From: Phillip Wood
This clashes with a function in sequencer.c
Signed-off-by: Phillip Wood
---
builtin/rebase.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 52114cbf0d..b634879c5b 100644
--- a/builtin/rebase.c
+++ b/builtin/r
From: Phillip Wood
path_state_dir() and merge_dir() refer to the same path so remove one of
them.
Signed-off-by: Phillip Wood
---
builtin/rebase.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 80252d72df..e55bd0348a 100644
--
On Tue, Mar 19, 2019 at 2:33 PM Jeff Hostetler wrote:
> On 3/19/2019 12:42 PM, Eric Sunshine wrote:
> > Rather than adding a new "sparse" mode, I wonder if this entire
> > concept can be boiled down to a single new function:
> >
> > void finish_progress(struct progress **p_progress, const cha
On 3/19/2019 12:42 PM, Eric Sunshine wrote:
On Tue, Mar 19, 2019 at 10:37 AM Jeff Hostetler via GitGitGadget
wrote:
Add new start_sparse_progress() and start_delayed_sparse_progress()
constructors and "sparse" flag to struct progress.
Teach stop_progress() to force a 100% complete progress
On 3/19/2019 1:13 PM, tbo...@web.de wrote:
From: Torsten Bögershausen
Some compilers don't allow NULL to be passed for a va_list,
and e.g. "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516"
errors out like this:
trace2/tr2_tgt_event.c:193:18:
error: invalid operands to binary &&
From: Torsten Bögershausen
Some compilers don't allow NULL to be passed for a va_list,
and e.g. "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516"
errors out like this:
trace2/tr2_tgt_event.c:193:18:
error: invalid operands to binary &&
(have ‘int’ and ‘va_list {aka __va_list}’)
if (
On Tue, Mar 19, 2019 at 10:37 AM Jeff Hostetler via GitGitGadget
wrote:
> Add new start_sparse_progress() and start_delayed_sparse_progress()
> constructors and "sparse" flag to struct progress.
>
> Teach stop_progress() to force a 100% complete progress message before
> printing the final "done"
Hi All,
Can anyone please tell me if there is way to see the command history
of a local git repo? If there isn't a way, why hasn't the
command-history feature been implemented?
Thanks,
Balaji M
--
:-)balaji
From: Jeff Hostetler
Fix "git multi-pack-index verify" to handle repos with thousands
of packfiles.
Midx verify adds the individual "packed_git" structures to the
multi_pack_index.packs array, but it does not add them to the
"repository.objects.packed_git" list. During the verification
code, ea
From: Jeff Hostetler
Add new start_sparse_progress() and start_delayed_sparse_progress()
constructors and "sparse" flag to struct progress.
Teach stop_progress() to force a 100% complete progress message before
printing the final "done" message when "sparse" is set.
Calling display_progress() f
From: Jeff Hostetler
Teach `multi-pack-index verify` to sort the set of objects by
packfile so that only one packfile needs to be open at a time.
This is a performance improvement. Previously, objects were
verified in OID order. This essentially requires all packfiles
to be open at the same ti
Version 2 addresses progress-related concerns raised in the previous version
of the midx verify code.
This version also extends the existing progress.[ch] code and adds a
"sparse" mode that automatically ensures the 100% message is issued.
From: Jeff Hostetler
Log multi-pack-index command mode.
Log number of objects and packfiles in the midx.
Signed-off-by: Jeff Hostetler
---
builtin/multi-pack-index.c | 3 +++
midx.c | 4
2 files changed, 7 insertions(+)
diff --git a/builtin/multi-pack-index.c b/builti
On Tue, Mar 19 2019, Jeff Hostetler wrote:
> On 3/18/2019 6:02 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Mon, Mar 18 2019, Jeff Hostetler wrote:
>>
>>> On 3/18/2019 11:53 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
> [...]
>
Hi Duy
Thanks for doing this, one minor comment - I try to use
phillip.w...@dunelm.org.uk for git as it wont change if I change my
email provider.
Best Wishes
Phillip
On 18/03/2019 11:38, Nguyễn Thái Ngọc Duy wrote:
Phillip found out that 'git checkout -f ' does not restore
conflict/unmerg
On 3/18/2019 6:02 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Mar 18 2019, Jeff Hostetler wrote:
On 3/18/2019 11:53 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
[...]
+ QSORT(pairs, m->num_objects, compare_pair_pos_vs_id);
+
+
Thanks for the feedback.
Whilst I understand the options that you've both proposed, the intent
was to enable the Swift Package Manager to mirror repositories in a
transparent way. I'll look into whether these options can be
implemented inside the SPM.
Cheers,
Dimitri.
On 19/3/19 7:24 pm, Ævar
Hi Junio,
[It's been a while since this discussion, and recently I've got some
thoughts and questions about "first-parent" issues in general, below.]
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge
Hi Duy
On 19/03/2019 09:39, Nguyễn Thái Ngọc Duy wrote:
If you have staged changes in path A and perform 'checkout
--merge' (which could result in conflicts in a totally unrelated path
B), changes in A will be gone. Which is unexpected. We are supposed
to keep all changes, or kick and scream oth
Hi Denton
On 17/03/2019 10:16, Denton Liu wrote:
This change allows git-merge messages to be cleaned up with the
commit.cleanup configuration or --cleanup option, just like how
git-commit does it.
We also give git-pull the passthrough option of --cleanup so that it can
also take advantage of th
Hi Ævar
On 18/03/2019 11:01, Ævar Arnfjörð Bjarmason wrote:
Remove the rebase.useBuiltin setting, which was added as an escape
hatch to disable the builtin version of rebase first released with Git
2.20.
See [1] for the initial implementation of rebase.useBuiltin, and [2]
and [3] for the documen
If you have staged changes in path A and perform 'checkout
--merge' (which could result in conflicts in a totally unrelated path
B), changes in A will be gone. Which is unexpected. We are supposed
to keep all changes, or kick and scream otherwise.
This is the result of how --merge is implemented,
should no longer be reachable
>> now that i deleted that remote.
>
> After arriving at a similar state, I did:
>
> git remote rm linux-next
> git tag -d next-20190319
> git gc --prune=now
>
> My guess is you forgot the tag? There's not a general solution th
On Fri, Mar 08 2019, Mikko Rantalainen wrote:
> If I configure bare repo with
>
> git config gc.pruneExpire never
> git config gc.reflogExpire never
>
> then git will never garbage collect any commit ever stored in the repo.
> This is what I want.
>
> However, all commits referenced only via ref
On Tue, Mar 19 2019, Johannes Sixt wrote:
> Am 18.03.19 um 17:15 schrieb Ævar Arnfjörð Bjarmason:
>> +Using this option may optimize for disk space at the expense of
>> +runtime performance. See the `--depth` and `--window` documentation in
>> +linkgit:git-repack[1]. It is not recommended that t
On Tue, Mar 19 2019, Jeff King wrote:
> On Sat, Mar 09, 2019 at 10:46:09AM +, Dimitri Joukoff wrote:
>
>> Thus, this feature request is asking that the 'pre-receive' hook
>> triggers when someone tries to push to a repository regardless of
>> whether the repository exists. This would allow
Hi,
When testing version 2.21.0 of git on AIX (6.1 & 7.2), I have found an issue
with daemon.c and test t5570-git-daemon.sh : within test 4, the child_handler()
code gets crazy and calls itself recursively till the process crashes. We do
not have a clear idea why this issue occurs. Maybe that t
On Tue, Mar 19, 2019 at 08:12:54AM +0100, Martin Ågren wrote:
> > I just tried with asciidoc 2.0.0.rc.2, which came out last week. It does
> > seem to work from the command line:
> >
> > $ make USE_ASCIIDOCTOR=Yes \
> > ASCIIDOC_DOCBOOK=docbook5 \
> > ASCIIDOC='asciidoctor -ama
Hi Junio
On Tue, 19 Mar 2019 at 08:33, Martin Ågren wrote:
> between asciidoc and asciidoctor considerably. Let's assume for the
> moment that these patches or something like them enter master...
To be clear. *This* patch has a sufficiently incorrect commit message
that it really needs a makeove
On Tue, 19 Mar 2019 at 04:55, Junio C Hamano wrote:
>
> Jeff King writes:
>
> > So in my mind, the endgame is that we eventually drop asciidoc in favor
> > of asciidoctor. The repo at:
> >
> > https://github.com/asciidoc/asciidoc
> >
> > says:
> >
> > NOTE: This implementation is written in P
On Tue, 19 Mar 2019 at 04:30, Jeff King wrote:
>
> On Mon, Mar 18, 2019 at 10:46:45PM -0400, Jeff King wrote:
>
> > It does seem like "mansource" is the way asciidoctor expects us to do
> > this. Why doesn't it work from the command line? Is it a bug in
> > asciidoctor, or is there something more
On Tue, 19 Mar 2019 at 03:46, Jeff King wrote:
>
> On Sun, Mar 17, 2019 at 03:47:47PM +0100, Martin Ågren wrote:
>
> > Cc Todd and Peff who had a brief exchange [1] a while ago. Apparently
> > Todd saw this "[FIXME: source]" on Fedora but Peff did not on Debian.
> > I'm on Ubuntu 18.04 and used
On Sat, Mar 09, 2019 at 10:46:09AM +, Dimitri Joukoff wrote:
> Thus, this feature request is asking that the 'pre-receive' hook
> triggers when someone tries to push to a repository regardless of
> whether the repository exists. This would allow automatic creation of
> new repositories and sm
On Sun, 17 Mar 2019 at 20:44, Todd Zullinger wrote:
> Martin Ågren wrote:
> > * Provide the `mansource` attribute to Asciidoctor. This attribute
> > looks promising until one realizes that it can only be given inside
> > the source file (the .txt file in our case), *not* on the command
>
72 matches
Mail list logo
