| /* | |
| * Copyright (C) 2015 René Jeschke <[email protected]> | |
| * | |
| * Licensed under the Apache License, Version 2.0 (the "License"); | |
| * you may not use this file except in compliance with the License. | |
| * You may obtain a copy of the License at | |
| * | |
| * http://www.apache.org/licenses/LICENSE-2.0 | |
| * | |
| * Unless required by applicable law or agreed to in writing, software |
The Git for Windows team is currently testing their newest release candidates, which is a port of Git 2.3 to Windows. As this is a significant change, I've written up a guide for people who are interested in helping to test out things.
You can find the latest releases for Git for Windows over on the Releases page:
Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.
To deal with that, I started changing the package.json version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
| First create an author-map file for translating svn user names to Git user names in history: | |
| $ cat author-map | |
| em.colombo = Emanuele Colombo <[email protected]> | |
| [email protected] = Emanuele Colombo <[email protected]> | |
| Vittorio.Curcio = Vittorio Curcio <[email protected]> | |
| xxdede = xxdede <[email protected]> | |
| (no author) = no author <[email protected]> | |
| Now, do a git svn clone: |
If you are a normal Git user, and you have problems using Git, you can also try:
If you believe you've found a bug in Git for Windows or msysGit (Windows-specific), first check their issue tracker to see if the problem has already been reported. If not, send a message to [email protected] or visit the online forum version.
Copy, with line wrapping!
If you've been trying to copy/paste text from a multi-pane tmux session with the mouse, you've probably been pretty pissed at the blissful ignorance a terminal application has of the rodent in your hand.
The alternative, which is quote-unqoute native copy/pasting using copy-mode takes a bit to get used to. So this is one solution for copying and pasting lines from a session with correct line wrapping behaviour, albeit keyboard only.
Disclaimer
Since copy-mode has similar concepts of marks, regions, and temp buffers to Emacs .. you'll probably find it straight forward if you're familar with Emacsen. For people using vi-mode in tmux, the same still applies but obviously the default key bindings will differ alot from what I show below.
| #!/usr/bin/env python | |
| # Simple Image Diffs | |
| # ================== | |
| # | |
| # How to Install | |
| # -------------- | |
| # | |
| # Download the script somewhere on $PATH as 'simple-imagediff' with +x: | |
| # |
| #!/bin/sh | |
| # Git Remove (from version control) any file that is covered by the ignore patterns and exists on the filesystem. Could be improved to further check the file exists on the git filesystem too. | |
| for eachthing in `git ls-files --others --ignored --exclude-standard`; do if [ -e "$eachthing" ]; then git rm $eachthing; fi; done |
