rebase

The rebase extension to mercurial provides functionality similar to git's rebase . Letting the rebase execute takes something like 4 minutes (~240 s) for 100 commits. In my imagination this should be extremely fast, a few seconds at most, but clearly I'm missing something. What makes it take so long? Are the commits themselves just extremely expensive? Khanchi97 By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance, and to allow it to run if the working copy is dirty. Just add following lines in your .hgrc file: [rebase] experimental

I thought a file created on one branch will not appear in any other branches until I merge or rebase the branch? Example: I have two branches: master new_contact_page I checkout the new_contact_page branch. $ git checkout new_contact_page Then I create a new file. $ vi contact_page.html Without doing any Git commands, I switch back to my Master branch. $ git checkout master Then I see that this contact_page.html file is also in my Master branch. $ ls (contact_page.html shows up in the list!) Shouldn't the file only exist in new_contact_page branch? Git will never touch any files that aren't

I'm observing very strange crashes in git rebase. Operations that I'm performing haven't change, but their result has changed since some time ago. Instead of rebased branch I get help message from git rebase, describing command line options, and file bash.exe.stackdump with some hex numbers. The same behavior is observed during execution of git pull --rebase . Rebasing pulled commits is my default setting therefore this misbehavior is very annoying. Example: $ git rebase master feature/tune-logging usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] or:

So I'm more or less familiar with how rebasing works, but up until recently I usually just did a git rebase -i HEAD~20 , and modified whatever needed to be modified. I was surprised to learn that this will modify the hashes of all 20 commits, even if the only action I take is to squash the last two. I'm not sure what causes the hash change for the other 18 commits though, since neither their parents, neither their contents change... Or does it? Maybe a timestamp? Also is there a way to prevent that? this will modify the hashes of all 20 commits, even if the only action I take is to squash the

I have 2 branches, master & feature . Master occasionally receives small tweaks that are needed to go live quickly. Once these tweaks are done, master is rebased into feature so that feature is kept up to date. The files changed on master are generally not related to the bulk of the development on feature but I've been getting a high number of complicated 3 way merge conflicts. After looking at the commit log of feature , I've found the problem to be several duplicates and I'm attempting to solve it with an interactive rebase. My question is: Is this the best solution for the problem, and if

I'm looking for a good description of what happens if one commits during rebase and how this could be 'reverted' in an easy way. Let's consider a scenario, where a large commit is rebased. During rebase a conflict appears and user begins merging changes. Now, imagine a scenario where you were almost done, but you didn't call git rebase --continue - for whatever reason (be it long weekend or such). The next week you just resumed working, stil during rebase. Finally, you call git commit --amend to append the changes to the last commit and... they end up in the commit you were rebasing into.

I'm in the middle of a large "rebase in progress" with numerous conflicts . I would like to set this progress aside and attempt to resolve this issue using another approach. Is there a way I can save an in-progress rebase such that I can finish it later? If you're sitting at a conflicted merge as part of a rebase, you are kind of stuck. Here is why, how, and what you can do. Rebase = repeated cherry-pick Fundamentally, a rebase operation in Git is just a series of cherry-pick operations. We start with something like this: ...--A1--A2--A3--A4--A5 <-- branchA \ B1--B2--B3 <-- branchB and we want

Following on the scenario from this question, I'm performing a git rebase -s recursive -X theirs etc... and am surprised to be stopped with the following types of conflicts: added by them deleted by them deleted by us Is there some reason the strategy doesn't cope with these? (I don't know if this is significant, but git doesn't report conflicts in the output, it just says When you have resolved this problem run "git rebase --continue" ) UPDATE Here's a script that doesn't quite reproduce, but nearly: git init git symbolic-ref HEAD refs/heads/Branch1 #just to get the 'right' branch name echo

I have my feature branch which has exceeded around 30 or more commits. Meanwhile in development branch few other features have been pushed from other developers. Therefore, Everytime a new feature is published on development, I am asked to: Rebase development branch onto my feature branch Resolve conflicts if any Continue developing in your feature branch The problem The second step is the chicken's neck here. On rebasing it gives me conflicts for every commit of that branch. This is really iterative and redundant. Note, I can't always rebase the development branch immediately since my own