Archive for the ‘DVCS – Distributed Version Control’ Category
Posted by jpluimers on 2016/03/15
[WayBack] git-extras is awesome: it adds many [WayBack] useful commands to git. Like [WayBack] git ignore and [WayBack] git-info.
For instance, this adds README.md~ to the .gitignore file:
git ignore README.md~
It makes command-line git much more usable, even so much that it lessens the needs of SourceTree and other UIs tools.
You can get it at the GitHub repository [WayBack] tj/git-extras.
Lots of help is at [WayBack] git-extras/Commands.md: it explains all the commands that git-extras adds.
Thanks [WayBack] nifr for posting about git-extras at [WayBack] Is there an ignore command for git like there is for svn? – Stack Overflow.
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, GitHub, Software Development, Source Code Management, SourceTree | Leave a Comment »
Posted by jpluimers on 2016/01/05
The GitHub Contributions Archive is based on the GitHub Archive (see below) and provides insight in anyones contributions. I discovered through a recent post by Ilya Grigorik:
Handy new tool (built on top of githubarchive.org dataset!) that aggregates all of your GitHub activity: bit.ly/1mraQyT.Apparently I’ve contributed to… – Ilya Grigorik – Google+
The GitHub Archive is amazing as it provides way more history than Github does by itself:
GitHub Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis.
Researching that data can provide tons of information, for instance about behaviour. It is also available through Google BigQuery so you can write your own queries for it.
The GitHub Contributions Archive – built by Liam Bowen – provides one (very usable) kind of insight: contributions, but there is much much more as quite some research, visualizations and talks have shown.
Interesting stuff!
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, GitHub, Power User, Software Development, Source Code Management | Leave a Comment »
Posted by jpluimers on 2015/12/28
Unlike SourceTree for Windows, SourceTree for Mac still doesn’t automagically detect Beyond Compare even though that has been available for Mac OS X since : [SRCTREE-2092] Add built-in support for Beyond Compare version 4 – Atlassian JIRA.
Even modifying my ~/.gitconfig didn’t work, but manual configuration did. Here are the steps:
- Start the UI version of Beyond Compare
- Select the Beyond Compare menu, install the command-line tools
Read the rest of this entry »
Posted in Apple, Beyond Compare, Development, DVCS - Distributed Version Control, Keyboards and Keyboard Shortcuts, Mac, Mac OS X / OS X / MacOS, MacBook, MacBook Retina, MacBook-Air, MacBook-Pro, OS X 10.10 Yosemite, OS X 10.8 Mountain Lion, OS X 10.9 Mavericks, Power User, Source Code Management, SourceTree | 3 Comments »
Posted by jpluimers on 2015/11/24
A while ago, I had this error on BitBucket:
Running git.exe with arguments "fetch --prune" failed with return code 128 and error output: "fatal: unable to access 'https://%account%@bitbucket.org/%user%/%repository%.git/': Unknown SSL protocol error in connection to bitbucket.org:443
A quick search for “Unknown SSL protocol error in connection to bitbucket.org:443” pointed me to a comment by Ludwik Trammer on an answer by Jordfräs:
I resolved the issue by upgrading from git 1.8 to git 2.0.
Which reminded me this was a Windows system, where there is no package manager that verifies how far your non-system software is behind.
One day, I will write a script that finds out about the git version history and inform me of major/minor versions I’ve skipped.
Some notes for that:
Probably I will need to do something similar for Mercurial/hg in the future as well.
–jeroen
via: git – Unknown SSL protocol error in connection – Stack Overflow
Posted in Development, DVCS - Distributed Version Control, git, Power User, Software Development, Source Code Management, Windows, Windows 7, Windows 8, Windows 8.1, Windows 9, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 | Leave a Comment »
Posted by jpluimers on 2015/08/13
Besides commit statements from hg or git like this:
hg commit -m “fixes #6, resolve ticket #5 and see ticket #9 and ticket #5 in the tracker”
The best is to start with the command, then finish the comment (commands in the middle of a comment are far less reliable).
There is a whole bunch of commands for which BitBucket tries to understand conjugations of verbs:
| Command |
“Verb” |
Conjugation(s) |
| resolve |
close |
close
closes
closed
closing |
| resolve |
fix |
fix
fixed
fixes
fixing
|
| resolve |
resolve |
resolve
resolves
resolved
resolving |
| reopen |
reopen |
reopen
reopens
reopening |
| hold |
hold |
hold
holds
holding |
| wontfix |
wontfix |
wontfix |
| invalid |
invaldate |
invalidate
invalidates
invalidated
invalidating |
You can also use the word “issue” in the middle to just link to an issue like this syntax:
links to issue #1
Finally, you can refer from issues to change sets using a cset syntax: <<cset 2f2f8d4cae7da0e37a5ffbc81c527cb67cc56015>> where the hex number is from a URL in your commit list (for instance in https://bitbucket.org/jeroenp/fastmm/commits)
Note that linking from changesets to issues often automatically creates a back-link, but that doesn’t always work, and fixing it has very low priority (like many things on BitBucket): Issues getting linked to commits have the wrong link syntax, they show BB-6232 — Bitbucket.
–jeroen
via:
Posted in BitBucket, Development, DVCS - Distributed Version Control, git, Mercurial/Hg, Source Code Management | Leave a Comment »
Posted by jpluimers on 2015/08/12
Thanks to the answers and comments on stackoverflow, here are my steps to resurrect a closed hg branch:
- List all branches (including closed ones)
- Switch to a closed branch
hg update my_closed_branch_name
- Change anything
- For instance by adding a tag, as that is considered a versioned and mergeable change)
hg tag reopened_my_closed_branch
- Or making a change to a file, then ommit your changes
hg commit -m "I changed a message"
This works because of what Lazy Badger explained in another answer which summarised is:
A commit on top of a closed head effectively opens the head.
Note: if you while experimenting with this, you want to undo your last change before committing, perform this command to revert back one revision:
hg update -C -r .
The answers and comments (thanks Lóránt Pintér for asking the question):
Tim Delaney:
You can just hg update to the closed branch then do another hg commit and it will automatically reopen.The closed flag is just used to filter out closed branches from hg branches and hg heads unless you use the --closed option – it doesn’t prevent you from using the branches.
Francis Upton:
The commit won’t do anything unless there is something to actually commit, so you may need to make a gratuitous change to make it happen.
lorddev:
A tag is sufficient to make it commitable.
–jeroen
via: Is it possible to reopen a closed branch in Mercurial? – Stack Overflow.
Posted in Development, DVCS - Distributed Version Control, Mercurial/Hg, Source Code Management | Leave a Comment »
Posted by jpluimers on 2015/07/02
Hoping I never need it, but just in case:
Git: Remove sensitive data using git filter-branch and the BFG Repo-Cleaner.
Anyone who knows if there are equivalents for Mercurial/Hg?
–jeroen
via:
Posted in Development, DVCS - Distributed Version Control, git, Mercurial/Hg, Source Code Management | Leave a Comment »
Posted by jpluimers on 2015/06/23
I needed to get an existing Git repository to a client that had a tightened network. No SSH allowed, web proxy filtering out all sorts of sites and also performing a HTTPS man-in-the-middle to detect and reject all kinds of binaries, etc.
But we needed a public repository locally.
Which worked, thanks to pestrella, who answered about `bare` repositories to get my last steps correct:
In order to create a new Git repository from an existing repository one would typically create a new bare repository and push one or more branches from the existing to the new repository.
The trick is to know that server-side repositories are `bare` and client side repositories are `regular`. `bare` means the absence of a working copy on the server side.
I performed these steps:
Read the rest of this entry »
Posted in Development, DVCS - Distributed Version Control, git, Source Code Management | Leave a Comment »
The Wiert Corner - irregular stream of stuff 