1

Can anyone explain how something like the following system could be brought outside of git, i.e. using version numbers instead of git's context via branches and submodules:

Let's say we have some tools that are in a project git repo. The assets are in an assets repo, and because the data - organization, naming, number of data fields, etc. - changes over time, and because the tools must also update to work against these changes, we want to make the asset repo a submodule of the project repo. This lets us do things like branch project, checkout an older version, and have the assets move back in time to match, so the tools and data stay in sync over time. This lets us, e.g., checkout everything from a week ago.

It also means we can have a crazy idea for reshaping the data to make for new abilities in a particular tool, and we can branch project, then branch assets and in the new branch in project we can check out that new branch in assets, and effectively work on everything separately. If real work comes in, we can just hop back to project's master, and the assets update to follow suit. If the crazy new data structure works out, we can branch (or reuse the first branch) and bring the other tools in line with the new data, and when all of it works, we can merge everything back, without interrupting anyone (provided interfaces haven't changed). It seems like a nice workflow, and it keeps assets separate from tools, so various departments can use them without needing a large repo of tools that don't even work on their systems, and I can pull down the tools without a huge vat of assets if I just want to work on some logic separate from the assets on my laptop.

Is there anything approaching this level of complexity and flexibility using packages and version numbers? I've never used them, but I keep feeling like I'll need to if I want to break tools out of git for distribution elsewhere, while preserving interdependencies. How do people resolve git and package version numbers? I've been studying this for awhile and I'm still quite confused by all of it.

shyam
  • 9,134
  • 4
  • 29
  • 44
Gary Fixler
  • 5,632
  • 2
  • 23
  • 39

1 Answers1

0

The notion of package and version number is completely orthogonal to git:
Git versions text files.
If those text files represents a packages, and have somewhere an element which declares a version, that is entirely up to the user of the git repo. Git has no idea of those notions.

The closest of a version number deduced solely from git is git describe (as in "Deriving application build version from git describe - how to get a relatively straightforward string?").
But that won't do much more than that, and any version dependency mechanism you might want will have to be managed by you.
All that git submodules are doing is recording a fixed SHA1 for each submodule.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Right. I know how git works under the hood. I'm just not entirely clear on how dependencies and version numbers keep things aligned in other systems. My questions are probably more about Python than git. Git's hashes allow me to hop around and have everything follow suit. Does Python do this? If I install a tool that has dependencies, does it install them? If I roll back the tool somehow, do the dependencies roll back? How are things kept from colliding? This is the mess I don't yet get. – Gary Fixler Apr 01 '13 at 09:51
  • @GaryFixler good questions. My point was: this has nothing to do with git. – VonC Apr 01 '13 at 09:53
  • Point taken. I guess what I really meant was "Look at this nice setup I have in git; does this exist outside of git using version number schemes?" – Gary Fixler Apr 01 '13 at 09:57
  • @GaryFixler I guess it does not, at least not at a level which would know anything about git. It might exist, but independently of git. – VonC Apr 01 '13 at 10:09
  • It's okay if it loses some context with git. Basically, right now I have git repos that work together through git's submoduling feature. I don't want to presume everyone will be using git, though, or that they'll need all of my repos to maintain context. If I want to break two repos out, I'd like for someone to be able to clone those independently - so they're still they're own git repos - but then be able to sync them up outside of git via their version numbers. I.e. I could have particular releases on a website, which would really be particular commits of each repo. – Gary Fixler Apr 01 '13 at 17:53
  • 1
    @GaryFixler note that you could group those two git repos in a parent repo of their own, allowing contributors to clone only those two at the right version. But that is a pure git mechanism again. – VonC Apr 01 '13 at 18:44