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 
   - 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 

   - 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 
      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 
      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 
      the history of these old files that are not relevant any longer 
      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 

   - 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.



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 
For more options, visit

Reply via email to