stg pick --unapplied reverses the order of patches in arguments compared to plain stg pick

[NonLogicalDev]

To reproduce:

# assume branch name: master

$ stg new a -m a
$ stg new b -m b
$ stg new c -m c
$ stg new d -m d

$ stg series --no-description --noprefix | tee ~/patchset
a
b
c
d

$ stg branch --create test-branch-unapplied master
$ cat ~/patchset | xargs stg pick -B master --unapplied --

$ stg series --no-description --noprefix
d
c
b
a

$ stg branch --create test-branch-normal master
$ cat ~/patchset | xargs stg pick -B master --

$ stg series --no-description --noprefix
a
b
c
d

[NonLogicalDev]

There is also a bit of an inconsistency now with --no-apply vs --unapplied in arguments.

[jpgrayson]

Good find, @NonLogicalDev. Thanks!

Some findings from some history spelunking:

• The behavior of reversing the picked patch list when --unapplied is used has been there since the --unapplied option was introduced in 074f71b (circa 2008).
• There are no tests in the suite that check this behavior. There is only one test in t3400-pick.sh that uses --unapplied, but it only picks one patch, so the reversing is immaterial.

Here's what I think should be done:

1. Change the name of --unapplied to --noapply to match stg push --noapply. The passive --unapplied naming is really confusing.
2. Don't reverse the picked patch list when using --noapply. I cannot discern any sensible reason for this behavior.
3. Add a test case or two for pick --noapply with multiple patches.

[NonLogicalDev]

Hey @jpgrayson, thank you for lightning speed fix for this issue!!!

Something tells me that the logic for the unapplied was probably so that you could pipe the git log listing into the command verbatim. I guess as a quick way to import a set of commits.

git log --oneline -n 5 | awk '{print $1}' | xargs stg pick --unapplied

But I still believe it is a bit surprising. I suppose the author assumed that only commits will be imported this way. I almost err on the side of pick patch and pick commit should rather be distinct operations, as their semantics differ just enough to be annoying.

Worst case I would add a reverse flag to the pick operation to support piping stg series and git rev-list entries. But then git-revlist has a reverse flag so the point is a bit moot...

TLDR: This is a definite grey area. Probably not worth spending more effort on this until someone else stubs their toe on this.