On Thu, Dec 20, 2018 at 2:48 PM Thomas Gummerer wrote:
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 801de2f764..4ac8c55865 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -260,6 +260,9 @@ the conflicted merge in th
On Sun, Dec 23, 2018 at 3:05 AM Duy Nguyen wrote:
> On Thu, Dec 20, 2018 at 2:48 PM Thomas Gummerer wrote:
> > +--[no-]overlay::
> > + In the default overlay mode files `git checkout` never
>
> -ECANTPARSE. Maybe "files" should be removed from this line?
Also, add a comma after "mode".
>On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:
>> I’m attempting to perform fixups via git-rebase of UTF-16 LE files
>> (the project I’m working on requires that exact encoding on certain
>> files). When the rebase is complete, Git changes that file’s encoding
>> to UTF
The documentation for this option jumps right in with "With `add`",
without explaining that `add` is a sub-command of "git worktree".
Together with rather odd grammatical structure of the remainder of the
sentence, the description can be difficult for newcomers to understand.
Clarify by improving t
On Fri, Dec 21 2018, brian m. carlson wrote:
> On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:
>> I recently submitted my first patch using OSX and found the experience
>> frustrating, for reasons that have come up on the list before,
>> concerning git-send-email and perl dependenc
I'm interested in parsing the output of `git-interpret-trailers` in a
script. I had hoped that the `--parse` option would make this easy, but
it seems that the `trailer.separators` configuration option is used to
specify both the input format (which separators may indicate a trailer)
and the output
On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Dec 21 2018, brian m. carlson wrote:
> > How do git send-email and git svn work in such a case? They depend on
> > the Git and Git::SVN modules being in place, so if you use a Perl other
> > than the one you built
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to th
On Sun, Dec 23 2018, brian m. carlson wrote:
> On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Dec 21 2018, brian m. carlson wrote:
>> > How do git send-email and git svn work in such a case? They depend on
>> > the Git and Git::SVN modules being in place,
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to th
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to th
On Wed, Dec 19, 2018 at 2:36 PM Jonathan Nieder wrote:
> In Linux kernel land, Documentation/process/submitting-patches.rst
> contains the following:
>
> -- >8 --
> If your patch fixes a bug in a specific commit, e.g. you found an issue using
> ``git bisect``, please use the 'Fixes:' tag with the
On Mon, Dec 24, 2018 at 12:34:12AM +0100, Ævar Arnfjörð Bjarmason wrote:
> Yeah, but my reading (which may be wrong) of John Passaro's E-Mail
> upthread
> ()
> is that for some users this is the path of least resistance to getting
> git-send-email et al working for whatever reason.
I think we shou
13 matches
Mail list logo
