rebase

Can I rebase a Git branch without modifying my working copy?

╄→гoц情女王★ 提交于 2019-11-28 19:04:41
Suppose I have my "master" branch checked out. I've committed some production changes to "master", and now I want to rebase my "experimental" branch onto the latest master. But, I want to do this without modifying any files in my working copy. Essentially, I want all the magic to happen inside the .git directory, without touching the working copy. If not for the "don't modify my working copy" requirement, this would just be a matter of doing: # current branch is master git checkout experimental git rebase master git checkout master My real problem is that this modifies timestamps in my working

git rebase fatal: Needed a single revision

人走茶凉 提交于 2019-11-28 17:07:25
I have a branch of a public repository and I am trying to update my branch with the current commits from the original repository: $ git fetch <remote> remote: Counting objects: 24, done. remote: Compressing objects: 100% (20/20), done. remote: Total 20 (delta 12), reused 0 (delta 0) Unpacking objects: 100% (20/20), done. From git://github.com/path_to/repo 9b70165..22127d0 master -> $/master $ git rebase <remote> fatal: Needed a single revision invalid upstream <remote> The <remote> is in place of my remote name and is not actually my remote name. The documentation on this error seems to be a

How to move some changeset to a new branch in mercurial

房东的猫 提交于 2019-11-28 16:29:20
I want to move a changeset from one branch to another. Basically, I currently have: A -> B -> C -> D # default branch And I want: A # default branch \-> B -> C -> D # some_new_branch Where some_new_branch does not exist yet. I am used to git, so I guess there is a simple "mercurial" way I am missing. One way is to export a patch for B,C,D; update to A; branch; apply patch: hg export -o patch B C D hg update A hg branch branchname hg import patch To remove B,C,D from the default branch, use the mq extension's strip command. crazyscot Sounds a bit like a cherry-pick operation in git. The

Git Workflows: Rebasing Published/Shared Branches

瘦欲@ 提交于 2019-11-28 16:26:53
问题 Our team at work has enthusiastically adopted a rebase workflow, but we might have gotten a little carried away, which is the point of this question: you be the judge. Using pull --rebase is a no-brainer to me now. However, we also have large feature branches that multiple people work on. Periodically, we want to bring in changes that are happening on master. Conventional wisdom would have us merge since it's a shared branch. However, in our rebase-obsession, we've decided to rebase those

How to abort an interactive rebase if --abort doesn't work?

天涯浪子 提交于 2019-11-28 16:06:32
问题 I've got myself into a muddle via an interactive rebase, and I now wish to abort it. (i.e. go back to the point before I was dropped into interactive rebase mode, in my case via git pull --rebase .) The way to do this seems to be via git rebase --abort , but this doesn't work: $ git rebase --abort error: Ref refs/heads/master is at 55b388c141b1485b1acd9e050dbeb0eb90ef2ee7 but expected b918ac16a33881ce00799bea63d9c23bf7022d67 fatal: Cannot lock the ref 'refs/heads/master'. Could not move back

Edit a merge commit with git rebase

◇◆丶佛笑我妖孽 提交于 2019-11-28 15:43:14
In Git when I have commits eg. A - B - C and I want to edit the B commit, I use git rebase -i <A-commit-hash> , in the list I write edit command in front of B commit, git rebase stops right after B commit so I can fix anything I want using git commit --amend , and then I continue using git rebase --continue . As far as I know this is the best practice how to do this. With this method I can edit any commit in the past (as long as it hasn't been pushed to remote branch yet), and moreover with -p flag I can even preserve the merges. This is just great. My current problem is: I did a mistake (typo

Git: How to rebase to a specific commit?

风流意气都作罢 提交于 2019-11-28 15:21:50
I'd like to rebase to a specific commit, not to a HEAD of the other branch: A --- B --- C master \ \-- D topic to A --- B --- C master \ \-- D topic instead of A --- B --- C master \ \-- D topic How can I achieve that? Adam Dymitruk You can avoid using the --onto parameter by making a temp branch on the commit you like and then use rebase in it's simple form: git branch temp master^ git checkout topic git rebase temp git branch -d temp r0hitsharma You can even take a direct approach: git checkout topic git rebase <commitB> Adam Dymitruk Use the "onto" option: git rebase --onto master^ D^ D The

Change old commit message on Git

◇◆丶佛笑我妖孽 提交于 2019-11-28 15:07:55
I was trying to edit an old commit message as explained here . The thing is that now, when I try to run rebase -i HEAD~5 it says interactive rebase already started . So then I try: git rebase --continue but got this error: error: Ref refs/heads/master is at 7c1645b447a8ea86ee143dd08400710c419b945b but expected c7577b53d05c91026b9906b6d29c1cf44117d6ba fatal: Cannot lock the ref 'refs/heads/master'. Any ideas? VonC It says: When you save and exit the editor, it will rewind you back to that last commit in that list and drop you on the command line with the following message: $ git rebase -i HEAD

What does 'git remote add upstream' help achieve?

寵の児 提交于 2019-11-28 14:24:43
问题 I was reading on: https://wiki.diasporafoundation.org/Git_workflow#Rebase_your_development_branch_on_the_latest_upstream Here is an extract: Your Repository Up to Date In order to get the latest updates from the development trunk do a one-time setup to establish the main GitHub repo as a remote by entering: $ git remote add upstream git://github.com/diaspora/diaspora.git Rebase Your Development Branch on the Latest Upstream To keep your development branch up to date, rebase your changes on

How to squash/rebase in a single shot

a 夏天 提交于 2019-11-28 13:14:00
How can I, with minimum effort, squash all my commits (even with merges and conflict resolutions) to a single one on a feature branch and then rebase on top of the branch where I started developing from? Don't want to redo conflict resolution that's already done . Keep hassle to a minimum. Suppose the branches we are talking about are master and featureX. The simplest way I know is git checkout featureX git merge -m "Bring latest changes from master" master # magic starts here git reset --soft master # put featureX branch pointer on top of master tip # at this point all the changes related to