Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on
Here is an excerpt from a draft edition of "What's cooking" report
for topics that are about an immediate 2.20.1 maintenance release,
with five topics that I plan to merge to 'next' and then to 'maint'
soonish (they're all marked as "Will merge to 'next' and then to
'master'").
They'll be in 'pu'
Am 13.12.18 um 03:48 schrieb Junio C Hamano:
So,... what's the conclusion? The patch in the context of my tree
would be a no-op, and we'd need a prerequisite change to the support
function to accompany this patch to be effective?
Correct, that is my conclusion.
-- Hannes
On Thu, 13 Dec 2018 at 03:17:21, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > The basic idea of the service I imagine is simple:
> >
> > 1. You register a primary email address and specify a password. You
> >receive a verification email to confirm that the address is yours.
>
> I wo
Tejun Heo writes:
> Hmmm... I see. I still have a bit of trouble seeing why doing it that
> way is better tho. Wouldn't new-object-hook be simpler? They'll
> achieve about the same thing but one would need to keep the states in
> two places.
The new-object-hook thing will not have keep the st
Junio C Hamano writes:
> "Derrick Stolee via GitGitGadget" writes:
>
>> +SECOND_SMALLEST_SIZE=$(ls -l .git/objects/pack/*pack | awk
>> "{print \$5;}" | sort -n | head -n 2 | tail -n 1) &&
>
> awk is capable of remembering $5 from each line of input, sorting
> them and picking the se
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits, while
> specifying '-m 1' fails on non-merge commits.
>
> This patc
Steven Penny writes:
> On Wed, Dec 12, 2018 at 1:29 AM Johannes Sixt wrote:
>> As long as C:\Windows\System32 on my Windows computer contains only
>> 64-Bit binaries, I consider the characters "3" and "2" next to each
>> other in this order just noise and without any form of information. The
>> i
Hello, Junio, Stefan.
On Thu, Dec 13, 2018 at 12:09:39PM +0900, Junio C Hamano wrote:
> Please do not take the above as "don't do notes/xref-; instead read
> from the 'meta commits'". I do not have a preference between the
> two proposed implementations. The important thing is that we won't
> en
Hello, Junio.
On Thu, Dec 13, 2018 at 12:01:25PM +0900, Junio C Hamano wrote:
> > Wouldn't it be more useful to have repo-updated-with-these-commits
> > hook instead rather than putting more logic on note handling?
> >
> >> and scan the commits, just like you scan what you fetched. And when
> >>
Stefan Beller writes:
>> - now these three changes that were problematic in the past is
>>resent without any update (other than that it has one preparatory
>>patch to add tests).
>
> One of the three changes was problematic, (e98317508c02),
> the other two are good (in company of the thi
Stefan Beller writes:
>> Unlike the step 2/4 I commented on, this does explain what this
>> wants to do and why, at least when looked from sideways. Is the
>> above saying the same as the following two-liner?
>>
>> An ealier mistake while rebasing to produce 74d4731da1
>> failed
Junio C Hamano writes:
>> As long as we can keep the reverse rference notes consistent, wouldn't
>> amend propagation just consume them?
>
> Yes. Would that mean you do not need the notes/xref-* series we are
> seeing here, and instead (re)use what Stefan's series, which already
> needs to have
Tejun Heo writes:
>> allowed to be a bit stale and be completed immediately before it
>> gets used? A totally different approach could be to record list of
>> commits, all commits behind which have been scanned for reverse
>> mapping, in the tip of the notes history, perhaps in the commit log
>>
Jonathan Tan writes:
> Thanks, Aevar for looking into this. I haven't looked into detail, but:
> ...
> If you agree with the general direction I'm going in, when you send out
> another version, I would add patch 2 somewhere near the beginning of the
> set, and then squash both patch 1 and patch 3
Johannes Sixt writes:
+ if (is_dir_sep(template[0]) && !is_dir_sep(template[1]) &&
+ iswalpha(wtemplate[0]) && wtemplate[1] == L':') {
+ /* We have an absolute path missing the drive prefix */
>>>
>>> This comment is true for the source part, template, but I can't fi
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The test t4256-am-format-flowed.sh requires carefully applying a
> patch after ignoring padding whitespace. This breaks if the file
> is munged to include CRLF line endings instead of LF.
>
> Signed-off-by: Johannes S
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The new test_oid machinery in the test library requires reading
> some information from t/oid-info/hash-info and t/oid-info/oid.
> The shell logic that reads from these files is sensitive to CRLF
> line endings, causing a probl
Lukas Fleischer writes:
> The basic idea of the service I imagine is simple:
>
> 1. You register a primary email address and specify a password. You
>receive a verification email to confirm that the address is yours.
I would do so with my current, reachable address, I'd presume.
> 2. At any
On Wed, Dec 12, 2018 at 11:58:12AM -0800, Jonathan Tan wrote:
> > Yeah, this was the part that took me a bit to figure out, as well. The
> > optimization here is really just avoiding a call to lookup_commit(),
> > which will do a single hash-table lookup. I wonder if that's actually
> > worth this
On Wed, Dec 12, 2018 at 3:02 AM Jeff King wrote:
>
> On Tue, Dec 11, 2018 at 04:25:15PM -0800, Josh Steadmon wrote:
>
> > From: Masaya Suzuki
> >
> > In the Git pack protocol definition, an error packet may appear only in
> > a certain context. However, servers can face a runtime error (e.g. I/O
On Wed, Dec 12, 2018 at 01:32:17PM -0800, John Lopez wrote:
> Afternoon,
>
> I am inquiring to see if you have a repo for your software where we can
> point our 3rd party software to automatically download your software? It
> requires CAB's not sure if you do this or not, if so can you send me th
> Unlike the step 2/4 I commented on, this does explain what this
> wants to do and why, at least when looked from sideways. Is the
> above saying the same as the following two-liner?
>
> An ealier mistake while rebasing to produce 74d4731da1
> failed to update this BUG message. F
On Fri, Dec 7, 2018 at 9:57 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > A couple days before the 2.19 release we had a bug report about
> > broken submodules[1] and reverted[2] the commits leading up to them.
> >
> > The behavior of said bug fixed itself by taking a different approac
git-am has the --keep-non-patch option to pass -b to
git-mailinfo for keeping subject prefixes intact. Allow
this option to be used with quiltimport as well.
Signed-off-by: Laura Abbott
---
Documentation/git-quiltimport.txt | 5 -
git-quiltimport.sh| 6 +-
2 files changed
> Is there an easy way to figure out what object we're processing in
> create_delta? I have filtered out some large data files in .gitattributes
> already.
For the record:
* add breakpoint on create_delta at diff-delta.c:321
* stop the execution
* switch to the worker thread
* select frame 3: th
Afternoon,
I am inquiring to see if you have a repo for your software where we can
point our 3rd party software to automatically download your software? It
requires CAB's not sure if you do this or not, if so can you send me the
link for future versions
Thank you for your time and support.
V/R
J
On Wed, 12 Dec 2018 at 21:13, James Mason wrote:
>
> I have a large and active SVN repository. More than 36,000 revisions,
> thousands of branches - new ones created daily - and a non-standard
> layout. Also, a secondary git repository that serves as a faithful
> "git" copy of the work accumulat
When 99017ffac8 (submodule: use submodule repos for object lookup, 2018-11-13)
was merged, I had not yet addressed all outstanding review comments, such
as adapting the documentation for the function `open_submodule`, which
changed its signature during the development of that series.
Fix the docume
Signed-off-by: Stefan Beller
---
On Thu, Nov 15, 2018 at 11:54 AM Jonathan Tan wrote:
> Other than that, this patch looks good.
I'll incorporate these changes once resending.
Stefan
submodule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule
I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
On Wed, Dec 12, 2018 at 9:05 PM Stefan Beller wrote:
>
> On Wed, Dec 12, 2018 at 11:47 AM Duy Nguyen wrote:
> >
> > I'm not going to bother you with patches (yet) but I could use a few
> > eyeballs to check the help usage (and perhaps the option grouping) for
> > commands that take diff options.
On Wed, Dec 12, 2018 at 11:47 AM Duy Nguyen wrote:
>
> I'm not going to bother you with patches (yet) but I could use a few
> eyeballs to check the help usage (and perhaps the option grouping) for
> commands that take diff options.
The grouping looks good from a cursory view, but ...
> Forget ab
> On Sun, Dec 09, 2018 at 09:51:28AM +0900, Junio C Hamano wrote:
>
> > > -static int parse_commit_in_graph_one(struct commit_graph *g, struct
> > > commit *item)
> > > +static struct commit *parse_commit_in_graph_one(struct repository *r,
> > > + struct co
On Mon, Dec 10, 2018 at 8:09 PM Yaroslav Halchenko
wrote:
Thanks for the patches. The first patch looks good to me!
> [PATCH 2/2] RF+ENH(TST): compare the entire list of submodule status
> --recursive to stay intact
The subject is a bit cryptic (specifically the first part before the
colon), m
I'm not going to bother you with patches (yet) but I could use a few
eyeballs to check the help usage (and perhaps the option grouping) for
commands that take diff options.
Forget about hiding irrelevant options for this particular command for
now. This is something we can do later.
usage: git ra
> But again, I must confess, that either I forgot or just do not see a
> clear use-case/demand for submodule.update config myself any longer,
ok, let's drop that patch then.
> Probably I need to try "submodules update --merge" to see what is that
> rough edge which makes it different from the pot
CB Bailey writes:
> From: CB Bailey
>
> shortlog always respects the mailmap in its output. Pass the mailmap
> into the revision walker to allow the mailmap to be used with revision
> limiting options such as '--author'.
I am a bit torn on this.
If an author of interest has entries in the ma
Is there an easy way to figure out what object we're processing in
create_delta? I have filtered out some large data files in .gitattributes
already.
florin
In 321fd823 ("run-command: mark path lookup errors with ENOENT",
2018-10-24), we rewrote the logic to execute a command by looking
in the directories on $PATH; as a side effect, a request to run a
command that is not found on $PATH is noticed even before a child
process is forked to execute it.
We
On Wed, Dec 12 2018, CB Bailey wrote:
> From: CB Bailey
>
> shortlog always respects the mailmap in its output. Pass the mailmap
> into the revision walker to allow the mailmap to be used with revision
> limiting options such as '--author'.
>
> This removes some apparently inconsistent behavior
It seems to be spending a lot of time in create_delta. I have added a
breakpoint on calling create_delta and a few good minutes pass between the
breakpoint being hit. The large loop in create_delta has practically no
outgoing function calls (save for the realloc on line 476), so I still don't
u
I noticed that our CI builds (see [1] for an example) were returning success
much faster than they did before Git v2.20.0. Turns out that there was a
test script failure involving the new test hash logic.
error: bug in the test script: bad hash algorithm
make[1]: *** [Makefile:56: t-basic.sh]
From: Johannes Schindelin
The test t4256-am-format-flowed.sh requires carefully applying a
patch after ignoring padding whitespace. This breaks if the file
is munged to include CRLF line endings instead of LF.
Signed-off-by: Johannes Schindelin
Signed-off-by: Derrick Stolee
---
t/.gitattribut
From: Derrick Stolee
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is sensitive to CRLF
line endings, causing a problem when the test suite is run on a
Windows machine that
(Apologize for top-posting but making Outlook quote properly is a bear)
Down to 1+4 threads:
--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read writ| recv send| in out | int csw
0 13 87 0 0| 0 0 |2059B 15k| 0 0 |2200 1730
From: CB Bailey
shortlog always respects the mailmap in its output. Pass the mailmap
into the revision walker to allow the mailmap to be used with revision
limiting options such as '--author'.
This removes some apparently inconsistent behaviors when using
'--author', such as not finding some or
On Wed, Dec 12, 2018 at 2:27 PM Eric Sunshine wrote:
>
> On Tue, Dec 11, 2018 at 4:50 PM Thomas Gummerer wrote:
> > On 12/10, Duy Nguyen wrote:
> > > On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer
> > > wrote:
> > > > Move the worktree tests to t24* to adhere to that guideline. We're
> > > > go
On Wed, Dec 12, 2018 at 5:52 PM Iucha, Florin wrote:
>
> Jeff,
>
> Thank you for the advice, I will reduce the depth.
>
> Running "git pack-objects --all --no-reuse-delta --delta-base-offset --stdout
> /dev/null", it got to 99% fairly quickly, now it has 5 threads
> running (using 99.9% CPU), bu
From: CB Bailey
shortlog always respects the mailmap in its output. Pass the mailmap
into the revision walker to allow the mailmap to be used with revision
limiting options such as '--author'.
This removes some apparently inconsistent behaviors when using
'--author', such as not finding some or
Jeff,
Thank you for the advice, I will reduce the depth.
Running "git pack-objects --all --no-reuse-delta --delta-base-offset --stdout
/dev/null", it got to 99% fairly quickly, now it has 5 threads
running (using 99.9% CPU), but the "dstat 5" still shows lots of nothing, with
some heavy system
Thank you for this incredibly quick fix.
I see the fix made it to pu as 6b206be3e5 ("run-command: report exec
failure" 2018-12-11). For what it's worth, it fixes the issue as far
as I'm concerned and I'm very glad to see the behavior is covered by
tests now.
As a procedural question: I'd like to
Hello, Junio.
On Wed, Dec 12, 2018 at 04:26:57PM +0900, Junio C Hamano wrote:
> It also is not immediately obvious to me what your general strategy
> to maintain this reverse mapping is, when new ways and codepaths to
> cause new commits with "cherry-picked-from" trailer appear. Do we
> keep pili
On Wed, Dec 12 2018, Jeff King wrote:
> On Wed, Dec 12, 2018 at 03:01:47AM +, Iucha, Florin wrote:
>
>> I am running “git-repack -A -d -f -F --window=250 --depth=250” on a
>> Git repository converted using git-svn.
>
> Sort of tangential to your question, but:
>
> - Using "-F" implies "-f
Hi Elijah,
On Tue, 11 Dec 2018, Elijah Newren wrote:
> I'm worried based on other emails in this thread that there is a
> fundamental difference in frame of reference leading to a
> misunderstanding about rationale for naming, and worse that folks might
> not even realize where the misunderstandi
On Tue, Dec 11, 2018 at 01:55:09PM -0500, George King wrote:
> I just noticed that while `wsErrorHighlight = none` fixes the problem
> of extra green codes for regular diff, it fails to have any effect
> during interactive `git add -p`.
This is due to the way add--interactive invokes diff. It use
On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The new test_oid machinery in the test library requires reading
> some information from t/oid-info/hash-info and t/oid-info/oid.
> The shell logic that reads from these files is sensitive t
Hi Hannes,
On Wed, 12 Dec 2018, Johannes Sixt wrote:
> Am 12.12.18 um 01:42 schrieb Steven Penny:
> > On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
> > > > - pc-windows
> > > > - pc-win
> > > > - win
> > >
> > > I find all of those horrible.
> >
> > one windows triplet in use is "x8
On Tue, Dec 11, 2018 at 4:50 PM Thomas Gummerer wrote:
> On 12/10, Duy Nguyen wrote:
> > On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer wrote:
> > > Move the worktree tests to t24* to adhere to that guideline. We're
> > > going to make use of the free'd up numbers in a subsequent commit.
> >
> >
On Tue, Dec 11, 2018 at 11:41:18AM -0500, George King wrote:
> I first started playing around with terminal colors about 5 years ago,
> and I recall learning the hard way that Apple Terminal at least
> behaves very strangely when you have background colors cross line
> boundaries: background color
On Wed, Dec 12, 2018 at 1:29 AM Johannes Sixt wrote:
> As long as C:\Windows\System32 on my Windows computer contains only
> 64-Bit binaries, I consider the characters "3" and "2" next to each
> other in this order just noise and without any form of information. The
> important part of the name is
On Wed, Dec 12, 2018 at 03:01:47AM +, Iucha, Florin wrote:
> I am running “git-repack -A -d -f -F --window=250 --depth=250” on a
> Git repository converted using git-svn.
Sort of tangential to your question, but:
- Using "-F" implies "-f" already, so you don't need both. That said,
yo
Junio C Hamano writes:
> Sergey Organov writes:
>
>> So, finally, it's 'branch.linux.pushremote' that is the "offender".
>>
>> Looks like both 'git status' and 'git branch -vv' should somehow learn
>> about 'branch..pushremote' feature so that their
>> output/suggestions make more sense?
>
> Doe
On Tue, Dec 11, 2018 at 04:25:15PM -0800, Josh Steadmon wrote:
> From: Masaya Suzuki
>
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protoc
Sergey Organov writes:
> So, finally, it's 'branch.linux.pushremote' that is the "offender".
>
> Looks like both 'git status' and 'git branch -vv' should somehow learn
> about 'branch..pushremote' feature so that their
> output/suggestions make more sense?
Doesn't "ahead of X by N" mean "you for
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> We take pains to determine the longest command beforehand, so that we
> can align the category column after printing the command names.
>
> However, then we re-use that value when printing the aliases. If any
> alias
Josh Steadmon writes:
> This is a reroll of js/smart-http-detect-remote-error that also includes
> a fixed version of ms/proto-err-packet-anywhere [1].
Yay. Thanks for reducing a topic I have to worry about by 1 ;-).
> The first patch clarifies the use of ERR messages in the pkt-line
> protoco
"Derrick Stolee via GitGitGadget" writes:
> The verbose output included these values. Note how '\r' appears in the
> variable values.
> ...
> ++ read tag rest
Interesting. "read" does not realize that it is reading from a text
file and do whatever appropriate for the platform (i.e. treat CRLF
a
Hi,
after reading though [1] and [2] again, I believe a pattern in
.gitattributes like
*/src/*/assets/**/*-expected-* text eol=lf
should match a committed file at
reporter/src/funTest/assets/NPM-is-windows-1.0.2-expected-NOTICE
In other words, "**" should be able to match "nothing",
70 matches
Mail list logo
