Thread (4 messages) flat view 4 messages, 2 authors, 2017-07-13

Re: "groups of files" in Git?

From: Junio C Hamano <hidden>
Date: 2017-07-13 21:20:20

Nikolay Shustov [off-list ref] writes:
I am not really try to ignite the holy war between Perforce and Git
(and why would one???), but if you are interested in the answer on how
you'd do your scenario in Perforce, it would be: "use shelved
changelists".
Oh, that was not my intention, either.  My interest was to see if
there is a good solution that we could steal from other world.
In Perforce, you could "shelve" the changelist, similar to "stash" in
Git, but the difference is that the Perforce shelved changes are
accessible across clients. I.e. the other developer can "unshelve"
these pending changes to its sandbox (to the same or the different
branch) so that sandbox would get the pending changes as well. That
would be like the developer made these changes himself. Whatever
automated/manual process is involved, it is typical to run "a trial
build/tests" on shelved changelist (i.e. uncommitted yet files) to
verify the quality of changes.
Git achieves the same through the ease of manipulation with branches
and I like the way it does it much more.
Thanks.  Shelving and letting others unshelve is like keeping the
changes in separate branches and privately share them among
developers, so they sound pretty much equivalent features to me.
My question was about how to robustly handle "multiple pending
commits" which in Perforce are represented by concept of pending
changelists.
And in Git, they are represented by concept of commits that are not
yet pushed out to the public repository to become the final history
carved in stone.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help