Re: [git-users] avoid pulling binaries

2012-09-26 Thread Angelo Borsotti
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 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.

-Angelo

-- 
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 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] avoid pulling binaries

2012-09-26 Thread Angelo Borsotti
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, commits
that are not
   interesting for the overall project. E.g. s/he could have
committed, then run some
   tests, found bugs or improvements in the code, and then have
committed again.
   This is relevant only for the developer.
   2. the need to push only the binaries to reduce push time. A merge
without --squash
   creates a commit merge that has as parents the topic and the
develop merge.
   A push transfers all of them, including the commits on the
develop branch, that
   contain the binaries.

-Angelo

-- 
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 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



[git-users] avoid pulling binaries

2012-09-25 Thread Angelo Borsotti
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?

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/txZDxAw_laEJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



[git-users] git contents model

2012-07-13 Thread Angelo Borsotti
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 it. Then I can 
create files and commit changes.
When I am done, i.e. the files are ready to be released, I make the last 
commit, and thenI have the files
in the work directory AND in the .git. At this point if I delete the files 
from the work directory, I take
the project to an inconsistent state (as reported by git status, which 
tells me that all files have been
removed). So, the nornal state of a released project is to have its files 
stored twice.
Is this correct?
Is this what we want?

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/sGf0sgwK_NwJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.



Re: [git-users] git contents model

2012-07-13 Thread Angelo Borsotti
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 they are also
contained
in the .git repo. I was wandering why there should instead be a need to have
also the files (note that a directory with a .git in it and no other files
is a
project with a pending change in it that is the removal of all files, as
reported
by git status).

-Angelo

-- 
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 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.