The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,281 other followers

Archive for the ‘DVCS – Distributed Version Control’ Category


Posted by jpluimers on 2021/02/18

[WayBack] showthedocs

is a documentation browser that finds the relevant docs for your code. It works by parsing the code and connecting parts of it to their explanation in the docs

, and supports these languages:

  • SQL
    • postgresql
    • mysql
  • Configuration
    • nginx
    • gitconfig

You can enter any language text, then click the language, followed by clicking the “SHOW ME THE DOCS!” button, for which an example is further below.

The site has an open architecture, allowing to plug in more languages and documentation:


gitconfig example

So for instance the below ./git/config file leads to this result [WayBack] where you can click on all the coloured areas for easy navigation through the documentation:

Read the rest of this entry »

Posted in *nix, *nix-tools, Database Development, Development, DVCS - Distributed Version Control, git, MySQL, nginx, PostgreSQL, Power User, Software Development | Leave a Comment »

A choco install list

Posted by jpluimers on 2021/02/03

Sometimes I forget the choco install mnemonics for various tools, so here is a small list below.

Of course you have to start with an administrative command prompt, and have a basic Chocolatey Installation in place.

If you want to clean cruft:

choco install --yes choco-cleaner

Basic install:

choco install --yes 7zip
choco install --yes everything
choco install --yes notepadplusplus
choco install --yes beyondcompare
choco install --yes git.install --params "/GitAndUnixToolsOnPath /NoGitLfs /SChannel /NoAutoCrlf /WindowsTerminal"
choco install --yes hg
choco install --yes sourcetree
choco install --yes sysinternals

For VMs (pic one):

choco install --yes vmware-tools
choco install --yes virtio-drivers

For browsing (not sure yet about Chrome as that one has a non-admin installer as well):

choco install --yes firefox

For file transfer (though be aware that some versions of Filezilla contained adware):

choco install --yes filezilla
choco install --yes winscp

For coding:

choco install --yes vscode
choco install --yes atom

For SQL server:

choco install --yes sql-server-management-studio

For web development / power user:

choco install --yes fiddler

For SOAP and REST:

choco install --yes soapui

