Check `git reflog`.  You can walk back in time using those commit hashes as a reference in almost all cases.  

I&#39;d also physically copy the git repo directory elsewhere as a place to do preliminary testing to see what will work, that way you can mess with whatever you want without losing untracked files or getting things into a state that you **can&#39;t** come back from.

You should be able to get the SHA1 of your most recent commits (that disappeared after the `git rebase --abort`) with a [`git reflog`][1].

You will be able then to reset your current branch to those SHA1

    # Suppose the old commit was HEAD@{2} in the ref log
    git reset --hard HEAD@{2}

It is a bit like &quot;[Undoing a `git reset --hard HEAD~1`][2]&quot;.

See also the &quot;[illustrated guide to recovering lost commits with Git][3]&quot;, for other examples of recovery.


  [1]: https://stackoverflow.com/questions/134882/undoing-a-git-rebase/135614#135614
  [2]: https://stackoverflow.com/questions/5473/undoing-a-git-reset-hard-head1
  [3]: https://web.archive.org/web/20081220194200/http://programblings.com/2008/06/07/the-illustrated-guide-to-recovering-lost-commits-with-git/#post-50

Is there a [package manager][1] for Java like [easy_install][2] for Python ?  
I&#39;m looking for a solution usable from the command line and not from an IDE.


  [1]: http://en.wikipedia.org/wiki/Package_manager
  [2]: http://en.wikipedia.org/wiki/Easy_install

Is there a package manager for Java like easy_install for Python?

In MySQL database context, what is the difference among these 3 terms:

* *stored procedure*
* *stored function*
* *stored routine*

Also the build-in functions like those date time functions (e.g. `WEEKDAY()` etc) are considered as what?

What&#39;s the differences between stored procedures, functions and routines?

Crap! About a week ago, I was rebasing some commits while trying to clean up my repository, and apparently I didn&#39;t actually finish it. Today, a week and several commits later, I went to rebase to reorder a few commits from today, and it told me I was already in the middle of a rebase.

That should have been a cue to copy my repo just in case. But I did not...instead I ran `git rebase --abort` which sounded right at the time. Well, that was not right. It aborted the rebase from a week ago and reset master&#39;s HEAD to the old one. Dummy!

I&#39;ve got several other branches that are fairly recent, and I&#39;ve pushed to remote several times, but the most recent changes appear to be gone forever. I don&#39;t possess the appropriate level of git-fu to know if there&#39;s any way to recover my changes.

Am I screwed?

**EDIT** - WOW! Thanks guys! `git reflog` is awesome! I&#39;m fully recovered...lesson learned. Marking Tchalvak&#39;s answer accepted for being the first to post.


Aborted old git rebase and lost commits since the rebase started

Crap! About a week ago, I was rebasing some commits while trying to clean up my repository, and apparently I didn't actually finish it. Today, a week and several commits later, I went to rebase to reorder a few commits from today, and it told me I was already in the middle of a rebase.
That should have been a cue to copy my repo just in case. But I did not...instead I ran <code>git rebase --abort</code> which sounded right at the time. Well, that was not right. It aborted the rebase from a week ago and reset master's HEAD to the old one. Dummy!
I've got several other branches that are fairly recent, and I've pushed to remote several times, but the most recent changes appear to be gone forever. I don't possess the appropriate level of git-fu to know if there's any way to recover my changes.
Am I screwed?
EDIT - WOW! Thanks guys! <code>git reflog</code> is awesome! I'm fully recovered...lesson learned. Marking Tchalvak's answer accepted for being the first to post.

I need to search the history of a specific file in a git repository to find a line that is gone.  The commit message will not have any relevant text to search on.  What command do I use?

Further details: this is the history of my todo list out of our non-stellar task tracking software.  I&#39;ve been keeping it for two years because there&#39;s just not enough information kept for me in the software.  My commit messages usually have only the task ids, unfortunately, and what I need to do is find a closed task by subject, not by number.  Yes, the real solution is better task tracking software, but that is completely out of my hands.

How do I search git history for a disappeared line?

I have a desktop application using git for synchronization. I have also an android application which do the same as the desktop, but I don&#39;t know how to do the synchronization part on it. I haven&#39;t found any implementation of git on android. I found a jgit, but its unwell documented and I was not able to do even a commit with that. 

I was thinking about remote commands to my git server from my android app, but this is really a tease for me. 
Could you tell me if any other git implementation which can be used on android exists? If you have any idea how to solve that, please tell me. 


How to use Git on Android?

I have a large website that I am moving into a new framework and in the process adding git. The current site doesn&#39;t have any version control on it.

I started by copying the site into a new git repository. I made a new branch and made all of the changes that were needed to make it work with the new framework. One of those steps was changing the file extension of all of the pages.

Now in the time that I have been working on the new site changes have been made to files on the old site. So I switched to master and copied all of those changes in.

