[fpc-other] Git & SVN

[Graeme Geldenhuys]

On 2017-05-24 12:46, Mark Morgan Lloyd wrote:
>  >   [reportdesigner (reportdesigner)]$ git describe
>  >   v1.4.1-787-g45f932c1
>  >
>  > What does that output tell me:
>  >   * Whatever code I'm working on is follow on from the "v1.4.1"
>  >     release.
>  >   * This line of [development] history has seen "787" commits
>  >     since the v1.4.1 release.
>
> says explicitly that the modification with the hash g45f932c1 takes the
> project on the Git repository under consideration to something that
> could usefully be described as v1.4.1-787, and you can use that in
> conversation without having to be online to a repository.

Yes, you can use "v1.4.1-787" to describe a specific point in history, 
but the far more common and useful one is the "45f932c1" SHA1 reference, 
because the latter can be used directly in all Git commands.


> If multiple people were committing directly to the same repository (I
> presume Git supports that)

Yes.

>  presumably they'd see a consistent sequence
> of version identifiers, i.e. very much like Subversion.

Yes. A SHA1 reference like "45f932c1" only only points to a specific 
commit, it also describes the history that lead to that point.

Let me explain: Say you have two branches with the same file, and the 
file hasn't actually changed between those two branches. Now say I give 
you a patch file to apply to that file in both branches. The commits 
that gets generated in each branch - even though the diff is identical - 
will not have the same SHA1 reference. Because the history to get to 
that point has diverged because of the branching.

So if I mention a problem in the "45f932c1" commit of a Git repository. 
No matter how many clones [by multiple developers] there are of that 
repository, that SHA1 reference will point to the exact commit and code 
change - in all the Git repositories out there in the wild.

This is also one of the huge arguments about NOT using the git-rebase 
command on a branch that has been published, because a rebase command 
rewrites the history. So every commit (SHA1 reference) in that affected 
branch changes. Rebasing local branches (not made public yet) is 
obviously not a problem.

The Git project repo has a "short lived" branch where they do all kinds 
of testing. They explicitly note that nobody should base any new 
development on that branch, because it will frequently be destroyed and 
recreated (merging in new feature to be tested for the next cycle).


> What happens in the case where there's multiple repositories?

No difference. A git repo contains the full history. If you clone that 
repository 100 times between developers, you effectively have a 100 
backups. If the original repo had 5 branches, all 100 clones with have 
references (and full history) to those 5 branches too. Such remote 
branch can be listed using the following command:

   git branch -r

eg:

[tiopf (tiopf2)]$ git branch -r
   carlo_marona/Add_tiLogToDebugString
   carlo_marona/Additional_Mediators
   carlo_marona/Fix_BOOLEAN_Defines
   carlo_marona/Fix_TtiDatabaseZeosAbs_SetConnected_Except
   carlo_marona/Fix_tiCriteria_AssignClassProps
   carlo_marona/Fix_tiMediatorView
   carlo_marona/Fix_tiModelMediator
   carlo_marona/Fix_tiQueryZeosIBFB_Unit
   carlo_marona/tiOIDManager_Update
   carlo_marona/tiopf3
   github/master
   github/tiopf1
   github/tiopf2
   github/tiopf3
   sourceforge/HEAD -> sourceforge/master
   sourceforge/fea_Fix_Event_Execution_Of_TtiPropertyLinkDef
   sourceforge/fea_Missed_Changes_On_tiOPF3
   sourceforge/master
   sourceforge/tiopf1
   sourceforge/tiopf2
   sourceforge/tiopf3


Here you can see my local tiOPF repository has 3 remote repositories 
defined. "carlo_marona", "github" and "sourceforge". I frequently pull 
fixes from Carlo, so that is why I have a permanent remote repository 
link to his published work. For contributions from one-off developers I 
don't bother setting up a remote repository link - I use their 
repository URL directly in the git-fetch command.

The official public tiOPF repository lives on SourceForge.net, so that 
is the "sourceforge" remote repo link. The "github" link was just a 
backup public repo I used while SourceForge.net had a major global 
outage a little while ago. So development continued as usage without 
skipping a beat (thanks Git).

You can also see from Carlo's repository that he nicely names each 
branch, and every branch that is a bug fix has the prefix name "Fix_" to 
it. In the end you can name branches whatever you want though, and you 
can even groups things with a "/" in the name of the branch.







Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp