On Wed, 26 Sep 2012 11:53:08 +0200
Angelo Borsotti <angelo.borso...@gmail.com> wrote:

>    - created a topic branch
>    - forked a develop branch from it
>    - done all the development work, several commits saving all files,
> sources and binaries
>    - git checkout topic
>    - git merge --squash --no-commit develop  (this avoids to move the
> develop history to the topic)
>    - git rm -r --cached *.<all binaries>
>    - mv .git/info/exclude .git/info/exclude.save
>    - put a line in .git/info/exclude: *.<all binaries>
>    - git commit -m "some message"
>    - mv .git/info/exclude.save .git/info/exclude
>    - git push remote topic
> This keeps a "clean" topic branch in which there are only source files
> and a clean history, that can then be pushed to a public remote
> repository.

I don't quite follow why you used the --squash option to `git merge`
-- as I understand it, it basically lumped together the whole series of
commits "develop" has WRT "topic" and created one gross commit with
these changes on top of "topic", that is, you effectively lost the
development history of "develop", just kept the changes made on it.
I see you even mentioned this in your comment but can you really
elaborate on your decision?

To be more clear: losing history information is, say, a notorious
problem with merges as implemented in Subversion, and Git, being a DVCS,
enjoys the fact merges in it maintain proper heritage.  This approach to
merging has several benefits: one (obvious) is that one can easily
inspect the evolution of the code, another one (less obvious) is that
provided the commits were created sensibly (one commit per logical
change), they can be later dealt with individually -- for instance,
reverted with `git revert` or cherry-picked to somewhere else

I understand that having just one gross commit in the end on your
feature branch might be just okay for your workflow, but as you might
just miss the point of merges as implemented in Git, I decided to warn
you of possible implications of your approach.

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