Archive for the ‘DVCS – Distributed Version Control’ Category
Posted by jpluimers on 2020/04/14
I’ve used these excellent posts to find out which youtube-dl version started to exhibit troublesome NPO downloads, then later find the actual failing commit:
Why the effort? I needed an as recent as possible youtube-dl working on as many sites as possible because of some work preparation.
The first link is very important because brew versions and alternatives have stopped working some 6 years ago, even though they turn up high on Google searches for brew install specific version. Hence the quote from the first link:
Installing software packages on Mac is very easy with homebrew. You typically get the latest version, however often in production you do not have the latest version of a software package. Another use case is when you upgrade to the latest and you find out there is bug which blocks you doing something. In this case you would like to downgrade to the previous version until the bug is fixed.In both cases you need to install a specific version of a software package with homebrew on your Mac, which tends to be not that trivial. There is a lot of discussion about this on stackoverflow but some of them are outdated based on brew versions which is not available anymore.
Read the rest of this entry »
Posted in Apple, Conference Topics, Conferences, Development, DVCS - Distributed Version Control, Event, git, Home brew / homebrew, Power User, SocialMedia, Software Development, Source Code Management, YouTube | Leave a Comment »
Posted by jpluimers on 2020/04/07
At the time of writing:
- Rendering svg files at gitlab is impossible, as they are served with a http result 404; see
- Rendering svg files on gitea is possible either, despite a co-worker suggesting to remove the below DOCTYPE from the .svg file, see
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, gitea, GitHub, GitLab, Software Development, Source Code Management | Leave a Comment »
Posted by jpluimers on 2020/03/31
Since the Git output by default is not shown, here is how to enable it:
[WayBack] Version Control in Visual Studio Code: Git output window
You can always peek under the hood to see the Git commands we are using. This is helpful if something strange is happening or if you are just curious. :)
To open the Git output window, run View > Output and select Git from the dropdown.
Or shorter on MacOS:
- Press
Cmd–Shift–P
- Type
show git output
- Press enter
–jeroen
Posted in .NET, Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management, Visual Studio and tools, vscode Visual Studio Code | Leave a Comment »
Posted by jpluimers on 2020/03/12
There is git submodule add, but no git submodule remove. That one is called git submodule deinit, but still a lot of links on the internet do not mention it, so I’m glad there is a good answer to [WayBack] github – What is the current way to remove a git submodule? – Stack Overflow:
You have the git submodule deinit
git submodule deinit <asubmodule>
git rm <asubmodule>
# Note: asubmodule (no trailing slash)
# or, if you want to leave it in your working tree
git rm --cached <asubmodule>
rm -rf .git/modules/<asubmodule>
deinit
Un-register the given submodules, i.e. remove the whole submodule.$name
section from .git/config together with their work tree.
Further calls to git submodule update, git submodule foreach and git submodule sync will skip any unregistered submodules until they are initialized again, so use this command if you don’t want to have a local checkout of the submodule in your work tree anymore.
If you really want to remove a submodule from the repository and commit that use git rminstead.
If --force is specified, the submodule’s work tree will be removed even if it contains local modifications.
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, Source Code Management | Leave a Comment »
Posted by jpluimers on 2020/03/11
Since the “account.json” SourceTree search did not help me much, below are the steps for installing SourceTree for Windows 3.x on an air-gapped machine.
Prerequisites:
Steps:
- Run Process Explorer on the target system
- Run the SourceTreeSetup installer on the target system
- When registering, click on the “BitBucket” button on the target system
- In Process Explorer, find out the web browser process that the setup kicks off and grab the command-line, which looks like this when running Chrome as default browser:
"%LocalAppData%\Google\Chrome\Application\chrome.exe" -- "https://bitbucket.org/site/oauth2/authorize?response_type=code&client_id=123456789012345678&state=authenticated&redirect_uri=http://localhost:34106/"
- Copy the URL bit
https://bitbucket.org/site/oauth2/authorize?response_type=code&client_id=123456789012345678&state=authenticated&redirect_uri=http://localhost:34106/ over and paste it on a machine that has internet access
- Logon, and follow the steps until the URL look like this:
http://localhost:34106/?state=authenticated&code=876543210987654321
- Copy that URL over to a web-browser on the target system and execute it
- Finish the installation steps on the target system
Now a new file should be in %LocalAppData%\Atlassian\SourceTree\accounts.json suitable for SourceTree 3.x. In the future you might be lucky enough to copy that to a target system before installing.
I was not so lucky, because my accounts.json was SourceTree 2.x based, which the SourceTree 3.x setup modifies, but is still not happy with.
Note these number differ on each request:
123456789012345678 is a base64 encoded request ID876543210987654321 is a base64 encoded response ID34106 is a random TCP port where the installer is listening on to get the authentication information
Fiddler
Initially, I had Fiddler steps in the above, but found out I did not need those. One thing that complicated this is that Fiddler had been removed from Chocolatey for a while, so I was not sure it would stay as a product:
SourceTree
Now has an MSI installer:
Has old steps for 2.x versions to get around the above hoopla:
–jeroen
Posted in Development, DVCS - Distributed Version Control, Software Development, Source Code Management, SourceTree | Leave a Comment »
Posted by jpluimers on 2020/01/30
February 1st, the start commences of Sunsetting Mercurial support in Bitbucket – Bitbucket [WayBack]. Starting June 1st, only git is supported by Bitbucket, despite them having started with and focused mainly Mercurial at first.
Here are the major dates of the sunset:
- February 1, 2020: users will no longer be able to create new Mercurial repositories
- June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
All current Mercurial functionality in Bitbucket will be available through May 31, 2020.
So by now you should have started migrating from Mercurial to git, probably away from BitBucket.
Read the rest of this entry »
Posted in BitBucket, Development, DVCS - Distributed Version Control, git, Mercurial/Hg, Software Development, Source Code Management | Leave a Comment »
Posted by jpluimers on 2019/12/04
I like that you can add git repositories inside eachother using git submodule add but when it’s time to say goodbye to a submodule you need some convoluted statements. So I really wish one day there will be git submodule remove.
Until then, these links will help you to get rid of a git submodule:
TL;DR you have to manually edit the below files:
Then you need to:
- (recursively) remove the subdirectory containing the submodule in the repository
- sometimes (recursively) the subdirectory containing the submodule in
.git/modules
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, Source Code Management | Leave a Comment »
Posted by jpluimers on 2019/11/27
Since I tend to forget the exact statements for starting a fresh repository and push it to a git hoster like GitHub or GitLab: [WayBack] Git: Push a new or existing repo to Github · GitHub
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, GitHub, GitLab, Software Development, Source Code Management | Leave a Comment »
Posted by jpluimers on 2019/11/21
Some interesting thoughts on DVCS: [WayBack] Unorthodocs: Abandon your DVCS and Return to Sanity – bitquabit
Besides the very good point it raises about DVCS (Git, Mercurial and most other DVCSes treat the whole state of the repository as the atom) it also indicates quite a few shortcomings:
- most people hardly ever need the full history to be off-line
- having the full history means repositories get huge in size, including your off-line clone
- pseudo-solutions for huge repository sizes – like git-LFS or git-annex – are a no-go because now you loose atomicity
- huge repositories in file or commit counts make them slow, especially when the trees are deep
- splitting up repositories isn’t a good idea either because again: you loose atomicity
- all DVCS are hard, not just git, because they are distributed and full of features
- the workflow for submitting pull requests is quite a bit longer than submitting a patch, even though merging in a DVCS can be hard too (despite atomicity which does help a lot for DVCS systems)
I see many other advantages of DVCS systems (for instance that you only need to locally have the branches you are interested in, way better tooling for DVCS systems, ditto for sites hosting DVCS), but it always a good thing to know the weak spots of what you are working with.
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, Mercurial/Hg, Software Development, Source Code Management | Leave a Comment »
The Wiert Corner - irregular stream of stuff 