[git-users] Git Can't push a link file into remote repo?
HI, All: I am a recently setup a git server on mac os ,meanwhile I use a git client on ubuntu to do interaction with this git server. I have a code directory(it's very large ,about 1G ) and I did the following commands to push it to server side: 1. cd ~/test 2. git init 3. git add . 4. git commit -m clean copy for first commit to server 5. git remote add origin ssh://gitadmin@mylocalgitserver/gitrepos/test 6. git push origin master In the code ,there are some directories which contain some link files ,something like this: cd asm ls arch arch-mb86r0x arch-s3c4510b config.h ptrace.h ll st lrwxrwxrwx 1 gitadmin ubuntu10 11 2012-09-26 14:00 arch - arch-sc8810/ my problem is ,this link file arch can't be committed to my local repository at step 4 ,so after i finished the step 6 for push ,if i clone ths remote repo on server ,i can't see the link file arch at all so that i can't get a total same code copy as original source. But I also did try to make a simple code sample directory which only have a directory with one file and a link file to this directory , i can commit this code sample to local repo and push it to server side successfully ! Then if i checkout the code from remote ,i can get a total same code copy: a directory with one file and a link file to this directory I am totally confused ... Is there anyone can help me out? -- 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/-/x8AHhsC_qZMJ. 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 *.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
On Wed, 26 Sep 2012 11:53:08 +0200 Angelo Borsotti angelo.borso...@gmail.com 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 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. I don't quite follow why you used the --squash option to `git merge` -- as I understand it, it basically lumped together the whole series of commits develop has WRT topic and created one gross commit with these changes on top of topic, that is, you effectively lost the development history of develop, just kept the changes made on it. I see you even mentioned this in your comment but can you really elaborate on your decision? To be more clear: losing history information is, say, a notorious problem with merges as implemented in Subversion, and Git, being a DVCS, enjoys the fact merges in it maintain proper heritage. This approach to merging has several benefits: one (obvious) is that one can easily inspect the evolution of the code, another one (less obvious) is that provided the commits were created sensibly (one commit per logical change), they can be later dealt with individually -- for instance, reverted with `git revert` or cherry-picked to somewhere else I understand that having just one gross commit in the end on your feature branch might be just okay for your workflow, but as you might just miss the point of merges as implemented in Git, I decided to warn you of possible implications of your approach. -- 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, 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] Merge and modification strategy
On Wed, 26 Sep 2012 04:24:39 -0700 (PDT) Salah khamassisa...@gmail.com wrote: [...] I have a little question though: Some team developers that I encountered would like to be able to see which files (codes) are modified in the present time locally. They told me that in their projects, some codes have to be modified by one person at time. For example, developer A wants to modify a code, but receives a notification (or some alert) that developer B is changing the file in his local machine but that he has not committed yet. I am aware this stops work a little bit, but those are their requirements. I am wondering if GIT offers this possibility to developers. No, it does not. Actually, the whole point of a DVCS system is to allow disconnected development -- you have all the history locally and are able to do any number of commits to any branch and only reconcile your work with another repository (a reference one, for example) when you're back online. As you could see, since you have all the history locally, and nothinhg prevents you from creating any number of branches locally and juggle code between them as you see fit, the whole point of I am editing this source file at the moment becomes quite moot. One another problem is that Git does not even really track file names in the sense many people expect it to, see [1]. 1. https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_renames.3F -- 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] Re: Merge and modification strategy
Hi Salah, It sounds like your team might be more familiar with something like Visual SourceSafe. In the VSS model, VSS keeps your code, and one person can check-it-out at a time. VSS discourages multiple users from accessing the same file simultaneously. In Git anyone with access to the repository can clone it and modify any and every file in their local working directory. This is more flexible because in VSS someone can checkout a file while they are at lunch, overnight, or over the weekend, and the other team members are locked-out of making changes to that file. Also, the Git paradigm allows multiple users to edit the same file and helps merge their results together. If I make changes in one part of the file, and you make changes in another part, Git can automatically merge those changes together when we commit and push. The problem you are probably worried about if when two users make changes to the exact same code; that is, when two developers edit the same lines of code in the same source file. It's still possible to merge the files, but Git will recognize that there is a merge conflict and someone will need to review and resolve the conflict. If you are worried about preventing these kinds of conflicts, the best policy is for your team to clearly communicate their efforts. Assigned responsibilities so that Team Member A is responsible for the DataAccessLayer and Team Member B is responsible for the Customer object. Or use an incident tracking system, like JIRA, and have your developers add notes when they are taking ownership on an issue. Then other developers can check to see if someone is already working on a specific issue before they jump in and duplicate efforts. But in the worse case scenario when two developers edited the same code, you can still review and accept either person's modifications, or some hybrid merge which combines some mods made by one developer with some lines made by the other developer. Konstantin, I see you wrote , the whole point of 'I am editing this source file at the moment' becomes quite moot., but is that really true? Don't you see how it can still be important for a team to avoid working on the same exact lines of code in order to reduce wasted efforts (inefficient use of resources) and to reduce complicated mergers? The nice thing about Git is that we can all work on any part of the project at the same time. When I edit the header portion of home.html and you edit the footer, we can merge without incident. But if we both edit some HTML form in contact.html, then we duplicated efforts and someone has to deal with merge conflicts. So I don't feel it's entirely a moot point for a team to communicate who tasks should be delegated, at least in a commercial software development setting where time is money. Maybe it's less of an issue in open-source where everyone is just voluntarily making contributions and hoping theirs will get accepted. Thoughts? On Wednesday, September 26, 2012 8:24:39 PM UTC+9, Salah wrote: I am doing a research on continuous integration process. I am reading some topics from the book available online and understood the Clone-Commit-Fetch -Push process. I have a little question though: Some team developers that I encountered would like to be able to see which files (codes) are modified in the present time locally. They told me that in their projects, some codes have to be modified by one person at time. For example, developer A wants to modify a code, but receives a notification (or some alert) that developer B is changing the file in his local machine but that he has not committed yet. I am aware this stops work a little bit, but those are their requirements. I am wondering if GIT offers this possibility to developers. Salah -- 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/-/tHUj-yZfdhUJ. 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] Re: Merge and modification strategy
Do you have any information of delegates and Git? I haven't come across that feature yet. Could be useful to OP. On Thu, Sep 27, 2012 at 3:20 AM, Gadget/Steve gadgetst...@hotmail.comwrote: On 26/09/2012 6:51 PM, Max Hodges wrote: Yes I don't disagree: that notion of locking a file makes no sense in Git. I just wanted to emphasis the importance for teams to stay in communication if they want to reduce any annoying conflicts during merging because of this feature. Just like when you're renovating a house, a little communication, planning and some policies can prevent two or three people from painting the same wall a different color at the same time. The nice thing about Git is that the worse case scenario--where two people edited the same code in some conflicting way--isn't really that big of a problem. You just need to review and make some decisions. From my reading the Git way around this is to use delegates, i.e. if there is a load of artwork than needs updating then the artwork team/team member is delegated that area of the project, etc. Gadget/Steve -- 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. -- 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] Re: Merge and modification strategy
On 26/09/2012 8:14 PM, Max Hodges wrote: Do you have any information of delegates and Git? I haven't come across that feature yet. Could be useful to OP. Take a look at http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows specifically the Dictator - Lieutenant workflow. -- 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.
