Greetings, I am a member of a multi-hundred person engineering organization. We are considering changing our SCM system to git. As we evaluate the potential impact of this move, a number of questions have arisen to which I am seeking guidance or opinions if not actual answers. I am sure some of these are considered quite basic and I expect I will discover the answers to these as I continue experiment with Git. I thought I would put this list out there and ask the community to contribute their opinions / experience early in my prototyping/evaluation process and possibly save myself some time and/or get insight into where I should look for answers.
I thank the community in advance for any light you may be able to shed on these concerns/questions: - Is there any way to edit commit comments? - Is there any way to set up triggers/notifications when commits are made either in general or for specific resources under source control? - Is there a way to auto-merge trivial conflicts? - Does git maintain/version file-level permissions? File-level metadata? - How does git handle backing out: - A commit that involved a file merge? - A commit that involved a file merge when additional commits have been made after the merge commit? - A commit that involved the addition of a file? (assume it just deletes it again?) - Does git handle binary files well? - Does git preserve/version file encoding and Unicode? - Does git handle Symlinks? - How does git handle two people adding and then attempting to commit: - a file in the same directory with exactly the same name - a directory with the same name containing files (some of which have the same names between the two users and some of which are named differently). - If I commit a change to a file, others commit changes to that same file and then I back out my original commit, is there a record of those changes and could I "get back" that original commit that I made after I back it out? - How does git handle very large numbers of files/folders? Would 50,000 files be "overload" for a single repository would would that many files bring git to its knees, performance wise? - How does git handle CR/LF issues between OSs? - Our current SCM tool has a concept of a "sparse" repository or workspace. The scenario in which this concept is important is outlined as follows: - Assume I have a mature git repository containing files for a particular software product. - We have a central, master repository located on a server accessible to our build system and developers. - We have reached a point in our product's evolution at which files in a given directory or directory tree have reached end-of-life and are no longer needed for work going forward. - These files/directories are still required for building / patching previously existing versions of the product so we still want access to them under certain circumstances. - Our desire is that when a new developer joins our team and begins working on this product, we don't want them to be burdened by having all of the history of these old files that are not relevant any longer cluttering up their locally cloned repositories and using space on their hard drives that could be put to better uses. Our current SCM tool allows us to selectively "defunct" (or, effectively, ignore) a directory tree, single directory or individual files. This means that, when a new developer pulls down the code from the repository, they don't even know these ignored files exist. Does git offer any sort of similar functionality? We would like our developers to be able to see past history of the files that they are working with but not be burdened with the entire history of files that have effectively been deleted from the repository. - When I move a file from one place in the directory structure to another, does git simply "change the pointer" to that file or does it carry two copies of that file around in the history. I believe it just does the pointer magic but I am being asked to verify this. I plan to try this on a new test repository but I thought I'd ask the question here as well. - Our current SCM has a structural feature which seems logically similar to git 'branches', let's call these structures "buckets". Buckets are hierarchical in that buckets "inherit" from parent buckets and buckets can have child buckets. A file that is in a parent bucket is also in a child (flows down). Changes to a file in a parent bucket also affect the files in its children unless the child bucket has had an independent change made to that same file in which case this requires a merge. I am wondering if branches can be configured to work similarly either automatically or through running a script to "update" a branch with changes from its parent branch? When I want to move code from a child bucket to a parent bucket (synchronize their contents), how difficult is this? Any best practices to follow, assuming "bucket === branch" holds true? Again, thank you in advance to everyone who is able to contribute to my knowledge related to any of the above. Regards, Peter. -- 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.