Nikolay Shustov <nikolay.shustov@xxxxxxxxx> 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.
