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 1,509 other followers

Archive for the ‘Source Code Management’ Category

During git mv (rename): “unable to unlink old” “invalid argument”

Posted by jpluimers on 2019/03/20

I had an error when doing a rename (mv) in git “unable to unlink old” “invalid argument”. This appeared to be a process having a lock on that file.

In my case, this was a bit hard to track down (I used Process Explorer for it), as the culprit was SourceTree running git in the background to keep an eye on changes in the repository because it has a file system watcher on the repository tree and a different process was writing log files in the same directory structure.

Can you still follow? I had a hard time so here it is in manageable bits:

  1. By default SourceTree has a file system watcher on your repositories
  2. If that watcher fires, SourceTree runs a background git process to get the current state of the repository
  3. If you perform UI actions, SourceTree runs a foreground git process to perform the action
  4. SourceTree does not have a mechanism to wait for the background git process to finish before running the foreground process
  5. I had had another process running that logged into a relative directory that happened to be within the repository tree (but using files excluded by .gitignore)

Basically SourceTree should do two things:

  • keep track of the background process and not fire a foreground one
  • do not start the background process for files excluded by .gitignore

I tracked down what happened using these tips:


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

How can I rename a git stash? – Stack Overflow

Posted by jpluimers on 2019/03/07

SourceTree does not like it when by accident two git stash entries have exactly the same name.

To work around that, you have to rename one.

The easiest way to do this is on the console using the tips from [WayBack] How can I rename a git stash? – Stack Overflow (thanks [WayBack] qzb):

$ git stash list
stash@{0}: WIP on master: Add some very important feature
stash@{1}: WIP on master: Fix some silly bug

First, you must remove stash entry which you want to rename:

$ git stash drop stash@{1}
Dropped stash@{1} (af8fdeee49a03d1b4609f294635e7f0d622e03db)

Now just add it again with new message using sha of commit returned after dropping:

$ git stash store -m "Very descriptive message" af8fdeee49a03d1b4609f294635e7f0d622e03db

And that’s it:

$ git stash list
stash@{0}: Very descriptive message
stash@{1}: WIP on master: Add some very important feature

This solution requires git 1.8.4 or later, and yes, it works with dirty working directory too.

Some other useful git stash commands:


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

Move the most recent commit(s) to a new branch with Git – Stack Overflow

Posted by jpluimers on 2019/03/05

Below are the git statements I used to solve this ASCII art problem from me (as I work in Git Flow feature branches):

old situation:

commit-1..4  -  commit-5  -  commit-6  -  commit-7  -  commit-8  -  commit-9
                   ^            ^            ^            ^           ^
                   |            |            |            |           |
                master       develop      feature/A                 feature/old


commit-1..4  -  commit-5  -  commit-6  -  commit-7  -  commit-8  -  commit-9
                   ^            ^            ^            ^           ^
                   |            |            |            |           |
                master       develop      feature/A    feature/old  feature/new


git branch
git rev-parse HEAD
git log --pretty=format:'%H' -n 2
git checkout -b feature/new hash-of-commit-8
git branch --set-upstream-to=feature/old
git cherry-pick ..feature/old
git branch --force feature/old hash-of-commit-8

Step by step, this is what happens:

  1. branch lists the current branches
  2. rev-parse HEAD shows the hash of the current commit (commit-9)
  3. log --pretty=format:'%H' -n 1shows the hash of the previous two commits (from top to bottom: commit-9 and commit-8)
  4. checkout creates a new branch based on the past commit-8
  5. branch --set-upstream ensures the new branch tracks the old branch
  6. cherry pick ensures the new branch gets all the commits from the old branch
  7. branch --force ensure the old branch looses the extra commits you wanted to only be in newBranchName

Based on


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

RawGit is going away: redirect your content before October 2019 (it does disappear after that)

Posted by jpluimers on 2019/02/04

[WayBack] RawGit: RawGit served raw files directly from GitHub with proper Content-Type headers.

This means you have to redirect your existing RawGit links before October 2019, and you cannot add new links on RawGit.

You might want to try alternatives, for instance this one I mentioned in 2017: – like but supports bitbucket as well and runs on plain nginx.

[WayBack] serves raw files directly from GitHub, Bitbucket or GitLab with proper Content-Type headers.

There are some other options that RawGit itself mentions:

What you should use instead

The following free services offer fantastic alternatives to some or all of RawGit’s functionality. You may like them even more than RawGit.

RawGit source is still at [WayBack] GitHub – rgrove/rawgit: Served files from, but with the correct content types., so if you want to host your own alternative you can.

It means I need to change these pages:



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

git on Windows: prevent “The requested URL returned error: 403” during push of https based repository

Posted by jpluimers on 2019/01/10

When you search for git push "The requested URL returned error: 403", then the usual answer is “use ssh over https”, for instance at [WayBackgithub – Pushing to Git returning Error Code 403 fatal: HTTP request failed – Stack Overflow.

However, lots of places (especially larger corporations and financials) limit outgoing traffic to http and https based for (often perceived) security reasons.

In this case, I needed a solution for Windows, which – after a long search – found two solutions that are below.

I use the repository as an example, but it isn’t limited to GitLab: the same symptoms happen with other hosters as well (for instance on GitHub and BitBucket):

First what doesn’t work: they all give the same 403 message.

  1. Installing a newer git version (I tried git version
  2. have the plain URL:
  3. put just the username or e-mail address in the URL
  4. put just the username or e-mail address in the URL with a blank password
  5. for the four above, add the caching credential helper then add a credential:

What could work

The first thing that works is to include the actual password in the repository URL like this:

When you enter the correct password, everything is fine. Except that the password is stored as plain text on disk.

What works

The real solution on Windows is to use the Windows Credential Manager. I found this because of the 5th failure above.

To see which username/password combinations have been stored or add your own, you can start the Credential Manager on the command-line like this (each Windows version seems to have a different path to the UI from the control panel; the console trick just works on all Windows versions I tested):

%windir%\explorer.exe shell:::{1206F5F1-0569-412C-8FEC-3204630DFB70}

Note the above was the reason for writing List of Shell GUIDs for various Windows versions for use in shortcuts and batch files.

What might work on non-Windows systems

I have the impression that the “cached” credential manager will work on non-Windows systems, but need to find some time testing that on multiple platforms. Stay tuned (:

For that I need to look into at least these:


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

%d bloggers like this: