The Wiert Corner – irregular stream of stuff

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

  • My work

  • 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,844 other followers

Archive for May 16th, 2017

Bitbucket – when you suddenly cannot login with git username/password from git any more

Posted by jpluimers on 2017/05/16

When logging in using the Web UI with a username

When logging in using the Web UI with a username

As of a few days, I was getting this error in my SourceTree output when pushing to git :

remote: Invalid username or password. If you log in via a third party service you must ensure you have an account password set in your account profile.

I think this is at least related to a change Bitbucket made 2 years ago for their site logon:

You can no longer log in with a username. Use your Atlassian account email address instead.

Source: Bitbucket

Pushing to bitbucket with cached credentials from SourceTree has worked for months. One thing that was different now (and should have given me a clue) the broken [WayBack] broken Git Credentials Manager popup showed but should not have.

When you get this credential manager you have to escape it as otherwise you will get an “Empty password” error.

Broken Git Credential Manager for Windows

Broken Git Credential Manager for Windows

Initially I blamed the error on the SourceTree 2.x upgrade I did last week. Unlike previous upgrades, this one had kept the old version (in my case 1.9.13.7) around and after a few clicks (skipping the “go to download page” prompt forever) and closing SourceTree 2.0, I fas able to start SourceTree 1.9 again.

SourceTree 1.9 had the same problem which meant it was either git itself, or the Bitbucket back-end.

To prove it was the Bitbucket back-end, I did everything An example of this is in the output below.

Solving the problem

What helped were these steps:

  1. Change the git repository from https://jeroenp@bitbucket.org/jeroenp/fastmm.git to
    https://bitbucket.org/jeroenp/fastmm.git
  2. Change the “username” field for the bitbucket repository to be my email address.
  3. Remove any bitbucket cached credentials from SourceTree.
  4. Restart SourceTree.
  5. Performing a push
  6. Cancel the Git Credential Manager popup
  7. Use my primary bitbucket email address for logon

Now SourceTree happily cached my credentials.

I’ve used this to scan the git config files for ones starting with a username:

grep -inSwl jeroenp@bitbucket config

Notes:

From the console

Reproduction of the issue:

C:\Users\jeroenp\Versioned\FastMM>git --version
git version 2.12.2.windows.1

C:\Users\jeroenp\Versioned\FastMM>git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags --set-upstream bitbucket develop:develop
Pushing to https://jeroenp@bitbucket.org/jeroenp/fastmm.git
Logon failed, use ctrl+c to cancel basic credential prompt.
Password for 'https://jeroenp@bitbucket.org/':
remote: Invalid username or password. If you log in via a third party service you must ensure you have an account password set in your account profile.
fatal: Authentication failed for 'https://jeroenp@bitbucket.org/jeroenp/fastmm.git/'

This has worked for months (after [WayBack] canceling the Git Credentials Manager popup as that has been broken for a very long time and gives you a remote: Empty password).

What helped was this:

C:\Users\jeroenp\Versioned\FastMM>git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags --set-upstream bitbucket develop:develop
Pushing to https://bitbucket.org/jeroenp/fastmm.git
Logon failed, use ctrl+c to cancel basic credential prompt.
Username for 'https://bitbucket.org/': jeroen...@....com
Password for 'https://jeroen...@....comcom@bitbucket.org/':
Total 0 (delta 0), reused 0 (delta 0)
POST git-receive-pack (196 bytes)
remote:
remote: Create pull request for develop:
remote:   https://bitbucket.org/jeroenp/fastmm/pull-requests/new?source=develop&t=1
remote:
To https://bitbucket.org/jeroenp/fastmm.git
   xxxxxxxx..xxxxxxxx  develop -> develop
updating local tracking ref 'refs/remotes/bitbucket/develop'
Branch develop set up to track remote branch develop from bitbucket.

–jeroen

 

 

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

On the design of the Delphi TStream classes – why aren’t they decomposed better?

Posted by jpluimers on 2017/05/16

Ever since I started using Delphi more than 2 decades ago, I wondered about the design of the TStream classes, especially as “stream16.zip” by Duncan Murdoch from the DOS Turbo Pascal era (which I copied in the below gist) showed how to perform composition using streams.

Even though by now there is TStreamReader/TStreamWriter allowing some level of composition, it always bugged me that large parts of the resource handling and component (de)serialisation is in it (centred around ReadComponentRes/WriteComponentRes in stead of fully being in TFiler/TReader/TWriter or even further decomposed), that you cannot interrogate capabilities (like supporting seeking, length, directionality and such) and that a lot of overloads (for instance Read/ReadBuffer/ReadBufferData/Write/WriteBuffer/WriteBufferData) are still based on signed or 32-bit types (though it has improved back in the early days they were even signed 16-bit types).

I’m not the only one who wonders about this: Faster FileStream with TBufferedFileStream • DelphiABall mentioned a new Berlin piece the TStream hierarchy and – being in the field a lot longer – Stefan Glienke rightly asked why the buffering isn’t done with the decorator pattern like JclStreams does, and Asbjørn Heid chimed in with a very dense version of more gripes.

Even TZCompressionStream/TZDecompressionStream (though relatively new) aren’t doing composition really well (by not abstracting the compression/decompression from the write-only/read-only behaviour).

Now that all key players from the early TStream design day and age have left the core Delphi R&D team, maybe one of them can step in and explain why.

–jeroen

via: [WayBack] I was wondering if the TBufferedFileStream (see https://delphiaball.co.uk/2016/04/29/faster-filestream-tbufferedfilestream/) would not have been implemented using the decorator pattern… – Stefan Glienke – Google+ -> https://github.com/project-jedi/jcl/blob/master/jcl/source/common/JclStreams.pas#L207

TJclBufferedStream = class(TJclStreamDecorator)

Read the rest of this entry »

Posted in Delphi, Development, Software Development | 2 Comments »

 
%d bloggers like this: