Hello Jeff,
Thanks again for the response.
I am not building GIT and also don't know either how to build. I am just
pulling up the binaries from http://hpux.connect.org.uk/.
Both HPUX and linux machine are in same network/subnet so network shouldn't be
a problem here. ssh to HPUX box is supe
> -Original Message-
> From: Johannes Sixt
> Sent: Tuesday, May 28, 2019 2:22 AM
> To: LU Chuck
> Cc: git@vger.kernel.org; chuck...@qq.com
> Subject: Re: git filter-branch re-write history over a range of commits did
> notwork
>
> Am 27.05.19 um 10:01 schrieb LU Chuck:
> > Hi team,
> >
On 2019-05-15 at 22:27:56, brian m. carlson wrote:
> On Tue, May 14, 2019 at 07:46:17PM +0700, Duy Nguyen wrote:
> > 'struct string_list;' should be enough (and a bit lighter) although I
> > don't suppose it really matters.
>
> I can make that change.
One thing I noticed when making this change i
On Wed, May 29, 2019 at 01:34:32AM +0200, René Scharfe wrote:
> It figures.
>
> So something like the patch below?
>
> Parsing trees with symlinks twice is not ideal, but keeps the set
> structure simple -- a standard oidset suffices.
If blobs comes after trees (and they usually do in a pack),
On 5/28/2019 4:54 PM, Jeff King wrote:
> On Tue, May 28, 2019 at 08:19:07AM -0700, Derrick Stolee via GitGitGadget
> wrote:
>
>> From: Derrick Stolee
>>
>> The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
>> (sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and i
Am 28.05.19 um 21:08 schrieb Jeff King:
> On Tue, May 28, 2019 at 08:01:43PM +0200, René Scharfe wrote:
>
>> Am 28.05.19 um 07:58 schrieb Jeff King:
>>> On Sat, May 25, 2019 at 03:26:53PM +0200, René Scharfe wrote:
>>>
We could
make git fsck report such symlinks.
>>>
>>> This is a little
The availability of these pattern selections is not obvious from
the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
Provide examples.
Re-order the `git branch` synopsis to emphasise the `--list `
pairing. Also expand and reposition the `all/remotes` options.
Split the over-l
Hi Junio,
Junio C Hamano 於 2019年5月29日 週三 上午4:41寫道：
>
> 林自均 writes:
>
> > Hi Junio,
> >
> > John Lin via GitGitGadget 於 2019年5月15日 週三 下午6:54寫道：
> >>
> >> From: John Lin
> >>
> >> Before this patch, there is inconsistency between the status
> >> messages with hints and the ones without hints: th
On Sun, May 19 2019, SZEDER Gábor wrote:
> For an environment variable that is supposed to be set by users, the
> GIT_TR2* env vars are just too unclear, inconsistent, and ugly.
>
> Most of the established GIT_* environment variables don't use
> abbreviations, and in case of the few that do (GIT
On Thu, May 23, 2019 at 05:55:12PM -0700, Emily Shaffer wrote:
> What does it look like? Is it human-readable in its current form? I ask
> because (without having looked ahead) I think you're going to move it
You can make the error appear in this way:
$ git rev-list --filter=blob:nonse --objects
On Tue, May 28 2019, Dominy, Patrick A wrote:
> Hi,
> Running git fsck against one of our repositories yields the following:
> Error in tree xxx: duplicateEntries: contains duplicate file entries
>
> We are struggling with the best approach to resolve the issue. We’ve used
> git replace, w
[This is what I had in mind re:merging the different filter type structs. This
is essentially a clean-up which makes the following patches a little simpler,
even more simpler than the previous version of the patchset.]
Before this patch, there is a lot of boilerplate code associated with
invoking
(see also https://github.com/google/zoekt/issues/81)
It looks like git 2.21 included a regression. The command
git clone --bare --progress \
--config "remote.origin.fetch=+refs/heads/*:refs/heads/*" \
https://github.com/google/zoekt.git \
/tmp/zoekt-git2.20.git
would succeed with git 2.20,
On Tue, May 28, 2019 at 03:08:31PM -0700, Junio C Hamano wrote:
> Quite a few new topics, most of which are fixes with different
> urgency, have been picked up. Perhaps we'd need an extra -rc for
> this cycle to squash existing regression at the tip of 'master'.
> At this point, the criteria for
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.
Quite a few new topics, most of wh
On Tue, May 21, 2019 at 05:21:52PM -0700, Matthew DeVore wrote:
> Allow combining filters such that only objects accepted by all filters
> are shown. The motivation for this is to allow getting directory
> listings without also fetching blobs. This can be done by combining
> blob:none with tree:. T
Hi,
Running git fsck against one of our repositories yields the following:
Error in tree xxx: duplicateEntries: contains duplicate file entries
We are struggling with the best approach to resolve the issue. We’ve used git
replace, which successfully creates the replace reference, but fsck s
On Tue, May 28, 2019 at 04:29:13PM -0500, Brendan Boerner wrote:
> To answer your previous question I'm using git v2.21.0. I'm using the
> Ubuntu 14.04 PPA as well as Linuxbew (also v2.21.0).
>
> Your help helped me narrow this down to linuxbrew. Take it out of my
> path no segfault.
>
> Uninsta
On Tue, May 28, 2019 at 01:06:21PM +0200, Johannes Schindelin wrote:
> > Or do you prefer having a one-liner? I'd rather come up with a more
> > generic helper to cover this case, that can run any command and compare
> > it to a single argument (or stdin). E.g.,:
> >
> > test_cmp_cmd no-conflict
On Tue, May 28, 2019 at 06:45:18PM +, Vanak, Ibrahim wrote:
> BUT still I have significant slowness(50 times slower than clone on
> linux machine) while cloning. HPUX box is having very good H/W
> configuration and network is also stable.
>From your output:
> [hpux]
> Receiving objects: 100%
Thanks Jeff.
To answer your previous question I'm using git v2.21.0. I'm using the
Ubuntu 14.04 PPA as well as Linuxbew (also v2.21.0).
Your help helped me narrow this down to linuxbrew. Take it out of my
path no segfault.
Uninstall linuxbrew git, linuxbrew still in PATH, use PPA git, segfault.
Jeff King writes:
> So I guess you are asking only about the part that I dismissed above as
> "not all that interesting". I.e., do people actually run:
>
> git bundle verify foo.bundle &&
> git clone foo.bundle
>
> That is not nonsense, per-se, but it is somewhat pointless since the
> clone w
On Tue, May 28, 2019 at 01:03:26PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > As Gábor noted in the earlier thread, if the bundle doesn't have any
> > prerequisites, this _used_ to work before b1ef400eec (setup_git_env:
> > avoid blind fall-back to ".git", 2016-10-20). I don't know i
Hi Johannes
On Tue, May 28, 2019 at 10:31 PM Johannes Sixt wrote:
>
> Am 28.05.19 um 18:34 schrieb Junio C Hamano:
> > Marc-André Lureau writes:
> >
> >> Ok, I am adding:
> >> ...
> >> sure, I thought it was already covered.
> >> ...
> >> I think that would be fine, ok I am changing it
> >
> > T
On Tue, May 28, 2019 at 01:17:41PM +0200, Johannes Schindelin wrote:
> > As Gábor noted in the earlier thread, if the bundle doesn't have any
> > prerequisites, this _used_ to work before b1ef400eec (setup_git_env:
> > avoid blind fall-back to ".git", 2016-10-20). I don't know if anybody
> > cares
On Tue, May 28, 2019 at 03:53:51PM -0500, Brendan Boerner wrote:
> Lot of good tips for debugging for me to work on - I'll work on that.
>
> Both to avoid spamming the list and if sending large files e.g. strace
> is it ok if I continue correspondence with you directly? (And
> Johannes?)
In gene
On Tue, May 28, 2019 at 08:19:07AM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
> (sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and is used to
> prevent the fetch_objects() method wh
Hey Jeff,
Lot of good tips for debugging for me to work on - I'll work on that.
Both to avoid spamming the list and if sending large files e.g. strace
is it ok if I continue correspondence with you directly? (And
Johannes?)
Thanks!
Brendan
On Tue, May 28, 2019 at 3:40 PM Jeff King wrote:
>
> O
On Tue, May 28, 2019 at 02:56:13PM -0500, Brendan Boerner wrote:
> Unfortunately not a lot in the stack trace.
> [...]
> (gdb) bt
> #0 0x7fd321805fdf in ?? ()
> #1 0x in ?? ()
I'll say. :)
I'd suspect either:
1. Your git isn't built with debugging symbols. Is it possible
林自均 writes:
> Hi Junio,
>
> John Lin via GitGitGadget 於 2019年5月15日 週三 下午6:54寫道：
>>
>> From: John Lin
>>
>> Before this patch, there is inconsistency between the status
>> messages with hints and the ones without hints: there is an
>> empty line between the title and the file list if hints are
>
"Mike Mueller via GitGitGadget" writes:
> From: Mike Mueller
>
> git p4 unshelve was failing with these errors:
>
> fatal: Not a valid object name HEAD0
> Command failed: git cat-file commit HEAD^0
>
> (git version 2.21.0.windows.1, python 2.7.16)
>
> The pOpen call used by git-p4 to invoke the
Am 28.05.19 um 18:34 schrieb Junio C Hamano:
> Marc-André Lureau writes:
>
>> Ok, I am adding:
>> ...
>> sure, I thought it was already covered.
>> ...
>> I think that would be fine, ok I am changing it
>
> Thanks, both.
>
> The previous round has already hit 'next' (which means that we won't
>
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
> (sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and is used to
> prevent the fetch_objects() method when enabled.
>
> However, there is a pro
Am 28.05.19 um 18:37 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Junio will very likely appreciate if you resend with these fixes applied.
>
> Heh, thanks, for spotting, but this round has already been in 'next'
> so any updates should be done incrementally X-<.
>
I don't terribly min
Jeff King writes:
> As Gábor noted in the earlier thread, if the bundle doesn't have any
> prerequisites, this _used_ to work before b1ef400eec (setup_git_env:
> avoid blind fall-back to ".git", 2016-10-20). I don't know if anybody
> cares about that case or not, but we could do something like:
>
Yes, providing the repo isn't an option.
Thanks for the suggestions, here's what I can provide. Unfortunately
not a lot in the stack trace.
Do you need the whole repo or would bits of it suffice e.g. index?
bboerner@myhost:~/funproject/Src$ GIT_TRACE=1 git stash list
14:52:22.633388 git.c:670
Christian Couder writes:
> If someone wants to use as a filter a sparse file that is in the
> repository, something like "--filter=sparse:oid=:"
> already works.
>
> So 'sparse:path' is only interesting if the sparse file is not in
> the repository. In this case though the current implementation
Nguyễn Thái Ngọc Duy writes:
> Most number-related OPT_ macros store the value in an 'int'
> variable. Many of the variables in 'struct diff_options' have a
> different type, but during the conversion to using parse_options() I
> failed to notice and correct.
Why does this patch need to be so n
On Tue, May 28, 2019 at 08:01:43PM +0200, René Scharfe wrote:
> Am 28.05.19 um 07:58 schrieb Jeff King:
> > On Sat, May 25, 2019 at 03:26:53PM +0200, René Scharfe wrote:
> >
> >> We could
> >> make git fsck report such symlinks.
> >
> > This is a little tricky, because fsck generally looks at indi
We check for a handy environment variable GIT_DEBUGGER when running via
bin-wrappers/, but this feature is undocumented. Add a hint to how to
use it into the CodingGuidelines (which is where other useful
environment settings like DEVELOPER are documented).
Signed-off-by: Emily Shaffer
---
Docume
Vishal Verma writes:
> From: Vishal Verma
>
> Convert option_commit to tristate, representing the states of
> 'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in
> place, check whether option_commit was enabled by cli when squashing a
> merge. If so, error out, as this is not
On Thu, May 23, 2019 at 06:09:17AM -0400, Eric Sunshine wrote:
> On Wed, May 22, 2019 at 8:56 PM Emily Shaffer wrote:
> > We check for a handy environment variable GIT_DEBUGGER when running via
> > bin-wrappers/, but this feature is undocumented. Add a hint to how to
> > use it into the CodingGuid
On Thu, May 23, 2019 at 05:49:38PM -0700, Emily Shaffer wrote:
> This commit message might read more easily on its own if you define
> "this bundle of data" at least once. Since there are things being moved
> from both list-objects-filter.c (filter_blobs_none_data) and
> list-objects-filter.h (list
Thanks everyone for the inputs !!! upgrade of GIT to 2.21 worked.
BUT still I have significant slowness(50 times slower than clone on linux
machine) while cloning. HPUX box is having very good H/W configuration and
network is also stable.
Do you have any inputs on this.?
-Ibrahim
-Origina
On Tue, May 28, 2019 at 8:35 AM Robert Dailey wrote:
>
> On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
> >
> > On Mai 24 2019, Robert Dailey wrote:
> >
> > > Can anyone provide some advice on how to properly restructure this
> > > repository to create some ancestry, as if all along a `m
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat`
> options, 2018-09-04), we added a line that wanted to remove the
> `REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation.
>
> Fo
Hi Matheus,
On Tue, 28 May 2019, Matheus Tavares Bernardino wrote:
> On Tue, May 28, 2019 at 7:37 AM Johannes Schindelin
> wrote:
> >
> > On Mon, 20 May 2019, Matheus Tavares wrote:
> >
> > > > Give "rebase -i" some option so when you "reword" the patch is
> > > > included in the message.
> > >
From: Mike Mueller
git p4 unshelve was failing with these errors:
fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0
(git version 2.21.0.windows.1, python 2.7.16)
The pOpen call used by git-p4 to invoke the git command can take either a
string or an array as a firs
git p4 unshelve was failing with "fatal: Not a valid object name HEAD0" and
"Command failed: git cat-file commit HEAD^0" on certain systems e.g. git
version 2.21.0.windows.1 + python 2.7.16
It seems that certain python pOpen implementations drop the ^ character when
invoked using a string instead
Hi Philip,
On Tue, 28 May 2019, Philip Oakley wrote:
> On 28/05/2019 14:56, Jeff Hostetler wrote:
>
> > Did you mean to send this upstream or to Git for Windows?
> >
> > I didn't think that the VS2015/VS2017 vcpkg-aware version of
> > compat/vcbuild/* had made it upstream yet, so this patch might
Am 28.05.19 um 07:58 schrieb Jeff King:
> On Sat, May 25, 2019 at 03:26:53PM +0200, René Scharfe wrote:
>
>> We could
>> make git fsck report such symlinks.
>
> This is a little tricky, because fsck generally looks at individual
> objects, and the bad pattern is a combination of a tree and a blob
>
Jonathan Nieder writes:
> Jonathan Tan wrote:
>
>> Currently, if any server options are specified during a protocol v2
>> fetch, server options will be sent before "command=fetch". Write server
>> options to the request buffer in send_fetch_request() so that the
>> components of the request are s
Jeff Hostetler writes:
> In the RFC version, there was discussion [2] of the wire format
> and the need to be backwards compatible with existing servers and
> so use the "combine:" syntax so that we only have a single filter
> line on the wire. Would it be better to have compliant servers
> adve
Jonathan Nieder writes:
> Emily Shaffer wrote:
>
>> Signed-off-by: Emily Shaffer
>> Reviewed-by: Jonathan Nieder
>> ---
>> Since v3, only the commit message has changed. Reworked based on
>> Jonathan Nieder's suggestions (with some modifications for readability).
>>
>> grep.c | 4
>> 1 fi
Simon Williams writes:
> When unshelving a changelist, git-p4 tries to work out the appropriate
> parent commit in a given branch (default: HEAD). To do this, it looks
> at the state of any pre-existing files in the target Perforce branch,
> omitting files added in the shelved changelist. Curre
On Tue, May 28, 2019 at 7:37 AM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Mon, 20 May 2019, Matheus Tavares wrote:
>
> > > Give "rebase -i" some option so when you "reword" the patch is
> > > included in the message.
> > >
> > > I keep going to the shell because I have no idea what change
Jeff Hostetler writes:
> For now, I've guarded my usage of pthread_getspecific() in the trace2
> (similar to what index-pack does), so its not urgent that we update it.
> And I'd rather we take this simple trace2 fix now and not try to combine
> it with fixes for the pthread macros. Especially n
Jeff King writes:
> Revised patch below.
Thanks. I never took the "separate namespaces" thing as a serious
feature, so it is understandable that I ignored it completely when I
did 7171d8c15f.
The explanation and the code both look good. Thanks.
> -- >8 --
> Subject: [PATCH] upload-pack: str
Jakub Narebski writes:
> I thik that this implemetation detail of `--literally` is here to stay;
> how would you otherwise fix the issue if garbage object makes Git crash?
By repacking, presumably ;-).
More importantly, there needs a way to extend "enum object_type" to
allow unbounded number of
Ævar Arnfjörð Bjarmason writes:
> Clarify the hash-object docs to explicitly note that the --literally
> option guarantees that a loose object will be written, but that a
> normal -w ("write") invocation doesn't.
>
> At first I thought talking about "loose object" in the docs was a
> mistake in
On 5/28/2019 12:25 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> For an environment variable that is supposed to be set by users, the
>> GIT_TR2* env vars are just too unclear, inconsistent, and ugly.
>
> FWIW, I personally am in favor of this change and would prefer to see
> this done b
Jonathan Nieder writes:
> Jeff King wrote:
>
>> The patch itself looks good to me.
>
> For what it's worth,
>
> Reviewed-by: Jonathan Nieder
>
> as well. It's a straightforward patch and solves the reader-facing
> problem. Thanks.
Thanks, all.
Barret Rhoden writes:
> Hi -
>
> On 5/20/19 4:32 PM, Michael Platings wrote:
>> Hi Junio,
>> The SQUASH??? patches look good to me. Please squash away!
>> Thanks,
>> -Michael
>
> I can squash them into the next version of the patch set too, pending
> other comments / changes.
Thanks for the offe
Johannes Sixt writes:
> Junio will very likely appreciate if you resend with these fixes applied.
Heh, thanks, for spotting, but this round has already been in 'next'
so any updates should be done incrementally X-<.
Marc-André Lureau writes:
> Ok, I am adding:
> ...
> sure, I thought it was already covered.
> ...
> I think that would be fine, ok I am changing it
Thanks, both.
The previous round has already hit 'next' (which means that we won't
replacing the patch wholesale), so whatever you do, please make
Derrick Stolee writes:
> On 5/20/2019 6:01 AM, Johannes Schindelin wrote:
>> Hi Stolee,
>>
>> *really* minor nit: the commit subject probably wants to have a "rename"
>> after the colon ;-)
>
> I did put that there, but then the subject line was too long. I'm not
> opposed to putting it back.
L
SZEDER Gábor writes:
> For an environment variable that is supposed to be set by users, the
> GIT_TR2* env vars are just too unclear, inconsistent, and ugly.
FWIW, I personally am in favor of this change and would prefer to see
this done before the use of the names with unguessable abbreviation
On 28/05/2019 16:51, Junio C Hamano wrote:
Philip Oakley writes:
However, isn't `-r ` broken?
No.
Then why does it say:
fatal: -a and -r options to 'git branch' do not make sense with a
branch name
when there is no `-a` given?
phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (b
Duy Nguyen writes:
> On Mon, May 20, 2019 at 8:17 PM Jeff King wrote:
>> The patch looks good, though I wonder if we could simplify even further
>> by just embedding an index into the repository object. The purpose of
>> having it as a pointer, I think, is so that the_repository can point to
>>
Philip Oakley writes:
> However, isn't `-r ` broken?
No.
> phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (branch-patterns)
> $ git branch -a -l 'junio/*'
You are asking "branch --all --list" here.
> $ git branch -a -r 'junio/*'
> fatal: -a and -r options to 'git branch' do not make sen
From: Derrick Stolee
The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
(sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and is used to
prevent the fetch_objects() method when enabled.
However, there is a problem with the current use. The definition of
OBJECT_INFO
I found this interaction while testing the VFS for Git fork rebasing onto
v2.22.0-rc1 [1]. It seems this new flag meant for partial clone prefetches
interacts poorly with the read-object hook we use in our fork.
The issue is that OBJECT_INFO_FOR_PREFETCH has multiple bits on, so testing
"flag & OB
On 5/28/2019 2:28 AM, Jeff King wrote:
On Sat, May 25, 2019 at 05:43:55PM +0700, Duy Nguyen wrote:
+typedef struct {
+ void *data;
+ /* extra indirection because setspecific is passed key by value */
+ void **vdata;
Ha! I was thinking a separate key->value mapping which i
Hi Junio,
On 28/05/2019 15:17, Philip Oakley wrote:
On 28/05/2019 14:58, Junio C Hamano wrote:
Philip Oakley writes:
The availability of these pattern selections is not obvious from
the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
Provide examples.
Signed-off-by: Phi
On 5/28/2019 10:09 AM, Philip Oakley wrote:
Hi Jeff,
On 28/05/2019 14:56, Jeff Hostetler wrote:
On 5/28/2019 8:08 AM, Philip Oakley wrote:
When the user installs an updated version of Visual Studio, the
previously
generated MSVC-DEFS-GEN will need to be deleted to allow updating.
Alternat
On 28/05/2019 14:58, Junio C Hamano wrote:
Philip Oakley writes:
The availability of these pattern selections is not obvious from
the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
Provide examples.
Signed-off-by: Philip Oakley
---
Please try again, perhaps after readi
Hi Jeff,
On 28/05/2019 14:56, Jeff Hostetler wrote:
On 5/28/2019 8:08 AM, Philip Oakley wrote:
When the user installs an updated version of Visual Studio, the
previously
generated MSVC-DEFS-GEN will need to be deleted to allow updating.
Alternatively the whole vcpkg download may be cleaned al
Philip Oakley writes:
> The availability of these pattern selections is not obvious from
> the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
>
> Provide examples.
>
> Signed-off-by: Philip Oakley
> ---
Please try again, perhaps after reading
Thanks.
>
> in response to
Ævar Arnfjörð Bjarmason writes:
> That's:
>
> git for-each-ref 'refs/remotes//'
> git branch -a -l '/'
>
> The latter will conflate with any local branches you happen to
> have prefixed with .
Wouldn't "branch -r -l /" be without that downside?
Why use "-a"?
On 5/28/2019 8:08 AM, Philip Oakley wrote:
When the user installs an updated version of Visual Studio, the previously
generated MSVC-DEFS-GEN will need to be deleted to allow updating.
Alternatively the whole vcpkg download may be cleaned allowing it to be
reloaded, though this may take much
On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
>
> On Mai 24 2019, Robert Dailey wrote:
>
> > Can anyone provide some advice on how to properly restructure this
> > repository to create some ancestry, as if all along a `master` existed
> > and all release branches were based on this in a
On 5/28/2019 2:13 AM, Jeff King wrote:
On Fri, May 24, 2019 at 02:46:06PM -0400, Jeff Hostetler wrote:
My original thoughts were that we could limit the sparse:path to
local use and disallow it over the wire to the server, but that
distinction is probably not worth the bother. Removing it c
From: Johannes Schindelin
The `--preserve-merges` option is now deprecated in favor of
`--rebase-merges`; Let's stop recommending the former.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentati
From: Johannes Schindelin
As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will
be officially deprecated in favor of the `--rebase-merges` backend.
Consequently, `git pull --rebase=preserve` will also be deprected. State
this explicitly.
Signed-off-by: Johannes Schindelin
---
Turns out that I forgot a couple of spots when I sent the patch series to
deprecate git rebase -p earlier...
Johannes Schindelin (3):
tests: mark a couple more test cases as requiring `rebase -p`
docs: say that `--rebase=preserve` is deprecated
rebase docs: recommend `-r` over `-p`
Documen
From: Johannes Schindelin
The `--preserve-merges` option has been deprecated, and as a consequence
we started to mark test cases that require that option to be supported,
in preparation for removing that support eventually.
Since we marked those test cases, a couple more crept into the test
suit
The availability of these pattern selections is not obvious from
the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
Provide examples.
Signed-off-by: Philip Oakley
---
in response to
https://public-inbox.org/git/?q=%3CCACsJy8CwY8gzeWa9kNRX3ecez1JGiQiaOknbAoU7S%2BhiXBoUGQ%4
When the user installs an updated version of Visual Studio, the previously
generated MSVC-DEFS-GEN will need to be deleted to allow updating.
Alternatively the whole vcpkg download may be cleaned allowing it to be
reloaded, though this may take much longer on slower connections.
Signed-off-by: Ph
Hi Peff,
On Mon, 27 May 2019, Jeff King wrote:
> On Mon, May 27, 2019 at 12:59:14PM -0700, Johannes Schindelin via
> GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > The deal with bundles is: they really are thin packs, with very little
> > sugar on top. So we really need a repository
Hi Peff,
On Fri, 24 May 2019, Jeff King wrote:
> On Thu, May 23, 2019 at 09:12:27AM +0200, Johannes Schindelin wrote:
>
> > > + echo no-conflict >expect &&
> > > + git log -1 --format=%s >actual &&
> > > + test_cmp expect actual
> >
> > I would prefer
> >
> > test no-conflict = "$(git show -s
Hi Matheus,
On Mon, 20 May 2019, Matheus Tavares wrote:
> > Give "rebase -i" some option so when you "reword" the patch is
> > included in the message.
> >
> > I keep going to the shell because I have no idea what change I'm
> > describing.
>
> I have the same problem, so I wanted to try solving
Hi,
On Tue, 28 May 2019, Vanak, Ibrahim wrote:
> We are seeing issue with GIT 2.14 version.
You definitely want to upgrade ASAP. Not only is the issue that you
reported fixed, but two distinct vulnerabilities have been fixed since
v2.14.0. Your version is still vulnerable.
Ciao,
Johannes
From: Paolo Bonzini
In some cases, git request-pull might be invoked with remote and
local objects that differ even though they point to the same commit.
For example, the remote object might be a lightweight tag
vs. an annotated tag on the local side, or the user might have
reworded the tag local
From: Paolo Bonzini
The local part of the third argument of git-request-pull is used in
a regular expression without quoting it. Use qr{} and \Q\E to ensure
that e.g. a period in a tag name does not match any character on the
remote side.
Signed-off-by: Paolo Bonzini
---
git-request-pull.sh
From: Paolo Bonzini
In some cases, git request-pull might be invoked with remote and
local objects that differ even though they point to the same commit.
For example, the remote object might be a lightweight tag
vs. an annotated tag on the local side; or the user might have
reworded the tag local
> -Original Message-
> From: Johannes Sixt
> Sent: Tuesday, May 28, 2019 2:22 AM
> To: LU Chuck
> Cc: git@vger.kernel.org; chuck...@qq.com
> Subject: Re: git filter-branch re-write history over a range of commits did
> notwork
>
> Am 27.05.19 um 10:01 schrieb LU Chuck:
> > Hi team,
>
Hi,
On Tue, 28 May 2019, Philip Oakley wrote:
> On 28/05/2019 08:10, LU Chuck wrote:
> [snip]
> > > Copying and pasting examples literally is dangerous. You should know what
> > > you
> > > are doing.
> > >
> > > "..." is a revision range that computes the mergebase between HEAD and
> > > HEAD,
>
> -Original Message-
> From: Philip Oakley
> Sent: Tuesday, May 28, 2019 5:34 PM
> To: LU Chuck ; Johannes Sixt
> Cc: git@vger.kernel.org; chuck...@qq.com
> Subject: Re: git filter-branch re-write history over a range of commits did
> notwork
>
> Hi Chuck,
>
> On 28/05/2019 08:10, LU
On Tue, May 28 2019, Jeff King wrote:
> On Tue, May 28, 2019 at 09:10:12AM +, Vanak, Ibrahim wrote:
>
>> We are seeing issue with GIT 2.14 version. When we try to clone the
>> repos, it is taking HUGE amount of time on HPUX, whereas on the linux
>> machine with same network configuration, it
On Tue, May 28, 2019 at 09:10:12AM +, Vanak, Ibrahim wrote:
> We are seeing issue with GIT 2.14 version. When we try to clone the
> repos, it is taking HUGE amount of time on HPUX, whereas on the linux
> machine with same network configuration, it's getting cloned in less
> than mins. So we wa
1 - 100 of 105 matches
Mail list logo
