1

I got a bit thrown into the cold water with this…

We have a product which consists of generally used files plus a few user specific ones. Based on the very good experience with Git for the development cycle, we are considering using Git as well for the distribution to the end users.

Distributing the generally used files is not such a big deal; that can be done with a specific branch. But I am somehow stuck with the user-specific files. One condition with those is that other users are not allowed to even know about them. The way I understand Git so far is that every place has the complete set of files, and that would not be allowed.

So, the questions:

  1. Is Git still the tool for distribution to use?

  2. If so, how would we implement the user-specific file distribution? (note that an update of the system would consist of new general files plus new user-specific ones)

  3. What would be a good source of information helping me with these questions (aside of asking here)?

  4. If Git is not really the tool for our purpose, which direction should we look at?

Thanks in advance for any comments.

Biffen
  • 6,249
  • 6
  • 28
  • 36
Max Wyss
  • 3,549
  • 2
  • 20
  • 26
  • What is your software? Who are your users? How do they use your code? Do they have to compile / are these scripts we're talking about? Git is not a software distribution tool, but it does make sense if you're talking about *library* code that other developers are going to use, or other things utilized by power users. Don't expect grandma to `git clone` your software though. – Jonathon Reinhart May 09 '14 at 07:56
  • The files we distribute are Applescripts, Acrobat Preflight profiles, Acrobat Preflight droplets, some ICC profiles etc. All which has to be done on the user's side is to copy/install those files. In fact, we would like to do that using a client-side script (maybe run once a month or so), or/and otherwise, manually using remote maintenance tools. The end user rarely has anything to do with the files. – Max Wyss May 09 '14 at 08:16

2 Answers2

2

1/ Is Git still the tool for distribution to use?

No: "distribution" means "release management" (packaging + delivery publication), while Git is strictly a (distributed) versioning tool.

2/ If so, how would we implement the user-specific file distribution? (note that an update of the system would consist of new general files plus new user-specific ones)

You can use branches, combined with value files, and let git generate for you the right final file during checkout (smudge script).
You would declare a content filter driver able to recognize the current branch.

smudge

(From Pro Git book 7.2 Customizing Git - Git Attributes)

But that is a way to build the right set of file from which you make your release.
It is not a way to distribute those files: see next point.

3/ If Git is not really the tool for our purpose, which direction should we look at?

Release management is usually done from a build scheduler (Jenkins, Hudson, TeamCity, ...)

That is where you can:

  • get automatically the latest revision of your git repo (the smudge script above would apply and generate the right user files, depending on the branch monitored by the job in that scheduler)
  • package and distribute those files: that is done by the script you attach to a job, and that script can be in any language, doing whatever you want to:

  • generate something that you can easily distribute (For instance, a simple zip file): that is the packaging step

  • copy that package wherever you need to be copied.

The added benefit of that approach is that you don't need Git on the production server, meaning you have one less "moving part" to debug/update/maintain on said production server, keeping it simple(r).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

You have to use some git servers with a fine-grain access control on branches / tags:


Gitolite

Gitolite allows you to setup git hosting on a central server, with fine-grained access control and many more powerful features.


Gerrit

Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system.

Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.

Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git.

NOTE: Gerrit has been created for code review but it include an internal git server with fine-grain access control and can be used only for this if the review is not needed. Moreover, Gerrit can be easily configured using web UI.

jmlemetayer
  • 4,774
  • 1
  • 32
  • 46