Hi,

The feature is finished with documentation and tests in this
iteration.  I've written an extensive t3420 which proves that the
feature works flawlessly.  Further, I've made every attempt to
actually explain what I'm doing: I've taken care to inspect all the
return values.

Overall, I'm elated with the design and interface.  I think it is most
intuitive, while not trading off power/ flexibility.

One subtle detail that you might disagree with: I report success if
the rebase succeeds but the stash application fails.  Are we okay with
this?

Also, does t3420 exercise all the cases sufficiently?  Have I missed
anything?

Enjoy reading and reviewing this.

Ramkumar Ramachandra (8):
  am: suppress error output from a conditional
  rebase -i: don't error out if $state_dir already exists
  am: tighten a conditional that checks for $dotest
  rebase: prepare to do generic housekeeping
  am: return control to caller, for housekeeping
  rebase -i: return control to caller, for housekeeping
  rebase --merge: return control to caller, for housekeeping
  rebase: implement --[no-]autostash and rebase.autostash

 Documentation/config.txt     |   8 +++
 Documentation/git-rebase.txt |  10 +++
 git-am.sh                    |  15 +++--
 git-rebase--am.sh            |   8 +--
 git-rebase--interactive.sh   |  11 ++--
 git-rebase--merge.sh         |   5 +-
 git-rebase.sh                |  46 +++++++++++++-
 t/t3420-rebase-autostash.sh  | 148 +++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 233 insertions(+), 18 deletions(-)
 create mode 100755 t/t3420-rebase-autostash.sh

-- 
1.8.3.rc1.52.gc14258d

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to