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
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
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?
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
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
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
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