The problem is when I merge the branch with the new framework back onto master there is a conflict on every file that was changed on the master branch.

I wouldn&#39;t be to worried about it but there are a couple of hundred files with changes. I have tried `git rebase` and `git rebase --merge` with no luck.

How can I merge these 2 branches without dealing with every file?

git merge with renamed files

I cloned a git repo that I have hosted on github to my laptop.  I was able to successfully push a couple of commits to github without problem.  However, now I get the following error: 

    Compressing objects: 100% (792/792), done.
    error: RPC failed; result=22, HTTP code = 411
    Writing objects: 100% (1148/1148), 18.79 MiB | 13.81 MiB/s, done.
    Total 1148 (delta 356), reused 944 (delta 214)
    

From here it just hangs and I finally have to &lt;kbd&gt;CTRL&lt;/kbd&gt; + &lt;kbd&gt;C&lt;/kbd&gt; back to the terminal.

Git fails when pushing commit to github

I&#39;d like to learn other people workflow when using either vcs or dvcs.  

Please describe your strategy to handle the following tasks:

 - Implement a feature
 - Fixing bugs (during development and deployed app)
 - Code Review
 - Refactoring code (post code-review)
 - Incorporate patches
 - Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?)

Feel free to organize your answer not grouped by the tasks but grouped by whatever you think is relevant but please organize it by VCS/DVCS (please don&#39;t mix them). 

Thank you.

Describe your workflow of using version control (VCS or DVCS)

`git-rebase` man page mentions `-X&lt;option&gt;` can be passed to `git-merge`. When/how exactly?

I&#39;d like to rebase by applying patches with *recursive* strategy and *theirs* option (apply whatever sticks, rather than skipping entire conflicting commits). I don&#39;t want merge, I want to make history linear.

I&#39;ve tried:

&lt;!-- language: sh --&gt;

    git rebase -Xtheirs

and

&lt;!-- language: sh --&gt;

    git rebase -s &#39;recursive -Xtheirs&#39;

but git rejects `-X` in both cases.

----

`git rebase -Xtheirs` works in recent versions, except tree conflicts need to be resolved manually. You need to run `git rebase -Xtheirs --continue` (with `-X` repeated) after resolving those conflicts.

How do I select a merge strategy for a git rebase?

Would it make sense to perform `git rebase` while preserving the commit timestamps?

I believe a consequence would be that the new branch will not necessarily have commit dates chronologically. Is that *theoretically* possible at all? (e.g. using plumbing commands; just curious here)

If it is theoretically possible, then is it possible in practice with rebase, not to change the timestamps?

For example, assume I have the following tree:

    master &lt;jun 2010&gt;
      |
      :
      :
      :     oldbranch &lt;feb 1984&gt;
      :     /
    oldcommit &lt;jan 1984&gt;

Now, if I rebase `oldbranch` on `master`, the date of the commit changes from feb 1984 to jun 2010. Is it possible to change that behaviour so that the commit timestamp is not changed? In the end I would thus obtain:

          oldbranch &lt;feb 1984&gt;
          /
     master &lt;jun 2010&gt;
        |
        :

Would that make sense at all? Is it even allowed in git to have a history where an old commit has a more recent commit as a parent?

git rebase without changing commit timestamps

We have a Git repository with over 400 commits, the first couple dozen of which were a lot of trial-and-error. We want to clean up these commits by squashing many down into a single commit. Naturally, git-rebase seems the way to go. My problem is that it ends up with merge conflicts, and these conflicts are not easy to resolve. I don&#39;t understand why there should be any conflicts at all, since I&#39;m just squashing commits (not deleting or rearranging). Very likely, this demonstrates that I&#39;m not completely understanding how git-rebase does its squashes.

Here&#39;s a modified version of the scripts I&#39;m using:

-----
repo_squash.sh (this is the script that is actually run):

-----

    rm -rf repo_squash
    git clone repo repo_squash
    cd repo_squash/
    GIT_EDITOR=../repo_squash_helper.sh git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

-----
repo_squash_helper.sh (this script is used only by repo_squash.sh):

-----

    if grep -q &quot;pick &quot; $1
    then
    #  cp $1 ../repo_squash_history.txt
    #  emacs -nw $1
      sed -f ../repo_squash_list.txt &lt; $1 &gt; $1.tmp
      mv $1.tmp $1
    else
      if grep -q &quot;initial import&quot; $1
      then
        cp ../repo_squash_new_message1.txt $1
      elif grep -q &quot;fixing bad import&quot; $1
      then
        cp ../repo_squash_new_message2.txt $1
      else
        emacs -nw $1
      fi
    fi

-----
repo_squash_list.txt: (this file is used only by repo_squash_helper.sh)

-----

    # Initial import
    s/pick $251a190$/squash \1/g
    # Leaving &quot;Needed subdir&quot; for now
    # Fixing bad import
    s/pick $46c41d1$/squash \1/g
    s/pick $5d7agf2$/squash \1/g
    s/pick $3da63ed$/squash \1/g

-----

I&#39;ll leave the &quot;new message&quot; contents to your imagination. Initially, I did this without the &quot;--strategy theirs&quot; option (i.e., using the default strategy, which if I understand the documentation correctly is recursive, but I&#39;m not sure which recursive strategy is used), and it also didn&#39;t work. Also, I should point out that, using the commented out code in repo_squash_helper.sh, I saved off the original file that the sed script works on and ran the sed script against it to make sure it was doing what I wanted it to do (it was). Again, I don&#39;t even know why there *would* be a conflict, so it wouldn&#39;t seem to matter so much which strategy is used. Any advice or insight would be helpful, but mostly I just want to get this squashing working.

Updated with extra information from discussion with Jefromi:
---

Before working on our massive &quot;real&quot; repository, I used similar scripts on a test repository. It was a very simple repository and the test worked cleanly.

The message I get when it fails is:

    Finished one cherry-pick.
    # Not currently on any branch.
    nothing to commit (working directory clean)
    Could not apply 66c45e2... Needed subdir

This is the first pick after the first squash commit. Running `git status` yields a clean working directory. If I then do a `git rebase --continue`, I get a very similar message after a few more commits. If I then do it again, I get another very similar message after a couple dozen commits. If I do it yet again, this time it goes through about a hundred commits, and yields this message:

    Automatic cherry-pick failed.  After resolving the conflicts,
    mark the corrected paths with &#39;git add &lt;paths&gt;&#39;, and
    run &#39;git rebase --continue&#39;
    Could not apply f1de3bc... Incremental

If I then run `git status`, I get:

    # Not currently on any branch.
    # Changes to be committed:
    #   (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)
    #
    # modified:   repo/file_A.cpp
    # modified:   repo/file_B.cpp
    #
    # Unmerged paths:
    #   (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)
    #   (use &quot;git add/rm &lt;file&gt;...&quot; as appropriate to mark resolution)
    #
    # both modified:      repo/file_X.cpp
    #
    # Changed but not updated:
    #   (use &quot;git add/rm &lt;file&gt;...&quot; to update what will be committed)
    #   (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)
    #
    # deleted:    repo/file_Z.imp

The &quot;both modified&quot; bit sounds weird to me, since this was just the result of a pick. It&#39;s also worth noting that if I look at the &quot;conflict&quot;, it boils down to a single line with one version beginning it with a [tab] character, and the other one with four spaces. This sounded like it might be an issue with how I&#39;ve set up my config file, but there&#39;s nothing of the sort in it. (I did note that core.ignorecase is set to true, but evidently git-clone did that automatically. I&#39;m not completely surprised by that considering that the original source was on a Windows machine.)

If I manually fix file_X.cpp, it then fails shortly afterward with another conflict, this time between a file (CMakeLists.txt) that one version thinks should exist and one version thinks shouldn&#39;t. If I fix this conflict by saying I do want this file (which I do), a few commits later I get another conflict (in this same file) where now there&#39;s some rather non-trivial changes. It&#39;s still only about 25% of the way through the conflicts.

I should also point out, since this might be very important, that this project started out in an svn repository. That initial history very likely was imported from that svn repository.

Update #2:
----

On a lark (influenced by Jefromi&#39;s comments), I decided to do the change my repo_squash.sh to be:

    rm -rf repo_squash
    git clone repo repo_squash
    cd repo_squash/
    git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

And then, I just accepted the original entries, as is. I.e., the &quot;rebase&quot; shouldn&#39;t have changed a thing. It ended up with the same results describe previously.

Update #3:
---

Alternatively, if I omit the strategy and replace the last command with:

    git rebase -i bd6a09a484b8230d0810e6689cf08a24f26f287a

I no longer get the &quot;nothing to commit&quot; rebase problems, but I&#39;m still left with the other conflicts.

Update with toy repository that recreates problem:
---

test_squash.sh (this is the file you actually run):

    #========================================================
    # Initialize directories
    #========================================================
    rm -rf test_squash/ test_squash_clone/
    mkdir -p test_squash
    mkdir -p test_squash_clone
    #========================================================
    
    #========================================================
    # Create repository with history
    #========================================================
    cd test_squash/
    git init
    echo &quot;README&quot;&gt;README
    git add README
    git commit -m&quot;Initial commit: can&#39;t easily access for rebasing&quot;
    echo &quot;Line 1&quot;&gt;test_file.txt
    git add test_file.txt
    git commit -m&quot;Created single line file&quot;
    echo &quot;Line 2&quot;&gt;&gt;test_file.txt 
    git add test_file.txt 
    git commit -m&quot;Meant for it to be two lines&quot;
    git checkout -b dev
    echo Meaningful code&gt;new_file.txt
    git add new_file.txt 
    git commit -m&quot;Meaningful commit&quot;
    git checkout master
    echo Conflicting meaningful code&gt;new_file.txt
    git add new_file.txt 
    git commit -m&quot;Conflicting meaningful commit&quot;
    # This will conflict
    git merge dev
    # Fixes conflict
    echo Merged meaningful code&gt;new_file.txt
    git add new_file.txt
    git commit -m&quot;Merged dev with master&quot;
    cd ..
    
    #========================================================
    # Save off a clone of the repository prior to squashing
    #========================================================
    git clone test_squash test_squash_clone
    #========================================================
    
    #========================================================
    # Do the squash
    #========================================================
    cd test_squash
    GIT_EDITOR=../test_squash_helper.sh git rebase -i HEAD@{7}
    #========================================================
    
    #========================================================
    # Show the results
    #========================================================
    git log
    git gc
    git reflog
    #========================================================

test_squash_helper.sh (used by test_sqash.sh):

    # If the file has the phrase &quot;pick &quot; in it, assume it&#39;s the log file
    if grep -q &quot;pick &quot; $1
    then
      sed -e &quot;s/pick $.*$ $Meant for it to be two lines$/squash \1 \2/g&quot; &lt; $1 &gt; $1.tmp
      mv $1.tmp $1
    # Else, assume it&#39;s the commit message file
    else
    # Use our pre-canned message
      echo &quot;Created two line file&quot; &gt; $1
    fi


P.S.: Yes, I know some of you cringe when you see me using emacs as a fall-back editor.

P.P.S.: We do know we&#39;ll have to blow away all of our clones of the existing repository after the rebase. (Along the lines of &quot;thou shalt not rebase a repository after it&#39;s been published&quot;.)

P.P.P.S: Can anyone tell me how to add a bounty to this? I&#39;m not seeing the option anywhere on this screen whether I&#39;m in edit mode or view mode.




Why does git-rebase give me merge conflicts when all I&#39;m doing is squashing commits?

[Another question][1] says that `git pull` is like a `git fetch` + `git merge`.

But what is the difference between `git pull` and `git fetch` + `git rebase`?

  [1]: https://stackoverflow.com/questions/292357/whats-the-difference-between-git-pull-and-git-fetch

What is the difference between git pull and git fetch + git rebase?

I managed to create a little mess in my local git repository. I was trying to fix a broken commit by using the [following instructions][1]. Before running the &quot;git commit --amend&quot; (and after the git rebase --interactive) I decided that my changes were incorrect and so I executed &quot;git reset HEAD --hard&quot;. Not a good idea, I tell you.

Now the interactive rebase seems to be &quot;stuck&quot;. Git shows the current branch as (|REBASE-m). Every command (cd .., ls, git rebase...) inside my repository gives the following error:

&gt; cat: .git/rebase-merge/head-name: No such file or directory

Here&#39;s how git rebase --abort looks like:

    $ git rebase --abort
    cat: c:/_work/project/src/git/.git/rebase-merge/quiet: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/head-name: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/orig-head: No such file or directory
    HEAD is now at 4c737fb Revert &quot;Modified file names&quot;
    rm: cannot remove `c:/_work/project/src/git/.git/rebase-merge/done&#39;: Permission denied
    rm: cannot remove directory `c:/_work/project/src/git/.git/rebase-merge&#39;: Directory
    not empty
    cat: .git/rebase-merge/head-name: No such file or directory

Here&#39;s the result of git rebase --continue:

    $ git rebase --continue
    cat: c:/_work/project/src/git/.git/rebase-merge/prev_head: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/end: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/msgnum: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/onto: No such file or directory
    cat: c:/_work/project/src/git/.git/rebase-merge/quiet: No such file or directory
    prev_head must be defined
    cat: .git/rebase-merge/head-name: No such file or directory

Any ideas? I would like to reset the situation back to the state it was before I started my well-thought rebase operation.

Here&#39;s how git log --oneline shows the situation:

    4c737fb Revert &quot;Modified file names&quot;
    247ac02 Modified file names
    33141e6 Message modifications
    10a4a04 Modified db script

And this is fine. 

I&#39;m using msysgit v1.7.0.2.

  [1]: https://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit

Content Type	Original Author	Original Content on Stackoverflow
Question	Dan Breen	View Question on Stackoverflow
Solution 1 - Git	Kzqai	View Answer on Stackoverflow
Solution 2 - Git	VonC	View Answer on Stackoverflow

Aborted old git rebase and lost commits since the rebase started

Git Problem Overview

Git Solutions

Solution 1 - Git

Solution 2 - Git

What's the differences between stored procedures, functions and routines?

Is there a package manager for Java like easy_install for Python?

Attributions