3

On Windows we have root\folder1, root\folder2, root\folder3. On Linux we have root/folder1/folder2, root/folder1/folder3

I would strongly prefer NOT to use submodules nor subtreees.

Is there another solution? Would it work to create a branch and re-arrange the files to the Linux structure? And would merges between the branches make sense?

Edit

I have done much more reading, especially about branch work flows. I'm now re-considering the NOT submodules statement. I was concerned with having the day-to-day developer repository containing submodules and the complications that seems to entail. But, I think that the developers do not need submodules, they can meet the need with embedded repositories.

Say folder 1, folder 2 and folder3 are separate git repositories - repo 1, repo 2 and repo 3. On Windows the 3 repositories are separate. On Linux, folder 1 is repo 1, folder1/folder 2 is repo 2, etc.

If I'm in folder 1 and there are changes in folder 2, will a git add . not include the folder2 change? Does git stop when it sees another .git?

There could be 2 separate bare repositories for building which includes the 3 repos as submodules in the appropriate configuration for Windows and Linux. The release branches can then be managed here. But what branching is seen in repo 1, 2 and 3? Has anyone tried something like this? Did it work well?

RobG
  • 744
  • 6
  • 16
  • 1
    On Linux you can create and track symbolic links. But, you are better off refactoring your app to have the same directory structure on all platforms – mvp Jun 18 '13 at 05:06
  • I have edited my answer below to address your edit. – VonC Jun 19 '13 at 14:49

1 Answers1

3

Beside the symlinks mentioned by mvp (note: you can have symlink on Windows 7+ too, see also "Git Symlinks in Windows"), this would be a deployment issue:

Ie: you would have:

  • your regular local clone
  • a copy of that clone with the right structure
  • a way to diff/import any modification made in that copy back into the regular git repo

... so yes, keeping a common directory structure remains the simplest solution.

If I'm in folder 1 and there are changes in folder 2, will a git add . not include the folder 2 change?

No, it will only consider changers in any part of folder 1, except folder 2 content.

Does git stop when it sees another .git?

Exactly.

There could be 2 separate bare repositories for building which includes the 3 repos as submodules in the appropriate configuration for Windows and Linux

Note: a bare repo cannot contain another repo, since there is no working tree for said repo to include... anything.

A nested repo wouldn't be recorded at all in a branch of a parent repo, contrary to a submodule.

I suspect subtree is a better fit for us.

Yes, subtree (part of git since 1.7.11) would involve 2 repos: one for Windows and one for Linux.
Each one would aggregate subtree repos with the right structure.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Pretty sure that git won't add or create symbolic links on any version of Windows...? – Edward Thomson Jun 19 '13 at 13:28
  • @EdwardThomson git alone won't add/create symlink, yes, you are correct. But a script registered as a post-checkout hook could: http://stackoverflow.com/q/5917249/6309 – VonC Jun 19 '13 at 14:41
  • Phew, just checking... symbolic links and junctions are so odd on Windows that I would have been frightened if that functionality had been added (in the box, so to speak) but I wouldn't have been shocked! :) – Edward Thomson Jun 19 '13 at 21:27
  • Ok, thanks. I'm a little unclear on the bare repositories. Are you saying that a bare repo cannot contain a submodule given a submodule is a repo? – RobG Jun 19 '13 at 22:09
  • @RobG a bare repo can contain the *reference* of a submodule (as a [special entry](http://stackoverflow.com/a/2300638/6309)), but since a bare repo doesn't show any actual file (no working tree), you won't see that submodule content. I was referring to nested git repo (not submodules): a bare repo cannot contained a nested repo because a nested repo is not a bare repo (it has a working tree). A bare repo can contain a reference to a submodule. Not a nested repo. – VonC Jun 19 '13 at 22:46
  • OK. So, when a branch is created in a repo, say `Parent Repo`, that contains submodules, can that branch be synced to the repo that the submodule represents? That is, can it be seen? Can a developer work on, say, a Release branch in `Repo 1` synced from `Parent Repo`/Release? and push commits back to `Parent Repo`/Release? – RobG Jun 20 '13 at 11:07
  • @RobG branches form a parent repo have no relationship whatsoever with branches in a submodule (or with branches in a simple nested git repo, for that matter). You can however configure a submodule to follow a branch from the [upstream repo](http://stackoverflow.com/a/2749166/6309) that submodule is from: see http://stackoverflow.com/a/17199855/6309. Again, the parent repo doesn't care what branch you are working on in the submodule (and the submodule ignores completely the existence of a parent repo). – VonC Jun 20 '13 at 13:50
  • 1
    For more on that, see **[true nature of submodules](http://stackoverflow.com/a/1979194/6309)**. – VonC Jun 20 '13 at 13:54
  • @VonC What I read on submodules does not make me think its a good technique for us to solve the Windows/Linux difference. It may become necessary if our repo becomes too large for Git to handle well. Then we made need to split it up. – RobG Jun 21 '13 at 00:48
  • @VonC I suspect `subtree` is a better fit for us. – RobG Jun 21 '13 at 00:50
  • 1
    @RobG yes, I have added this option to the answer, with a link to more details about subtrees. – VonC Jun 21 '13 at 06:13