From: Nikolay Shustov <nikolay.shustov@gmail.com>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: Git Users <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Stefan Beller <sbeller@google.com>
Subject: Re: "groups of files" in Git?
Date: Thu, 13 Jul 2017 11:21:09 -0400 [thread overview]
Message-ID: <CAEcERAyhyiQXyiJ_DdL_UaFMgYnQnxBqP_oFqAcjA6xHDOCZhw@mail.gmail.com> (raw)
In-Reply-To: <5FDE1F7C-9C01-4C50-996C-920F6E0E2DCB@gmail.com>
Thank you, this could work, but if I am adding new file to the
feature/removing the existing file from the feature, aliases usage for
"add" doesn't help much.
I would really need to have the lists of files... and attributes look
more promising.
On Tue, Jul 11, 2017 at 4:20 PM, Lars Schneider
<larsxschneider@gmail.com> wrote:
>> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider
>> <larsxschneider@gmail.com> wrote:
>>>
>>>> On 11 Jul 2017, at 17:45, Nikolay Shustov <nikolay.shustov@gmail.com> wrote:
>>>>
>>>> Hi,
>>>> I have been recently struggling with migrating my development workflow
>>>> from Perforce to Git, all because of the following thing:
>>>>
>>>> I have to work on several features in the same code tree parallel, in
>>>> the same Perforce workspace. The major reason why I cannot work on one
>>>> feature then on another is just because I have to make sure that the
>>>> changes in the related areas of the product play together well.
>>>>
>>>> With Perforce, I can have multiple changelists opened, that group the
>>>> changed files as needed.
>>>>
>>>> With Git I cannot seem to finding the possibility to figure out how to
>>>> achieve the same result. And the problem is that putting change sets
>>>> on different Git branches (or workdirs, or whatever Git offers that
>>>> makes the changes to be NOT in the same source tree) is not a viable
>>>> option from me as I would have to re-build code as I re-integrate the
>>>> changes between the branches (or whatever changes separation Git
>>>> feature is used).
>>>> Build takes time and resources and considering that I have to do it on
>>>> multiple platforms (I do cross-platform development) it really
>>>> denominates the option of not having multiple changes in the same code
>>>> tree.
>>>>
>>>> Am I ignorant about some Git feature/way of using Git that would help?
>>>> Is it worth considering adding to Git a feature like "group of files"
>>>> that would offer some virtutal grouping of the locally changed files
>>>> in the checked-out branch?
>>>
>>> Interesting question that came up at my workplace, too.
>>>
>>> Here is what I suggested:
>>> 1. Keep working on a single branch and make commits for all features
>>> 2. If you make a commit, prefix the commit message with the feature name
>>> 3. After you are done with a feature create a new feature branch based on
>>> your combined feature branch. Use `git rebase -i` [1] to remove all
>>> commits that are not relevant for the feature. Alternatively you could
>>> cherry pick the relevant commits [2] if this is faster.
>>>
>>> I wonder what others think about this solution. Maybe there is a better
>>> solution that I overlooked?
>>>
>>> - Lars
>>>
>>> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history
>>> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html
>>>
>
>> On 11 Jul 2017, at 19:54, Nikolay Shustov <nikolay.shustov@gmail.com> wrote:
>>
>> Thank you for the idea, however I am having troubles with basically
>> maintaining the uncommitted groups of files: I would prefer the clear
>> distinction that "those files belong to feature A" and "these files
>> belong to feature B", before I commit anything. Committing separately
>> every change for feature A and for feature B would probably a good
>> option unless I have many changes and then cherry-picking the proper
>> commits to create a single changeset for the integration would become
>> a nightmare.
>
> I see. Why so complicated with gitattributes then?
>
> How about this:
> Let's say you start working on featureX that affects file1 and file2
> and featureY that affects file8 and file9
>
> 1. Create aliases to add the files:
> $ git config --local alias.featx 'add file1 file2'
> $ git config --local alias.featy 'add file8 file9'
>
> 2. Work on the features. Whenever you have something ready for featureX
> run this:
> $ git featx
> $ git commit
>
> Whenever you have something ready for featureY run this:
> $ git featy
> $ git commit
>
> Wouldn't that work?
>
> - Lars
>
>
next prev parent reply other threads:[~2017-07-13 15:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-11 15:45 "groups of files" in Git? Nikolay Shustov
2017-07-11 17:18 ` Stefan Beller
2017-07-11 17:47 ` Nikolay Shustov
2017-07-13 18:22 ` Junio C Hamano
2017-07-13 19:47 ` Nikolay Shustov
2017-07-13 21:20 ` Junio C Hamano
2017-07-13 22:39 ` Igor Djordjevic
2017-07-13 23:32 ` Igor Djordjevic
2017-07-13 23:40 ` Igor Djordjevic
2017-07-11 17:27 ` Randall S. Becker
2017-07-11 17:27 ` Junio C Hamano
2017-07-11 18:10 ` Nikolay Shustov
2017-07-11 18:19 ` Stefan Beller
2017-07-11 18:30 ` Nikolay Shustov
2017-07-11 17:39 ` Lars Schneider
2017-07-11 17:54 ` Nikolay Shustov
2017-07-11 20:20 ` Lars Schneider
2017-07-13 15:21 ` Nikolay Shustov [this message]
2017-07-11 22:46 ` Igor Djordjevic
2017-07-13 15:37 ` Nikolay Shustov
2017-07-13 18:09 ` Junio C Hamano
2017-07-13 19:31 ` Nikolay Shustov
2017-07-11 20:09 ` Fredrik Gustafsson
2017-07-11 22:27 ` astian
2017-07-13 17:04 ` Nikolay Shustov
2017-07-13 23:06 ` Igor Djordjevic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEcERAyhyiQXyiJ_DdL_UaFMgYnQnxBqP_oFqAcjA6xHDOCZhw@mail.gmail.com \
--to=nikolay.shustov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).