In git you can generally use
git --git-dir=D:/path/to/Mirrordir/.git ...further arguments
This was not possible in the first versions of git, but later added. Also for example usable for https://en.wikipedia.org/wiki/TortoiseGit
or also for other GUIs you can write a file with the name
.git instead the directory, which contains:
Then also local git commands works with this remote repository location. This repository location should be able to localize anywhere in the file tree, also at a network directory.
This allows the following approach:
WorkingdirA .git ------------------+ MirrorDir WorkingDir/files +---> .git ...Git-Repository | MirrorDir/files WorkingdirB | .git ------------------+ WorkingDir/files
As you see you can have more as one working directory, whereas also only one is sensible, and a second so named "mirror", also as active git directory (not a bare repository).
One of the idea may be:
The content of the
MirrorDirfollows anytime the content of the repository. The files there are never edited. But they are a proper base for compare.
The content of the
Workingdirfiles are not so closed depending on the Git repository.
For example you can change the version of the repository (using
git checkout) in the
MirrorDir, only if you want to compare your working files with another version. For comparing you can use both, either the git commands which compare your working tree (! independent of the checkout action) with the git repository immediately, or you can use a file comparison with the
MirrorDir, which is also supported by some tools. After do some changes in the
Workingdiryou can switch to another proper version in your git repository, using again
git checkoutin the
MirrorDir, and at last commit your working tree content. The
MirrorDircontent can then updated then first removing all files, and then call
git checkout --forcewhich resynchronizes all files from the current version.
Due to the habits of Linux, the resynchronized files from older versions in the repository gets always new time stamps.
That may be important, because of maker are sensitive to the time stamp of files, and newly resynchronized files (via
git checkout )
may be a candidate for make.
But on the other hand, the time stamp is an information for the user, especially after checkout or afterwards in view situations,
it may be interesting whether a file has the same time stamp as another, was changed while that or that situation etc.
This information may be also gotten from the version history, yes, ok, but it is more simple to look on the time stamp.
It depends from the taste of the user. Note that a
copy command on Windows (and his pre versions DOS and CPM)
has copied the file with the time stamp information, other as UNIX.
See the description ../../SwEng/html/restoreTimestampsInSrc.html
Presumed, on the own working environment there is a git archive started from a dedicated version:
A-B-C(master) .... this version, master branch
Now a contributer makes some changes by itself, tests it and would push it. But the contributer may have not the overview about the whole project.
In the own environment of the contributer the archive shows:
local: A-B-C-D(master).... D is the new version in the own branch, it is the master branch
If nobody else has committed, then the push changes the master branch on the central repository. This may not be expected or desired. Firstly the maintainer should check the version D.
If another commit exists then the master branch has the structure:
central: A-B-C-D-E(master) ... D and E are other commits!
On a simple
git push urlpath/to/central/.git
an error message occurs "cannot push…". That is ok.
Usual a "merge" should be done. But this merge may not be allowed by the contributer, because he/she may not have the full overview. For the same reason the contributer should nothing change on his own repository in respect to the remote changes. It means, a "pull" of any new versions should not be done. The contributer should only push his/here own work.
A second approach: The contributer should anyway not change the master branch, because the work should be firstly reviewed.
The working goal is, to create a local branch. This can be done also after the own commit in the own archive as "master":
git checkout -b localName
The wording "checkout" is a little bit misleading. It may be correct from the view on the central repository, and anybody gets a version for his own. But from the point of view of the own repository, which is already pulled (or just fetched or checked out), this command should be better named as "makebranch" or better "rename" (of the own branch). But the names of the git commands cannot be discussed.
After this checkout the following is gotten:
local: A-B-C-D(localName).... D is the new version in the own branch, designated as localName branch
posibility todo use
git branch rename ok
renames the current branch to another name.
Now the push is possible, with an additional option:
git push --set-upstream urlpath/to/central/.git localName
As result in the central repository is shown:
central: A-B-C-D-E(master) ... D and E are other commits! +D(localName)
or also maybe:
central: A-B-C(master) ... D and E are other commits! +D(localName)
localName is firstly not interesting for other people.
Only the maintainer can view the change, make a merge, and inform the contributer to use the new master version for further development.