Thank you for your answers! I have a few follow-up questions:

   - It appears your comments for the "can git support 'sparse' workspaces" 
   question was lost. All that you posted was "Yes and No. Git supports". It 
   appears that the remainder of your comments were cut off.
   - For the last question, how then would one "update" a branch of a 
   repository to include changes in the "main" branch. For example, let's 
   assume I have a brand new git repo. I add some files to it, let's say, 
   representing version "A" of my application. I now "branch" this repo in 
   order to work on version "B" of my repo. I want the "B" branch to be an 
   integration branch into which two separate teams will "dump" their eventual 
   changes for two headlines" Each of these two teams then create separate 
   branches stemming from "B", call them "B1" and "B2" representing work on 
   these two independent headlines. Team 1 reaches a milestone and wants to 
   "push" their completed code into "B" and begin work on the next headline. 
   They would like to do something in Git to synchronize their "B1" branch 
   with the contents of "B" so that the two branches would, upon completion of 
   that "something", have identical contents. Assuming that is possible and it 
   is now completed, team 2 would like to "pull" the current state of "B" into 
   their own branch "B1", merging that content with what they have done in 
   "B2" so that, when they are done, B2 would have all of the changes that B1 
   pushed up to B + any additional, interim changes they have made thus far in 
   B2 prior to this action. When they are done with their headline, they would 
   like to sync "B2" with "B" so that "B" would then have all of their changes 
   too. Is there any way to accomplish this sort of thing in Git? How would 
   one coordinate the work of multiple teams working on different headlines 
   all of which eventually have to be "merged" into one codebase?



On Monday, March 25, 2013 3:38:55 PM UTC-4, Konstantin Khomoutov wrote:

> On Mon, 25 Mar 2013 10:51:34 -0700 (PDT) 
> Peter Pavlovich < <javascript:>> 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 
> moment. 
> >    - 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 
For more options, visit

Reply via email to