Nikolay Shustov <nikolay.shustov@xxxxxxxxx> writes: > Thank you for the detailed explanation, it looks like merging the > commits would be helpful in my case. And I think it is a very good > analogy that Perforce changelists are like multiple pending committs, > if Git were supporting such. > > What it won't be achieving by using commits in this schema is the > following thing I can do in Perforce: > In the uncommitted Perforce changelists I can revert the changed file > to the original state and move the files between the changelists. > Quite often, while working on something, in the middle I would decide > to isolate changes to a certain set of files to a separate changelsit > - but then I might change my mind. It is all flexible until I actually > commit my Perforce changelist, after which it becomes very much as > committed changes in any other source control. > This is actual flexibility I am looking for achieving in Git. I actually think we already have such a flexibility. Unlike Perforce, Git is distributed, and the most important aspect of the distinction is that what happens _in_ your local Git repository may be called "committed" in Git lingo, but not visible to the public. You can consider these commits you make in your repository "pending" when you think of your workflow in Perforce terms, until you merge and push out the result, which roughly corresponds to "submitting" in Perforce lingo. Once you start treating your local commits that you haven't pushed out as changes that are still "pending" when observed from the outside world, you'd realize that you have as much flexibilty, if not more, to dice and slice them with the local tools like "rebase -i", "add -p", etc., as you would have in your Perforce workflow, I would think.
