<p>GIT hooks <em>could</em> work, but the trouble is that they're not automatically installed when the developers pulls a workspace. Which means they <em>might</em> end up being installed/used correctly or not. Unreliable.</p>

<p>CI scripts <em>could</em> work as well, but the're reactive, simply indicating that something went wrong, in most cases humans still need to identify the culprit (which <em>might</em> be caused by an improper DTO subtree or by something else) and fix the problem.</p>

<p>If you want your developers to properly pull their subtrees - offer them a scripted wrapper to do so - put the effort into that script so that it is simple to use and robust/working well such that the developer's workflow is effectively simplified. If you manage to do this (most of) the developers will see the benefit and they will use it.</p>

<p>For the push side - you need to take into account that mistakes in push will happen (even with the above-mentioned script, if it's not used by <em>all</em> developers, for example). Everyone makes mistakes.</p>

<p>Personally I favour <em>preventing</em> developers from directly pushing their changes into the integration branch and thus blocking possible mistakes from affecting the integration branch.</p>

<p>Instead I'd have all <em>candidate</em> changes (i.e. either pushed in separate branches or just as diffs) funnelled through a mandatory <em>centralized</em> pre-commit verification system. Automated, of course, with the proper git subtrees management made reliable through that automation. The changes would only be committed/merged into the integration branch automatically by this system, if they meet the quality checks. </p>

<p>This approach is applicable to <em>any</em> potential regression-causing mistakes, not just improper DTO subtrees. An example of such approach would be <a href="https://docs.openstack.org/infra/manual/developers.html" rel="nofollow noreferrer">the gerrit-based development on OpenStack</a>.</p>

CC BY-SA 3.0
2017-12-03T04:47:14.497Z
2017-12-03T04:47:14.497Z
Dan Cornilescu
<p><strong>Problem:</strong> </p>

<p>We use Data Transfer Objects (DTO) to ensure consistent interfaces across multiple services using TypeScript. </p>

<p>We're currently using a git subtree in order to make sure that each repository has its DTO dependencies up to date. These DTOs are changed semi-frequently. </p>

<p>The challenging part is that subtree pull / subtree push are outside the traditional git process for most developers. </p>

<p><strong>Question:</strong></p>

<p>What process patterns have people found work well to ensure each related repositories subtree is up to date on each push / pull? Post commit hooks? CI scripts? Etc. etc? </p>

CC BY-SA 3.0
2017-09-11T19:30:33.883Z
Why do you use DTOs?
030
CC BY-SA 3.0
2017-09-11T19:48:37.283Z
What programming language do you use? Could you example of such a DTO?
030
CC BY-SA 3.0
2017-09-11T20:06:17.677Z
https://martinfowler.com/eaaCatalog/dataTransferObject.html
Jack Murphy
CC BY-SA 3.0
2017-09-17T03:06:20.053Z
I don't know what a DTO is, but I would suggest that if you're asking your developers to treat subtrees as anything other than read-only clones you're probably asking for trouble.  If developers regularly need to edit files in subtrees directly, or need to update them with something other than `git submodule update`, people will probably find them hard to work with.
larsks
CC BY-SA 3.0
2017-11-24T23:16:27.810Z
@larsks In my opinion you could post this comment as an answer.
030
<git>
How to ensure that git subtrees are kept up to date?
Jack Murphy
# How to ensure that git subtrees are kept up to date?

(Asked by: username_0 on 2017-09-11)

**Problem:**

We use Data Transfer Objects (DTO) to ensure consistent interfaces across multiple services using TypeScript.

We're currently using a git subtree in order to make sure that each repository has its DTO dependencies up to date. These DTOs are changed semi-frequently.

The challenging part is that subtree pull / subtree push are outside the traditional git process for most developers.

**Question:**

What process patterns have people found work well to ensure each related repositories subtree is up to date on each push / pull? Post commit hooks? CI scripts? Etc. etc?

**Tags:** git

> **Comments:**
> **username_1**: Why do you use DTOs?  
> **username_1**: What programming language do you use? Could you example of such a DTO?  
> **username_0**: https://martinfowler.com/eaaCatalog/dataTransferObject.html  
> **username_2**: I don't know what a DTO is, but I would suggest that if you're asking your developers to treat subtrees as anything other than read-only clones you're probably asking for trouble.  If developers regularly need to edit files in subtrees directly, or need to update them with something other than `git submodule update`, people will probably find them hard to work with.  
> **username_1**: @username_2 In my opinion you could post this comment as an answer.  

---

## 1 answers

### Answer by username_3 on 2017-12-03. Score: 2

GIT hooks *could* work, but the trouble is that they're not automatically installed when the developers pulls a workspace. Which means they *might* end up being installed/used correctly or not. Unreliable.

CI scripts *could* work as well, but the're reactive, simply indicating that something went wrong, in most cases humans still need to identify the culprit (which *might* be caused by an improper DTO subtree or by something else) and fix the problem.

If you want your developers to properly pull their subtrees - offer them a scripted wrapper to do so - put the effort into that script so that it is simple to use and robust/working well such that the developer's workflow is effectively simplified. If you manage to do this (most of) the developers will see the benefit and they will use it.

For the push side - you need to take into account that mistakes in push will happen (even with the above-mentioned script, if it's not used by *all* developers, for example). Everyone makes mistakes.

Personally I favour *preventing* developers from directly pushing their changes into the integration branch and thus blocking possible mistakes from affecting the integration branch.

Instead I'd have all *candidate* changes (i.e. either pushed in separate branches or just as diffs) funnelled through a mandatory *centralized* pre-commit verification system. Automated, of course, with the proper git subtrees management made reliable through that automation. The changes would only be committed/merged into the integration branch automatically by this system, if they meet the quality checks.

This approach is applicable to *any* potential regression-causing mistakes, not just improper DTO subtrees. An example of such approach would be [the gerrit-based development on OpenStack](https://docs.openstack.org/infra/manual/developers.html).


---

