Hello,
Heh, what is more useful than apology is to tell us which order
these three (apparent) series build on top of each other ;-)
The answer, IIUC, is that
* oidf+tests come first, then
* apply/drop/branch/pop (as these rely on oidf) on top, and finally
* list (as it wants to add to stash--helper that is a new file in the middle)
When there is clear dependency like that, I agree that it would help
readers to emphasize that these cannot be applied in an arbitrary
order. It is especially true as the second part of the above _will_
apply more-or-less cleanly without the first one, and then fail to
compile due to lack of oidf.
Thanks.
I would actually say that it was 100% my fault (I could have tested
before sending patches or ask if I was not completely sure) and I would
like to apologize for this.
The order of the commits is actually good. The only thing that is not
right are the cover letters, which are missing. Every 1/N marks the
beginning of a series of patches. Just to be more clear, this is the
right order:
First patch:
sha1-name.c: added 'get_oidf', which acts like 'get_oid'
stash: improve option parsing test coverage
stash: update test cases conform to coding guidelines
stash: renamed test cases to be more descriptive
Second patch:
stash: convert apply to builtin
stash: convert drop and clear to builtin
stash: convert branch to builtin
stash: convert pop to builtin
Third patch:
stash: implement the "list" command in the builtin
stash: convert show to builtin
stash: change `git stash show` usage text and documentation
stash: refactor `show_stash()` to use the diff API
stash: update `git stash show` documentation
stash: convert store to builtin
The only thing which was in the cover letters and might be worth
mentioning here is related to `git stash show`. Although it might not be
efficient, a 1:1 conversion is more easily to follow and review. Because
of that, the first commit related to `git stash show` approaches a 1:1
conversion to C. There is a subsequent patch (`refactor ....`) which
makes the `show` subcommand use the existent API. Any change of behavior
is noted in the commit message which introduces that change.
Best,
Paul
