remove a few orphaned comments
This commit is contained in:
Joey Hess
parent
f15675e109
commit
9169fc86f3
15 changed files with 0 additions and 248 deletions
|
|
@ -1,9 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://edheil.wordpress.com/"
|
||||
ip="99.54.57.201"
|
||||
subject="comment 1"
|
||||
date="2013-01-06T05:23:25Z"
|
||||
content="""
|
||||
Fair enough. :) Power user solution to power user whine!
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmcYryijvlF8bJvM_eZNSrUPEkMlxMDGTQ"
|
||||
nickname="Thiago"
|
||||
subject="Also relevant for machines behind pagekite.net"
|
||||
date="2013-02-19T20:00:30Z"
|
||||
content="""
|
||||
I'm running into this problem too. I need to use an ssh alias because machines behind pagekite have to be accessed using an HTTP connect proxy, which is done with the ProxyCommand option in the ssh config file. I'm mentioning this because IMHO it's much less of a power user problem than you seem to think.
|
||||
|
||||
In fact, I'd argue that a power user is more likely to have access to a machine with a fixed IP address or FQDN. It is people which fall more into the \"mere mortal\" side of the spectrum that need to resort to ssh aliases to access machines behind NAT or dynamic IPs. :-)
|
||||
|
||||
All that to say that it would be nice if this usecase was explicitly supported in the UI (maybe a checkbox saying \"this is an ssh alias\", or a textfield to enter a proxy through which the connection has to be routed).
|
||||
"""]]
|
||||
|
|
@ -1,79 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
|
||||
nickname="Jim"
|
||||
subject="Case sensitivity"
|
||||
date="2011-11-22T18:51:03Z"
|
||||
content="""
|
||||
I agree, it's weird, but that's what I'm seeing:
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
if [ $UID != 0 ] ; then echo \"need root\" ; exit 1 ; fi
|
||||
|
||||
set -x
|
||||
|
||||
# make image
|
||||
cd /tmp
|
||||
dd if=/dev/zero of=diskimage bs=1M count=40
|
||||
DEV=$(losetup --find --show diskimage)
|
||||
|
||||
# make FAT32 fs
|
||||
mkfs.vfat -F 32 $DEV
|
||||
|
||||
# mount it
|
||||
mkdir annex
|
||||
mount -o shortname=mixed,utf8=1 $DEV annex
|
||||
|
||||
# show bug
|
||||
(
|
||||
cd annex
|
||||
mkdir zP
|
||||
mkdir Zp
|
||||
ls Zp
|
||||
ls
|
||||
touch zP
|
||||
touch Zp
|
||||
)
|
||||
|
||||
# cleanup
|
||||
umount annex
|
||||
rm -r annex
|
||||
losetup -d $DEV
|
||||
rm diskimage
|
||||
|
||||
# info
|
||||
uname -a
|
||||
|
||||
Output:
|
||||
|
||||
+ cd /tmp
|
||||
+ dd if=/dev/zero of=diskimage bs=1M count=40
|
||||
40+0 records in
|
||||
40+0 records out
|
||||
41943040 bytes (42 MB) copied, 0.0847729 s, 495 MB/s
|
||||
++ losetup --find --show diskimage
|
||||
+ DEV=/dev/loop0
|
||||
+ mkfs.vfat -F 32 /dev/loop0
|
||||
mkfs.vfat 3.0.9 (31 Jan 2010)
|
||||
Loop device does not match a floppy size, using default hd params
|
||||
+ mkdir annex
|
||||
+ mount -o shortname=mixed,utf8=1 /dev/loop0 annex
|
||||
+ cd annex
|
||||
+ mkdir zP
|
||||
+ mkdir Zp
|
||||
mkdir: cannot create directory `Zp': File exists
|
||||
+ ls Zp
|
||||
ls: cannot access Zp: No such file or directory
|
||||
+ ls
|
||||
zP
|
||||
+ touch zP
|
||||
+ touch Zp
|
||||
touch: cannot touch `Zp': File exists
|
||||
+ umount annex
|
||||
+ rm -r annex
|
||||
+ losetup -d /dev/loop0
|
||||
+ rm diskimage
|
||||
+ uname -a
|
||||
Linux pilot 3.0.3+ #1 SMP Mon Aug 29 15:21:18 EDT 2011 x86_64 GNU/Linux
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 2"
|
||||
date="2011-11-22T19:56:55Z"
|
||||
content="""
|
||||
All right, I see the same thing with linux 3.1.0. It seems this behavior has changed since linux 3.0.0. Mounting with shortname=lower avoids the problem.
|
||||
|
||||
I feel a good case could be made that this new behavior is a linux bug. Your example with touch particularly shows how weird it is.
|
||||
|
||||
<pre>
|
||||
$ touch Foo
|
||||
$ echo hi > foo
|
||||
sh: cannot create foo: File exists
|
||||
$ rm foo
|
||||
rm: cannot remove `foo': No such file or directory
|
||||
</pre>
|
||||
"""]]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
|
||||
nickname="Jim"
|
||||
subject="comment 3"
|
||||
date="2011-11-22T20:35:01Z"
|
||||
content="""
|
||||
I see the same results (\"`touch: cannot touch 'Zp': File exists`\") on these Debian systems:
|
||||
|
||||
Linux pilot 3.0.3+ #1 SMP Mon Aug 29 15:21:18 EDT 2011 x86_64 GNU/Linux
|
||||
Linux neurosis 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux
|
||||
Linux bucket 2.6.39-2-amd64 #1 SMP Tue Jul 5 02:51:22 UTC 2011 x86_64 GNU/Linux
|
||||
Linux psychosis 2.6.37-trunk-amd64 #1 SMP Thu Jan 6 14:13:28 UTC 2011 x86_64 GNU/Linux
|
||||
Linux bacon 2.6.32-5-amd64 #1 SMP Thu Aug 12 13:01:50 UTC 2010 x86_64 GNU/Linux
|
||||
|
||||
It does NOT happen on this Ubuntu system:
|
||||
|
||||
Linux esensor 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
|
||||
|
||||
So really it seems like only the Ubuntu kernel is the outlier here? Maybe it has something to do with charsets or something; I think FAT is a mess in that regard and even long versus short filenames can behave differently.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 4"
|
||||
date="2011-11-22T20:59:55Z"
|
||||
content="""
|
||||
Your ubuntu system has 3.0.0 which as noted does not have the problem.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 5"
|
||||
date="2011-11-22T21:01:14Z"
|
||||
content="""
|
||||
I am surprised if it happens on 2.6.x though. Debian 3.0.0 seemed to not have the problem but perhaps my test was bad.
|
||||
"""]]
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.154"
|
||||
subject="comment 1"
|
||||
date="2014-03-15T15:53:17Z"
|
||||
content="""
|
||||
This is a bit tricky because I'm not sure which repository the map is failing on. Probably the one that comes after /media/archive/annex in the `git remote list` output.
|
||||
|
||||
If you go to each of the remotes and run `git config --null --list`, does it exit nonzero in any of them?
|
||||
"""]]
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawkBEmz5XoJVzN0u-0nOtpn7BBBDHsiLmxY"
|
||||
nickname="Eric"
|
||||
subject="comment 2"
|
||||
date="2014-03-15T16:17:18Z"
|
||||
content="""
|
||||
actually i removed .../xubuntu/... from the initial bug report, here is the text scraped directly from xterm.
|
||||
|
||||
|
||||
xubuntu@tab:/media/xubuntu/archive/annex$ git annex map --debug
|
||||
map /media/xubuntu/archive/annex ok
|
||||
[2014-03-15 11:10:17 CDT] read: git [\"config\",\"--null\",\"--list\"]
|
||||
[2014-03-15 11:10:17 CDT] read: git [\"config\",\"--null\",\"--list\"]
|
||||
[2014-03-15 11:10:17 CDT] read: git [\"config\",\"--null\",\"--list\"]
|
||||
|
||||
git-annex: user error (git [\"config\",\"--null\",\"--list\"] exited 126)
|
||||
failed
|
||||
git-annex: map: 1 failed
|
||||
xubuntu@tab:/media/xubuntu/archive/annex$ git remote
|
||||
archive-backup
|
||||
bkup06-a81d-1000
|
||||
bkup08-da84-1000
|
||||
bkup19-0064
|
||||
master
|
||||
master-backup
|
||||
...
|
||||
no obvious errors on non-zero return codes from running `git config --null --list` on all remotes
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.154"
|
||||
subject="comment 3"
|
||||
date="2014-03-15T21:41:13Z"
|
||||
content="""
|
||||
Since this is map, it could be one of the remotes of /media/xubuntu/archive/annex, or one of the remotes of one of the remotes, etc. Pretty sure it's a local repository it's choking on, and not a ssh remote though.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawkBEmz5XoJVzN0u-0nOtpn7BBBDHsiLmxY"
|
||||
nickname="Eric"
|
||||
subject="comment 4"
|
||||
date="2014-03-16T04:52:19Z"
|
||||
content="""
|
||||
i don't have any ssh remotes yet. these are all local. so if it is one of the remotes, then what do i do to get it un-choked?
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.154"
|
||||
subject="comment 6"
|
||||
date="2014-03-17T19:30:37Z"
|
||||
content="""
|
||||
I was able to easily reproduce this kind of failure by making a git repository have a remote that did not exist.
|
||||
"""]]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
|
||||
nickname="Justin"
|
||||
subject="comment 1"
|
||||
date="2012-12-23T17:40:13Z"
|
||||
content="""
|
||||
Using a plain tcp connection would be simpler than HTTP, the sending side would just need to tell the receiver to listen on a port and write any data received to a file(or the reverse). Basically what you can do with netcat.
|
||||
|
||||
I had a similar problem, but I found that using arcfour was fast enough:
|
||||
|
||||
.ssh/config:
|
||||
|
||||
Host slow
|
||||
Ciphers arcfour
|
||||
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="4.152.246.126"
|
||||
subject="comment 2"
|
||||
date="2012-12-23T19:26:23Z"
|
||||
content="""
|
||||
You can configure multiple git remotes that access the same repository using different transports, and use an un-encrypted transport when necessary for speed. I sometimes use an NFS mount for this.
|
||||
"""]]
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="4.152.246.126"
|
||||
subject="comment 3"
|
||||
date="2012-12-23T19:29:27Z"
|
||||
content="""
|
||||
BTW, I have yet to find any Haskell http library that can upload files without buffering their full contents in memory. (Not, not even http-conduit.) If someone fixes that, git-annex's S3 and WebDAV support will get a lot better and I could consider adding something like what's suggested.
|
||||
"""]]
|
||||
Loading…
Reference in a new issue