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
On 09/27, Beyondhorizon Zheng wrote:
> [git issue] git am failed for patches of converting the file format of
> source codes from dos to unix
>
> Git version: git version 2.23.0
> Host PC: ubuntu 16.04.10
> Reporter: Shuang Zheng
>
> I have submitted a patch which co
[git issue] git am failed for patches of converting the file format of
source codes from dos to unix
Git version: git version 2.23.0
Host PC: ubuntu 16.04.10
Reporter: Shuang Zheng
I have submitted a patch which convert the file format of source file
from dos to unix with command:
dos2unix misc
index is getting corrupted. I reverted to git 2.14 and I'm working
> fine again. I've got my system admin looking into updating both AIX
> and SAMBA, but I thought I would report the issue here as well. Let me
> know if you need anything else from me. Thanks.
I don't have any par
've got my system admin looking into updating
both AIX and SAMBA, but I thought I would report the issue here as well. Let me
know if you need anything else from me. Thanks.
Gary Poli | Lead ERP Programmer
o 949 509 6216
4199 Campus Drive, 9th Floor
Irvine, CA 92612
This e-mail
On Fri, Jun 28, 2019 at 04:18:37PM +, Vanak, Ibrahim wrote:
> But HPUX Dev team have seen one significance difference, when they
> were triaging this issue, the ways GIT operations handled by 2 OSs: On
> linux, around 40 processes are spawned for handling a GIT operation
> whe
Hello ALL,
I did try GIT_TRACE* environment variables but couldn't isolate the problem.
But HPUX Dev team have seen one significance difference, when they were
triaging this issue, the ways GIT operations handled by 2 OSs: On linux, around
40 processes are spawned for handling a GIT oper
On 6/18/2019 10:31 AM, Vanak, Ibrahim wrote:
Hello ALL again,
Has anyone tested the performance of GIT on HP-UX platform? Can someone please
look into the issue we are seeing.
Thanks,
Ibrahim
You might try setting some of the GIT_TRACE* environment variables
listed in [1] on both your
Hello ALL again,
Has anyone tested the performance of GIT on HP-UX platform? Can someone please
look into the issue we are seeing.
Thanks,
Ibrahim
-Original Message-
From: Vanak, Ibrahim
Sent: Tuesday, June 11, 2019 10:09 PM
To: Jeff King
Cc: git@vger.kernel.org
Subject: RE: GIT
Thank Peff. Unfortunately I am living with this issue, no one able to find out
what is causing this significant delay. Re-initiating this thread if someone
can help on this.
Thanks & Regards,
Ibrahim Vanak
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Thursday,
On Wed, May 29, 2019 at 09:06:18AM +, Vanak, Ibrahim wrote:
> After cloning when I tried to checkout a branch on HPUX and Linux, I
> still significant time difference there as well even though network is
> not involve here. Do you suspect anything with HPUX OS? Do you have
> any mechanism to f
Hello Jeff,
Just sharing more information with you on this issue:
After cloning when I tried to checkout a branch on HPUX and Linux, I still
significant time difference there as well even though network is not involve
here. Do you suspect anything with HPUX OS? Do you have any mechanism to
, May 29, 2019 3:00 AM
To: Vanak, Ibrahim
Cc: git@vger.kernel.org
Subject: Re: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
On Tue, May 28, 2019 at 06:45:18PM +, Vanak, Ibrahim wrote:
> BUT still I have significant slowness(50 times slower than clone on
>
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%
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Tuesday, May 28, 2019 3:07 PM
To: Vanak, Ibrahim 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 configu
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
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 sa
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
>
Hello,
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 want to
know has anyone reported this issue? What is th
I saw this in one of my builds that followed the bleeding edge of Git for
Windows' SDK: git.exe has a different idea of the test script's PID than the
test script itself. Yet another of the quirks Git for Windows has to deal
with...
Johannes Schindelin (1):
t6500(mingw): use the Windows PID of t
Hi all,
I submitted a patch on 2019/4/23 with the title "[PATCH] status: add
an empty line when there is no hint". However, it didn't get any
review. Should I create an issue somewhere before submitting it? What
should I do to get my patch reviewed? Thanks.
Best,
John Lin
On 03/04/2019 09:11, Bryan Turner wrote:
On Wed, Apr 3, 2019 at 1:00 AM Amiel Elboim wrote:
Very helpful! annotated tag is good solution for us.
However fix of this issue is important, because it's confusing when you want to
track on your version using git tags.
Lightweight tags ha
On Wed, Apr 3, 2019 at 1:00 AM Amiel Elboim wrote:
>
> Very helpful! annotated tag is good solution for us.
>
> However fix of this issue is important, because it's confusing when you want
> to track on your version using git tags.
Lightweight tags have no metadata to al
On Tue, Apr 2, 2019 at 11:47 PM Amiel Elboim wrote:
> Hi!
>
> I've found strange behavior with 'git describe' command, look like for me as
> bug.
>
> In the case I create 2 tags on same commit and I run 'git describe --tags' I
> expect to get the latest tag, but always I get the first tag I crea
Hi!
I've found strange behavior with 'git describe' command, look like for me as
bug.
In the case I create 2 tags on same commit and I run 'git describe --tags' I
expect to get the latest tag, but always I get the first tag I created on the
commit.
Unlike git-describe documentations - "Th
On Mon, Mar 25, 2019 at 08:19:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > $ git tag -a mytag
> > error: refusing to make a recursive tag
> > hint: The object 'mytag' referred to by your new tag is already a tag.
> > hint:
> > hint: If you meant to create a tag of a tag, use:
> > hin
On Mon, Mar 25, 2019 at 11:43:52AM -0700, Bryan Turner wrote:
> > I don't think I've ever seen a tag-to-a-tag in the wild, but I wouldn't
> > be surprised if somebody has found a use for it. For example, because
> > tags can be signed, I can make a signature of your signature, showing a
> > crypto
On Mon, Mar 25 2019, Jeff King wrote:
> On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
>
>> On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
>> > Tags can point to any object, including another tag. It looks like
>> > somebody made an annotated tag of an annotated tag (probably
On Mon, Mar 25, 2019 at 7:49 AM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
>
> > On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> > > Tags can point to any object, including another tag. It looks like
> > > somebody made an annotated tag of an annotated
On Mon, Mar 25, 2019 at 9:49 AM Jeff King wrote:
> I think "just commits" is too restrictive. linux.git contains a tag of a
> tree, for example (we also have tags pointing to blobs in git.git, but
> they are not annotated).
>
> However, I could see an argument for the git-tag porcelain to notice a
On Mon, Mar 25, 2019 at 08:50:14AM -0500, Robert Dailey wrote:
> On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> > Tags can point to any object, including another tag. It looks like
> > somebody made an annotated tag of an annotated tag (probably by
> > mistake, given that they have the same t
On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> Tags can point to any object, including another tag. It looks like
> somebody made an annotated tag of an annotated tag (probably by
> mistake, given that they have the same tag-name).
>
> Try this:
>
> git init
> git commit -m commit --allow-
On Thu, Mar 21, 2019 at 12:04:22PM -0700, Bryan Turner wrote:
> > Why does it show two entries? In my `packed-refs` file, it also shows
> > a strange revision for the tag (I expect to see just 1 SHA1). Not sure
> > if it is related:
> >
> > ```
> > 66c41d67da887025c4e22e9891f5cd261f82eb31 refs/tag
On Thu, Mar 21, 2019 at 11:59:42AM -0500, Robert Dailey wrote:
> I have a particular tag in my repo that shows 2 annotated
> descriptions, which is very confusing.
>
> The command I ran:
>
> ```
> git show --format=fuller 4.2.0.1900
> ```
>
> And the output:
>
> ```
> tag 4.2.0/1900
> Tagger:
uot;fully-peeled") then every annotated (or signed)
tag in the file should have a second line prefixed by "^".
Hopefully this at least resolves part of your question!
Bryan
>
> Note I'm checking all of this on a bare clone (used `git clone
> --mirror`). Can someone help me understand what is going on here? I
> found this issue because I'm trying to do `git lfs migrate import`,
> and it isn't processing my tag because of this.
```
Note I'm checking all of this on a bare clone (used `git clone
--mirror`). Can someone help me understand what is going on here? I
found this issue because I'm trying to do `git lfs migrate import`,
and it isn't processing my tag because of this.
> Subject: [GSOC][PATCH] Fixed an issue which contained extra unnecessary code
Commit messages (and titles) should always be in the imperative mood.
The title in particular should be a short description of what the
patch is doing, and should give meaningful information to people
reading
On Sun, Mar 10, 2019 at 4:30 PM sushmaunnibhavi
wrote:
>
> From 5a6c233c6bf0a35aca000b32b9e936a34532900a Mon Sep 17 00:00:00 2001
> From: sushmaunnibhavi
> Date: Sun, 10 Mar 2019 19:37:33 +0530
> Subject: [GSOC][PATCH] Fixed an issue which contained extra unnecessary code
> Sig
>From 5a6c233c6bf0a35aca000b32b9e936a34532900a Mon Sep 17 00:00:00 2001
From: sushmaunnibhavi
Date: Sun, 10 Mar 2019 19:37:33 +0530
Subject: [GSOC][PATCH] Fixed an issue which contained extra unnecessary code
Signed-off-by: Sushma Unnibhavi
---
Since '\n' and '\0' ar
On 05/03/2019 03:35, brian m. carlson wrote:
On Mon, Mar 04, 2019 at 07:04:02PM -0500, Patrick Hogg wrote:
Hi all,
While investigating the last issue I reported (and fixed) I was trying
to come up with a good test case for repos with large objects. In the
process I found an issue on Windows
On Mon, Mar 04, 2019 at 07:04:02PM -0500, Patrick Hogg wrote:
> Hi all,
>
> While investigating the last issue I reported (and fixed) I was trying
> to come up with a good test case for repos with large objects. In the
> process I found an issue on Windows with objects at least 4g
Hi all,
While investigating the last issue I reported (and fixed) I was trying
to come up with a good test case for repos with large objects. In the
process I found an issue on Windows with objects at least 4g large:
git init test
cd test
echo "*.exe binary" > .gitattributes
t
On Wed, Feb 27, 2019 at 12:38:04PM +, Adrian Wright wrote:
> I am a git-for-windows user and have run into issues with casing on
> Windows OS.
>
> I filed a GitHub issue directly on the git-for-windows repo:
>
> The issue can be found on URL:
> https://github.com/git-f
Hi,
I am a git-for-windows user and have run into issues with casing on Windows OS.
I filed a GitHub issue directly on the git-for-windows repo:
The issue can be found on URL:
https://github.com/git-for-windows/git/issues/2066
See the GitHub link above for more details on the bug.
According
Kevin Daudt writes:
> On Mon, Jan 28, 2019 at 10:20:02AM -0500, Randall S. Becker wrote:
>> On January 28, 2019 9:25, COLLOMB Joris wrote:
>> ...
>> > git checkout -f -b "branch_name"
>> > gives me " Fatal: A branch named 'branch_name' already exists."
>>
>> Once the branch is created, you can't
ut on a forced branch creation at .
So the only solution for me is :
git branch -f "branch_name" && git checkout "branch_name"
So to resume:
- This is not an issue, just a divergence between my logic and git
implementation.
- The message "Fatal: '-f' is not a
@vger.kernel.org Objet : RE: Git checkout multiple options issue
> >>
> >> On January 28, 2019 8:25, COLLOMB Joris wrote:
> >> > git checkout -fb "branch_name"
> >> > (force branch creation and checkout it)
> >> >
> >> >
On January 28, 2019 11:03, COLLOMB Joris wrote:
>> -Message d'origine-
>> De : Randall S. Becker Envoyé : lundi 28 janvier
>> 2019 16:20 À : COLLOMB Joris -EXT ;
>> git@vger.kernel.org Objet : RE: Git checkout multiple options issue
>>
>> On J
On January 28, 2019 9:25, COLLOMB Joris wrote:
> -Message d'origine-
>> De : Randall S. Becker Envoyé : lundi 28 janvier
>> 2019 15:12 À : COLLOMB Joris -EXT ;
>> git@vger.kernel.org Objet : RE: Git checkout multiple options issue
>>
>> On Janu
: lundi 28 janvier 2019 15:12
À : COLLOMB Joris -EXT ; git@vger.kernel.org
Objet : RE: Git checkout multiple options issue
On January 28, 2019 8:25, COLLOMB Joris wrote:
> git checkout -fb "branch_name"
> (force branch creation and checkout it)
>
> doesn't work (even
On January 28, 2019 8:25, COLLOMB Joris wrote:
> git checkout -fb "branch_name"
> (force branch creation and checkout it)
>
> doesn't work (even if option a separated).
>
> I don't know if this is consider as an issue, but here it is.
I think you might mean
Hello,
Something like this:
git checkout -fb "branch_name"
(force branch creation and checkout it)
doesn't work (even if option a separated).
I don't know if this is consider as an issue, but here it is.
Thanks for reading,
Joris
CONF
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
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
Hello,
I've got confusing behavior and the cause was somewhat hard to discover:
-- 8< --
$ git status
On branch linux
Your branch is ahead of 'vendor/jps2rin_arm' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
$ git push
Everything up-to-date
k to get some feedback on
the small default font issue as well as documented a workaround to
allow per user default fonts.
https://core.tcl-lang.org/tk/tktview/dccd82bdc70dc25bb6709a6c14880a92104dda43
Any suggestions?
-Eric
And yet another patch coming through Git for Windows...
Change since v1:
* Using a better oneline now.
Gaël Lhez (1):
bundle: cleanup lock files on error
bundle.c| 7 ---
t/t5607-clone-bundle.sh | 4
2 files changed, 8 insertions(+), 3 deletions(-)
base-commit: 88
And yet another patch coming through Git for Windows...
Gaël Lhez (1):
bundle: refuse to create empty bundle
bundle.c| 7 ---
t/t5607-clone-bundle.sh | 4
2 files changed, 8 insertions(+), 3 deletions(-)
base-commit: 8858448bb49332d353febc078ce4a3abcc962efe
Published
Hi,
Thank you very much!
The git-bug project is what I'm looking for even if it is not very interesting
without gitlab connection.
There is an issue about it on Gitlab:
https://gitlab.com/gitlab-org/gitlab-ce/issues/50435
Maybe some encouragment from git core developer would help!
I
On Sun, Nov 11, 2018 at 11:50:00PM +0100, Martin Delille wrote:
> This would be awesome to handle issue directly with git: Having an
> offline version of the issues synced to the gitlab/github issues. A
> lot of work is done on the issues and it is lost when migrating from
> one se
On Mon, Nov 12 2018, Konstantin Khomoutov wrote:
> On Mon, Nov 12, 2018 at 09:35:31AM +0800, yan ke wrote:
>
>> > This would be awesome to handle issue directly with git:
>> > Having an offline version of the issues synced to the gitlab/github issues.
>> > A
On Mon, Nov 12, 2018 at 09:35:31AM +0800, yan ke wrote:
> > This would be awesome to handle issue directly with git:
> > Having an offline version of the issues synced to the gitlab/github issues.
> > A lot of work is done on the issues and it is lost when migrating
> >
git issue track!
Martin Delille 于2018年11月12日周一 上午6:52写道：
>
> Hi,
>
> This would be awesome to handle issue directly with git:
> Having an offline version of the issues synced to the gitlab/github issues.
> A lot of work is done on the issues and it is lost when migrating from one
Hi,
This would be awesome to handle issue directly with git:
Having an offline version of the issues synced to the gitlab/github issues.
A lot of work is done on the issues and it is lost when migrating from one
service to the other.
Beside we don’t always have a good internet connection.
There
From: Johannes Schindelin
Since we cannot stash dirty submodules, there is no use in requiring
them to be clean (or stash them when they are not).
This brings the built-in rebase in line with the previous, scripted
version, which also did not care about dirty submodules (but it was
admittedly no
Sergey Andreenko writes:
> git.exe diff --numstat "C:\diff" "C:\base"
> ...
> output will be:
>
> 0 1 {iff => ase}/1.txt
>
> So (folder_name_length) symbols were cut from the path (“C:\\d” and “C:\\b”).
>
> Is any way to avoid that? I have checked several git versions an
s.
Does anyone have a suggestion how to do a fetch by SHA-1? Or is there
another approach to solve this issue on travis-ci?
Thnx,
Maurice
git diff –numstat FOLDER1 FOLDER2 works strange when run from a git
controlled folder.
The output shrinks some symbols in the diff file paths.
For example:
Create a folder and call git init, for example: `C:\test`.
mkdir C:\test
cd C:\test
git init
basic issue is not with
Git, but with gpg bundled with latest Git version.
I have tested both version for below 4 cases and here are the test
results in below table:
Case Test Description Result For Git-2.18.0-64-bit.exe Result For
Git-2.19.1-64-bit.exe
CASE1: gpg import with default GNUPG Home
On Wed, Sep 26, 2018 at 06:14:11PM +0200, Martin Ågren wrote:
> diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
> index b2ca77b338..5fcf281dfb 100755
> --- a/t/t7005-editor.sh
> +++ b/t/t7005-editor.sh
> @@ -112,7 +112,7 @@ do
> done
>
> test_expect_success 'editor with a space' '
> - e
On Wed, Sep 26, 2018 at 06:14:11PM +0200, Martin Ågren wrote:
> From: Alexander Pyhalov
>
> Commit 4362da078e (t7005-editor: get rid of the SPACES_IN_FILENAMES
> prereq, 2018-05-14) removed code for detecting whether spaces in
> filenames work. Since we rely on spaces throughout the test suite
> (
From: Alexander Pyhalov
Commit 4362da078e (t7005-editor: get rid of the SPACES_IN_FILENAMES
prereq, 2018-05-14) removed code for detecting whether spaces in
filenames work. Since we rely on spaces throughout the test suite
("trash directory.t1234-foo"), testing whether we can use the filename
"e
tered a problem pushing
commits back to the subtree repo which generated a question and maybe exposed
an issue, though the issue could be with our repo for all I know.
[first attempt 2.16.0 (windows), retried with same results 2.19.0 (windows)]
Easier one first. Repo is set up to include code fr
On Fri, Aug 24, 2018 at 11:20 AM Ævar Arnfjörð Bjarmason
wrote:
> The test guarded by PERLJSON added in 75459410ed ("json_writer: new
> routines to create JSON data", 2018-07-13) assumed that a JSON boolean
> value like "true" or "false" would be represented as "1" or "0" in
> Perl.
>
> This behav
The test guarded by PERLJSON added in 75459410ed ("json_writer: new
routines to create JSON data", 2018-07-13) assumed that a JSON boolean
value like "true" or "false" would be represented as "1" or "0" in
Perl.
This behavior can't be relied upon, e.g. with JSON.pm 2.50 and
JSON::PP A JSON::PP::Bo
The test guarded by PERLJSON added in 75459410ed ("json_writer: new
routines to create JSON data", 2018-07-13) assumed that a JSON boolean
value like "true" or "false" would be represented as "1" or "0" in
Perl.
This behavior can't be relied upon, e.g. with JSON.pm 2.50 and
JSON::PP A JSON::PP::Bo
On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote:
> > if (used_deprecated_reflog_option) {
> > - warning("the '-l' alias for '--create-reflog' is
> > deprecated;");
> > - warning("it will be removed in a future version of Git");
> > + if
On Fri, May 25, 2018 at 4:40 AM, Jeff King wrote:
> -- >8 --
> Subject: [PATCH] branch: customize "-l" warning in list mode
>
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in that command does (and the "-l" become
Jeff King writes:
> So I think you're proposing:
>
> - step 0: warn about "-l" when it actually gets used, and otherwise
> continue ignoring
>
> - step 1: turn "-l" into "--list"
>
> - step 2: there is no step 2
>
> ... So I
> guess the right rule is to warn when we are not in list-mode
On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote:
Jeff King writes:
Right, what I meant by "gentler" is that we continue to perform the same
behavior as the old version, alongside the warning. It's arguable here
because running "git branch -l" has _always_ been wrong. It's just wrong
in
On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, what I meant by "gentler" is that we continue to perform the same
> > behavior as the old version, alongside the warning. It's arguable here
> > because running "git branch -l" has _always_ been wron
t;
> > Oh, and did we want to mark these for translation on the step 0 branch?
> > Obviously that would impact this hunk.
>
> I was hoping that we can settle the "multi-line message translation
> that can potentially result in different number of lines" issue
> before we have to mark the above for translation ;-)
Yeah, right after saying that I realized it would create horrible
translation-lego. I agree we should punt for now.
-Peff
Jeff King writes:
> Right, what I meant by "gentler" is that we continue to perform the same
> behavior as the old version, alongside the warning. It's arguable here
> because running "git branch -l" has _always_ been wrong. It's just wrong
> in a way that happens to do what the user wants. ;)
>
t;);
>> -warning("it will be removed in a future version of
>> Git");
>> -}
>> -}
>> -
>
> Oh, and did we want to mark these for translation on the step 0 branch?
> Obviously that would impact this hunk.
I was hoping that we can settle the "multi-line message translation
that can potentially result in different number of lines" issue
before we have to mark the above for translation ;-)
On Tue, May 29, 2018 at 05:20:29PM -0400, Jeff King wrote:
> Thanks. There's one bit missing here, because it did not cause a textual
> conflict during the rebase (but it's now dead code). Patch below (to be
> squashed to the tip of jk/branch-l-1-removal).
> [...]
> - if (used_deprecated_reflo
On Sat, May 26, 2018 at 11:32:35AM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Yup, thanks for being extra explicit. I do imagine there are quite
> > a few of us who would be puzzled without this update (but with the
> > previous one to unhide it from behind the pager).
>
> Wit
On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote:
> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme" from your suggested patch would only affect "branch -l".
> >
> > Stil
On Friday 25 May 2018 08:10 AM, Jeff King wrote:
> Subject: [PATCH] branch: customize "-l" warning in list mode
>
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in that command does (and the "-l" becomes a
> silent
On Friday 25 May 2018 01:01 AM, Jeff King wrote:
> On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote:
>
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extreme" from your suggested patch woul
Jeff King writes:
>> By the way, this is one of these times when I feel that we should
>> have a better multi-line message support in die/error/warning/info
>> functions. Ideally, I should be able to write
>>
>> warning(_("the '-l' option is an alias for '--create-reflog' and\n"
>>
Junio C Hamano writes:
> With these two patches queued on top of jk/branch-l-0-deprecation,
> the follow-up patches jk/branch-l-1-removal that makes 'branch -l'
> to fail and then jk/branch-l-2-reincarnation that makes 'branch -l'
> a synonym to 'branch --list' needs rebasing. Both are trivial a
Junio C Hamano writes:
> Yup, thanks for being extra explicit. I do imagine there are quite
> a few of us who would be puzzled without this update (but with the
> previous one to unhide it from behind the pager).
With these two patches queued on top of jk/branch-l-0-deprecation,
the follow-up p
On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> - warning("the '-l' alias for '--create-reflog' is deprecated;");
> >> - warning("it will be removed in a future version of Git");
> >> + if (list) {
> >> +
Junio C Hamano writes:
>> -warning("the '-l' alias for '--create-reflog' is deprecated;");
>> -warning("it will be removed in a future version of Git");
>> +if (list) {
>> +warning("the '-l' option is an alias for
>> '--create-reflog' and")
Jeff King writes:
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in that command does (and the "-l" becomes a
> silent noop).
>
> Since afc968e579 (branch: deprecate "-l" option, 2018-03-26)
> we've warned that "-
On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme" from your suggested patch would only affect "bra
Jeff King writes:
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extreme" from your suggested patch would only affect "branch -l".
> Still, I think I prefer the gentler version that we get by keep
I think I prefer the gentler version that we get by keeping it as
a warning even in the latter case.
Here's the patch. It goes on top of jk/branch-l-0-deprecation (and will
naturally conflict with the removal branch, but the resolution should be
obvious).
-- >8 --
Subject: [PATCH] branch: iss
On Thu, May 10, 2018 at 05:42:52PM +, Derrick Stolee wrote:
> We use the lockfile API to avoid multiple Git processes from writing to
> the commit-graph file in the .git/objects/info directory. In some cases,
> this directory may not exist, so we check for its existence.
> [...]
This version
1 - 100 of 518 matches
Mail list logo
