git-rebase

I work with a small team that uses git for source code management. Recently, we have been doing topic branches to keep track of features then merging them into master locally then pushing them to a central git repository on a remote server. This works great when no changes have been made in master: I create my topic branch, commit it, merge it into master, then push. Hooray. However, if someone has pushed to origin before I do, my commits are not fast-forward. Thus a merge commit ensues. This also happens when a topic branch needs to merge with master locally to ensure my changes work with the

Short version: Do you need to preserve-merges only if you explicitly merged after you did a local commit? What exactly happens otherwise? Does it reapply your committed code to the merged branch? Please explain when it is useful to git pull --rebase --preserve-merges vs. a regular git pull --rebase ? I read about an issue with git pull --rebase here: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ That could cause code changes to be duplicated. I read here: When will `git pull --rebase` get me in to trouble? That it only happens if you basically rebase after some the commits

I have a git tree with a lot of commits and a lot of files. Now, I want to revert specific commits that touch a file only. To explain: > git init Initialized empty Git repository in /home/psankar/specific/.git/ > echo "File a" > a > git add a ; git commit -m "File a" [master (root-commit) 5267c21] File a 1 file changed, 1 insertion(+) create mode 100644 a > echo "File b" > b > git add b; git commit -m "File b" [master 7b560ae] File b 1 file changed, 1 insertion(+) create mode 100644 b > echo "File c" > c > git add c; git commit -m "File c" [master fd6c132] File c 1 file changed, 1 insertion(+)

Story: in the middle of a project my colleague created a new branch from master and started doing her heavy re-factoring work. I created my branch from master and started doing new stuff on the page. We are committing regularly, but only I can rebase code to master (because colleagues changes are too heavy and cannot be deployed from master yet). Unfortunately some of our work rely on the same files. So after few days of work when she finally wanted to rebase her changes to master , she had a lot of git conflicts. my_branch #---#----#-#-------#----#--#-----#---#----#----# / \ \ \ \ \ \ master

As Git user I regular come across the situation, that I need to rework one or more commits in a way which do not fit into --amend or rebase -i with fixup commits. Typically I would do something like git reset HEAD~1 # hack, fix, hack git commit -a # argh .. do I need to retype my message? I take sensible composed commit messages quite serious. They typically contain larger text with references & justifications for the change. Until now, I'm quite annoyed on the lengthy process to recover my old commit message via an unsorted git reflog , git log and copy & paste process. Is there a better to

I have reorganized the commits in a branch before it is going to be made public causing the timestamps of the commits to be in an mixed up order. I would rather have them be all be today with only seconds in between. Obviously these time stamps won't be correct either, but since this is the time when things go public I prefer that over a mixed up history, time-wise. So how do I tell git to create new timestamps while rebasing? git rebase --ignore-date In my case rebasing changed timestamps to CommitDate value, so in gitweb a bunch of months old commits showed up as 4 days old. I found the last

In an attempt to achieve git nirvana, I'm spending the day learning how to leverage rebase for situations where I currently merge. When running through what I consider to be a git 101 flow (which I spell out below), I have to push --force when pushing my changes back to the origin. I'm not the only one - I know that this is covered ground (see 1 , 2 , 3 , 4 , 5 ), and I understand the technical reasons why a force is necessary. My issue is this --- there are many (many) blog entries singing the praises of rebase and how it's changed their lives (see 1 , 2 , 3 , 4 to list a few), but none of

Okay. If I'm on a branch (say working ), and I want to merge in the changes from another branch (say master ), then I run the command git-merge master while on the working branch, and the changes get merged in without rebasing the history at all. If I run git-rebase master , then the changes in master are rebased to be put on the top of my working branch. But what if I want to merge in the changes from master but rebase my changes in working to be on top? How do I do that? Can it be done? I could run git-rebase working on my master branch to put my changes on top in the master branch, but I'd

I have conflicting branches, branch2 branched from branch1. Let's say when rebasing branch2 on current branch1 , while resolving conflicts, I decide to take some (not all) of "their" (i.e. branch1 ) files as-is. How do I do that? I tried: git checkout branch1:foo/bar.java fatal: reference is not a tree: TS-modules-tmp:foo/bar.java git checkout refs/heads/branch1:foo/bar.java fatal: reference is not a tree: refs/heads/TS-modules-tmp:foo/bar.java iGEL You want to use: git checkout --ours foo/bar.java git add foo/bar.java If you rebase a branch feature_x against master (i.e. running git rebase