[git-users] Re: ignore files with hard definition
Am Freitag, 31. Januar 2014 10:28:21 UTC+1 schrieb Thomas Ferris Nicolaisen: I think the best way is to keep a clear and well-made .gitignore file, and foster a culture that respects not changing it without good reason. Hard constraints on contributors are usually counter-productive in the long run. You are right, but the problem is, that on errors the first try is, to modify the file, which creates the block, the error isn't be fixed. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: ignore files with hard definition
On Friday, January 31, 2014 8:25:00 AM UTC+1, Philipp Kraus wrote: Hello, can I define on my server repository, that the ignored file patterns are hard defined. My problem is, that each use can modify the gitignore, but I get with this modification files into the server repo, which should not be there, so I would like to define in the server (bare) repo files patterns, which should be never pushed into the repo. I would like to do this with a hook, check the pushed filelist and reject the push, if some filepattern is found Is this the correct way or is there a better solution? I think the best way is to keep a clear and well-made .gitignore file, and foster a culture that respects not changing it without good reason. Hard constraints on contributors are usually counter-productive in the long run. However, you can make pre-receive hooks in repositories that reject pushes based on anything you can express in a script. Example: http://stackoverflow.com/questions/2569960/git-pre-receive-hook -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: Ignore files
Oh, and if you do revise the git repo, I don't know what will happen if you do a git push to a remote repo. It may fail. Or it may update the remote in such a way that others have problems doing a fetch or pull. Perhaps one of the very experienced will speak up on this issue. I really hate doing revisions which impact sharing (like rebase in most cases). On Wednesday, January 2, 2013 11:47:53 AM UTC-6, fpefpe wrote: Hello -- I realized after-the-fact that I should nave ignored some files at the start of a project and new repo -- If I add these file name to the .gitignore file would files already tracked stay in the log/history and that future add/commits would now ignore those files? --
[git-users] Re: Ignore files
On Wednesday, January 2, 2013 7:06:40 PM UTC+1, John McKown wrote: Oh, and if you do revise the git repo, I don't know what will happen if you do a git push to a remote repo. It may fail. Or it may update the remote in such a way that others have problems doing a fetch or pull. Perhaps one of the very experienced will speak up on this issue. I really hate doing revisions which impact sharing (like rebase in most cases). Indeed, a filter-branch operation will rewrite history, so you need to announce this to others with access to the repo, if any. They will get an warning upon pulling, and will have to reset their own branches to the new references you've created through the re-write. However, I did just try this with git 1.8, and I might be wrong on this, but it seems Git has gotten a bit friendlier towards forced-updates recently, and treat the rewritten tracking branch simply as a diverged branch - ie. people will get a merge commit on their next pull. Example output. From *clone-repo-number-1* I have pointed my HEAD revision at some rewritten commit, and then push it to to the *central-repo's*origin/master branch: git push -f origin HEAD:master Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 358 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To /Users/tfnico/temp/foo.git + bd8a45c...158266b HEAD - master (forced update) And here I have another *clone-repo-number-2* connected to the same remote * central-repo* origin that I just force-updated, doing a pull: git pull remote: Counting objects: 5, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /Users/tfnico/temp/foo + bd8a45c...158266b master - origin/master (forced update) Merge made by the 'recursive' strategy. fee.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) In this case, I actually wish to force the local master branch into being the same history and state as the forced-update one, so I do: git reset --hard origin/master Now all repos (*clone-repo-number-1, central-repo and ** clone-repo-number-2) *have matching history. Using git 1.8.0 btw. --
