On Wed, Nov 24, 2021 at 09:16:21AM -0800, Lars Ruoff wrote:
[...]
> We use a minimalist branching workflow in that there is a main development
> branch, then at regular intervals, we branch off what will be the customer
> release versions.
> These different releases have to be maintained for several years each.
> Bug fixes may go to either branch and may then be merged into the others.
This point "then be merged into the others" is a red flag for me but there
could be some terminological problem; I'll address it later.
> Note that we are talking TFS/TFVC style "heavyweight" branches here.
[...]
> The Tests part isn't needed by every developer though.
> In TFS/TFVC, we have the common practice to "cloak" the Tests for people
> not concerned and "map" them to different parts of the file system for
> those who are.
[...]
> 1)
> It seems that the above size and layout may pose problems when using Git?
> Especially, we don't want people not using the Tests part to suffer any
> burden (disk space, checkin/out performance) when working locally.
> Is it possible? Should we structure our repository differently?
Yes, it's possible, and no, it's not needed to restructure the repository:
Git has a feature called "sparse checkout" [1] which can be used to not
check out parts of the project layout which match a set of configured
patterns. (You can also search the 'net for "git sparse checkout" to read
informal intros to this topic.)
Note that there may be some mismatches in terminologies between Git and TVFS.
Since Git it a distributed version control system (a DVCS), each developer has
its own local version of the repository. Usually an enterprise has a central
"rendez-vouz", "blueprint" repository everyone sends their work to and fetches
the work of others from, and for this reason local versions of such repository
are typically called "clones". This basically means every developer will have
those 10+ GiB of data on their filesystem.
Now "checking out" in Git has no relation to fetching data from some
repository, instead, it's an act of populating the so-called "work tree" - a
directory on the file system attached to the local repository - with the state
of a certain commit recorded in that repository. The developer then modified
the files in the work tree and then records the changes, producing a new
commit. So, sparse checkout allows to omit certain path hierarchies when
populating the work tree, but the data which is omitted is still kept in the
repository.
> Also is it possible to map the Tests part to a different part of the
> filesystem?
AFAIK, there is no direct support for that in Git but I think it can be done
with some effort (that would possibly require setting up another local
repository which will borrow the objects from the original one (Git can do
that) and then use sparse checkout feature configured "inversely" to the
original repo - so that there Git ignores the source code files but checks out
the test suite.) Probably there are simpler ways to do that but the obvious
question is: why not solve this using directory symbolic links?
> 2)
> Concerning the branch layout.
> With TFS, developers were used to having several working copies (called
> workspaces in TFS), for working on different subjects and the different
This one is easy as Git supports multiple worktrees attached to a single
repository [2].
Note that this has nothing to do with branch layout (may be this is another
terminological mismatch).
> We'd prefer solutions that work well with Visual Studio.
> (VS does integrate git support natively in the IDE for common tasks)
Configuring sparse checkout and several work trees are all stock Git
operations but I have no idea if the VS plugin for Git covers them.
Anyway, I think it's possible to occasionally resort to typing some commands
in cmd.exe or provide the devs with scripts (or some crude GUI tool) to do
that. Also good 3rd-party Git front-ends exist which might have support for
this stuff; personally, I'd recommend to look at Git Extensions [3].
OK, let me now address two points from your question here (so that they do not
derail the flow of the answer).
First, you could consider submodules [4] and split your monorepo into two
repositories - one with the source code and another one with tests.
Submodules is a way for one repository to "refer to" one or more other
repositories. A key property of this approach is that the "main" repository
(module) refers to particular commits in its submodules, and these references
are maintained in a file which is committed in the main repository. This way,
you still can have strict correlation between commits in the repository
containing the source code with the matching commits in the repository
containing the tests.
Another possibility - as you appear to be a Windows-only shop - is to explore
the possibility of using VFSForGit (ex GVFS) [6]. I did not use it personally
so cannot really comment on its pros and cons, but ISTR it's used by Microsoft
(who has developed it) for in-house work.
Second, as I've said, the statement
> Bug fixes may go to either branch and may then be merged into the others.
sounds foreign to the ear of a Git user.
In Git, merging "binds" one or more lines of history together - creating a
special commit, from which all those lines will be "reachable" (can be
traversed from the merge commit all the way down), like this:
-->A-->B-->C-\
M-->...
-->X-->Y-->Z-/
Hence when you have several release branches - as you seem to do - it's
unnatural to use merging to bring the same change into multiple such branches
because such merges would create bogus ties between the branch which
implements the original fix and the branch which recive the fix.
In Git, it's more natural to use "cherry-picking" [5] to bring a series of
changes into multiple disjoint places.
To round up, I'd recommend to first read up on Git (the "Pro Git" book is a
good start, see [4]) then try to play with multiple approaches to organizing
the repositories and the workflow, maybe ask further questions and then settle
on which works best.
1. https://git-scm.com/docs/git-sparse-checkout
2. https://git-scm.com/docs/git-worktree
3. https://gitextensions.github.io/
4. https://git-scm.com/book/en/v2/Git-Tools-Submodules
5. https://git-scm.com/docs/git-cherry-pick
6. https://github.com/microsoft/VFSForGit
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/20211124182212.mqvikcp7chu75ygt%40carbon.
