aboutsummaryrefslogtreecommitdiff
path: root/git-rebase--interactive.sh
Commit message (Collapse)AuthorAge
...
* | | Merge branch 'fc/doc-fast-forward'Junio C Hamano2009-11-15
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * fc/doc-fast-forward: Use 'fast-forward' all over the place Conflicts: builtin-merge.c
| * | | Use 'fast-forward' all over the placeFelipe Contreras2009-10-24
| |/ / | | | | | | | | | | | | | | | | | | It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Junio C Hamano2009-10-28
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | * maint: help -a: do not unnecessarily look for a repository Do not try to remove directories when removing old links rebase -i: more graceful handling of invalid commands help -i: properly error out if no info viewer can be found
| * | rebase -i: more graceful handling of invalid commandsJan Krüger2009-10-27
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when there is an invalid command, the rest of the line is still treated as if the command had been valid, i.e. rebase -i attempts to produce a patch, using the next argument as a SHA1 name. If there is no next argument or an invalid one, very confusing error messages appear (the line was '.'; path to git-rebase-todo substituted): Unknown command: . fatal: ambiguous argument 'Please fix this in the file $somefile.': unknown revision or path not in the working tree. Use '--' to separate paths from revisions fatal: Not a valid object name Please fix this in the file $somefile. fatal: bad revision 'Please fix this in the file $somefile.' Instead, verify the validity of the remaining line and error out earlier if necessary. Signed-off-by: Jan Krüger <jk@jk.gs> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rebase -i: fix reword when using a terminal editorStephen Boyd2009-10-19
| | | | | | | | | | | | | | | | | | | | | | | | We don't want to use output() on git-commit --amend when rewording the commit message. This leads to confusion as the editor is run in a subshell with it's output saved away, leaving the user with a seemingly frozen terminal. Fix by removing the output part. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Teach 'rebase -i' the command "reword"Björn Gustavsson2009-10-07
|/ | | | | | | | Make it easier to edit just the commit message for a commit using 'git rebase -i' by introducing the "reword" command. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix rebase -p --ontoGreg Price2009-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a rebase with --onto, the correct test for whether we can skip rewriting a commit is if it is already on top of $ONTO, not $UPSTREAM. Without --onto, this distinction does not exist and the behavior does not change. In a situation with two merged branches on a common base X: X---o---o---o---M \ / x---x---x---x Y if we try to move the branches from their base on X to be based on Y, so as to get X Y---o'--o'--o'--M' \ / x'--x'--x'--x' then we fail. The command `git rebase -p --onto Y X M` moves only the first-parent chain, like so: X \ x---x---x---x \ Y---o'--o'--o'--M' because it mistakenly drops the other branch(es) x---x---x---x from the TODO file. This tests and fixes this behavior. Signed-off-by: Greg Price <price@ksplice.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'uk/maint-1.5.3-rebase-i-reflog' into maintJunio C Hamano2009-06-11
|\ | | | | | | | | | | | | | | * uk/maint-1.5.3-rebase-i-reflog: rebase--interactive: remote stray closing parenthesis Conflicts: git-rebase--interactive.sh
| * rebase--interactive: remote stray closing parenthesisUwe Kleine-König2009-06-11
| | | | | | | | | | | | | | | | it was introduced in 68a163c9b483ae352fcfee8c4505d113213daa73 Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Jöhännës "Dschö" Schindëlin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rebase -i: avoid 'git reset' when possibleJohannes Schindelin2009-03-03
| | | | | | | | | | | | | | | | | | | | | | When picking commits whose parents have not changed, we do not need to rewrite the commit. We do not need to reset the working directory to the parent's state, either. Requested by Sverre Rabbelier. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/maint-rebase-i-submodule'Junio C Hamano2009-01-31
|\ \ | | | | | | | | | | | | | | | * js/maint-rebase-i-submodule: Fix submodule squashing into unrelated commit rebase -i squashes submodule changes into unrelated commit
| * | Fix submodule squashing into unrelated commitJohannes Schindelin2009-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually, I think the issue is pretty independent of submodules; when "git commit" gets an empty parameter, it misinterprets it as a file. So avoid passing an empty parameter to "git commit". Actually, this is a nice cleanup, as MSG_FILE and EDIT_COMMIT were mutually exclusive; use one variable instead Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | rebase -i: correctly remember --root flag across --continueJunio C Hamano2009-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | d911d14 (rebase -i: learn to rebase root commit, 2009-01-02) tried to remember the --root flag across a merge conflict in a broken way. Introduce a flag file $DOTEST/rebase-root to fix and clarify. While at it, also make sure $UPSTREAM is always initialized to guard against existing values in the environment. [tr: added tests] Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | rebase -i --root: fix check for number of argumentsJohannes Schindelin2009-01-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we are not rebasing with --root, then $# can only be either 1 (base) or 2 (base and the name of the branch to be rebased). If we are rebasing with --root, then it is Ok if $# is 0 (rebase the current branch down to everything) or 1 (rebase the named branch down to everything). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'tr/rebase-root'Junio C Hamano2009-01-17
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | * tr/rebase-root: rebase: update documentation for --root rebase -i: learn to rebase root commit rebase: learn to rebase root commit rebase -i: execute hook only after argument checking
| * | rebase -i: learn to rebase root commitThomas Rast2009-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach git-rebase -i a new option --root, which instructs it to rebase the entire history leading up to <branch>. This is mainly for symmetry with ordinary git-rebase; it cannot be used to edit the root commit in-place (it requires --onto <newbase>). Commits that already exist in <newbase> are skipped. In the normal mode of operation, this is fairly straightforward. We run cherry-pick in a loop, and cherry-pick has supported picking the root commit since f95ebf7 (Allow cherry-picking root commits, 2008-07-04). In --preserve-merges mode, we track the mapping from old to rewritten commits and use it to update the parent list of each commit. In this case, we define 'rebase -i -p --root --onto $onto $branch' to rewrite the parent list of all root commit(s) on $branch to contain $onto instead. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | rebase -i: execute hook only after argument checkingThomas Rast2009-01-03
| | | | | | | | | | | | | | | | | | | | | | | | Previously, the pre-rebase-hook would be launched before we knew if the <upstream> [<branch>] arguments were supplied. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint-1.6.0' into maintJunio C Hamano2009-01-13
|\ \ \ | |/ / |/| | | | | | | | | | | * maint-1.6.0: Avoid spurious error messages on error mistakes. contrib/examples/README: give an explanation of the status of these files
| * | Avoid spurious error messages on error mistakes.Pierre Habouzit2009-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to that, if the user chose "squash" as a first action, the stderr looked like: grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory Cannot 'squash' without a previous commit Now the first line is gone. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | rebase -i -p: leave a --cc patch when a merge could not be redoneJohannes Schindelin2008-12-24
| | | | | | | | | | | | | | | The result is easier to review this way, and the merge resolution has to be done inside the work tree, not by adjusting "the patch" anyway.
* | | rebase -i -p: Fix --continue after a merge could not be redoneJohannes Sixt2008-12-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a merge that has a conflict was rebased, then rebase stopped to let the user resolve the conflicts. However, thereafter --continue failed because the author-script was not saved. (This is rebase -i's way to preserve a commit's authorship.) This fixes it by doing taking the same failure route after a merge that is also taken after a normal cherry-pick. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'sh/rebase-i-p'Junio C Hamano2008-11-02
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * sh/rebase-i-p: git-rebase--interactive.sh: comparision with == is bashism rebase-i-p: minimum fix to obvious issues rebase-i-p: if todo was reordered use HEAD as the rewritten parent rebase-i-p: do not include non-first-parent commits touching UPSTREAM rebase-i-p: only list commits that require rewriting in todo rebase-i-p: fix 'no squashing merges' tripping up non-merges rebase-i-p: delay saving current-commit to REWRITTEN if squashing rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD rebase-i-p: test to exclude commits from todo based on its parents
| * | | git-rebase--interactive.sh: comparision with == is bashismJunio C Hamano2008-10-22
| | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: minimum fix to obvious issuesJunio C Hamano2008-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jeff King noticed that this series uses non-portable ${var:0:7} syntax to splice a string, which is not even in POSIX, in the script. A quick look at around the offending part revealed a few issues, which this commit fixes: * Why filter output from "rev-list --left-right A...B" and look for the ones that begin with ">"? Wouldn't "rev-list A..B" give that? * The abbreviated SHA-1 are made with "rev-list --abbrev=7" into $TODO in an earlier invocation, and it can be more than 7 letters to avoid ambiguity. Not just that "${r:0:7} is not even in POSIX", but use of it here is actively wrong. * There is no point in catting a single file and piping it into grep. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: if todo was reordered use HEAD as the rewritten parentStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This seems like the best guess we can make until git sequencer marks are available. That being said, within the context of re-ordering a commit before its parent in todo, I think applying it on top of the current commit seems like a reasonable assumption of what the user intended. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: do not include non-first-parent commits touching UPSTREAMStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers an odd boundary case found by Avi Kivity's script where a branch coming off of UPSTREAM is merged into HEAD. Initially it show up in UPSTREAM..HEAD, but technically UPSTREAM is not moving, the rest of head is, so we should not need to rewrite the merge. This adds a check saying we can keep `preserve=t` if `p=UPSTREAM`...unless this is the first first-parent commit in our UPSTREAM..HEAD rev-list, which could very well point to UPSTREAM, but we still need to consider it as rewritten so we start pulling in the rest of the UPSTREAM..HEAD commits that point to it. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: only list commits that require rewriting in todoStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is heavily based on Stephan Beyer's git sequencer rewrite of rebase-i-p. Each commit is still found by rev-list UPSTREAM..HEAD, but a commit is only included in todo if at least one its parents has been marked for rewriting. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: fix 'no squashing merges' tripping up non-mergesStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also only check out the first parent if this commit if not a squash--if it is a squash, we want to explicitly ignore the parent and leave the wc as is, as cherry-pick will apply the squash on top of it. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: delay saving current-commit to REWRITTEN if squashingStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the current-commit was dumped to REWRITTEN, but then we squash the next commit in to it, we have invalidated the HEAD was just written to REWRITTEN. Instead, append the squash hash to current-commit and save both of them the next time around. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEADStephen Haberman2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If OLDHEAD was reordered in the todo, and its mapped NEWHEAD was used to set the ref, commits reordered after OLDHEAD in the todo would should up as un-committed changes. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'sh/maint-rebase3'Junio C Hamano2008-10-19
|\ \ \ \ | |/ / / | | | | | | | | | | | | * sh/maint-rebase3: rebase--interactive: fix parent rewriting for dropped commits
| * | | rebase--interactive: fix parent rewriting for dropped commitsStephen Haberman2008-10-16
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `rebase -i -p` got its rev-list of commits to keep by --left-right and --cherry-pick. Adding --cherry-pick would drop commits that duplicated changes already in the rebase target. The dropped commits were then forgotten about when it came to rewriting the parents of their descendents, so the descendents would get cherry-picked with their old, unwritten parents and essentially make the rebase a no-op. This commit adds a $DOTEST/dropped directory to remember dropped commits and rewrite their children's parent as the dropped commit's possibly-rewritten first-parent. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Merge branch 'ns/rebase-noverify'Junio C Hamano2008-10-19
|\ \ \ | |/ / |/| | | | | | | | | | | * ns/rebase-noverify: rebase: Document --no-verify option to bypass pre-rebase hook rebase --no-verify
| * | rebase --no-verifyNanako Shiraishi2008-10-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is sometimes desirable to disable the safety net of pre-rebase hook when the user knows what he is doing (for example, when the original changes on the branch have not been shown to the public yet). This teaches --no-verify option to git-rebase, which is similar to the way pre-commit hook is bypassed by git-commit. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | rebase -i: do not fail when there is no commit to cherry-pickJohannes Schindelin2008-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case there is no commit to apply (for example because you rebase to upstream and all your local patches have been applied there), do not fail. The non-interactive rebase already behaves that way. Do this by introducing a new command, "noop", which is substituted for an empty commit list, so that deleting the commit list can still abort as before. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Merge branch 'sg/maint-intrebase-msghook' into maintShawn O. Pearce2008-10-09
|\ \ \ | |/ / |/| | | | | | | | | | | * sg/maint-intrebase-msghook: rebase -i: remove leftover debugging rebase -i: proper prepare-commit-msg hook argument when squashing
| * | rebase -i: remove leftover debuggingSZEDER Gábor2008-10-03
| | | | | | | | | | | | | | | Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | rebase -i: proper prepare-commit-msg hook argument when squashingSZEDER Gábor2008-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One would expect that the prepare-commit-msg hook gets 'squash' as the second argument when squashing commits with 'rebase -i'. However, that was not the case, as it got 'merge' instead. This patch fixes the problem. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | | Teach rebase -i to honor pre-rebase hookNanako Shiraishi2008-10-06
|/ / | | | | | | | | | | | | | | | | The original git-rebase honored pre-rebase hook so that public branches can be protected from getting rebased, but rebase --interactive ignored the hook entirely. This fixes it. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | git-rebase--interactive: auto amend only edited commitDmitry Potapov2008-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git rebase --continue" issued after git rebase being stop by "edit" command is trying to amend the last commit using stage changes. However, if the last commit is not the commit that was marked as "edit" then it can produce unexpected results. For instance, after being stop by "edit", I have made some changes to commit message using "git commit --amend". After that I realized that I forgot to add some changes to some file. So, I said "git add file" and the "git rebase --continue". Unfortunately, it caused that the new commit message was lost. Another problem is that after being stopped at "edit", the user adds new commits. In this case, automatic amend behavior of git rebase triggered by some stage changes causes that not only that the log message of the last commit is lost but that it will contain also wrong Author and Date information. Therefore, this patch restrict automatic amend only to the situation where HEAD is the commit at which git rebase stop by "edit" command. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-rebase-interactive: do not squash commits on abortDmitry Potapov2008-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If git rebase interactive is stopped by "edit" command and then the user said "git rebase --continue" while having some stage changes, git rebase interactive is trying to amend the last commit by doing: git --soft reset && git commit However, the user can abort commit for some reason by providing an empty log message, and that would leave the last commit undone, while the user being completely unaware about what happened. Now if the user tries to continue, by issuing "git rebase --continue" that squashes two previous commits. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rebase -i -p: fix parent rewritingThomas Rast2008-08-13
| | | | | | | | | | | | | | | | The existing parent rewriting did not handle the case where a previous commit was amended (via edit or squash). Fix by always putting the new sha1 of the last commit into the $REWRITTEN map. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
* | rebase -i -p: handle index and workdir correctlyThomas Rast2008-08-13
| | | | | | | | | | | | | | | | | | | | | | | | 'git rebase -i -p' forgot to update the index and working directory during fast forwards. Fix this. Makes 'GIT_EDITOR=true rebase -i -p <ancestor>' a no-op again. Also, it attempted to do a fast forward even if it was instructed not to commit (via -n). Fall back to the cherry-pick code path and let that handle the issue for us. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
* | rebase -i: When an 'edit' stops, mention the commitJohannes Sixt2008-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a rebase session where more than one commit is to be 'edit'ed, and the user spends considerable time to 'edit' a commit, it is easy to forget what one wanted to 'edit' at the individual commits. It would be helpful to see at which commit the rebase stopped. Incidentally, if the rebase stopped due to merge conflicts or other errors, the commit was already reported ("Could not apply $sha1..."), but when rebase stopped after successfully applying an "edit" commit, it would not mention it. With this change the commit is reported. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2008-07-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Start preparing 1.5.6.4 release notes git fetch-pack: do not complain about "no common commits" in an empty repo rebase-i: keep old parents when preserving merges t7600-merge: Use test_expect_failure to test option parsing Fix buffer overflow in prepare_attr_stack Fix buffer overflow in git diff Fix buffer overflow in git-grep git-cvsserver: fix call to nonexistant cleanupWorkDir() Documentation/git-cherry-pick.txt et al.: Fix misleading -n description Conflicts: RelNotes
| * | rebase-i: keep old parents when preserving mergesStephan Beyer2008-07-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When "rebase -i -p" tries to preserve merges of unrelated branches, it lost some parents: - When you have more than two parents, the commit in the new history ends up with fewer than expected number of parents and this breakage goes unnoticed; - When you are rebasing a merge with two parents and one is lost, the command tries to cherry-pick the original merge commit, and the command fails. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"Johannes Schindelin2008-07-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the files generated and used during a rebase are never to be tracked, they should live in $GIT_DIR. While at it, avoid the rather meaningless term "dotest" to "rebase", and unhide ".dotest-merge". This was wished for on the mailing list, but so far unimplemented. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/rebase-orig-head'Junio C Hamano2008-07-14
|\ \ \ | | | | | | | | | | | | | | | | | | | | * jc/rebase-orig-head: Documentation: mention ORIG_HEAD in am, merge, and rebase Teach "am" and "rebase" to mark the original position with ORIG_HEAD
| * | | Teach "am" and "rebase" to mark the original position with ORIG_HEADJunio C Hamano2008-07-07
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "merge" and "reset" leave the original point in history in ORIG_HEAD, which makes it easy to go back to where you were before you inflict a major damage to your history and realize that you do not like the result at all. These days with reflog, we technically do not need to use ORIG_HEAD, but it is a handy way nevertheless. This teaches "am" and "rebase" (all forms --- the vanilla one that uses "am" as its backend, "-m" variant that cherry-picks, and "--interactive") to do the same. The original idea and a partial implementation to do this only for "rebase -m" was by Brian Gernhardt; this extends on his idea. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Make rebase--interactive use OPTIONS_SPECStephan Beyer2008-07-13
|/ / | | | | | | | | | | | | | | Also add some checks that --continue/--abort/--skip actions are used without --onto, -p, -t, etc. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-03 06:16:30 +0000