Hi Konstantin,
the idea of using merge --squash comes from:
1. the need to have a clean history of the changes: the developer
that implements
something (e.g. a feature or a bugfix) on a topic branch could
have done it
creating several commits in her/his development branch, commit
On Wed, 26 Sep 2012 11:53:08 +0200
Angelo Borsotti 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 devel
Hi Konstantin,
I have got your suggestion, and done the following:
- 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
On Tue, 25 Sep 2012 02:11:14 -0700 (PDT)
Angelo Borsotti 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 rec
The SHA-1 hash which identifies each commit in git is generated from the
state of the tree at that point and thus having a version of that commit
with binaries and a version without results in -- as far as git is
concerned -- entirely separate commits. It is really useful when the
same commit maps
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
