(+cc: bmwill@, who is working on protocol v2)
Hi,
Dorian Taylor wrote:
> On Feb 21, 2018, at 2:15 PM, Jeff King wrote:
>> Thanks, I agree the document is buggy. Do you want to submit a patch?
>
> Will this do?
Thanks for writing it.
Do you mind if we forge your sign-off? (See
+git-for-windows
Hi,
Raining Chain wrote:
> On Windows 10, git version 2.16.2.windows.1, running the command
>
> git status
>
> will trigger a file change event to file C:\myPath\.git "Attributes changed."
>
> This causes problems when using scripts that detect file changes such
> as tsc -w
On Windows 10, git version 2.16.2.windows.1, running the command
git status
will trigger a file change event to file C:\myPath\.git "Attributes changed."
This causes problems when using scripts that detect file changes such
as tsc -w (Typescript compiler) and using softwares that regularly
When using git log, boundary commits (ie, those commits added by
specifying --boundary) do not respect the order (e.g., --date-order,
--topo-order). Consider the following commit history, where number
indicates the order of the commit timestamps:
0125 <--A
\ \
TYPO IN EXPECTED OUTPUT.
To avoid inevitable confusion, creating new thread "Bug: git log:
boundary commits do not respect order (e.g. date-order, topo-order)
2".
DON'T REPLY TO THIS MESSAGE. Instead reply to the new message
On Wed, Feb 21, 2018 at 6:28 PM, Josh Tepper <j...
> On Feb 21, 2018, at 2:15 PM, Jeff King wrote:
>
> Thanks, I agree the document is buggy. Do you want to submit a patch?
Will this do?
Note I am not sure what the story is behind that `version 1` element, whether
it's supposed to go before or after the null packet or if there
When using git log, boundary commits (ie, those commits added by
specifying --boundary) do not respect the order (e.g., --date-order,
--topo-order). Consider the following commit history, where number
indicates the order of the commit timestamps:
0125 <--A
\ \
On Wed, Feb 21, 2018 at 10:29:35AM -0800, Dorian Taylor wrote:
> I didn’t get an insight until I ran with GIT_TRACE_PACKET=true on a
> known-good remote (i.e. GitHub), that the null packet-line `` has to
> follow the service line. This is not reflected in the example here:
>
>
Hello list,
I had been banging my head all morning trying to figure out why I couldn’t get
a little HTTP implementation to clone/push via the smart protocol (just
wrapping git-receive-pack/git-upload-pack). I kept getting the following
(likely familiar to some) error:
```
fatal: Could not
dn't help. Best would be to prepare a minimal example of shell
> commands to reproduce the behavior you're trying to illustrate.)
Good point. Again, my bad - very long day debugging. I wanted to show where I
was in the directory so I sacrificed brevity for completeness and noise. My
apologies.
So, no bug, just a buggy user.
Cheers,
Randall
On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker
wrote:
> I’m a bit confused about this, as I thought I understood worktrees :(.
>
> /home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt
> /home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v
> Removing
Im a bit confused about this, as I thought I understood worktrees :(.
/home/randall/nsgit/test/test dir.mytest/dest git worktree list
/home/randall/nsgit/test/test dir.mytest/dest: git worktree list
/home/randall/nsgit/test/test dir.mytest/dest 4e901ca [master]
/home/randall/nsgit/test/test
System: Ubuntu 17.10 Gnome
When opening git-gui from a directory which is a repository, minimize
and maximize buttons are showing and functional in git-gui.
However, if I open git-gui in a non-repo directory, git-gui opens a
dialog where I can "Create New Repository", "Clone Existing
This series fixes a small quoting problem in 511155db51 (remote-curl:
allow push options, 2017-03-22). The interesting one is the second
patch.
[1/2]: t5545: factor out http repository setup
[2/2]: remote-curl: unquote incoming push-options
remote-curl.c | 11 ++-
Jeff King writes:
> Here's the patch to make "show -B --stat" work. I'll give some more
> thought to whether this is a good idea and prepare a series.
>
> One downside is that in the common case it causes us to look up each
> object twice (once to get its size, and then again to
The title says it all.
If I run `git init --template=~/path/to/my/template` I get the following
message:
warning: templates not found ~/path/to/my/template
But, if I run:
$ env GIT_TEMPLATE_DIR=~/path/to/my/template git init
I don't get a warning and the template is used just
generate diffstat" message a bit too.
One reason the message is so vague is that we don't actually have any
kind of error code. Though really the only reason for xdiff to fail is
due to file size. So we could perhaps offer some advice there. But if we
do all the things I suggested above, then
On Thu, Feb 8, 2018 at 3:45 AM, Jeff King wrote:
> On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote:
>
>> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
>> > Hello,
>> >
>> > I am using git frequently and usually it is running great.
>> >
>> > I
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Will queue with the above typofix, together with the other one. I
>>> am not sure if we want to say "Before 2.17", though.
>>
>> I'm just keeping in mind the user who later on upgrades git
Ævar Arnfjörð Bjarmason writes:
>> Will queue with the above typofix, together with the other one. I
>> am not sure if we want to say "Before 2.17", though.
>
> I'm just keeping in mind the user who later on upgrades git from say
> 2.14 to 2.18 or something, and is able to
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:
>
>> +Before 2.17, the untracked cache had a bug where replacing a directory
>> +with a symlink to another directory could cause it to incorrectly show
>> +files tr
Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:
> +Before 2.17, the untracked cache had a bug where replacing a directory
> +with a symlink to another directory could cause it to incorrectly show
> +files tracked by git as untracked. See the "status: add a fai
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, and it's no
Hello,
Git versions tested: 2.13.6, 2.1.4
When passing-in a large context value for the --unified option for
git-diff, Git will produce an invalid-looking range information for
hunks.
For example, if running 'git diff --unified=10 HEAD^', the output will
include (this is just a run against my
On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote:
> Given that all references to this shell function seem to do
>
> sometree=$(toptree_for_commit $something)
>
> and then $sometree is used as if it were a tree object name, I can
> understand why the lack of
On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote:
> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
> > Hello,
> >
> > I am using git frequently and usually it is running great.
> >
> > I read to write to this eMail address regarding problems and possible bugs.
On Wed, Feb 07, 2018 at 09:25:42AM -0800, Elijah Newren wrote:
> > So other_head_refs knows that it's looking at the worktrees. And it
> > passes the alternate ref-store to refs_head_ref(), with "add_one_ref" as
> > the callback. But the knowledge that we're not talking about the real
> > "HEAD"
t it (which I see from your message
> that it also fails to do).
>
> I guess that's two more items on my todo list :)
Cool, if you're taking a look at those, I'll take a look at the other
one mentioned by Peff in this thread -- "make fsck pay attention to
other worktree HEADs"
On Wed, Feb 7, 2018 at 8:29 AM, Birger Skogeng Pedersen
wrote:
> Steps to reproduce (on Ubuntu 17.10):
> - Open git-gui in a repository with two or more unstaged, changed files
> - Select two or more files in the "Unstaged Changes"
> - Click CTRL+T to stage the files that you
On Wed, Feb 7, 2018 at 5:21 AM, Jeff King wrote:
> On Tue, Feb 06, 2018 at 04:00:32PM -0800, Elijah Newren wrote:
>
>> It took me hours to figure it out, after users ran out of ideas and
>> came and asked me for help. (Maybe if I was familiar with worktree,
>> and knew they had
Apologies if this is the wrong place to send a bug report for
Contributed software.
I've run into what seems like an issue/bug with git subtree.
I am trying to split a single directory of our repo into its own repo
using git subtree. I ran the the following command from our project
root:
git
ed in my earlier mail),
then you successfully confirmed that we fixed a bug, and that you expected
the buggy behavior.
> - with change SHA.
>
> It seems to be bug in recent version.
>
> Should I provide additional information?
Ciao,
Johannes
> On 02/06/2018 12:4
In git-gui, multiple files from the "Unstaged Changes" widget can be
selected. Once multiple files are selected, they can be staged by
clicking (toolbar) "Commit"->"Stage To Commit". All the files that
were selected then gets staged for the commit. The "Stage To Commit"
hotkey (CTRL+T) behaves
On Wed, Feb 07, 2018 at 08:21:57AM -0500, Jeff King wrote:
> The best PSA for this particular bug may be "try pruning the worktrees":
>
> $ git worktree prune -v
> Removing worktrees/foo: gitdir file points to non-existent location
>
> $ git prune; echo
On Wed, Feb 07, 2018 at 06:08:40PM +0700, Duy Nguyen wrote:
> > And/or ideas of what steps could cause corruption so I can send out a
> > PSA to help users avoid it?
>
> There is another thing we could do. One bad HEAD should not abort the
> entire operation (at least if it's not the current
nk
that materially changes anything. Until you run "git worktree prune",
that HEAD file is still there and still supposed to be valid.
> I suspect you mean that there was another previous bug that induced
> corruption, that this commit fixed that other bug, while also
> introduc
ing and move on, or don't warn at all and
let "git worktree prune" collect it (which I see from your message
that it also fails to do).
I guess that's two more items on my todo list :) Sorry for all the
trouble because of this bug of mine.
> If not, I'll try to dig more, but I thought I'd ask others familiar
> with this area.
--
Duy
ng directory that made use of a
now gc'ed commit. In the case I was able to dig into, we did not.
(There was a left-over .git/worktree/ that had a now gc'ed
commit, but no working directory that used it.)
I suspect you mean that there was another previous bug that induced
corruption, that this
On Tue, Feb 6, 2018 at 3:04 PM, Elijah Newren wrote:
>
> Does anyone have an idea what may have happened here or how to avoid it?
According to Peff this got fixed
https://public-inbox.org/git/20171020031630.44zvzh3d2vlhg...@sigill.intra.peff.net/
and but you've had a corrupted
the unused directory under .git/worktree (perhaps
because it thought something was using it?). The fetch bug didn't go
away until doing an 'rm -rf .git/worktree/3.0-release'.
I have no experience prior to today with git worktree, and the
developer in question doesn't remember how things got to th
Jeff King writes:
> I'm not entirely convinced it's worth all of this effort, but I think it
> would be _possible_ at least.
I thought that the original poster wants to have a knob that the
project can ask its participants to enable in their clones of the
repository that wars
I’m not git expert but, from a user point of view, the following would make
sense. When adding a file, git could check whether a different file is already
in the repository with the same name (case-insensitive check). Then simply
report that this may be a mistake and request to use ‘git add -f’
On Tue, Feb 06, 2018 at 02:24:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 3) Such hooks slow down pushes, especially on big repos, you can
> optimize things a bit (e.g. only look in the same directories), but
> pathologically you end up needing to compare the cross-product of
>
On Tue, Feb 06 2018, Filip Jorissen jotted:
> Hi all,
>
> Thank you for your quick responses. I was able to resolve the problem based
> on your feedback!
>
> Based on this experience, I would like to suggest that git is somehow able to
> avoid these problems by doing a case check itself rather
On Tue, Feb 6, 2018 at 8:09 PM, Filip Jorissen
wrote:
> Hi all,
>
> Thank you for your quick responses. I was able to resolve the problem based
> on your feedback!
>
> Based on this experience, I would like to suggest that git is somehow able to
> avoid these
Hi all,
Thank you for your quick responses. I was able to resolve the problem based on
your feedback!
Based on this experience, I would like to suggest that git is somehow able to
avoid these problems by doing a case check itself rather than relying on the
host OS for this?
Kind regards!
Hi,
On Mon, 5 Feb 2018, Bulat Musin wrote:
> Now there are 3 sequential commits, I want to squash them into 1:
>
> git rebase -i HEAD~2
>
> In editor I changed all "pick" to "squash", saved file, I got:
>
> error: cannot 'squash' without a previous commit
You cannot start with a squash. You
Hi.
To reproduce:
git init testrepo
cd testrepo
echo 1 >> file
git add file
git commit -m'1'
echo 2 >> file
git add file
git commit -m'2'
echo 3 >> file
git add file
git commit -m'3'
Now there are 3 sequential commits, I want to squash them into 1:
git rebase -i HEAD~2
In editor I
Stephen R Guglielmo writes:
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index cc033af73..dec085a23 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -475,7 +475,7 @@ squash_msg () {
>
>
On Mon, Feb 5, 2018 at 9:30 AM, Stephen R Guglielmo
wrote:
> On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
> wrote:
>> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C
On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
wrote:
> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
There
On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
> Hello,
>
> I am using git frequently and usually it is running great.
>
> I read to write to this eMail address regarding problems and possible bugs.
> I am using git version 2.16.1.windows.2 / 64 Bit and during commit the
Hello,
I am using git frequently and usually it is running great.
I read to write to this eMail address regarding problems and possible bugs.
I am using git version 2.16.1.windows.2 / 64 Bit and during commit the
following error message comes up:
e:\Internet>git commit -m 2018-01-27
fatal:
Stephen R Guglielmo writes:
> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>>
>> Sorry I can't help more.
>>
>> Good luck,
>>
>> Avery
>
> Thanks all for the discussion/replies.
>
> We use subtrees extensively in our environment right now.
On Tuesday 30 January 2018 05:32 AM, Andrew Ardill wrote:
> Hi Ilija,
>
> On 30 January 2018 at 10:21, Ilija Pecelj <pec...@gmail.com> wrote:
>> Though it might not be considered a bug 'per se' it is definitely wired.
>> Namely, when you type 'yes' word and hit en
On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>> There has not been feedback for a while on this thread.
>>> I think that is because subtrees
On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>> There has not been feedback for a while on this thread.
>> I think that is because subtrees are not in anyone's hot
>> interest area currently.
>>
>> This is definitely the
Stefan Beller writes:
> There has not been feedback for a while on this thread.
> I think that is because subtrees are not in anyone's hot
> interest area currently.
>
> This is definitely the right place to submit bugs.
> Looking through "git log --format="%ae %s" -S
On Tue, Jan 30, 2018 at 11:15 AM, Stephen R Guglielmo
<srguglie...@gmail.com> wrote:
> Hi, just following up on this bug report. I have not heard back. Is
> there additional information that's needed? Is there a better place to
> file bug reports?
>
> Additionally, I have co
Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?
Additionally, I have confirmed that this bug still exists with git
version 2.16.1.
Thanks
On Thu, Jan 18, 2018 at 11:19 AM, Stephen R
Hi Ilija,
On 30 January 2018 at 10:21, Ilija Pecelj <pec...@gmail.com> wrote:
> Though it might not be considered a bug 'per se' it is definitely wired.
> Namely, when you type 'yes' word and hit enter in git bash for widnows, the
> process enters infinite loop and just prints 'y
Though it might not be considered a bug 'per se' it is definitely wired.
Namely, when you type 'yes' word and hit enter in git bash for widnows,
the process enters infinite loop and just prints 'y' letter in new line.
It can be interrupted with CTRL+C. I'm not sure if it has any other
he
> end of this email. Git checkout does not work to remove the file changes.
> This behavior seems to be reproducible across multiple computers. Is this a
> bug? How can I fix the repository?
>
> Changes not staged for commit:
> (use "git add ..." to update what will
On Sat, Jan 27, 2018 at 08:59:50PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Jan 27 2018, Filip Jorissen jotted:
>
> > I think our git repository is bugged. The reason why I say this is the
> > following. When cloning the repository, the newly cloned repository
> > immediately has file
On Sat, Jan 27 2018, Filip Jorissen jotted:
> I think our git repository is bugged. The reason why I say this is the
> following. When cloning the repository, the newly cloned repository
> immediately has file changes[...].
If you run this:
git ls-files | tr '[:upper:]' '[:lower:]' | sort
changes. This behavior
seems to be reproducible across multiple computers. Is this a bug? How can I
fix the repository?
Thanks in advance for the support!
Filip
MacBook-Pro-van-Filip:git filip$ git clone g...@github.com:open-ideas/IDEAS.git
Cloning into 'IDEAS'...
remote: Counting objects: 48419
On Fri, Jan 26, 2018 at 2:50 PM, Kaartic Sivaraam
<kaartic.sivar...@gmail.com> wrote:
> This might seem to be a bug as the comment in "git-rebase-todo" says,
>
> However, if you remove everything, the rebase will be aborted.
>
> But "man git rebase" cl
problem is, HEAD is moved away anyway (to origin/master
I
> think)
For me it left HEAD at @~3. Reading the synopsis of `man git rebase` I
could guess that the corresponding abstract form would be,
$ git rebase -i
> even if rebase is supposed to abort the operation and leave
On Thu, Jan 25, 2018 at 12:16:33PM -0500, Robert Leach wrote:
> But perhaps access to KA from a remote ssh session is restricted for
> security reasons? I'm just curious I suppose. Should/can this work?
It's definitely not a restriction from the osxkeychain credential
helper. I believe that
Hi,
I wanted to submit an issue regarding the credential-osxkeychain interface
functionality. I don't know whether it's a bug or a feature request. Maybe
it's even impossible to address? - I don't know, but here's my issue. Let me
know if fixing/implementing this is a bad idea or if it's
rebase scripts are too much for me, so I'll play the user reporting
bugs this time :)
Instead of doing
$ git rebase -i --onto origin/master @~3
I sometimes accidentally type
$ git rebase -i origin/master @~3
("rebase -i" is actually an alias, which is why I never forget to type -i)
Yeah it seems like this bug. Thank you for sharing this with me.
--
Sincerely,
Dimitriy Ryazantcev
> Could this be the same one as reported as Git for Windows issue
> #1437[1] ("`git status` reports (non-existent) modifications after
> `git stash push`", 2018-01-20), fixed
On Tue, Jan 23, 2018 at 3:52 AM, Edward Thomson
wrote:
> Indeed, when I added merge to libgit2, we put the higher-level conflict
> analysis into application code because there was not much interest in it
> at the time. I've been meaning to add this to `git_status` in
Hi Dimitriy,
On 24/01/2018 13:19, Dimitriy wrote:
>
> Looks like regression in 2.16.
> Worked fine before update.
> Seems like git stash is not always working.
> Any ideas?
Could this be the same one as reported as Git for Windows issue
#1437[1] ("`git status` reports (non-existent)
Thanks, Ed. I think I'll pursue the libgit2 route; sounds promising.
>> But the alternative appears to be punting entirely, as libgit2 does,
>> and merely providing something akin to three index entries.
>
> Indeed, when I added merge to libgit2, we put the higher-level conflict
> analysis into
Looks like regression in 2.16.
Worked fine before update.
Seems like git stash is not always working.
Any ideas?
$ git --version
git version 2.16.0.windows.2
$ git config pull.rebase
true
$ git config rebase.autoStash
true
$ git status
On branch develop
Your branch is behind 'origin/develop'
From: Ævar Arnfjörð Bjarmason <ava...@gmail.com>
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others wi
he "sleep 1"
after the "checkout master" are needed to reproduce this, presumably
due to the untracked cache tracking on the basis of cached whole
seconds from stat(2).
When git gets into this state, a workaround to fix it is to issue a
one-off:
git -c core.untrackedCa
On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder
wrote:
> Looking over your list above, at a minimum, libgit2 might not have a
> particularly good way to represent submodule/file or
> submodule/directory conflicts, because is-a-submodule is defined
> external to a
>> I'm experimenting with some new porcelain for interactive rebase. One
>> goal is to leave the work tree untouched for most operations. It looks
>> to me like 'git merge-tree' may be the right plumbing command for
>> doing the merge part of the pick work of the todo list, one commit at
>> a
On Sat, Jan 20, 2018 at 7:00 PM, Josh Bleecher Snyder
wrote:
> Hi, all.
>
> I'm experimenting with some new porcelain for interactive rebase. One
> goal is to leave the work tree untouched for most operations. It looks
> to me like 'git merge-tree' may be the right plumbing
On Sun, Jan 21 2018, Josh Bleecher Snyder jotted:
> 3. Feature suggestion
>
> There's no direct indication of whether any given file's merge
> succeeded. Currently I sniff for merge conflicts by looking for
> "+<<< .our", which feels like an ugly kludge. Could we provide an
> explicit
. If I'm wrong about this, I'd love pointers; what follows may
still be interesting anyway.
I've encountered some bumps with 'git merge-tree'. A bug report and
some feature requests follow. Apologies for the long email.
1. Bug
When a binary file containing NUL is added on only one side, the
resulting
Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?
Thanks
On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
<srguglie...@gmail.com> wrote:
> Hi all,
>
> I've noticed an
On Tue, Jan 16, 2018 at 12:48:32PM +0100, Andreas Schwab wrote:
> On Jan 15 2018, Michael Giuffrida wrote:
>
> > It doesn't seem like a useful feature -- you wouldn't expect `git
> > fetch --prune` to remove your local branches that you were developing
> > on, right?
>
>
On Jan 15 2018, Michael Giuffrida wrote:
> It doesn't seem like a useful feature -- you wouldn't expect `git
> fetch --prune` to remove your local branches that you were developing
> on, right?
Don't mix local and remote refs. There is a reason why remote tracking
On Tue, Jan 16 2018, Michael Giuffrida jotted:
> Just to confirm, you're talking about the behavior of removing *all*
> tags that aren't found on the remote? (Not just tags that used to be
> on some remote, but have since been removed from that remote.) So,
> with your proposed workflow, you
, which
> > clearly does not happen in this case. On the platform, if the perl
> > script is via stdin, 162 or 169 are returned. If via file (perl
> > file.pl), 255 comes back. The port has issues. I have an opened a bug
> > report with the platform developers. Usua
in, 162 or 169 are returned. If via file (perl
> file.pl), 255 comes back. The port has issues. I have an opened a bug
> report with the platform developers. Usual non-Open Source timeframes
> to fix apply. ☹
I believe the standard behavior for Perl with die is the following:
exit $!
Just to confirm, you're talking about the behavior of removing *all*
tags that aren't found on the remote? (Not just tags that used to be
on some remote, but have since been removed from that remote.) So,
with your proposed workflow, you would never create your own tags
locally, without pushing
On Mon, Jan 15 2018, Michael Giuffrida jotted:
> `git remote prune ` should "delete all stale remote-tracking
> branches under ". I was surprised to discover, after some
> troubleshooting, that it also deletes *all* local tags that don't
> exist on the remote, if the following refspec is
`git remote prune ` should "delete all stale remote-tracking
branches under ". I was surprised to discover, after some
troubleshooting, that it also deletes *all* local tags that don't
exist on the remote, if the following refspec is included in the
remote's fetch config:
funky would be
> short-sighted. [I'm saying all this without knowing how perl specifies 'die'
> beyond the paragraph you cited. Perhaps there's more about 'die' that
> justifies exit code 162.] I'd say that the perl port is broken.
I agree that 162 is wrong. Its interpretation is 128+signal,
Am 15.01.2018 um 03:37 schrieb Randall S. Becker:
On January 14, 2018 4:33 PM, I wrote:
The exotic error code coming back from perl is 162. I can muck with it, if
there was a value more useful to git.
* 553 } else if (WIFEXITED(status)) {
* 554 code =
On January 14, 2018 4:33 PM, I wrote:
> On January 14, 2018 1:41 PM Johannes Sixt wrote:
> > Sent: > > Am 14.01.2018 um 17:50 schrieb Randall S. Becker:
> > > Follow-up: This looks like the completion code from perl on NonStop
> > > is not the same as expected by git in the case of failures. I
> -Original Message-
> From: Johannes Sixt [mailto:j...@kdbg.org]
> Sent: On January 14, 2018 1:41 PM wrote:
> Am 14.01.2018 um 17:50 schrieb Randall S. Becker:
> > Follow-up: This looks like the completion code from perl on NonStop is
> > not the same as expected by git in the case of
Am 14.01.2018 um 17:50 schrieb Randall S. Becker:
Follow-up: This looks like the completion code from perl on NonStop is not
the same as expected by git in the case of failures. I need to debug this to
get more details to the team. We have had completion issues before relating
to interpretation
On January 13, 2018 3:17 PM, I wrote:
> On January 13, 2018 2:31 PM, I wrote:
> > On January 13, 2018 1:08 PM, I wrote:
> > > Heres where things are. This is probably the best git release so
> > > far
> > (ever).
> > > After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new.
> > > Many
On January 13, 2018 2:31 PM, I wrote:
> On January 13, 2018 1:08 PM, I wrote:
> > Heres where things are. This is probably the best git release so far
> (ever).
> > After applying a4cdf02, I had 6 total breakages. 3 existing, 3 new.
> > Many reduced. The test took about 24 hours to run on
On January 12, 2018 9:39 AM, Jeff King wrote:
> On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote:
>
> > > executed because the test_commit fails with a non-zero git commit
> > > completion code. There is no rn (actual r n 252 252 252 252) in
> > > the objects directory - even
601 - 700 of 4422 matches
Mail list logo