Re: [RFC] git stash: add porcelain for sharing stashes through remotes

[Hanan Arshad <hananarshad619@gmail.com>]

> All of the three you listed (discovery, transfer, clean-up) become
> easier to work with if you used branches, branches have always had
> good support for these three (and other) operations, and I do not
> see a good reason to add a parallel support to do something similar.

I understand the concern. I think I did not explain the workflow that
originally motivated the RFC clearly enough.

The idea came from a workflow I used with Perforce shelves. One concrete
case is build configuration. The repository contains configuration
templates, while I may have several local configuration variants that
should not become part of the normal project history.

A tester may need to apply the same configuration while testing
different branches or revisions, for example:

    branch A       + configuration X
    branch B       + configuration X
    release branch + configuration X

Using a branch for configuration X makes it another line of history
based on some revision. When the code being tested changes, that
configuration then has to be merged, rebased, cherry-picked, or
otherwise combined with the revision being tested.

What I want instead is an overlay: the tester chooses the code revision
and the temporary configuration independently, applies the
configuration for the test, and then discards it.

Perforce shelves give this kind of temporary handoff a straightforward
user-facing workflow. Git already has the underlying functionality as
well; that became clearer to me during this discussion. A stash can
already be pushed as a ref, so I agree that adding a separate
"publish" command would not be justified.

My motivation for the RFC is therefore not to add another transport or
storage mechanism. It is to see whether the existing stash/ref
functionality could have a more coherent UX for this kind of temporary
handoff, instead of requiring users to compose the generic ref,
push/fetch, and stash operations themselves.

This configuration-overlay workflow is one concrete use case that
motivated the idea. There may be other temporary handoff use cases, but
I do not want to rely on hypothetical cases to justify it.

Thanks,
Hanan