Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Apr 26, 2006
  1. rebase: typofix.

    Junio C Hamano authored
    Noticed by Sean.
    Signed-off-by: Junio C Hamano <>
Commits on Apr 13, 2006
  1. Shell utilities: Guard against expr' magic tokens.

    Mark Wooding authored Junio C Hamano committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 22, 2006
  1. Fix typo in

    Jason Riedy authored Junio C Hamano committed
    s/upsteram/upstream in
    Signed-off-by: Jason Riedy <>
    Signed-off-by: Junio C Hamano <>
  2. @cworth-gh

    git-rebase: Clarify usage statement and copy it into the actual docum…

    cworth-gh authored Junio C Hamano committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 18, 2006
  1. Merge branch 'jc/rebase-limit'

    Junio C Hamano authored
    * jc/rebase-limit:
      rebase: allow rebasing onto different base.
Commits on Feb 15, 2006
  1. rebase: allow rebasing onto different base.

    Junio C Hamano authored
    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 <>
Commits on Feb 13, 2006
  1. rebase: allow a hook to refuse rebasing.

    Junio C Hamano authored
    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 <>
Commits on Dec 15, 2005
  1. Bugfixes for git-rebase

    Lukas Sandström authored Junio C Hamano committed
    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 <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 14, 2005
  1. rebase: do not get confused in fast-forward situation.

    Junio C Hamano authored
    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 <>
  2. git-rebase: Usage string clean-up, emit usage string at incorrect inv… authored Junio C Hamano committed
    Signed-off-by: Fredrik Kuivinen <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 28, 2005
  1. rebase: one safety net, one bugfix and one optimization.

    Junio C Hamano authored
    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 <>
Commits on Nov 25, 2005
  1. git-sh-setup: die if outside git repository.

    Junio C Hamano authored
    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 <>
Commits on Nov 18, 2005
  1. Rewrite rebase to use git-format-patch piped to git-am.

    Junio C Hamano authored
    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 <>
Commits on Sep 28, 2005
  1. Use git-update-ref in scripts.

    Junio C Hamano authored
    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
    Signed-off-by: Junio C Hamano <>
Commits on Sep 8, 2005
  1. Big tool rename.

    Junio C Hamano authored
    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
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.