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
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
