Re: [git-users] avoid pulling binaries
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.
Re: [git-users] avoid pulling binaries
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 *. - mv .git/info/exclude .git/info/exclude.save - put a line in .git/info/exclude: *. - 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.
[git-users] avoid pulling binaries
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 bugs reporting
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 the web visit https://groups.google.com/d/msg/git-users/-/ke2eDiumPEsJ. 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
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? -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] git contents model
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.
[git-users] git contents model
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.
