Contact

Subscribe via Email

Subscribe via RSS

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Git branch verbose

This is worth remembering:

These switches work with the -a switch too:

Don’t forget: this is cached information.

Git pull default

The same way you can set the default repository and branch to push to, you can set defaults for git pull too.

The master branch has a default set automatically when you clone the repository the first time, but branches don’t have these unless you specify manually. We’ve already seen the command to specify upstream branches manually when pushing. The same command applies here too:

Here testing is the local branch and origin/<branch> is the remote branch. I can skip testing if I am already checked out to that branch locally. And I can skip the = sign between the switch and remote name. Also, -u can be used as a shorter alternative to --set-upstream-to.

Here’s what the command actually does:

Git push default – difference between simple, matching, current, etc.

Whenever I’d issue a git push without specifying the remote repository or branch, expecting it to just pick up the default remote repository and push to the remote branch with the same name as the current local branch, I get the following message:

Usually I’d ignore the message and go ahead anyways, but today I decided to explore further.

So, first up: what are these two behavior options matching and simple? From the git-config manpage I understand there are five such options:

  • nothing: If you don’t specify the remote, do nothing.
  • current: If you don’t specify the remote, push the current branch to a branch with the same name on the remote end. If a branch of the same name doesn’t exist at the remote end, create one.
  • upstream: If you don’t specify the remote, push the current branch to the branch you have designated as upstream. Note: this is similar to current just that the remote branch isn’t chosen based on one with the same name, it is chosen based on what you have set as the upstream branch. This is useful when the remote branch name is not the same as the local branch name.

    How do you set a branch as upstream? Use git branch --set-upstream-to. (Note: --set-upstream too works but is deprecated. You may also use -u instead of --set-upstream-to).

    Here’s an example. I have three branches for my repository: 0.1, master, and testing. All three branches exist both locally and remotely.

    Next I change the push policy to upstream and …

    The last example makes the difference between current and upstream very clear. If the push policy is set to current it always pushes to a branch of the same name on the remote end, and if such a branch doesn’t exist it creates one. This makes it impossible to have your local branch point to a differently named remote branch and issue git push without any further instructions and expect it to work. If that’s the behavior you want, be sure to set the push policy as upstream.

    As an aside: I found this and this – two useful posts from StackOverflow to understand the concept of an upstream remote. These in turn helped me understand why the push policy is called upstream and the scenarios where one might require such a policy. This GitHub help page too is worth a read.

  • simple: If you don’t specify the remote, push the current branch to a branch with the same name on the remote end. However, if a branch of the same name doesn’t exist at the remote end, a new one won’t be created. Thus simple is a cross between current and upstream – unlike current it does not create a new branch and unlike upstream it cannot push to a branch with a different name.

    Starting from Git 2.0 the simple will be the default for git push. This is the safest option and so considered beginner friendly.

  • matching: If you don’t specify the remote, push all branches having the same name on both ends.

    If a branch of the same name doesn’t exist at the remote end, create one.

    Currently matching is the default git push policy but starting with Git 2.0 it will be replaced with simple.

Good stuff! I’ve now set my default to simple.

Useful Sublime Text 2 stuff

Sublime Text 2 has packages – basically modules made by users that extend Sublime’s functionality.

Package Control is your friend when it comes to finding & installing such packages. Installation instructions are on the site. Once you install it and restart Sublime go to Preferences > Package Control and select Install Package to search for a package and install it.

A great feature of Sublime is that of viewing the same file in multiple panes. So I can open a file, view it in two panes side by side, and any edits I make in one pane will automatically reflect in the other. This is very useful when you have code all over the place in a large file. Without panes you’ll have to keep moving around, but with panes you can stay where you are in one pane and use the other pane to move to where you want to be.

To create a new view of a file go to File > New View into File. This will open a tab with the same file. Next, go to View > Layout and choose a layout (I prefer Columns:2). This will split the Sublime window into two columns. Then all you have to do is drag the tab with the new view into the newly created column, and you’ll have both views side by side! Nice.

Here are the packages I installed (will be updating this list as I add more):

  • Find Function Definition: Let’s me select a function name in my code and press F8 to find the function definition. I expected the package to search the currently open file(s) and find the function definition, but it does not work that way. You have to define a Project first as only files in current project are searched. I have all my code as various sub-folders of a folder anyway, so I just created a new Project by going to Project > Add Folder to Project and added this folder to the Project. Then I went to Project > Save Project As... and saved the Project so I can easily open it in future. I haven’t explored Projects much, but it seems to be a way of clubbing together multiple folders to create a project and defining common settings just for that project. When you save the Project two files are created, and this is the impression I got from looking at those files.
  • Origami: Makes the aforementioned task of creating new views etc very easy. Creates a menu under View > Origami (and defines keyboard shortcuts) to create new panes, clone the open file into the new pane, etc.

Good stuff!

Console2 and Sublime Text 2

