summaryrefslogtreecommitdiff
path: root/git-rebase.sh
AgeCommit message (Collapse)AuthorFilesLines
2006-11-21remove merge-recursive-oldLibravatar Junio C Hamano1-9/+0
This frees the Porcelain-ish that comes with the core Python-free. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-04git-rebase: Add a -v option to show a diffstat of the changes upstream at ↵Libravatar Robert Shearman1-1/+11
the start of a rebase. Signed-off-by: Robert Shearman <rob@codeweavers.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-04git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.Libravatar Robert Shearman1-1/+1
This reduces the number of conflicts when rebasing after a series of patches to the same piece of code is committed upstream. Signed-off-by: Robert Shearman <rob@codeweavers.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-24Deprecate merge-recursive.pyLibravatar Junio C Hamano1-15/+4
This renames merge-recursive written in Python to merge-recursive-old, and makes merge-recur as a synonym to merge-recursive. We do not remove merge-recur yet, but we will remove merge-recur and merge-recursive-old in a few releases down the road. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-12Merge branch 'master' into js/c-merge-recursiveLibravatar Junio C Hamano1-9/+6
Adjust to hold_lock_file_for_update() change on the master.
2006-07-31rebase: Make the fast-fowarding message more user-friendly by using branch ↵Libravatar Robert Shearman1-1/+1
names instead of SHA1 IDs. Signed-off-by: Robert Shearman <rob@codeweavers.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-31rebase: Fix the detection of fast-forwarding of the current branch to upstream.Libravatar Robert Shearman1-8/+5
Previously, a rebasing operation with on a branch that is just tracking an upstream branch would output a confusing "Nothing to do" due to no patches being given to git-am. The test brings the behaviour back into line with that of just before e646c9c8c0aa995eac284ea0a2117add19c4461c. Signed-off-by: Robert Shearman <rob@codeweavers.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-30Merge branch 'js/read-tree' into js/c-merge-recursiveLibravatar Junio C Hamano1-3/+6
* js/read-tree: (107 commits) read-tree: move merge functions to the library read-trees: refactor the unpack_trees() part tar-tree: illustrate an obscure feature better git.c: allow alias expansion without a git directory setup_git_directory_gently: do not barf when GIT_DIR is given. Build on Debian GNU/kFreeBSD Call setup_git_directory() much earlier Call setup_git_directory() early Display an error from update-ref if target ref name is invalid. Fix http-fetch t4103: fix binary patch application test. git-apply -R: binary patches are irreversible for now. Teach git-apply about '-R' Makefile: ssh-pull.o depends on ssh-fetch.c log and diff family: honor config even from subdirectories git-reset: detect update-ref error and report it. lost-found: use fsck-objects --full Teach git-http-fetch the --stdin switch Teach git-local-fetch the --stdin switch Make pull() support fetching multiple targets at once ...
2006-07-13recur vs recursive: help testing without touching too many stuff.Libravatar Junio C Hamano1-2/+13
During git-merge-recur development, you could set an environment variable GIT_USE_RECUR_FOR_RECURSIVE to use WIP recur in place of the recursive strategy. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-13Status update on merge-recursive in CLibravatar Johannes Schindelin1-2/+2
This is just an update for people being interested. Alex and me were busy with that project for a few days now. While it has progressed nicely, there are quite a couple TODOs in merge-recursive.c, just search for "TODO". For impatient people: yes, it passes all the tests, and yes, according to the evil test Alex did, it is faster than the Python script. But no, it is not yet finished. Biggest points are: - there are still three external calls - in the end, it should not be necessary to write the index more than once (just before exiting) - a lot of things can be refactored to make the code easier and shorter BTW we cannot just plug in git-merge-tree yet, because git-merge-tree does not handle renames at all. This patch is meant for testing, and as such, - it compile the program to git-merge-recur - it adjusts the scripts and tests to use git-merge-recur instead of git-merge-recursive - it provides "TEST", a script to execute the tests regarding -recursive - it inlines the changes to read-cache.c (read_cache_from(), discard_cache() and refresh_cache_entry()) Brought to you by Alex Riesen and Dscho Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-13Record rebase changes as 'rebase' in the reflog.Libravatar Shawn Pearce1-3/+6
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-08Using 'perl' in *.shLibravatar Michal Rokos1-1/+1
Some GIT's shell script are using bare 'perl' for perl invocation. Use @@PERL@@ symbol and replace it with PERL_PATH_SQ everywhere. Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28rebase: check for errors from git-commitLibravatar Eric Wong1-1/+6
commit does not always succeed, so we'll have to check for it in the absence of set -e. This fixes a regression introduced in 9e4bc7dd1bb9d92491c475cec55147fa0b3f954d Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28rebase: get rid of outdated MRESOLVEMSGLibravatar Eric Wong1-8/+3
There was a time when rebase --skip didn't work when used with --merge, but that is no more so we don't need that message anymore. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27Fix expr usage for FreeBSDLibravatar Dennis Stosberg1-1/+1
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-25rebase: allow --skip to work with --mergeLibravatar Eric Wong1-1/+12
Now that we control the merge base selection, we won't be forced into rolling things in that we wanted to skip beforehand. Also, add a test to ensure this all works as intended. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-25rebase: cleanup rebasing with --mergeLibravatar Eric Wong1-28/+5
We no longer have to recommit each patch to remove the parent information we're rebasing since we're using the low-level merge strategies directly instead of git-merge. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-25rebase: allow --merge option to handle patches merged upstreamLibravatar Eric Wong1-4/+11
Enhance t3401-rebase-partial to test with --merge as well as the standard am -3 strategy. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-22rebase --merge: fix for rebasing more than 7 commits.Libravatar Junio C Hamano1-13/+10
Instead of using 4-digit numbers to name commits being rebased, just use "cmt.$msgnum" string, with $msgnum as a decimal number without leading zero padding. This makes it possible to rebase more than 9999 commits, but of more practical importance is that the earlier code used "printf" to format already formatted $msgnum and barfed when it counted up to 0008. In other words, the old code was incapable of rebasing more than 7 commits, and this fixes that problem. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-21rebase: error out for NO_PYTHON if they use recursive mergeLibravatar Eric Wong1-0/+9
recursive merge relies on Python, and we can't perform rename-aware merges without the recursive merge. So bail out before trying it. The test won't work w/o recursive merge, either, so skip that, too. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-21rebase: Allow merge strategies to be used when rebasingLibravatar Eric Wong1-9/+183
This solves the problem of rebasing local commits against an upstream that has renamed files. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21git-rebase: use canonical A..B syntax to format-patchLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14Make git rebase interactive help match documentation.Libravatar Sean1-5/+16
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-26Add --continue and --abort options to git-rebase.Libravatar sean1-24/+38
git rebase [--onto <newbase>] <upstream> [<branch>] git rebase --continue git rebase --abort Add "--continue" to restart the rebase process after manually resolving conflicts. The user is warned if there are still differences between the index and the working files. Add "--abort" to restore the original branch, and remove the .dotest working files. Some minor additions to the git-rebase documentation. [jc: fix that applies to the maintenance track has been dealt with separately.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-26rebase: typofix.Libravatar Junio C Hamano1-1/+1
Noticed by Sean. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13Shell utilities: Guard against expr' magic tokens.Libravatar Mark Wooding1-1/+1
Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-21Fix typo in git-rebase.sh.Libravatar Jason Riedy1-1/+1
s/upsteram/upstream in git-rebase.sh. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-21git-rebase: Clarify usage statement and copy it into the actual documentation.Libravatar Carl Worth1-10/+14
I found a paper thin man page for git-rebase, but was quite happy to see something much more useful in the usage statement of the script when I went there to find out how this thing worked. Here it is cleaned up slightly and expanded a bit into the actual documentation. Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-18Merge branch 'jc/rebase-limit'Libravatar Junio C Hamano1-18/+71
* jc/rebase-limit: rebase: allow rebasing onto different base.
2006-02-14rebase: allow rebasing onto different base.Libravatar Junio C Hamano1-18/+71
This allows you to rewrite history a bit more flexibly, by separating the other branch name and new branch point. By default, the new branch point is the same as the tip of the other branch as before, but you can specify where you graft the rebased branch onto. When you have this ancestry graph: A---B---C topic / D---E---F---G master $ git rebase --onto master~1 master topic would rewrite the history to look like this: A'\''--B'\''--C'\'' topic / D---E---F---G master Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-13rebase: allow a hook to refuse rebasing.Libravatar Junio C Hamano1-0/+9
This lets a hook to interfere a rebase and help prevent certain branches from being rebased by mistake. A sample hook to show how to prevent a topic branch that has already been merged into publish branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14Bugfixes for git-rebaseLibravatar Lukas Sandström1-11/+18
Fix bugs in git-rebase wrt rebasing another branch than the current HEAD, rebasing with a dirty working dir, and rebasing a proper decendant of the target branch. [jc: with a bit of hand-merging] Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14rebase: do not get confused in fast-forward situation.Libravatar Junio C Hamano1-0/+3
When switching to another branch and rebasing it in a one-go, it failed to update the variable that holds the branch head, and did not detect fast-forward situation correctly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14git-rebase: Usage string clean-up, emit usage string at incorrect invocationLibravatar freku045@student.liu.se1-2/+3
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28rebase: one safety net, one bugfix and one optimization.Libravatar Junio C Hamano1-1/+27
When a .dotest from a previously failed rebase or patch application exists, rebase got confused and tried to apply mixture of what was already there and what is being rebased. Check the existence of the directory and barf. It failed with an mysterious "fatal: cannot read mbox" message if the branch being rebased is fully in sync with the base. Also if the branch is a proper descendant of the base, there is no need to run rebase logic. Prevent these from happening by checking where the merge-base is. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-25git-sh-setup: die if outside git repository.Libravatar Junio C Hamano1-1/+1
Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Rewrite rebase to use git-format-patch piped to git-am.Libravatar Junio C Hamano1-56/+16
The current rebase implementation finds commits in our tree but not in the upstream tree using git-cherry, and tries to apply them using git-cherry-pick (i.e. always use 3-way) one by one. Which is fine, but when some of the changes do not apply cleanly, it punts, and punts badly. Suppose you have commits A-B-C-D-E since you forked from the upstream and submitted the changes for inclusion. You fetch from upstream head U and find that B has been picked up. You run git-rebase to update your branch, which tries to apply changes contained in A-C-D-E, in this order, but replaying of C fails, because the upstream got changes that touch the same area from elsewhere. Now what? It notes that fact, and goes ahead to apply D and E, and at the very end tells you to deal with C by hand. Even if you somehow managed to replay C on top of the result, you would now end up with ...-B-...-U-A-D-E-C. Breaking the order between B and others was the conscious decision made by the upstream, so we would not worry about it, and even if it were worrisome, it is too late for us to fix now. What D and E do may well depend on having C applied before them, which is a problem for us. This rewrites rebase to use git-format-patch piped to git-am, and when the patch does not apply, have git-am fall back on 3-way merge. The updated diff/patch pair knows how to apply trivial binary patches as long as the pre- and post-images are locally available, so this should work on a repository with binary files as well. The primary benefit of this change is that it makes rebase easier to use when some of the changes do not replay cleanly. In the "unapplicable patch in the middle" case, this "rebase" works like this: - A series of patches in e-mail form is created that records what A-C-D-E do, and is fed to git-am. This is stored in .dotest/ directory, just like the case you tried to apply them from your mailbox. Your branch is rewound to the tip of upstream U, and the original head is kept in .git/ORIG_HEAD, so you could "git reset --hard ORIG_HEAD" in case the end result is really messy. - Patch A applies cleanly. This could either be a clean patch application on top of rewound head (i.e. same as upstream head), or git-am might have internally fell back on 3-way (i.e. it would have done the same thing as git-cherry-pick). In either case, a rebased commit A is made on top of U. - Patch C does not apply. git-am stops here, with conflicts to be resolved in the working tree. Yet-to-be-applied D and E are still kept in .dotest/ directory at this point. What the user does is exactly the same as fixing up unapplicable patch when running git-am: - Resolve conflict just like any merge conflicts. - "git am --resolved --3way" to continue applying the patches. - This applies the fixed-up patch so by definition it had better apply. "git am" knows the patch after the fixed-up one is D and then E; it applies them, and you will get the changes from A-C-D-E commits on top of U, in this order. I've been using this without noticing any problem, and as people may know I do a lot of rebases. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28Use git-update-ref in scripts.Libravatar Junio C Hamano1-2/+3
This uses the git-update-ref command in scripts for safer updates. Also places where we used to read HEAD ref by using "cat" were fixed to use git-rev-parse. This will matter when we start using symbolic references. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-0/+68
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>