If you don’t like manually downloading SequoiaView at (

choco install --yes windirstat

For drawing, image manipulation ( last, as it needs a UI action):

choco install --yes gimp
choco install --yes imagemagick
choco install --yes

For ISO image mounting in pre Windows 10:

choco install --yes wincdemu

For hard disk management:

choco install --yes hdtune
choco install --yes seatools
choco install --yes speedfan

For Fujitsu ScanSnap scanners (not sure yet this includes PDF support):

choco install --yes scansnapmanager


Posted in .NET, 7zip, Atom, Beyond Compare, Chocolatey, Compression, Database Development, Development, DVCS - Distributed Version Control, Everything by VoidTools, Fiddler, Firefox, Fujitsu ScanSnap, git, Hardware, Mercurial/Hg, Power User, Scanners, SOAP/WebServices, Software Development, Source Code Management, SQL Server, SSMS SQL Server Management Studio, SysInternals, Text Editors, Versioning, Virtualization, Visual Studio and tools, Visual Studio Code, VMware, VMware ESXi, Web Browsers, Web Development, Windows | Leave a Comment »

Syncing your fork to the original repository via the browser · KirstieJane/STEMMRoleModels Wiki · GitHub

Posted by jpluimers on 2020/12/31

[WayBack] Syncing your fork to the original repository via the browser · KirstieJane/STEMMRoleModels Wiki · GitHub

TL;DR: you can do the sync from the Web UI, but it always gives you an extra merge commit.


Posted in Development, DVCS - Distributed Version Control, git, GitHub, LifeHacker, Power User, Source Code Management | Leave a Comment »

git the meaning of `–` is to treat the rest of the arguments as file names (Hard reset of a single file – Stack Overflow)

Posted by jpluimers on 2020/12/16

Learned TWO things at once Mark Longair and VonC at [WayBack] git – Hard reset of a single file – Stack Overflow :

You can use the following command:

git checkout HEAD -- my-file.txt

… which will update both the working copy of my-file.txt and its state in the index with that from HEAD.

-- basically means: treat every argument after this point as a file name. More details in this answer. Thanks to VonC for pointing this out.


  • [WayBack] User Mark Longair – Stack Overflow
  • [WayBack] User VonC – Stack Overflow
  • [WayBack] User zwol – Stack Overflow
  • [WayBack] Difference between “git checkout ” and “git checkout -​- ” – Stack Overflow

    The special “option” -- means “treat every argument after this point as a file name, no matter what it looks like.” This is not Git-specific, it’s a general Unix command line convention. Normally you use it to clarify that an argument is a file name rather than an option, e.g.

    rm -f      # does nothing
    rm -- -f   # deletes a file named "-f"

    git checkout1 also takes -- to mean that subsequent arguments are not its optional “treeish” parameter specifying which commit you want.

    So in this context it’s safe to use -- always, but you need it when the file you want to revert has a name that begins with -, or is the same as the name of a branch. Some examples for branch/file disambiguation:

    git checkout README     # would normally discard uncommitted changes
                            # to the _file_ "README"
    git checkout master     # would normally switch the working copy to
                            # the _branch_ "master"
    git checkout -- master  # discard uncommitted changes to the _file_ "master"

    and option/file disambiguation:

    git checkout -p -- README  # interactively discard uncommitted changes
                               # to the file "README"
    git checkout -- -p README  # unconditionally discard all uncommitted
                               # changes to the files "-p" and "README"

    I’m not sure what you do if you have a branch whose name begins with -. Perhaps don’t do that in the first place.

    1 in this mode; “checkout” can do several other things as well. I have never understood why git chose to implement “discard uncommitted changes” as a mode of the “checkout” subcommand, rather than “revert” like most other VCSes, or “reset” which I think might make more sense in git’s own terms.

  • [WayBack] Deleting a badly named git branch – Stack Overflow

    Did you try

    git branch -D -- --track

    ? the “--” is usually the convention for “what follows is not an option, whatever its name”

    From “The Art of Unix Programming“, section “Command-Line Options“:

    It is also conventional to recognize a double hyphen as a signal to stop option interpretation and treat all following arguments literally.

    You will find that convention in other (not necessary Unix-related) CLI (Command Line Interface) like cleartool:

    If a nonoption argument begins with a hyphen () character, you may need to precede it with a double-hyphen argument, to prevent it from being interpreted as an option:

    cleartool rmtype -lbtype -- -temporary_label- 

    The P18 (a fast and flexible file preprocessor with macro processing capabilities and special support for internationalization) mentions that also and gives a good description of the general idea behind that convention:

    All option arguments passed to the commands start with a single hyphen.
    All option arguments (if any) must precede all non-option arguments.
    The end of the option arguments may be signaled using a double hyphen, this is useful if a non-option argument starts with a hyphen. Terminating the list of option arguments with a double hyphen works for all commands, even those that don’t take any option arguments.

    The OptionParser tool written in ruby also lays it out quite plainly:*

    Option Parsing Termination

    It is convention that a double hyphen is a signal to stop option interpretation and to read the remaining statements on the command line literally. So, a command such as:

     app -- -x -y -z

    will not ‘see’ the three mode-flags. Instead, they will be treated as arguments to the application:

     #args = ["-x", "-y", "-z"]

    Note: sometimes, it takes three dashes and not two, especially when the CLI follows strictly the Gnu options styles:

    The Gnu style command line options provide support for option words (or keywords), yet still maintain compatibility with the Unix style options.
    The options in this style are sometimes referred to as long_options and the Unix style options as short_options.
    The compatibility is maintained by preceding the long_options with two dashes

    Similar to the Unix style double-hyphen ’--’, the Gnu style has a triple-hyphen ’---’ to signal that option parsing be halted and to treat the remaining text as arguments (that is, read literally from the command line)

    So… if ‘ -- ‘ is not enough (it should be with Git commands), try ‘ --- ‘


Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »

How to have git log show filenames like svn log -v – Stack Overflow

Posted by jpluimers on 2020/12/01

I stick to git log --name-status as suggested in [WayBack] How to have git log show filenames like svn log -v – Stack Overflow.

A slightly less readable alternative isgit log --num-status .

There is also git log --name-only as suggested in [WayBack] How to show changed file name only with git log? – Stack Overflow


Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »

%d bloggers like this: