On Mon, 25 Mar 2013 10:51:34 -0700 (PDT)
Peter Pavlovich <pavlov...@gmail.com> wrote:

>    - Is there any way to edit commit comments?

Yes, at the time a commit is done.
Yes, after a commit is done but not yet pushed ("amendment").
If a commit is pushed, even then you are able to change it, but pushing
it out then would create problems for those who happened to fetch
the original commit to their repos.  I think we'll stop here at the

>    - Is there any way to set up triggers/notifications when commits
> are made either in general or for specific resources under source
> control?

Git supports "hooks" for their repositories: programs (usually scripts)
which run before/at/after certain events in the repository.
There are post-commit hooks, post-push hooks etc.

What are "resources"?

>    - Is there a way to auto-merge trivial conflicts?

What are "trivial conflicts"?
If you mean changes to different areas of the same file, then the
answer is yes.
Git also supports merging strategies (like "our changes trump theirs"),
and has a special tool (git rerere) which is able to remember how a
particular merge with conflicts has been carried out by the developer
and automate this the next time this happend.

>    - Does git maintain/version file-level permissions? File-level
> metadata?

Stock Git does not support any permissions on anything.  I mean, you
either has push access (because you has been authenticated and
authorized by whatever serves Git for you -- SSH or HTTP[S]) or not.
There are specialized server-side front-ends (gitolite is the most
popular one) which provide finer-grainer access controls, but AFAIK
this works on a per-branch level only.

You should understand very well that Git does not explicitly track
files (!).  I mean, it does track them physically but it does not
attach any sacred meaning to them -- their contents is everything it
cares about.

What what is "file-level metadata"?

>    - How does git handle backing out:
>       - A commit that involved a file merge?

There's no "file merges" in Git.  Git operates on trees only.

Yes, you can back put a merge commit, but this might have certain
repercussions which have to be understood and planned.

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

Git is able to back out any commit at all since backing out a commit
means recording another commit which reverts certain changes on a
"textual" level.

>       - Does git handle binary files well?

It does handle binary files.  But if by "handles" you mean something
special like being able to checkout one huge file out of a (remote)
repository, modify it and commit back, then no.  Or be more precise.

>    - Does git preserve/version file encoding and Unicode?

Git does not care about the encoding of files -- it only ever messes
with EOL conversion if it treats a file as text.
If Git thinks (or is told to think) a file as binary (no EOL
conversions), the file is manipulated as is.

Also note that the word "Unicode" supposedly used in a wrong context
here since Unicode itself does not specify any encodings.

>    - Does git handle Symlinks?

On POSIX platforms and Mac OS; not on Windows.

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

Git is a DVCS so do not confuse committing and pushing commits to a
shared repository -- these are distinct things completely.  Git does
not support "server-side merging" (I beleive no DVCS does).  From this
it logically follows that Git does it support pushing selected files
and/or directories.  It's only possible to push commits and series of
commits which represent complete snapshots of the whole repository.
That's how a DVCS works.

With regard to server-side conflicts, the Git workflow looks like this.
Suppose you fetched from a shared repository, and decided to do some
work on its branch named "foo".  Presently, the tip commit of that
branch is A.  You record some more commits on it (say, B and C) and
attempt to update with them that same branch "foo" in the shared
repository.  A Git instance working on the server will take your commits
(B and C), notice that B's parent is A and see if the current tip of
the branch you're trying to update on the server is also A.  If it
isn't, your push operation will simply fail (unless forced), and you
will have to first fetch the updated state of that branch, merge it
into your own work (or rebase your own work upon the new state of the
branch), possibly resolving any conflicts, and then retry your push.

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

Yes.  If you really mean backing out a commit and not erasing it from
the history (Git can do history rewriting, to be clear).

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

Webkit and the Linux kernel are examples of insanely huge code bases
maintained using Git.

>    - How does git handle CR/LF issues between OSs?

It supports several knobs related to EOL conversions.
Which policy to employ, and how, depends on your particular case.

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

Yes and no.  Git supports 
>    - 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.

Git does not store two copies of the file, but neither does it "change
a pointer": the contents of a file are referred to by the SHA-1 hash
value calculated on that contents.  When you move a file, its hash does
not change, and so there won't be another copy of that blob in the
database.  But since the file moved, the so-called "tree objects", which
loosely represent directories on a filesystem, will change.

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

No "buckets", no propagation of anything from "parents" to "children".

All commits in a Git database form a directed acyclic graph (DAG), of
which certain commits are reachable via branches and tags.  Both
branches and tags point to just a single commit each, and it's that
commit who knows who its parent is (or multiple parents -- for merge
commits).  So in Git model "parents" have absolutely no idea who their
children are.

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.

Reply via email to