On 22/10/19 09:46AM, Bert Wesarg wrote:
> On Mon, Oct 21, 2019 at 9:35 PM Johannes Sixt wrote:
> >
> > Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> > > Dear Pratyush,
> > >
> > > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > > the stage-list. But I think it should be disab
On 22/10/19 10:17AM, Bert Wesarg wrote:
> On Mon, Oct 21, 2019 at 9:04 PM Pratyush Yadav wrote:
> >
> > On 21/10/19 11:16AM, Bert Wesarg wrote:
> > > Dear Pratyush,
> > >
> > > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > > the stage-list. But I think it should be disabl
Hello,
This is a follow-up on my previous emails related to the proposal of a new
signing interface:
https://public-inbox.org/git/CACi-FhDeAZecXSM36zroty6kpf2BCWLS=0r+duwub96lqfk...@mail.gmail.com/T/#r43cbf31b86642ab5118e6e7b3d4098bade5f5a0a
https://public-inbox.org/git
s lines by the commit that introduced them [3]. Thanks
>> Peff for the feedback on that idea.
>>
>
> []
>>
>> Torsten Bögershausen ebb8d2c9 mingw: support UNC in git clone
>> file://server/share/repo
>> connect.c
>> ebb8d2c9 921) path = host - 2; /* i
On Wed, Oct 23, 2019 at 09:32:26AM -0400, Eric Sunshine wrote:
> On Wed, Oct 23, 2019 at 8:04 AM Denton Liu wrote:
> > Before, the output of `git diff HEAD` would always be piped to
> > sanitize_conflicted_diff(). However, since the Git command was upstream
> > of the
feedback on that idea.
>
[]
>
> Torsten Bögershausen ebb8d2c9 mingw: support UNC in git clone
> file://server/share/repo
> connect.c
> ebb8d2c9 921) path = host - 2; /* include the leading "//" */
>
I actually looked into this one, and my understanding is that t
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-56.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this
Since `git config` leaves the configurations set even after the test
case completes, use `test_config` instead so that the configurations are
reset once the test case finishes.
Signed-off-by: Denton Liu
---
t/t4108-apply-threeway.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Before, the output of `git diff HEAD` would always be piped to
sanitize_conflicted_diff(). However, since the Git command was upstream
of the pipe, in case the Git command fails, the return code would be
lost. Rewrite into separate statements so that the return code is no
longer lost.
Since only
On Wed, Oct 23, 2019 at 07:22:12AM +, Aleksey Mikhaylov wrote:
> "Could not access submodule" error when pulling recursively with Git 2.22.0.
> This issue causes if there is submodule in submodule.
> Please use my simple test repository to reproduce the problem:
&
PROBLEM DESCRIPTION
"Could not access submodule" error when pulling recursively with Git 2.22.0.
This issue causes if there is submodule in submodule.
At first, we reported this problem for Git for Windows:
https://github.com/git-for-windows/git/issues/2361
But we received the answer t
to the graph and point to
> +either another tag or a commit.
Either say "generally point to", or "point to another object"
(i.e. a tag that points to a tree or a blob is normal---it is just
they do not so frequently appear).
> They're generally used to mark releases
From: Johannes Schindelin
The presence of this path will be used in the next commit to fix an
incorrect piece of advice in `git commit` when in the middle of a
rebase.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 4 ++--
sequencer.h | 1 +
2 files changed, 3 insertions(+), 2 deletions
From: Johannes Schindelin
In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02),
`git commit` learned to suggest to run `git cherry-pick --skip` when
trying to cherry-pick an empty patch, but that was never tested for.
Here is a test that verifies that a message is given to the
On Fri, Sep 20, 2019 at 06:47:01PM -0700, Emily Shaffer wrote:
> On Fri, Sep 20, 2019 at 10:04:48AM -0700, Jonathan Tan wrote:
> > > Prospective mentors need to sign up on that site, and should propose a
> > > project they'd be willing to mentor.
> >
> > [snip]
> >
> > > I'm happy to discuss poss
Vegard Nossum wrote:
> I sent v2 of the patches (with metadata _after_ the diff) to the git
> list here:
>
> https://public-inbox.org/git/20191022114518.32055-1-vegard.nos...@oracle.com/T/#u
>
> As I wrote in there, we could already today start using
>
>git a
On 10/22/19 3:53 PM, Theodore Y. Ts'o wrote:
On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
As I wrote in there, we could already today start using
git am --message-id
when applying patches and this would provide something that a bot could
annotate with git
Hi Dscho,
Install went Ok.
Did a quick test on the config locations and `git config -l
-show-origin` has 'lost' the ProgramData location as planned.
The minor pedant did notice that the new location is listed slightly
differently from the release notes.
`file:C:/Program Files/G
On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
>
> As I wrote in there, we could already today start using
>
> git am --message-id
>
> when applying patches and this would provide something that a bot could
> annotate with git notes pointing to lore/LKML/
where the diff ends. A comment in 'git apply' suggested that
detecting the difference between "--" as a diff/signature separator and
as part of the diff is nontrivial in the sense that you need to
actually
do some parsing and keep track of hunk sizes.
Could we cheat by having
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
Currently, if a Git command fails in an unexpected way, such as a
segfault, it will be masked and ignored. Replace the ! with
test_must_fail so that only expected failures pass.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
Before, if the invocation of git failed, it would be masked by the pipe
since only the return code of the last element of a pipe is used.
Rewrite the test to put the Git command on its own line so its return
code is not masked.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 3 ++-
1 file
On Mon, Oct 21, 2019 at 9:04 PM Pratyush Yadav wrote:
>
> On 21/10/19 11:16AM, Bert Wesarg wrote:
> > Dear Pratyush,
> >
> > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > the stage-list. But I think it should be disabled, like the 'Revert
> > Hunk' and 'Revert Line' menu
Hello,
I added the git list to Cc:. For the new readers: The context of this
thread can be found at
https://lwn.net/ml/linux-kernel/20191017234348.wcbbo2njexn7ixpk@willie-the-truck/
On Mon, Oct 21, 2019 at 08:46:58AM +0200, Ingo Molnar wrote:
> Anyway, a small Git feature request: it would
On Mon, Oct 21, 2019 at 9:35 PM Johannes Sixt wrote:
>
> Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> > Dear Pratyush,
> >
> > I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> > the stage-list. But I think it should be disabled, like the 'Revert
> > Hunk' and 'Revert Line' menu
On Mon, Oct 21, 2019 at 04:04:22PM -0700, Elijah Newren wrote:
> > 4211.3: git log --follow [...]8.56(8.41+0.15) -0.2% 3.67(3.53+0.13)
> > -57.2%
>
> Many nice speedups here, not just commit-graph (the rev-list cases)
> but also log -L (from sg/line-log-tree-diff-o
7) +3.1% 0.34(0.29+0.05) -46.9%
> 0001.6: rev-list --parents -- dummy 0.66(0.60+0.05)
> 0.67(0.62+0.05) +1.5% 0.36(0.32+0.03) -45.5%
[...]
> 4211.2: git rev-list --topo-order (baseline) 6.32(6.04+0.28)
> 6.30(6.09+0.2
Team,
a couple of days later than I wanted, but at least it is now here:
https://github.com/git-for-windows/git/releases/tag/v2.24.0-rc0.windows.1
Please test...
Thank you,
Johannes
% 6.52(6.26+0.26) -7.3%
4205.7: log with %h-%h-%h 7.79(7.57+0.22)
7.79(7.55+0.24) +0.0% 7.10(6.84+0.26) -8.9%
4211.2: git rev-list --topo-order (baseline) 6.32(6.04+0.28)
6.30(6.09+0.21) -0.3% 1.15(0.96+0.19
In this blog post, we discuss updates in to the Git commit-graph
feature since it was announced shortly after Git 2.18.0. This
answers the following:
1. What is the commit-graph?
2. Why should I enable the commit-graph?
3. How do I enable it now, or disable in time for 2.24.0?
4. How do I write
On 10/18/2019 8:20 PM, Emily Shaffer wrote:
> An overview of what Git object types mean and how they loosely translate
> into filesystem types users are already familiar with is a good start to
> making Git's internals less scary to users. This post is an interactive
> overvi
Am 21.10.19 um 11:16 schrieb Bert Wesarg:
> Dear Pratyush,
>
> I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> the stage-list. But I think it should be disabled, like the 'Revert
> Hunk' and 'Revert Line' menu entry.
>
> Can you confirm this?
Technically, it need not be dis
On 21/10/19 11:16AM, Bert Wesarg wrote:
> Dear Pratyush,
>
> I just noticed that the 'Revert Last Hunk' menu entry is enabled in
> the stage-list. But I think it should be disabled, like the 'Revert
> Hunk' and 'Revert Line' menu entry.
I'm not sure what you mean. There is no "Revert Last Hunk" m
Here is today's test coverage report. You can find it at the normal place
[1][2][3].
I set the "master@{1}" to be the maint branch, so this should cover all new
code that
is not in the previous release.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/rep
From: Jiang Xin
Hi,
Git v2.24.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 35 updated messages need to be translated since last update:
l10n: git.pot: v2.24.0 round 1 (35 new, 16 removed)
Generate po/git.pot from v2.24.0-rc0 fo
fore the
> previous one are lost.
>
> Signed-off-by: Pratyush Yadav
> ---
> git-gui.sh | 18 +-
> lib/diff.tcl | 53 ----
> 2 files changed, 66 insertions(+), 5 deletions(-)
>
> diff --git a/git-gui.sh
Emily Shaffer writes:
> +Under the covers, Git is mostly a directed graph of objects. Those objects
> come
> +in four flavors; from root to leaf (generally), those flavors are:
Is "acyclic" worth mentioning, I wonder.
> +
> +- Tag
> +- Commit
> +- Tree
>
On 10/20/19 5:17 AM, Willy Tarreau wrote:
On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
The problem I ran into with putting the metadata at the end was
detecting where the diff ends. A comment in '
when thinking about how to implement
server-side workflows (for a non-kernel project). My goal is to ensure a
patch can only be pushed to the master branch if it has received review.
The easy way to do so it to check the Reviewed-by tags, but those can
easily be forged. I was thus wondering if we should have a way to sign
tags (as in commit message tags, not git tags).
--
Regards,
Laurent Pinchart
On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
> > The problem I ran into with putting the metadata at the end was
> > detecting where the diff ends. A comment in 'git apply' su
Hi all,
I tried pretty hard yesterday to get a preview of Git for Windows out,
based on v2.24.0-rc0, but I need a bit more time.
The PR at https://github.com/git-for-windows/git/pull/2360 shows where I
am going, and I started the automation based on it, but it failed (and I
could not monkey
An overview of what Git object types mean and how they loosely translate
into filesystem types users are already familiar with is a good start to
making Git's internals less scary to users. This post is an interactive
overview of the various types, demonstrating subcommands which show wha
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
Currently, if a Git command fails in an unexpected way, such as a
segfault, it will be masked and ignored. Replace the ! with
test_must_fail so that only expected failures pass.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
Before, if the invocation of git failed, it would be masked by the pipe
since only the return code of the last element of a pipe is used.
Rewrite the test to put the Git command on its own line so its return
code is not masked.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 3 ++-
1 file
akley"]
[reformat_date [concat "" "Sun May 19 22:33:37 2019 +0100"]]
"compat/vcSegmentation fault
Not exactly the same, but almost. Ends the same place, with as similar short
line.
This is run inside the bash that is started directly by the git-for-windows
sdk sta
On Fri, Oct 18, 2019 at 11:00 AM SZEDER Gábor wrote:
> On Thu, Oct 17, 2019 at 02:08:12PM -0400, Eric Sunshine wrote:
> > It is a long-standing To-Do[1] for "git worktree list [--porcelain]"
> > to indicate whether a worktree is locked, prunable, etc. Looking at
> >
Currently, if you do:
$ git branch zonk origin/master
$ git worktree add zonk zonk
$ rm -rf zonk
$ git branch -d zonk
You get the following error:
$ git branch -d zonk
error: Cannot delete branch 'zonk' checked out at
'/home/pjones/devel/kernel.org/git/zonk'
It isn't
gt; > + return;
>
> I think this check is insuffient: even if the directory of the working
> tree is not present, the working tree might still exist, and should
> not be ignored (or deleted/pruned in the second patch).
>
> See the description of 'git worktree lock&#
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
> I started out using this approach, but I changed it because the
> implementation was a bit annoying: 'git am' runs 'git mailsplit',
> which just splits the email into two parts:
>
> 1) headers, cha
arge the sigs
from those are.
I want to underline that my use of minisign was specifically for patches
sent via email, without the intent of preserving them in git history
(which is why in my proposal they are put under the `---` cutoff). Git
itself would continue to use PGP signing.
(This
most care
about namely, the patch itself. :-)
Yes, agreed.
I started out using this approach, but I changed it because the
implementation was a bit annoying: 'git am' runs 'git mailsplit',
which just splits the email into two parts:
1) headers, changelog, and diffstat;
2)
he patch itself. :-)
If we move the PGP signature to the end, then the fact that it is so
big and bulky becomes much less of an issue. A mini-sig might still
be a cool thing, from a space savings perspective both in the mail
archives, and in the git repo itself, if we start signing all commits.
But
This seems like something
> > > that could be added to git as an alternative to gpg without too much
> > > trouble, I think.
> >
> > I wonder how big the pgp payload would be with ed25519 as the underlying
> > algorithm. AFAICT, the payload of a minisign s
On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote:
Seeing how large this signature is, I have to admit that I am partial to
Konstantin's suggestion of using minisign. This seems like something
that could be added to git as an alternative to gpg without too much
troub
> Seeing how large this signature is, I have to admit that I am partial to
> Konstantin's suggestion of using minisign. This seems like something
> that could be added to git as an alternative to gpg without too much
> trouble, I think.
>
>
I wonder how big the pgp payloa
pure.paranoia.local_&d=DwICaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=yZMPY-APGKyVIX7HgQFZJA&m=-7NJMybpa_bV7Y1FxWmqo1cUHOsDXAsRR1vvpQmYhyI&s=iFHNwBfYAPr---qMdv0mvKQAxqjXxvf1mAiAYZG6DIE&e=
> >>
> >>
> >> However, since git's PGP signatures are made for the content
On Thu, Oct 17, 2019 at 02:08:12PM -0400, Eric Sunshine wrote:
> On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> > Complete the paths of existing working trees for 'git worktree's
> > 'move', 'remove', 'lock', and 'unlock'
On 10/16/19 4:45 PM, Santiago Torres Arias wrote:
Hi Willy, Vegard.
On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
Hi Vegard,
On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
(cross-posted to git, LKML, and the kernel workflows mailing lists.)
Hi all,
I&#x
t; or
>>>> any other bylines. I expect this is a deal-breaker for most maintainers.
>>> Yeah it is :(
>>>
>>> But, if we could just have the signature on the code change, not the
>>> changelog text, that would help with that issue.
>>
An early preview release Git v2.24.0-rc0 is now available for
testing at the usual places. It is comprised of 493 non-merge
commits since v2.23.0, contributed by 63 people, 15 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The
Vegard Nossum wrote:
> Disadvantages:
>
> - requires patching git
The bigger disadvantage is this won't work with a historical
patch series (and some folks stay on ancient git). But maybe
that window for that is only a few years...
The toughest part right now for public-inbo
s is a deal-breaker for most maintainers.
> >
> > Yeah it is :(
> >
> > But, if we could just have the signature on the code change, not the
> > changelog text, that would help with that issue.
>
> We totally should, and I even mused on how we would do that he
e, not the
changelog text, that would help with that issue.
We totally should, and I even mused on how we would do that here:
https://public-inbox.org/git/20190910121324.GA6867@pure.paranoia.local/
However, since git's PGP signatures are made for the content in the
actual commit record (tr
On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
> > > I wonder if it'd be also possible to then embed gpg signatures over
> > > send-mail payloads so as they can be transparently transferred to the
> > > commit.
> >
>
Understood (and agree).
We do use git for source code (where we use SSH
and key authentication for CI/CD), but also for
configuration control of other files like
financial reports, engineering drawings, etc.
where access is via HTTPS. In that 2nd group the
challenge is to make it as &quo
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> In case an invocation of a Git command fails within the subshell, the
> failure will be masked. Replace the subshell with a file-redirection and
> a call to test_cmp.
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5
Before, if the invocation of git failed, it would be masked by the pipe
since only the return code of the last element of a pipe is used.
Rewrite the test to put the Git command on its own line so its return
code is not masked.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 3 ++-
1 file
Currently, if a Git command fails in an unexpected way, such as a
segfault, it will be masked and ignored. Replace the ! with
test_must_fail so that only expected failures pass.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
On 2019-10-17 at 14:33:38, Ralph Ewig wrote:
> Quick follow up question: can the git client pass
> a token read from a cookie with a request? That
> would enable users to sign-in via a browser, store
> the cookie, and then use that as the access token
> to authenticate a git reque
On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
I wonder if it'd be also possible to then embed gpg signatures over
send-mail payloads so as they can be transparently transferred to the
commit.
That's a crazy idea. It would be nice if we could do that, I like it
:)
It could only po
On Wed, Oct 16, 2019 at 10:45:19AM -0400, Santiago Torres Arias wrote:
> Hi Willy, Vegard.
>
> On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
> > Hi Vegard,
> >
> > On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
> > > (cross
ave a config option, and it should
be turned off by default. That said, I'd certainly like to hear what
other people think on this topic.
> FWIW I've also got 2 comments on this in GH[1].
>
> [1] https://github.com/git-for-windows/git/issues/2341
--
Regards,
Pratyush Yadav
On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> Complete the paths of existing working trees for 'git worktree's
> 'move', 'remove', 'lock', and 'unlock' subcommands.
> [...]
> Arguably 'git worktree unlock ' should
Complete paths of working trees and refs for 'git worktree's various
subcommands.
The last two patches do the actual improvements, the first four are
preparatory steps.
An early version of the last patch was already sent to the list as a
PoC over four years ago [1], but I didn'
The completion function for 'git worktree' uses separate but very
similar case arms to complete --options for each subcommand.
Combine these into a single case arm to avoid repetition.
Note that after this change we won't complete 'git worktree remove's
'--force&#
Complete the paths of existing working trees for 'git worktree's
'move', 'remove', 'lock', and 'unlock' subcommands.
Note that 'git worktree list --porcelain' shows absolute paths, so for
simplicity's sake we'll complete full
Complete paths after 'git worktree add ' and refs after 'git
worktree add -b ' and 'git worktree add some/dir '.
Uncharacteristically for a Git command, 'git worktree add' takes a
mandatory path parameter before a commit-ish as its optional last
paramet
On Thu, Oct 17, 2019 at 12:28 PM Peter Jones wrote:
> Currently, if you do:
>
> $ git branch zonk origin/master
> $ git worktree add zonk zonk
> $ rm -rf zonk
> $ git branch -d zonk
>
> You get the following error:
>
> $ git branch -d zonk
> error: Cannot de
Currently, if you do:
$ git branch zonk origin/master
$ git worktree add zonk zonk
$ rm -rf zonk
$ git branch -d zonk
You get the following error:
$ git branch -d zonk
error: Cannot delete branch 'zonk' checked out at
'/home/pjones/devel/kernel.org/git/zonk'
It isn't
ategy indicating how to treat empty ancestor
exemple: orphan branch1 created 2 weeks ago, develop branch existing since
years. File a.txt created 2 years ago on develop but only 2 weeks ago on
branch1. In such case, it's very likely that it has been created from a "git
checkout develop --
On Thu, 17 Oct 2019 16:01:33 +0200
Vegard Nossum wrote:
> In your example, couldn't Darrick simply base his xfs work on the latest
> xfs branch that was pulled by Linus? That should be up to date with all
> things xfs without having any of the things that made Linus's tree not
> work for him.
Su
ees, so the
delta between v5.3 and v5.3-rc1 is ***huge***.
So while I could base my development on my previous ext4.git branch
(based off of v5.3-rc4), at *some* point I need to be able to sync up
with upstream. And the usual way to do this is to start a new
development branch based on (for exam
Quick follow up question: can the git client pass
a token read from a cookie with a request? That
would enable users to sign-in via a browser, store
the cookie, and then use that as the access token
to authenticate a git request.
On 10/16/2019 11:03 PM, Jeff King wrote:
> On Thu, Oct
ph Ewig wrote:
>
>> Thanks for the reply. I was hoping the Git GUI
>> might be able to handle the OpenID authentication
>> flow, but it makes sense that it would be
>> inconsistent with other git clients.
> I don't think we'd ever do the full flow, but it migh
me was to just CONFIG_KMEMLEAK --- although of course, if I do have to
run a KMEMLEAK test run, I'll need to cherry-pick the fix which landed
this week on top of the ext4 git tree.)
What this all might mean is that sometimes it will make sense to allow
the user to override the base commit so such
On 10/17/19 5:17 AM, Junio C Hamano wrote:
Vegard Nossum writes:
Step 1:
* git send-email needs to include parent SHA1s and generally all the
information needed to perfectly recreate the commit when applied so
that all the SHA1s remain the same
* git am (or an alternative command
LEAK --- although of course, if I do have to
run a KMEMLEAK test run, I'll need to cherry-pick the fix which landed
this week on top of the ext4 git tree.)
What this all might mean is that sometimes it will make sense to allow
the user to override the base commit so such stablization patches
On 10/16/19 10:57 PM, Jonathan Nieder wrote:
Hi,
A few small points.
Vegard Nossum wrote:
* git am (or an alternative command) needs to recreate the commit
perfectly when applied, including applying it to the correct parent
Interesting. "git format-patch" has a --base option
ut.
I do that every now and then for git-gui, and Junio does that sometimes
for Git. I don't know if the folks over at Linux do something like this,
but using '--exact' would mean that contributors would have to send a
re-roll for even minor changes. Its mostly an inconvenience inst
Hi Johannes,
On Thu, Oct 17, 2019 at 7:33 AM Johannes Sixt wrote:
> FWIW, I would prefer to experiment with the feature for a few weeks
> before it (or a configuration that enables it by default) is baked in.
Yes please do. Obviously I'm glad someone other than me will be
actually testing it.
(A
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff for the feedback on that
On Thu, Oct 17, 2019 at 03:00:58AM +, Ralph Ewig wrote:
> Thanks for the reply. I was hoping the Git GUI
> might be able to handle the OpenID authentication
> flow, but it makes sense that it would be
> inconsistent with other git clients.
I don't think we'd ever do
Am 17.10.19 um 07:08 schrieb Birger Skogeng Pedersen:
> Hi Pratyush,
>
> On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
>> I mentioned this earlier, and I'll mention this again: I'm not sure
>> whether this feature would be a good thing for the larger population. So
>> this _might_ not end
ople react to
> the proposal. I thought I'd let you know to avoid any nasty surprises
> later.
Could you please elaborate on why you think the feature might be
undesired? Why would users not want a staged file to be selected
automatically?
FWIW I've also got 2 comments on this in GH[
Vegard Nossum writes:
> Step 1:
>
> * git send-email needs to include parent SHA1s and generally all the
> information needed to perfectly recreate the commit when applied so
> that all the SHA1s remain the same
>
> * git am (or an alternative command) needs t
Thanks for the reply. I was hoping the Git GUI
might be able to handle the OpenID authentication
flow, but it makes sense that it would be
inconsistent with other git clients.
Azure AD does support both LDAP and Kerberos, but
unfortunately only as an extra cost add-on called
"Domain Ser
On 2019-10-15 at 15:59:03, Ralph Ewig wrote:
> Hi Everyone, hoping you might have a solution for
> this problem:
>
> CONTEXT
>
> * I'm serving git repos using "smart https" via
> apache and basic authentication; everything works
> fine.
> * W
1 - 100 of 35392 matches
Mail list logo
