On Thu, 10 Sep 2015 11:34:32 -0700 (PDT)
> > The simplest solution I can think of, which does not involve any
> > tools outside of Git (well, almost), is using the lesser-known fact
> > Git's object database is able to store arbitrary data -- not
> > necessarily bound to a commit.
> Simplest solution? As a new VCS user, it appears to me too
Well, I'm not sure where to draw a line between "simple" and
"complicated", you know. If by "simple" you mean "supported right away
by some command in some GUI tool" then I'm afraid that no, there's no
such thing. On the other hand, one of the Git's strengths is that it's
really a *toolbox* rather than a tool, and things that are outright
impossible in other VCS systems are possible in Git once you're
familiar. The approach I suggested is not wizardry (IMO) but it
requires certain knowledge at least about the terms I used and you're
supposed to have read the manual pages of the commands I mentioned to
So... I don't know. If I were you, I'd try to gain that knowledge and
then approached the proposed solution once again.
Git has lots of good reading material available for it.
For instance, you might want to google for "Git from the bottom up"
and "Git for computer scientists" which arm the reader with the
knowledge of how Git manages its data.
> > * Have a separate branch for binaries.
> > After the release, save your binaries somewhere, check out that
> > branch, copy your binaries over, add/remove changes, commit.
> I don't think I understood.
Well, the fact Git supports multiple branches does not force you to
have mostly the same data in all those branches. To may be explain it
more visually, even if your repo typically starts with a single
branch named "master", and all the other branches are typically forked
off it (and off other branches, but that transitively makes them
"inherit" from "master" anyway), you can create a branch which "starts
from nowhere" and contains no data. The first commit recorded on it
will really be the first on it, and will have no relation to "master"
or any other branch.
Once you have such a branch, you can use it for storing your binaries.
Each commit will contain a new set of binairies -- related to a
This might sound like a magic (again) but this approach is routinely
used by certain tools. Off the top of my head I recall
git-buildpackage, which is used to prepare packages for the Debian OS
and uses a separate branch to store upstream tarballs (source code
If you're interested, read up on the "--orphan" command-line option
in the `git checkout` manual.
> Maybe it's simpler to make a commit of the final release tree, create
> a branch for the final release only, add every file I need (binaries)
> to the branch only and switch back to master.
> git commit -a -m "Version 1.0 RC1"
> git checkout -b v1.0-branch
> del .gitignore
> git add *
> git commit -m "Version 1.0"
> git tag -a v1.0 -m "Release 1.0 with binaries"
> git checkout master
> The only problem I see is I will have a different branch for each
> production release that isn't what the branching mechanism was
> thought for.
This approach can easily be improved by simply deleting the branch
git commit -a -m "Version 1.0 RC1"
git checkout -b temp
git add *
git commit -m "Version 1.0"
git tag -a v1.0 -m "Release 1.0 with binaries"
git branch -d temp
git checkout master
You now have a tag "v1.0" which references the (single) commit recorded
on the throw-away branch "temp" (and all commits it links to, of
Well, if this works for you, OK, go with it.
In my book, this stinks because mixing binaries with the source code
stinks. But again, don't try to follow dogmas: if what I proposed
still sounds like mumbo-jumbo, use whatever you understand and then
maybe reconsider your approach once you gain more Git knowledge.
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
For more options, visit https://groups.google.com/d/optout.