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
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
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
Hello,
where is the proper place to report bugs?
I have tried to send mails to g...@vger.kernel.org, as indicated by the git
website,
but all mails bounce back.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on
Hi P.J.
exactly. That is the answer. Surfing the web I have seen that "bare"
repositories
are supported only in git 1.7. Since it is (and was) not possible to push
to a
non-bare repository, I wander how the community used git pre-1.7. No one
ever used a remote repository to push files since now?
Hi,
I guess that a tarball would be the distro of the project, i.e. what is
deployed,
while a released project should contain the .git repo, with all the history
in it
so as to let future developers have all the data to start a new development.
In such a case what is not needed are the files since
I have the impression that the underlying model of a git repository is made
of a .git archive plus a work
directory in which (some version of, e.g. the latest) the files are
present. I.e. at least one version of
the files are stored twice.
E.g. suppose I create a new project and initialize git in