On Tue, 25 Sep 2012 02:11:14 -0700 (PDT)
Angelo Borsotti <angelo.borso...@gmail.com> wrote:

> Suppose I have a private repository and a public one. I develop using
> my private repository, and at significant steps I do a commit in
> which I save all, sources] and binaries. The reason for saving
> binaries is to allow to recover a previously committed version
> without having then to rebuild all binaries. When I have completed
> the development of a feature, I push it to a public repository, one
> that is accessed by an integrator, that takes my contributes and
> other developers' as well, and integrates all of them. After having
> pulled all the contributed, the integrator always rebuilds the
> binaries. Therefore, there is no need for me to push binaries from my
> private repository to the public one, and for him to pull them. Is
> there a way in git to avoid to push and pull binaries in this
> workflow?

One way I can imagine, is using `git filter-branch` [1] with
its --three-filter option to drop the binaries matching certain
patttern from a branch which is ready to be proposed upstream.
Basically, when your feature branch is ready, you "clone" it (by means
of saying `git checkout -b newbranch thatbranch`) and then run
`git filter-branch --tree-filter ...` on the new branch to re-write it
dropping all the cruft from the commits.  Then you check if it looks OK,
propose it to upstream or replace the original branch with its
rewritten copy.

One other approach I might imagine is juggling with two branches -- one
"clean", on which you just do the regular work and commit only the
relevant (that is, source) files, and another one -- a "dirty" branch,
which you check out from time to time, merge the "clean" branch in and
then commit the built cruft.  That is, you'll do continuous periodical
re-integration of the "clean" branch to the "dirty" branch with
commits of the binaries after each reintegration.

You can also have it backwards: do normal work on a "dirty" branch" but
implement a simple policy about what you commit: commits touching
relevant files must be done separately from the commits touching
binary cruft (these can even be marked by something like "[binary]"
prefix in their commit messages).  You then periodically switch to a
"clean" branch and perform cherry-picks [2] from the "dirty" branch,
picking only the "clean" commits.

1. http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
2. http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to