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