Re: "groups of files" in Git?

From: Nikolay Shustov <nikolay.shustov@gmail.com>
Date: Jul 13, 2017, 19:31 UTC
Message-ID: <CAEcERAyf+np9U-o-SGSOCWsibVPyEWPh2yY+uEOgLL+qYFe1mw@mail.gmail.com>
In-Reply-To: <xmqqmv88xl7f.fsf@gitster.mtv.corp.google.com>

Thank you, but I am not sure I quite understand the idea. Could you please elaborate on it for the following example?

I have two Perforce changelists ("A" and "B") that group uncommitted sets of files (paths to each of files could be different):

changelist A: file1 file2

changelist B: file3 file4

In Perforce, I am able to do the following:
- move files between changelists (e.g. file1 could be moved to changelist B)
- add new files to changeslit (e.g. changelist B can get additional file5)
- revert file changes which would effectively remove file from the
changelst (e.g. revert file2 will remove it from changelist A)

How would I do it with sets of files that would belong to Git commit?

On Thu, Jul 13, 2017 at 2:09 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 36 quoted lines

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