Let's all take a moment of silence... git pull is dead.

Nice work. Love that aliases. And love that explanation of the risks.

@emgiezet I appreciate that thanks bro. I will be writing a series of protips on git. Keep on the lookout.

Nice!

BTW, I think you would achieve the same results with git symbolic-ref --short HEAD

@jussi-kalliokoski Thanks Bro :) glad you liked it.
In which way would git symbolic-ref --short HEAD achieve the same thing? The same as a git rebase -p? I'm interested to hear more.

How so?

If you in put git symbolic-ref --short HEAD into your shell it will just echo out to the current branch you are on.

example:

(cat) $ git symbolic-ref --short HEAD
cat

• you can see git just tells us that we are on a branch called cat.

• if we do the same in master

(master)$ git symbolic-ref --short HEAD
master

• and git tells us we are on master.

How are you using symbolic-ref to recover from an accidentally squashed merge commit?

I thought that if you create a new branch using symbolic-ref it starts a new git history for the new branch that no longer has any connection to the parent repository.

here is a tidbit from git community book

Creating New Empty Branches

Ocasionally, you may want to keep branches in your repository that do not share an ancestor with your normal code. Some examples of this might be generated documentation or something along those lines. If you want to create a new branch head that does not use your current codebase as a parent, you can create an empty branch like this:

git symbolic-ref HEAD refs/heads/newbranch 
rm .git/index 
git clean -fdx 
<do work> 
git add your files 
git commit -m 'Initial commit'

you can also achieve the same effect as using symbolic-ref to create empty branches, in git 1.7.2 + by using git checkout --orphan.

This also creates a root branch, or a branch without previous history.

• I am interested how you are using symbolic-ref ? I am always eager to know more about git.

• Here is an informative bit from SO

• and another similar thread also from SO

I would like to know your thoughts on all of the above.

apologies if this bored you to sleep. I wrote this comment with users in mind that might read this thread that are just starting with git.

• So if you use git symbolic-ref HEAD newbranch it will create a branch called newbranch which is an orphan root branch that no longer shares the same history as the parent repository.

Your thoughts?

@jwebcat: Oh heh, sorry, I didn't mean you could replace the whole thing with it, I meant you had this:

function git_current_branch() {
  git symbolic-ref HEAD 2> /dev/null | sed -e 's/refs\/heads\///'
}

Which could be simplified to use less processes:

function git_current_branch() {
  git symbolic-ref --short HEAD 2> /dev/null
}

;)

Also thanks for the tip that that git symbolic-ref can be used for creating an orphan branch, I've always used git checkout --orphan for that.

Speaking of orphans, you might find this gist interesting, it's something I made when I had to extract a single file from a repository to its own repository and I didn't want to include the history for other files. Perhaps you even have a better way to do it, I'm extremely interested in learning new things about git as well!

I also use git symbolic-ref for changing the HEAD of remote --bare repos (for those that don't know, the branch set as HEAD is used as default when you clone a repo), since you obviously can't git checkout:

$ git symbolic-ref HEAD refs/heads/my-branch

@jussi-kalliokoski I added your insights and referenced you bro thanks ;) see the edit to gitcurrentbranch above.

Currently I am hacking on your gist to see what comes of it. Let's see if we can refactor it at all.

I will reply to the gist in a bit.

great piece of information, that came in the perfect timing.
Thanks!

The problem isn't pull, it's rebase. Just don't use rebase (or git pull --rebase) and you'll be fine. Rebasing changes history, and the point of a VCS is to maintain history. If you use rebase, you'll need version control for your VCS—that is, Git won't maintain an unaltered record of what came before, which means it's no longer a proper VCS. Rebase looks like it works, but is an accident waiting to happen. Banish it from your Git vocabulary.

Thanks a lot for the post - very interesting! One comment though - it seems that -p does preserve merge history, but it modifies the recreated commit from which the merge was performed. Below is an example (a bit long) flow that illustrates this issue (output of most commands was removed, only the relevant output was included) - the preserved commit contains the merge result, and not the initial commit as on the feature branch:

git init --bare /tmp/rebase

git clone /tmp/rebase /tmp/rebaseclone1

git clone /tmp/rebase /tmp/rebaseclone2

cd /tmp/rebase_clone1

touch file.txt

git add .

git commit -m 'added file.txt'

git push origin master

cd /tmp/rebase_clone2

git pull

git checkout -b feature

echo 2 file.txt

git commit -a -m 'wrote 2'

git checkout master

git merge --no-ff feature

git logk  # logk is an alias for nicely formatted log command.

*   f55163e - (HEAD, master) Merge branch 'feature' (43 seconds ago) <Alex Pulver>

|\

| * 2b51d05 - (feature) wrote 2 (43 seconds ago) <Alex Pulver>

|/

* 34edfbc - (origin/master) added file.txt (43 seconds ago) <Alex Pulver>

cd /tmp/rebase_clone1

echo 1 file.txt

git commit -a -m 'wrote 1'

git push origin master

cd /tmp/rebase_clone2

git push origin master

To /tmp/rebase

 ! [rejected]        master -master (fetch first)

error: failed to push some refs to '/tmp/rebase'

...

git fetch

git logk --all

* 7abff92 - (origin/master) wrote 1 (2 minutes ago) <Alex Pulver>

| *   f55163e - (HEAD, master) Merge branch 'feature' (5 minutes ago) <Alex Pulver>

| |\

|/ /

| * 2b51d05 - (feature) wrote 2 (5 minutes ago) <Alex Pulver>

|/

* 34edfbc - added file.txt (5 minutes ago) <Alex Pulver>

git rebase -p origin/master

error: could not apply 2b51d05... wrote 2

...

pico file.txt  # resolve the conflicts.

git add file.txt

git rebase --continue

git logk --all

*   a7e3457 - (HEAD, master) Merge branch 'feature' (86 seconds ago) <Alex Pulver>

|\

| * 4528467 - wrote 2 (2 minutes ago) <Alex Pulver>

|/

* 7abff92 - (origin/master) wrote 1 (5 minutes ago) <Alex Pulver>

| * 2b51d05 - (feature) wrote 2 (8 minutes ago) <Alex Pulver>

|/

* 34edfbc - added file.txt (8 minutes ago) <Alex Pulver>

git checkout 4528467

cat file.txt

1

2

git checkout 2b51d05

cat file.txt

2

</pre>

@marnen you're right and you're wrong. There's nothing wrong with rebasing a topic branch that only you've worked on to squash it down to change sets that actually make sense and/or to rebase it on top of master before sharing it with others. However, if you really don't want to have a pull erase a merge you've made, then you're right, you shouldn't be doing git pull --rebase. Keep master clean until you're ready to push. This means don't run git merge --no-ff mybranch until you've just run git pull on master. If you didn't do that, then fine, but still don't run git pull --rebase, just do a normal git pull and you'll have an extra merge commit, but that's kind of what you asked for.

@onlynone The latter approach is mostly the way I use Git. Although I do very occasionally rebase topic branches, I'd normally much rather have an extra merge commit than a false history.