Had read about Console2 (a command prompt application) and Sublime Text 2 (a code editor) on many blogs and decided to give them a try today.

Sublime Text 2 is straight-forward. (1) Download from here and install, (2) navigate to the folder where you installed it and then the Data\Packages folder within that, (3) create a folder called PowerShell there, (4) download this GitHub repostiry as a zip file, and (5) unzip it into the PowerShell folder previously created. Steps 2-5 are for adding PowerShell syntax highlighting to Sublime Text.

That’s just scratching the surface though. I’ve still got to explore why Sublime Text is so cool. It looks great if nothing else; I like the colors and fonts and just how it looks over all.

Console2 is also straight-forward. Download, install, and launch. Then go to Edit > Settings to tweak things. Here’s what I changed:

  • Under the Console section I set the Shell to PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) and the Startup directory to my folder containing code.
  • Under the same section I set the Window size to be 38×163. Arrived at this number by resizing the window with my mouse (the size appears in the bottom right corner of the status bar). That’s a cool thing about Console2 – you can resize it with the mouse!
  • Under the Appearance section I unticked Show command, Show command in tabs, and Tab titles. Ticked Use console window title. Set the font to Consolas size 12, with ClearType smoothing. Also I set the initial position to 45×58. Arrived at this number through trial and error for my screen.
  • Under the Appearance | More ... section I un-ticked Show menu/ toolbar/ status bar and also Tray icon. Set the Window transparency Alpha for both windows to 10. Number arrived at through trial and error.
  • Under the Behavior section I ticked Copy on select. This will give me the default PowerShell behavior which is to copy text to the clipboard when I select it. The cool thing is now it will work for the regular Command Prompt too!
  • Under the Hotkeys section I changed Copy selection to be Ctrl+X and Paste selection to be Ctrl+V. I really didn’t need to change the hotkey for Copy as just selecting text will copy it now thanks to the setting in the Behavior section. But it’s convenient to be able to Ctrl+V for paste. I didn’t set Ctrl+C as the hotkey for Copy as that would stop me from being able to interrupt commands via Ctrl+C.
  • Under the HotKeys | Mouse section I cleared the entry for Copy/ clear selection and assigned Left (without any modifiers) to Select text. This way I can just left click and select text with the mouse (and it will be automatically copied to the clipboard anyways thanks to the setting in the Behavior section). I assigned Right (without any modifiers) to Paste text, and Right with the Ctrl modifier to the Context menu. (Update: I have since changed my mind and assigned Paste as Right with Ctrl modifier (the default) and Context menu as Right (without any modifier) (the default). That way I don’t accidentally paste text by right clicking anywhere in the window).
  • Lastly, under the Tabs section I made removed the existing entry and made two. One called POSH, with C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe as the Shell and my code folder as the Startup dir (could skip the latter I guess as it’s set as the default earlier). And another called CMD, with C:\Windows\System32\cmd.exe as the Shell and my code folder as the Startup dir. For both these entries I set the Icon field too. You can only supply ICO files as icons, so I used IconsExtract to extract the icons from the PowerShell and command prompt executables and saved them as ICO files.

And that’s it.

A cool thing about Console2 is that the two tabs I defined above are just “types” of tabs.

Here I defined one tab of type PowerShell, another of type Command Prompt. I could create other types too – for say, the BASH shell, a script based menu, an SSH session (not PuTTY though, that opens a new window and crashes Console2) and so on. I can make up to 10 such tabs – or at least I can assign shortcuts for up to 10 such tabs – so using the default shortcuts I can press Ctrl+F1 and in my case that will create a new tab with PowerShell loaded. I can cycle through these tabs with Ctrl+Tab and Ctrl+Shift+Tab as usual and close these with Ctrl+W too. All hotkeys can be changed too. Neat!

Update: Console2 stores its configuration in a file called console.xml in the same folder as the program. I have uploaded my copy of this file, along with the two icons, here.

List remote Git branches

I used to think git branch -r was the way to go for finding remote branches.

Until today, when I was working on repository I hadn’t updated locally for a while and doing git branch -r gave me some older branch names that I was pretty sure I had deleted (and double checking GitHub confirmed that too).

Moreover shouldn’t git branch -r prompt for my SSH key when connecting to the repository? It doesn’t, so maybe the command’s just returning some cached info?

Turns out the accurate way of querying a remote repository is to use the git ls-remote command:

This does show the correct branches.

A better way to do this is to use the git remote command. This is easier to remember too and the output is more informative:

This command actually runs the git ls-remote command behind the scenes. If you want to see the cached information instead (what git branch -r was looking at) use the -n switch:

To remove the branches that are no longer present locally (stale branches) use the git remote prune command:

To summarize:

  • View current remote branches via git remote show origin
  • Prune stale local branches via git remote prune origin

Of course replace origin appropriately if your remote has a different name. The primary remote repository is usually given a friendly name origin.