"Johannes Schindelin via GitGitGadget"
writes:
> This can be seen very clearly when passing arguments with special
> characters, like
>
> git stash -- ':(glob)**/*.txt'
>
> Since this is exactly what we want to test in the next commit (where we
> fix this very incantation with the built-in
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When passing a list of pathspecs to, say, `git add`, we need to be
> careful to use the original form, not the parsed form of the pathspecs.
>
> This makes a difference e.g. when calling
>
> git stash -- ':(glob
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> Subject: [PATCH 1/2] stash: pass pathspec as pointer
>>
>> Passing the pathspec by value is potentially confusing, as the copy is
>> only a shallow copy, so save the overhead of the copy, and pass the
>> pathspec struct as a pointer.
>>
>> In
Hey Git people,
I didn't get a reply and I'm not sure what the appropriate ping
interval is, or when I should conclude that no one is interested.
There seemed to be some vaguely positive feedback before I embarked on
this project. At the same time I don't want to pester anyone into
applying patc
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.
The tip of 'next' has been rewound
On Mon, Mar 11, 2019 at 1:20 PM Junio C Hamano wrote:
>
> Eric Sunshine writes:
>
> >> case 2:
> >> + if (last == '.') { /* Refname contains "..". */
> >> + if (sanitized)
> >> + sanitized->l
Martin Ågren writes:
> Ok, then I'll take that offer. I'll squash these two patches into the
> original series. Thanks.
Our mails might cross, but just in case you haven't started, here
are the locally squashed results with updated log messages.
From: Martin Ågren
These stylesheets very rarely change, but when they do, it really helps
if the manpages depend on them. We're casting the net a bit too wide
here, since we'll only ever use a subset of the stylesheets, but since
these files change so rarely, that should be ok. It's better than
From: Martin Ågren
asciidoctor-extensions.rb has never changed, but when it does -- such as
in the next commit --, it helps if the xml-files depend on it. We're
casting the net a bit too wide here, since we'll be rebuilding even with
AsciiDoc, which won't look at this file. But since this file ch
From: Martin Ågren
When we render, e.g., "linkgit:gitglossary[7]." with Asciidoctor, we get
"gitglossary(7) ." with a space between the linkgit macro expansion and
the punctuation. We can fix this by dropping the trailing newline after
we've turned `linkgit:foo[bar]` into `..`.
The diff produced
On Mon, Mar 11, 2019 at 1:36 PM Junio C Hamano wrote:
> while (...)
> ; /* try again ... */
>
> This "strip all .lock repeatedly" made me stop and think a bit; this
> will never make the component empty, as the only way for this loop
> to make it empty is if
On Sat, Mar 9, 2019 at 7:35 PM Martin Ågren wrote:
> @@ -285,7 +285,7 @@ Note that this option uses the no overlay mode by default
> (see also
The part not shown here is
Using `--recurse-submodules` will update the content of all initialized
submodules according to the commit recorded i
Hello all,
I was in the process of deprecating `git diff ..` as
discussed here[1]. However, I ran into a weird case that I'm not sure
how to deal with.
In t3430-rebase-merges.sh:382, we have the following test case which
invokes git diff:
test_expect_success 'with --autosquash and --exec
On Tue, Feb 12, 2019 at 02:00:02AM -0800, Denton Liu wrote:
> On Thu, Feb 07, 2019 at 05:34:38PM -0500, Avery Pennarun wrote:
> > But I don't see any major problems with the patch in this thread.
> >
> > Thanks!
> >
> > Avery
>
> Hi Junio,
>
> If there are no other comments, I think that this p
Hi Denton/Eric
On 11/03/2019 05:49, Eric Sunshine wrote:
On Sun, Mar 10, 2019 at 11:42 PM 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
On Sun, Mar 10, 2019 at 11:37 PM Jeff King wrote:
>
> On Mon, Mar 11, 2019 at 11:00:25AM +0900, Junio C Hamano wrote:
>
> > Jeffrey Walton writes:
> >
> > > I think this is the patch for sha1dc/sha1.c . It stops using unaligned
> > > accesses by default, but still honors SHA1DC_FORCE_UNALIGNED_AC
On Mon, 11 Mar 2019 at 10:35, Duy Nguyen wrote:
>
> On Sat, Mar 9, 2019 at 7:35 PM Martin Ågren wrote:
>
> > @@ -285,7 +285,7 @@ Note that this option uses the no overlay mode by
> > default (see also
> The part not shown here is
>
> Using `--recurse-submodules` will update the content of al
On Mon, 11 Mar 2019 at 10:24, Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> > Ok, then I'll take that offer. I'll squash these two patches into the
> > original series. Thanks.
>
> Our mails might cross, but just in case you haven't started, here
> are the locally squashed results with updat
Hi Duy
On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timers sometimes). To remedy that, the
> command will be split into two new ones: switch and
> something-to-checkout-paths.
I think th
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
>
>
> Hi Duy
>
> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > "git checkout" doing too many things is a source of confusion for many
> > users (and it even bites old timers sometimes). To remedy that, the
> > command will be split into tw
On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
> And AFAIK there is no good way to
> modify the submodule-provided content as part of the build. Why do we
> even have the submodule again? ;P
Because of dogfooding of course. This is an interesting use case
though. I wonder if people often want
Hi Jonathan,
On Sun, 3 Mar 2019, Johannes Schindelin wrote:
> On Sun, 3 Mar 2019, Junio C Hamano wrote:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> > > From: Johannes Schindelin
> > >
> > > This fixes an issue pointed out by clang.
> > >
> > > Signed-off-by: Johannes Schind
Hi Duy,
On Fri, 8 Mar 2019, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/refs.c b/refs.c
> index 142888a40a..e9f83018f0 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -72,30 +72,57 @@ static unsigned char refname_disposition[256] = {
> * - it ends with ".lock", or
> * - it contains a "@{" portion
>
Hi Denton,
On Mon, 11 Mar 2019, Denton Liu wrote:
> I was in the process of deprecating `git diff ..` as
> discussed here[1]. However, I ran into a weird case that I'm not sure
> how to deal with.
>
> In t3430-rebase-merges.sh:382, we have the following test case which
> invokes git diff:
>
>
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of Elijah Newren
> Sent: March 9, 2019 14:38
> To: Nguyễn Thái Ngọc Duy
> Cc: Git Mailing List ; Junio C Hamano
>
> Subject: Re: [PATCH v1 11/11] doc: promote "git restore"
>
> On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái
Hello Johannes,
I installed the following snapshot on the problematic machine:
Sun, 10 Mar 2019 17:37:25 +0100
(commit eb5d06f545)
Git for Windows installer: 64-bit
And the problem is gone! No more issue!
At the time I had the issue I was on field trip with limited time and no other
version to
On Mon, Mar 11, 2019 at 2:32 AM Eckhard Maaß
wrote:
>
> On Thu, Nov 29, 2018 at 10:58:46PM +0100, Nguyễn Thái Ngọc Duy wrote:
> > + if (!opts->implicit_detach &&
> > + !opts->new_branch &&
> > + !opts->new_branch_force &&
> > + new_branch_info->name &&
> > + !ne
On Mon, Mar 11, 2019 at 9:12 PM Randall S. Becker
wrote:
>
> > -Original Message-
> > From: git-ow...@vger.kernel.org On Behalf
> > Of Elijah Newren
> > Sent: March 9, 2019 14:38
> > To: Nguyễn Thái Ngọc Duy
> > Cc: Git Mailing List ; Junio C Hamano
> >
> > Subject: Re: [PATCH v1 11/11]
On Mon, Mar 11, 2019 at 2:09 AM wrote:
>
> Hey Git people,
>
> I didn't get a reply and I'm not sure what the appropriate ping
> interval is, or when I should conclude that no one is interested.
>
> There seemed to be some vaguely positive feedback before I embarked on
> this project. At the same
On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
>
> On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
> >
> > Completion for restore is straightforward. We could still do better
> > though by give the list of just tracked files instead of all present
> > ones. But let's leave it for
Hi,
On Mon, Mar 11, 2019 at 2:37 AM Denton Liu wrote:
>
> Hello all,
>
> I was in the process of deprecating `git diff ..` as
> discussed here[1]. However, I ran into a weird case that I'm not sure
> how to deal with.
>
> In t3430-rebase-merges.sh:382, we have the following test case which
> invo
On Mon, Mar 11, 2019 at 10:22 PM Duy Nguyen wrote:
>
> On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
> >
> > On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy
> > wrote:
> > >
> > > Completion for restore is straightforward. We could still do better
> > > though by give the list of jus
Sorry, I forgot to Cc.
-- Forwarded message -
From: ttjtftx
Date: Mon, Mar 11, 2019 at 11:43 PM
Subject: Re: [GSoC][PATCH v2 4/5] t0022-crlf-rename: avoid using pipes
To: Eric Sunshine
On Sun, Mar 10, 2019 at 6:03 PM Eric Sunshine wrote:
> All of the patches in this series ar
In the end I managed to patch diffing code in libgit2
(git_diff_tree_to_index and git_diff_index_to_workdir) to make it
about 4x faster. It's now faster than `git status`, so good enough for
me.
I'm still curious whether it's possible to refresh index in git (not
libgit2), so please chime if if yo
On Sun, Mar 10, 2019 at 4:19 AM Duy Nguyen wrote:
>
> On Fri, Mar 8, 2019 at 5:17 PM Nguyễn Thái Ngọc Duy wrote:
> > - --index has a different meaning in git-apply. I don't have a good
> > suggestion except "yeah we have two different worlds now, the old
> > and the new one"
>
> I will rename
On Sun, Mar 10, 2019 at 5:51 PM Eric Sunshine wrote:
>
> On Sun, Mar 10, 2019 at 4:11 AM Jonathan Chang wrote:
> > Signed-off-by: Jonathan Chang
> >
> > diff --git a/t/t-basic.sh b/t/t-basic.sh
> > @@ -1136,8 +1136,8 @@ test_expect_success 'git commit-tree omits duplicated
> > parent in
Hi Junio,
On Sun, 10 Mar 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > If you care deeply about the commit history, I hereby offer to you to
> > clean up the built-in stash patches when you say you're ready to advance
> > them to `master`.
>
> What's the goal of such a rebase
Hi Junio,
On Mon, 11 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > When passing a list of pathspecs to, say, `git add`, we need to be
> > careful to use the original form, not the parsed form of the pathspecs.
> >
> >
Hi Junio,
On Sun, 10 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > So let's invert that test case to test for *anything else* than a
> > version starting with "1" (for MSys). That should safeguard us for the
> > future, even if Cygwin ends up releasing
Sorry, I forgot to Cc, again.
-- Forwarded message -
From: ttjtftx
Date: Tue, Mar 12, 2019 at 12:32 AM
Subject: Re: [GSoC][PATCH] tests: avoid using pipes
To: Christian Couder
On Sun, Mar 10, 2019 at 11:05 PM Christian Couder
wrote:
>
> On Sun, Mar 10, 2019 at 9:28 AM ttjtftx
Hi Denton
One small comment below, this basically looks fine to me
On 11/03/2019 03:42, Denton Liu wrote:
Since we implemented get_cleanup_mode, we had some duplicate code in
git_sequencer_config which essentially performed the same operations.
Refactor git_sequencer_config to take advantage of
Hi Denton
On 11/03/2019 03:42, 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
On Mon, Mar 11, 2019 at 6:14 AM Phillip Wood wrote:
> On 11/03/2019 05:49, Eric Sunshine wrote:
> > On Sun, Mar 10, 2019 at 11:42 PM Denton Liu wrote:
> >> + git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
> >
> > An earlier patch in this series "fixed" a test with a Git command
> > upst
Hi Duy
On 11/03/2019 11:47, Duy Nguyen wrote:
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
Hi Duy
On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
"git checkout" doing too many things is a source of confusion for many
users (and it even bites old timers sometimes). To remedy that, t
On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
>
> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> wrote:
> >
> > Hi Duy
> >
> > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > "git checkout" doing too many things is a source of confusion for many
> > > users (and it even bites old time
Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> git init longname-repo
> cd longname-repo
> touch f
> git add ..\longna~1\f
>
...
>
> C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git
> add ..\longna~1\f
> fatal: ..\longna~1\f: '..\longna~1\f' is outside repository
This ha
On Mon, Mar 11, 2019 at 10:48 AM Johannes Sixt wrote:
>
> Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> > git init longname-repo
> > cd longname-repo
> > touch f
> > git add ..\longna~1\f
> >
> ...
> >
> > C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git
> > add ..\longna
A few other comments that I thought of while responding elsewhere in
the thread that didn't make sense to include elsewhere...
On Fri, Mar 8, 2019 at 2:00 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timer
On Mon, Mar 11, 2019 at 06:48:11PM +0100, Johannes Sixt wrote:
> Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> > git init longname-repo
> > cd longname-repo
> > touch f
> > git add ..\longna~1\f
> >
> ...
> >
> > C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git
> > add ..\
Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
> On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
>> And AFAIK there is no good way to
>> modify the submodule-provided content as part of the build. Why do we
>> even have the submodule again? ;P
>
> Because of dogfooding of course. This is an interes
On Mon, Mar 11, 2019 at 10:55 AM Torsten Bögershausen wrote:
>
> On Mon, Mar 11, 2019 at 06:48:11PM +0100, Johannes Sixt wrote:
> > Am 10.03.19 um 23:41 schrieb Anthony Sottile:
> > > git init longname-repo
> > > cd longname-repo
> > > touch f
> > > git add ..\longna~1\f
> > >
> > ...
> > >
> > >
On Mon, Mar 11, 2019 at 06:40:21AM -0400, Jeffrey Walton wrote:
> > So anyway, I think this needs a patch to the upstream sha1dc project.
>
> https://github.com/cr-marcstevens/sha1collisiondetection/issues/47
Thanks, it looks like the turnaround on that may be pretty quick. Once
it's merged ther
On Mon, Mar 11, 2019 at 07:15:12PM +0100, Thomas Braun wrote:
> Am 11.03.2019 um 12:58 schrieb Duy Nguyen:
> > On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
> >> And AFAIK there is no good way to
> >> modify the submodule-provided content as part of the build. Why do we
> >> even have the sub
// CC'ing Thomas since this touches on a thread elsewhere about the glossary
On Mon, Mar 11, 2019 at 8:40 AM Duy Nguyen wrote:
>
> On Mon, Mar 11, 2019 at 10:22 PM Duy Nguyen wrote:
> >
> > On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
> > >
> > > On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Th
Hi Junio,
On Mon, 11 Mar 2019, Junio C Hamano wrote:
> * js/rebase-deprecate-preserve-merges (2019-03-08) 1 commit
> - rebase: deprecate --preserve-merges
>
> "git rebase --rebase-merges" replaces its old "--preserve-merges"
> option; the latter is now marked as deprecated.
>
> Will merge t
On Sun, Mar 10, 2019 at 5:29 PM Jacob Keller wrote:
>
> On March 8, 2019 1:57:41 AM PST, "Nguyễn Thái Ngọc Duy"
> wrote:
> >+::
> >+ Name for the new branch.
> >+
> >+::
> >+ The name of a commit at which to switch to before creating a
> >+ new branch or detach from.
>
> The word
Hi Phillip,
On Thu, 7 Mar 2019, Phillip Wood wrote:
> It's great to see this. Do we need the deprecation warning in both
> builtin/rebase.c and rebase--preserve-merges.sh? Won't that end up warning
> twice - maybe that's a good thing but if we go for only one I prefer the
> wording in rebase--pre
Hey Anthony,
Are you sure that you have 8.3 active on the partition you are using?
IIRC, It is not on by default anymore. To see, go to a cmd line and
type "dir /x". If there are any files that exceed the 8.3 format, it
will show those files with two names, the 8.3 name and the long name.
If it
Hi Eric,
On Thu, 7 Mar 2019, Eric Sunshine wrote:
> On Thu, Mar 7, 2019 at 6:11 AM Johannes Schindelin via GitGitGadget
> wrote:
> > We have something much better now: --rebase-merges (which is a
> > complete re-design --preserve-merges, with a lot of issues fixed such as
> > the inability to re
Hi Norbert,
On Fri, Mar 8, 2019 at 9:38 AM Norbert Nemec
wrote:
>
> Thanks, Elijah, I had indeed missed that block about the ^0 handling.
>
> I still don't get why this awkward workaround is required. Why isn't that
> lookup done by default? Performance can't be the reason, since the same
> loo
It had a good run, but its design was irreparably limited. So I came up with
a redesign:--rebase-merges. It seems to work all right, so now it is time to
start letting go of the previous design.
Changes since v1:
* The term --rebase-merges is now marked as such in the deprecation notice
in gi
From: Johannes Schindelin
We have something much better now: --rebase-merges (which is a
complete re-design --preserve-merges, with a lot of issues fixed such as
the inability to reorder commits with --preserve-merges).
Signed-off-by: Johannes Schindelin
---
Documentation/config/branch.txt |
Hi Junio,
On Fri, 8 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/builtin/init-db.c b/builtin/init-db.c
> > index 93eff7618c..94df241ad5 100644
> > --- a/builtin/init-db.c
> > +++ b/builtin/init-db.c
> > @@ -155,6 +155,9 @@ static int git_
This fixes an regression that was not present in Git for Windows's original
core.hideDotFiles patch, but in the shape of the core.hideDotFiles patch
that made it into git.git.
We fixed it in one big hurry in Git for Windows, and I simply forgot to
upstream this right away.
Changes since v1:
*
From: Johannes Schindelin
This is a brown paper bag. When adding the tests, we actually failed
to verify that the config variable is heeded in git-init at all. And
when changing the original patch that marked the .git/ directory as
hidden after reading the config, it was lost on this developer th
On Mon, Mar 11, 2019 at 12:34 PM Jack Adrian Zappa
wrote:
>
> Hey Anthony,
>
> Are you sure that you have 8.3 active on the partition you are using?
> IIRC, It is not on by default anymore. To see, go to a cmd line and
> type "dir /x". If there are any files that exceed the 8.3 format, it
> will
On Fri, Mar 08, 2019 at 05:27:36PM +0100, Johannes Schindelin wrote:
> > Or perhaps GGG can learn to avoid 0/1 for a single-patch topic ;-)
>
> It is easier, and more consistent, to have a cover letter even then, for
> things like the broader explanation of the context, the changes since the
> pr
Hi Everyone,
I enabled self tests for Solaris. Solaris has some anemic utilities so
I put /usr/gnu/bin first on-path.
make test is resulting in a lot of:
gmake -C templates SHELL_PATH='/bin/bash' PERL_PATH='/usr/bin/perl'
gmake[1]: Entering directory
`/export/home/jwalton/Build-Scripts/git-2.21
On 11/03/2019 17:24, Elijah Newren wrote:
On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
Hi Duy
On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
"git checkout" doing too many things is a source of confusion for many
users (and it even
[cc:+Ævar]
On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> I enabled self tests for Solaris. Solaris has some anemic utilities so
> I put /usr/gnu/bin first on-path.
The first question is if you are really running GNU 'sed'? My guess is
"no, it's still picking up Solaris's 'sed'".
> gma
On 03/11, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Agreed, I'd be happy to keep the parameter there. Looking at your
> > fork, you seem to have some WIP patches to introduce a UNUSED macro
> > for parameters like this, which I don't think I've seen on the list
> > yet (though I may
On 03/11, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thomas Gummerer writes:
> >
> >> Subject: [PATCH 1/2] stash: pass pathspec as pointer
> >>
> >> Passing the pathspec by value is potentially confusing, as the copy is
> >> only a shallow copy, so save the overhead of the copy, and pa
On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine wrote:
>
> [cc:+Ævar]
>
> On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> > I enabled self tests for Solaris. Solaris has some anemic utilities so
> > I put /usr/gnu/bin first on-path.
>
> The first question is if you are really running GNU 's
On Mon, Mar 11, 2019 at 1:51 PM Phillip Wood wrote:
> On 11/03/2019 17:24, Elijah Newren wrote:
> > On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> >> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> >> wrote:
> >>> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> "git checkout" doing
Passing the pathspec by value is potentially confusing, as the copy is
only a shallow copy, so save the overhead of the copy, and pass the
pathspec struct as a pointer.
In addition use copy_pathspec to copy the pathspec into
rev.prune_data, so the copy is a proper deep copy, and owned by the
revis
Hi there,
I've been bit by this bug many times, and always forget to report it
here, but this time I finally remembered.
The scenario is this:
- I have a local repository which tracks the upstream of the project.
- I have 120+ local commits.
- Every week or so, I have to rebase my local commit
On 03/11, Johannes Schindelin wrote:
> Hi Junio,
>
> On Mon, 11 Mar 2019, Junio C Hamano wrote:
>
> > Yup. I think Thomas and Peff were also looking at the vicinity of
> > this code wrt the pass-by-value-ness of ps parameter. Their fix
> > need to also come on top of this (or combined together)
On Mon, Mar 11, 2019 at 05:43:55PM -0400, Jeffrey Walton wrote:
> On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine wrote:
> > On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> > > I enabled self tests for Solaris. Solaris has some anemic utilities so
> > > I put /usr/gnu/bin first on-path.
> >
On Mon, Mar 11, 2019 at 04:24:13PM +0700, Duy Nguyen wrote:
> > > I think this needs to be:
> > >
> > > strbuf_setlen(sanitized, sanitized->len - 1);
> > >
> > > to ensure that NUL-terminator ends up in the correct place if this "."
> > > is the very last character in 'refname'. (Otherwise, th
On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior
wrote:
> # git rebase origin/master
> ...
> Applying: commitX
> Applying: commitY
> Applying: commitZ
> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>
> The first thing I did was to check whether the i
On Monday, March 11 2019, Eric Sunshine wrote:
> On Mon, Mar 11, 2019 at 6:17 PM Sergio Durigan Junior
> wrote:
>> # git rebase origin/master
>> ...
>> Applying: commitX
>> Applying: commitY
>> Applying: commitZ
>> fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File ex
On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine wrote:
>
> [cc:+Ævar]
>
> On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> > I enabled self tests for Solaris. Solaris has some anemic utilities so
> > I put /usr/gnu/bin first on-path.
>
> The first question is if you are really running GNU 's
On Wed, Mar 6, 2019 at 7:17 AM Duy Nguyen wrote:
>
> On Wed, Mar 6, 2019 at 6:47 AM Matheus Tavares Bernardino
> wrote:
> >
> > This exercise of estimating a good spot to gain performance with
> > parallelism at git seems more difficult than I thought, firstly. Also,
> > I'm not that familiar yet
On Mon, Mar 11, 2019 at 7:52 PM Jeffrey Walton wrote:
>
> On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine wrote:
> >
> > [cc:+Ævar]
> >
> > On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> > > I enabled self tests for Solaris. Solaris has some anemic utilities so
> > > I put /usr/gnu/bin fi
Denton Liu writes:
> - {
> - cat <<-EOF
> + cat >expect <<-EOF &&
> Squashed commit of the following:
>
> $(git show -s c7)
> @@ -242,8 +241,8 @@ test_expect_success 'merge --squash c3 with c7' '
> # Conflicts:
> #
On Mon, Mar 11, 2019 at 6:28 PM Eric Sunshine wrote:
>
> On Mon, Mar 11, 2019 at 05:43:55PM -0400, Jeffrey Walton wrote:
> > On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine
> > wrote:
> > > On Mon, Mar 11, 2019 at 4:32 PM Jeffrey Walton wrote:
> > > > I enabled self tests for Solaris. Solaris has
Signed-off-by: Ramsay Jones
---
Hi Jonathan,
If you need to re-roll your 'jt/fetch-cdn-offload' branch, could
you please squash this into the relevant patches. (The first hunk
into commit a8d662e3da4 ("upload-pack: refactor reading of pack-objects
out", 2019-03-08) and the second hunk into com
On Mon, Mar 11, 2019 at 9:07 PM Jeffrey Walton wrote:
>
> On Mon, Mar 11, 2019 at 6:28 PM Eric Sunshine wrote:
> >
> > On Mon, Mar 11, 2019 at 05:43:55PM -0400, Jeffrey Walton wrote:
> > > On Mon, Mar 11, 2019 at 5:15 PM Eric Sunshine
> > > wrote:
> > > > On Mon, Mar 11, 2019 at 4:32 PM Jeffrey
On Mon, Mar 11, 2019 at 9:55 PM Jeffrey Walton wrote:
>
> On Mon, Mar 11, 2019 at 9:07 PM Jeffrey Walton wrote:
> >
> > On Mon, Mar 11, 2019 at 6:28 PM Eric Sunshine
> > wrote:
> > >
> > > On Mon, Mar 11, 2019 at 05:43:55PM -0400, Jeffrey Walton wrote:
> > > > On Mon, Mar 11, 2019 at 5:15 PM Er
On Mon, Mar 11, 2019 at 10:11 PM Jeffrey Walton wrote:
>
> On Mon, Mar 11, 2019 at 9:55 PM Jeffrey Walton wrote:
> >
> > On Mon, Mar 11, 2019 at 9:07 PM Jeffrey Walton wrote:
> > >
> > > On Mon, Mar 11, 2019 at 6:28 PM Eric Sunshine
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at 05:43:55
On Mon, Mar 11, 2019 at 10:11:41PM -0400, Jeffrey Walton wrote:
> On Mon, Mar 11, 2019 at 9:55 PM Jeffrey Walton wrote:
> > Oh man, you're using GNU make. I thought Git was using that anemic
> > Posix Make. See attached.
> >
> > I think Solaris provides an older gawk. Is this an easier problem:
>
Signed-off-by: Ramsay Jones
---
Hi Denton,
If you need to re-roll your 'dl/merge-cleanup-scissors-fix' branch,
could you please squash this into the relevant patch (commit 9bcdf520cb
("sequencer.c: define get_config_from_cleanup", 2019-03-10)).
I note also, that the get_config_from_cleanup()
On Mon, Mar 11, 2019 at 10:53 PM Ramsay Jones
wrote:
> If you need to re-roll your 'dl/merge-cleanup-scissors-fix' branch,
> could you please squash this into the relevant patch (commit 9bcdf520cb
> ("sequencer.c: define get_config_from_cleanup", 2019-03-10)).
>
> /* note that we assume that clea
Jeff King wrote:
> On Sat, Mar 09, 2019 at 02:49:44AM +, Eric Wong wrote:
> > It would make life easier for people new to hosting git servers
> > (and hopefully reduce centralization :)
>
> I do think they're a net win for people hosting git servers. But if
> that's the goal, I think at most
On Mon, Mar 11, 2019 at 10:45 PM Eric Sunshine wrote:
>
> On Mon, Mar 11, 2019 at 10:11:41PM -0400, Jeffrey Walton wrote:
> > On Mon, Mar 11, 2019 at 9:55 PM Jeffrey Walton wrote:
> > > Oh man, you're using GNU make. I thought Git was using that anemic
> > > Posix Make. See attached.
> > >
> > >
Phillip Wood writes:
>> -if (0 < option_edit)
>> -strbuf_commented_addf(&msg, _(merge_editor_comment),
>> comment_line_char);
>> +if (0 < option_edit) {
>> +strbuf_addch(&msg, '\n');
>> +if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS)
>> +
Denton Liu writes:
> +struct cleanup_config_mapping {
> +const char *config_value;
> +enum commit_msg_cleanup_mode editor_cleanup;
> +enum commit_msg_cleanup_mode no_editor_cleanup;
> +};
Is this code using 4-space indent? Please don't. Also, I found
that Eric's comment on naming g
Jeff King writes:
> Another option _is_ to actually make it reversible. I.e., use "%2e"
> instead of ".", which would also necessitate replacing "%". I don't know
> if that has a huge value for this use-case, but it's a nice property
> that two sanitized names can't collide (unless they originall
Johannes Schindelin writes:
>> +static int check_refname_component(const char *refname, int *flags,
>> + struct strbuf *sanitized)
>> {
>> const char *cp;
>> char last = '\0';
>> +size_t component_start;
>
> This variable is uninitialized. It is then..
Thomas Gummerer writes:
>> Good catch on both acconts. I'll send a new patch soon, adding the
>> clear_pathspec() calls and rebasing it on top of Dscho's fix.
>
> Here it is. Thanks for the review of the first round Junio!
>
> This is on top of Dscho's series at
> applied to ps/stash-in-c.
Th
100 matches
Mail list logo
