Changes between Version 5 and Version 6 of GitRepository


Ignore:
Timestamp:
08/17/08 13:07:18 (5 years ago)
Author:
jhs
Comment:

English fixups. Software capitalization (Git, Gitweb, GITK) taken from what they use on their own web sites

Legend:

Unmodified
Added
Removed
Modified

  • GitRepository

    v5 v6  
    1 = git =  
     1= Git =  
    22 
    33[http://git.or.cz/ git] is a fast and popular revision control system. 
    … …  
    99== Importing into git branches == 
    1010 
    11 The git target is serving as testbed for proper branch support in tailor.  The relevant parts will be lifted into the generic classes as sees fit. 
     11The git target serves as a testbed for proper branch support in Tailor.  The relevant parts will be lifted into the generic classes as appropriate. 
    1212 
    1313=== Branching approaches === 
    1414 
    15 There are currently 2 approaches to branch support in the git target.  All of them use the '''branchpoint''' repositoy parameter to specify the point of the parent branch where the branch forked off. 
     15There are currently two approaches to branch support in the git target.  All of them use the '''branchpoint''' repositoy parameter to specify the point of the parent branch where the branch forked off. 
    1616 
    1717 One repository per branch:: 
    18   This is the intuitive way of branching for many distributed SCM systems, and the only one for some of them (eg. darcs).  It is however uncomfortable in several aspects: you need to fetch branches from several repositories (or create an additional one that does the merge), and does not really help when we'll want to implement merges, since usually the point to merge from won't be readily available, and the branch it belongs to will need to be known as well. 
     18  This is the intuitive way of branching for many distributed SCM systems, and the only one for some of them (eg. darcs).  It is however uncomfortable in several aspects: you need to fetch branches from several repositories (or create an additional one that does the merge), and it does not really help when we'll want to implement merges, since usually the point to merge from won't be readily available, and the branch it belongs to will need to be known as well. 
    1919 
    2020  This branching mode makes use of the '''parent-repo''' repository parameter.  Initialization of the branch's repository is done as a shared clone (using '''git-clone -s'''), so the parent branch's revisions are not needlessly duplicated. 
    … …  
    5959  }}} 
    6060 
    61 === Future developements === 
     61=== Future developments === 
    6262 
    6363 Map of source revisions to target revisions:: 
    … …  
    6565 
    6666 Merge support:: 
    67   We need to be able to ask the source repository who the parent revisions for theconsidered revision are, since they are not necessarily just the previous revision from the branch (in fact, prcs even allows the previous revision on the branch to be completely unrelated).  Then we'll be able to record merges in the target (if we can map those source revs to target revs). 
     67  We need to be able to ask the source repository who the parent revisions for the considered revision are, since they are not necessarily just the previous revision from the branch (in fact, prcs even allows the previous revision on the branch to be completely unrelated).  Then we'll be able to record merges in the target (if we can map those source revs to target revs). 
    6868 
    6969 Automatic determination of branchpoints:: 
    70   Some sources have knowledge about branchpoints (in cvs we'll have to guess, but that's cvs, we're used to that).  Once we can map source revs, that will be trivial. 
     70  Some sources have knowledge about branchpoints (in CVS we'll have to guess, but that's CVS, we're used to that).  Once we can map source revs, that will be trivial. 
    7171 
    7272 Automatic determination of branches:: 
    73   In repositories with many branches it is awkward to list them all.  Additionally, in SCMs handling history as a full-featured directed graph (eg. git), there are sometimes temporary branches that were merged into another one, and which stay reachable because of the merge, although they don't have a name.  They can be numerous, and it would be silly to expect the user to hunt them all. 
     73  In repositories with many branches it is awkward to list them all.  Additionally, in SCMs handling history as a full-featured directed graph (eg. Git), there are sometimes temporary branches that were merged into others, and which stay reachable because of the merge, although they don't have a name.  They can be numerous, and it would be silly to expect the user to hunt for them all. 
    7474 
    75   Here I expect to define a branch as something that starts off a branchpoint or an initial commit, and extends up to a merge or a (labelled) branch head. 
     75  Here I expect to define a branch as something that starts off a branchpoint or an initial commit, and extends up to a merge or a (labeled) branch head. 
    7676 
    77   Or maybe not: we may only need to query the source repo about (or explicitely request) branch heads.  Then exploring history backwards will teach us about root commits, branchpoints, and mergepoints. 
     77  Or maybe not: we may only need to query the source repo about (or explicitly request) branch heads.  Then, exploring history backwards will teach us about root commits, branchpoints, and mergepoints. 
    7878 
    7979 Support for joint merges:: 
    80   That is, support for merges that join two histories that started as separate ones.  Public examples in the git repository for git itself include merges of gitk and gitweb repositories. 
    81   The automatic determination of branches will be sufficient for SCMs where such merges appear as such, and histories are already kept separated.  In CVS, however, due to the lack of renaming capabilities, it can happen that joint merges are done by moving an external cvs module into the repository.  Dealing with this requires being able to separate the history of a given subtree up to a given point which is to be considered the merge.  Tricky. 
     80  That is, support for merges that join two histories that started as separate ones.  Public examples in the git repository for git itself include merges of GITK and Gitweb repositories. 
     81  The automatic determination of branches will be sufficient for SCMs where such merges appear as such, and histories are already kept separated.  In CVS, however, due to the lack of renaming capabilities, it can happen that joint merges are done by moving an external CVS module into the repository.  Dealing with this requires being able to separate the history of a given subtree up to a given point which is to be considered the merge.  Tricky.