git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: "groups of files" in Git?

From
Lars Schneider <larsxschneider@gmail.com>
Date
Jul 11, 2017, 17:39 UTC
Message-ID
<B5FDF25C-ED5A-4CD1-AAD7-04BD8D705C59@gmail.com>
In-Reply-To
<CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com>
Show 30 quoted lines
> 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

Previous: Nikolay ShustovNext: Nikolay Shustov
Message 15 of 26 in “"groups of files" in Git?”
  1. Nikolay ShustovJul 11, 2017
  2. Stefan BellerJul 11, 2017
  3. Nikolay ShustovJul 11, 2017
  4. Junio C HamanoJul 13, 2017
  5. Nikolay ShustovJul 13, 2017
  6. Junio C HamanoJul 13, 2017
  7. Igor DjordjevicJul 13, 2017
  8. Igor DjordjevicJul 13, 2017
  9. Igor DjordjevicJul 13, 2017
  10. Randall S. BeckerJul 11, 2017
  11. Junio C HamanoJul 11, 2017
  12. Nikolay ShustovJul 11, 2017
  13. Stefan BellerJul 11, 2017
  14. Nikolay ShustovJul 11, 2017
  15. Lars SchneiderJul 11, 2017
  16. Nikolay ShustovJul 11, 2017
  17. Lars SchneiderJul 11, 2017
  18. Nikolay ShustovJul 13, 2017
  19. Igor DjordjevicJul 11, 2017
  20. Nikolay ShustovJul 13, 2017
  21. Junio C HamanoJul 13, 2017
  22. Nikolay ShustovJul 13, 2017
  23. Fredrik GustafssonJul 11, 2017
  24. astianJul 11, 2017
  25. Nikolay ShustovJul 13, 2017
  26. Igor DjordjevicJul 13, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.