- 21 6月, 2006 1 次提交
-
-
由 Eric Wong 提交于
This solves the problem of rebasing local commits against an upstream that has renamed files. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 5月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 5月, 2006 1 次提交
-
-
由 Sean 提交于
Signed-off-by: NSean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 4月, 2006 2 次提交
-
-
由 sean 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Noticed by Sean. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 4月, 2006 1 次提交
-
-
由 Mark Wooding 提交于
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: NMark Wooding <mdw@distorted.org.uk> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 2月, 2006 2 次提交
-
-
由 Jason Riedy 提交于
s/upsteram/upstream in git-rebase.sh. Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Carl Worth 提交于
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: NCarl Worth <cworth@cworth.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 13 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 15 12月, 2005 2 次提交
-
-
由 Lukas Sandström 提交于
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: NLukas Sandström <lukass@etek.chalmers.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 14 12月, 2005 1 次提交
-
-
由 freku045@student.liu.se 提交于
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 26 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 19 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 29 9月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 08 9月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 30 8月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
The reverse patch application using "git apply" sometimes is too rigid. Since the user would get used to resolving conflicting merges by hand during the normal merge experience, using the same machinery would be more helpful rather than just giving up. Cherry-picking and reverting are essentially the same operation. You pick one commit, and apply the difference that commit introduces to its own commit ancestry chain to the current tree. Revert applies the diff in reverse while cherry-pick applies it forward. They share the same logic, just different messages and merge direction. Rewrite "git rebase" using "git cherry-pick". Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 8月, 2005 2 次提交
-
-
由 Junio C Hamano 提交于
Otherwise the first commit rebase makes could include whatever dirty state the original working tree had. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 8月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
It did not check to see if the working tree was clean and matched the commit we were starting out as, resulting in the initial rebased commit including whatever dirty state the working tree has had. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 8月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Make sure that we say --verify when we want to get a single SHA1 name. Also when we say --verify, --revs-only is redundant. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 8月, 2005 2 次提交
-
-
由 Junio C Hamano 提交于
Although these commands take only begin and end, not necessarily generic SHA1 expressions rev-parse supports, supporting a..b notation is good for consistency. This commit adds such without breaking backward compatibility. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
While moving '-m' to make room for CVS compatible "here is the log message", enhance source of log parameters. -m 'message': a command line parameter. -F <file> : a file (use '-' to read from stdin). -C <commit> : message in existing commit. -c <commit> : message in existing commit (allows further editing). Longer option names for these options are also available. While we are at it, get rid of shell array bashism. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 7月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
This patch changes rev-parse users that pass a single argument that is supposed to be a rev parameter to use "--verify". Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 26 6月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Using git-cherry, forward port local commits missing from the new upstream head. This also depends on "-m" flag support in git-commit-script. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-