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.
