gitk used to work fine until recently, when it started showing an error like:
can't read "arcnos()": no such element in array
and stopped showing the diffs etc. normally.
This happened with gitk-1:2.25.1-1ubuntu3.2 on Ubuntu 20.04.
Before this happened, I've been doing several git rebase and git reset --hard in my repo, which also has some git replace set up, if that could be important for the problem. (Although the history that I rebased doesn't intersect with the graft point.)
I've run git fsck, and it shows some dangling objects of different types. (I believe that a dangling object might cause some problems for gitk when it is trying to determine which objects like refs and tags refer to the shown commits...)
$ git fsck --name-objects
Checking object directories: 100% (256/256), done.
error in tag b2e1ebf3230672ae96d6c1c8f19cb023c8193f89: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 56faa4371fc7a58f55c2700f652c1ba6384f3ffa: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 221697dd45dfa25596feace71ab42d66aab67ff3: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 033c847da41536d2acc74589c4a8494269d963f9: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 1d048a4e4f1d303935db15e84ebd51951a4a03c4: missingSpaceBeforeDate: invalid author/committer line - missing space before date
Checking objects: 100% (143557/143557), done.
dangling blob 9f15c893db30e315f0688616faf4c57cac8d1dba
dangling blob d534a8fb5af2b7e2779a002828dd136078a35a4d
dangling blob e55478377eb2eb36fb782afa2a1614eac717a39b
dangling blob 21569023cc87b564c62e9dae2dc11abd7ed5ba49
dangling blob d35658eb27a2299b9f3f4ee5a91b450797f63bc5
dangling blob ac81c820e66afb3214d6dd934c88d1b02fbced5d
dangling blob ebbaa0d018d951882a6c083fa8c964fc912862d5
dangling blob ebc7e034b382ed525801eeac6d60fe0de08d0873
dangling blob 8bcca8b98f7d29a26b7e31db971617173e1b21a0
dangling blob 10e980a83644dab2ece20244837698ee50b6f823
dangling tag 61eb48fd6c81c40b1b29232b589f92e41734d3f4
dangling blob c913716dbc6651b87328289aab25340e0aadb8f3
dangling blob a414f19d695fbf64af81797a02a78d89f5537a6c
dangling blob 972539908d2b5f352a17ffff1870c89f870b5fe6
dangling commit 0f6b71242e4d49b3c47c9372eec400e38f480824
dangling tag e5ad513bb6f509f072fdf2a65acb3d1724d37d20
dangling blob 7ebfb1f1286c7e89647bb89cec2f600041474c44
dangling blob 4ce2f109be2c5de12c5d902b029c845b401ab813
dangling commit c9e3398b162a9a98f1c250ebc26974e961369192
dangling blob 0c23ba96d1be5f3fcac3c6d5b8977c6a07e19a89
dangling blob ac3cca70f44a0948be2c52024acda86789943320
dangling blob 434f9aa6b055bbb0069a2ae3bfa48c7a23f06794
dangling blob 9e567a4cb4fd493eaa163b88acec4873a3a58969
dangling blob 435f6a4b4456d2ec9b18155a7a348e4e2b6dbeae
dangling blob 4379ea6c75fdcca2eb6bd9858e01fd903f98a278
dangling blob e7873a34e1bf4a5ea0de7255d9b364081b3fa48d
dangling blob 8d8e6af8cbb360e5a33e36bcf48070e245d19490
dangling blob 6fa6f2cf2145f1108be5fc89c3b3c7e0494c82bb
dangling blob 19dafa14577dc7f15c25dd2e07de1fc861be77f3
dangling blob 7ae03af12390e4bb88c26d8c2a3bbd8037937f2f
dangling blob 9fe1aa411884fbbf33a456b9103e30fa819e316d
dangling blob 8ffd7a55ded446764f2bf2b8341bd5947cda8583
dangling blob 13008bf6146adf5d20ce63e62559c2db9c5ba122
dangling commit 3d2c5b7b3a09f3d21c5022e6e1491b9e10261b39
dangling blob 924463b9a67149fbf08bfe217c20a10b0ac69dbe
dangling commit 665733b438e268f691931647dfe1f418df16a72f
dangling blob 496f4b1d561962fa290f643bb27dba587bb9af55
dangling blob daa1e37be4d5ee34eac9d656c4da94f27a03a566
dangling blob 2ab37b0cfd90b4d3219d730162eb9b5cab4b24c2
dangling blob 7ccaebe839839a6024a33390509b7c8683714404
dangling blob 87d5a37c09593fe5633ff5228cd74af0f76f3581
dangling blob 681ab4995e851cb18cc6783db72e3856554b16ca
dangling blob d9748ca489073ebd1918a2da9fddcbbac8873611
dangling blob e980a417dc952b95c13adafdc7b06c1c8f8f4e53
dangling blob aa9394042e7e6f62598ca70d38033b4e92d5e498
dangling commit 71c92c28532148f98af0ba27ed06be7c59a2d343
dangling blob 4ff4f495f4d90329d0728500aafe1137ab26b8bf
dangling blob 162ebdcf785ba358ba9617f094e176754860dab5
dangling blob 39335522559ca3fb4e96f0eb8be81cb874d4ed6e
dangling blob 443b2d0c3faaf697dc3c4590d947b8f381232a76
dangling blob 79731d72367733730555b897d2f7d67c2fcd03bf
dangling blob ba77653bf80de6bea7b3f02befd4f7f13829fb58
dangling commit 2ed4751177d4a43e620759d512683cd26e3fa3cf
dangling blob 57d65d31d8ef4edd3159fa67e126eb2c5aed5225
dangling blob ca1166149c473a7e8dba419559af12cbea89f1fe
dangling blob 7f167ef137df333cba57323aab05abe3c6752926
dangling blob 631e1667578df65fe615c6027dd003fa4bed2df5
dangling blob 0dac3e4e4d3de589af4f425d24608f6cd80a7fb8
dangling blob 3ebcb673bcde734c71d07def507c5331280120c1
dangling blob 48c916ebf4d8c04eee55afe8cb651abf456f8240
dangling blob 71d4ae7368676e9d5067d9d7d14d7eab86bbcfd8
dangling blob 5bde4e96820d5eae42e6127315ffc1522d625a86
dangling blob d34e17b61d60eea42f6f35cee48dc3fef686a84a
dangling blob ed524fbf55d5fbf7eedb8c4c006f0c2133e191c0
dangling blob c95e472d07ebe4b2bce03c4c52821005786a00f0
dangling tree ff5fdfe988d1e286e3452c25abac2a725da42690
dangling blob ae8bbf993c674eabeee2ffea3628f691b8317955
dangling blob 06985761bb9deceb42098477e10d0ed64c03134b
A similar problem was reported in https://www.spinics.net/lists/git/msg407227.html with gitk 1:2.31.1-0ppa1~ubuntu18.04.1.
They suggested in https://www.spinics.net/lists/git/msg409774.html that git gc would fix the problem.
I ran git gc, too, and after it, the problem with gitk is gone.
Related
zp1/tmp/origin#1 ==(clone & snapshot)==> zp1/tmp/clone#1
...working...
(snapshot)
||
\/
zp1/tmp/origin#2 <==================== zp1/tmp/clone#2
||
$$copy the incremental parts between zp1/tmp/clone#1
and zp1/tmp/clone#2 to zp1/tmp/origin.$$
The $$copy ..$$ part is what I want, and I have tried the below test procedure but failed with does not match incremental source error. Please, note that it's not about backup.
Is it possible?
[test procedure]
# zfs create zp1/tmp/origin
# touch /zp1/tmp/origin/hi.txt
# zfs snapshot zp1/tmp/origin#1
# zfs clone zp1/tmp/origin#1 zp1/tmp/clone
# zfs snapshot zp1/tmp/clone#1
# touch /zp1/tmp/clone/bye.txt
# zfs snapshot zp1/tmp/clone#2
# zfs list -t all -r zp1/tmp
NAME USED AVAIL REFER MOUNTPOINT
zp1/tmp 256K 339G 96K /zp1/tmp
zp1/tmp/clone 64K 339G 96K /zp1/tmp/clone
zp1/tmp/clone#1 0B - 96K -
zp1/tmp/clone#2 0B - 96K -
zp1/tmp/origin 96K 339G 96K /zp1/tmp/origin
zp1/tmp/origin#1 0B - 96K -
# zfs send -v -I zp1/tmp/clone#1 zp1/tmp/clone#2 | zfs receive -v zp1/tmp/origin#2
send from #1 to zp1/tmp/clone#2 estimated size is 32.6K
total estimated size is 32.6K
TIME SENT SNAPSHOT zp1/tmp/clone#2
receiving incremental stream of zp1/tmp/clone#2 into zp1/tmp/origin#2
cannot receive incremental stream: most recent snapshot of zp1/tmp/origin does not
match incremental source
The zfs send command compares a UUID of the source that it’s sending from and the destination that it’s sending to, to make sure you’re replaying the changes on top of a filesystem that had exactly the same data in it. In your case you’re skipping part of the timeline though, so this UUID doesn’t match.
Your naming scheme for the snapshots on the clone is confusing — clone#1 is not the same snapshot as original-fs#1 even though they probably point at the same data, so I’m going to rename them slightly to make that clearer:
original-fs#1 comes first
clone comes next and has the same UUID as original-fs#1 at the start
clone#2 comes next
clone#3 comes next
You’re trying to send the delta between clone#2 and clone#3 onto a filesystem which doesn’t have clone#2 on it yet. Instead, you should send from original-fs#1 to clone#3 to capture the whole timeline (or you could do two sends, from original-fs#1 to clone#2, then clone#2 to clone#3, if you want to recreate the full snapshot sequence on both versions of the data).
That said, this is just copying a bunch of data around for no reason. Why not just zfs promote the clone so that it becomes the parent filesystem? (Then you can delete the old parent and rename the new one to take its place.)
I am getting the following error from my build:
'$/CCC/AAA/AAASchemas' cannot be cloaked because it does not have a mapped parent.
##[error]Exit code 100 returned from process: file name 'tf', arguments 'vc workfold /cloak /workspace:ws_26_26 $/CCC/AAA/AAASchemas /collection:https://usap-dev.visualstudio.com/ /loginType:OAuth /login:.,*** /noprompt'.
Here's how I've configured it:
How do I correctly add this folder?
The error message is very clear: You can't cloak that because you're not mapping anything in the hierarchy above it.
You're mapping $/CCC/AAA/FromHHHMethodist/DEV. The path $/CCC/AAA/AAASchemas isn't in that path. Thus, there's nothing to cloak, because it's not going to get downloaded in the first place. You'd only need to cloak it if you were mapping $/, $/CCC, or $/CCC/AAA.
ERROR: The specifed resource name contains invalid characters. ErrorCode: InvalidResourceName
2019-10-31T10:28:17.4678189Z <?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidResourceName</Code><Message>The specifed resource name contains invalid characters.
2019-10-31T10:28:17.4678695Z RequestId:
2019-10-31T10:28:17.4679207Z Time:2019-10-31T10:28:17.4598301Z</Message></Error>
I am trying to deploy my static website to blob storage in azure with azure DevOps, but I am getting this error. In my pipeline, I am using grunt build to build, and archive it to zip, then publishing to the azure pipeline, then in the release, I am extracting files, and trying to upload these files with azure CLI task.
I am using following command
az storage blob upload-batch --account-name something --account-key something --destination ‘$web’ --source ./
My Container name is $web
Permitted characters are lowercase a-z 0-9 and single infix hyphens
[a-z0-9\-]
https://learn.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata
I solved this problem by removing apostrophes around container name:
az storage blob upload-batch --account-name something --account-key something --destination $web --source ./
This will probably not solve your problem, but it will solve a related problem for other people:
If the aim is to simply download a file from Azure File Storage using a link, after generating a SAS token, as shown here: Azure File Storage URL in browser showing InvalidHeaderValue
If you remove the slash after the name of the file in the generated link, the file will download!
verify container name or coonection string might contain extra/nonallowed symbols... In my case it was having extra spaces in container name
Is there any way to see the current target SHA of a GitHub repository submodule via Octokit[.net] (without cloning it locally)?
I've been able to track down all the submodules by retrieving the .gitmodules file from the "parent" repo, but that file doesn't maintain where the submodule is pointing with in that submodule repo.
Prior attempts
After finding someone getting this information by indexing into a commit by the submodule path using LibGit2Sharp, I gave that a similar try in Octokit.
var submodulePathContents = await repositoriesClient.Content.GetAllContents(parentRepoId, "path/to/submodule");
While stepping through this code in the debugger, I see this in Locals/Autos, so it definitely knew I was pointing it to a submodule path.
System.Collections.Generic.IReadOnlyList.this[int].get Name:
mono-tools Path: path/to/submodule Type:Submodule
Octokit.RepositoryContent
Unfortunately, when I get the actual content from that list, submodulePathContents[0].Content is just null.
The GitHub web interface definitely surfaces this information when you navigate to a submodule's parent directory, so it makes me think I've just tried the wrong approach.
Is there some other magic way in the Octokit APIs that I've missed to get this submodule target hash?
TL;DR
As described in the question, if you get the contents at the submodule path found in .gitmodules, you will get a piece of content of type "Submodule". This has null content.
If, however, you get the contents of the parent directory for that same submodule path, you will get a piece of content of type "File", with the path of your submodule (e.g., path/to/submodule above). This files hash is the target SHA on the submodule's own repository.
Details
To get the SHA of a submodule, you need to get the contents of its parent directory and then index to the file representing the submodule. While going directly to the path gets you something of type "Submodule", getting the parent contents will get you bunch of "File" type things (and "Dir", if you have sibling subdirectories there). Oddly, this parent content list excludes the "Submodule" type you get when you point directly at the submodule path.
In the example above, just go one level up in the path.
var submodulePathContents = await repositoriesClient.Content.GetAllContents(parentRepoId, "path/to"); // no longer "path/to/submodule"
From there, grab the content item with the path you wanted in the first place (e.g., "path/to/submodule"), which will have a Sha field containing the submodule's target SHA on the submodule repository.
using System.Linq;
…
var submoduleTargetSha = submodulePathContents.First(content => content.Path == submodulePath).Sha;
Here's an example entry from the monodevelop repo's primary submodule directory.
Name: mono-tools Path: main/external/mono-tools Type:File Octokit.RepositoryContent
Content null string
DownloadUrl null System.Uri
EncodedContent null string
Encoding null string
GitUrl {https://api.github.com/repos/mono/mono-tools/git/trees/d858f5f27fa8b10d734ccce7ffba631b995093e5} System.Uri
HtmlUrl {https://github.com/mono/mono-tools/tree/d858f5f27fa8b10d734ccce7ffba631b995093e5} System.Uri
Name "mono-tools" string
Path "main/external/mono-tools" string
Sha "d858f5f27fa8b10d734ccce7ffba631b995093e5" string
Size 0 int
SubmoduleGitUrl null System.Uri
Target null string
Type File Octokit.ContentType
Url {https://api.github.com/repos/mono/monodevelop/contents/main/external/mono-tools?ref=master} System.Uri
And that hash lines up with the web UI.
I just finished cloning the (huge) netbeans repository for
the second time. I found that I couldn't
successfully pull changes, after my first attempt to clone, earlier this week.
I guessed that some intermittent error had
corrupted the repository the first time around... that appears not to
be the case.
I'm using hg 1.3.1 on Ubuntu 9.4 (32-bit).
I cloned with hg clone http://hg.netbeans.org/main main
hg verify (below) ends with:
9 warnings encountered!
9 integrity errors encountered!
incidentally, the size of 00manifest.d is 1.1GiB, is that normal?
What could be causing this? Where does one even report this kind of error?
(assuming for the moment that it's not a PEBKAC.)
This should give you an idea of what I'm seeing (repetitive bits removed to save space):
[smithma#oberon:~/w/netbeans/main]
$ { hg --version ; echo ; echo ; hg --debug verify ; } | tee
../netbeans-main-hg-verify.txt
Mercurial Distributed SCM (version 1.3.1)
Copyright (C) 2005-2009 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
manifest#?: rev 149491 points to unexpected changeset 149752
(expected 149754)
[...SNIP...]
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
applemenu/src/org/netbeans/modules/applemenu/layer.xml#?: rev 12
points to unexpected changeset 149753
(expected 41473 46378 56815 59563 66079 70568 71017 83303 103972 105432 135060 137239 147766 149755)
warning: cnd.repository/src/org/netbeans/modules/cnd/repository/disk/UnitImpl.java#74688:
copy source revision is nullid cnd.repository/src/org/netbeans/modules/cnd/repository/disk/UnitDiskRepository.java:000000000000
[...SNIP...]
defaults/src/org/netbeans/modules/defaults/mf-layer.xml#?: rev 74
points to unexpected changeset 149753
(expected 25730 25732 25733 25741 25746 25747 25752 25768 26270 26561
27350 27495 27539 27566 27776 28203 28741 29191 29244 29364 29582
32476 33848 34406 35712 35713 36197 38355 40775 40854 42144 43593 44912
46378 46644 46697 46757 48145 48325 49166 50888 54548 54616 54618
55792 56816 56868 56895 56915 57513 58323 59288 59456 59563 59709 60225
66549 67160 67595 76198 77297 85585 86938 87361 93609 93755 113163
113177 117980 117992 124182 124475 135060 147766 149755)
[...SNIP...]
118132 files, 151874 changesets, 591274 total revisions
9 warnings encountered!
9 integrity errors encountered!
First, no it's not a PEBKAC. The errors from verify are fixable, the best way is probably to contact a Mercurial dev to write a script fixing the broken linkrevs.
The huge manifest could be dealt with contrib/shrink-revlog.py, from a quick testing I think it would shrink to approximately 50MB.