Gitcmd-2016.html: Old meanwhile invalid document from 2016

gitUsage_de.html

1. Repository in another local referenced directory

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:

gitdir: D:/path/to/Mirrordir/.git

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 MirrorDir follows anytime the content of the repository. The files there are never edited. But they are a proper base for compare.

  • The content of the Workingdir files 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 Workingdir you can switch to another proper version in your git repository, using again git checkout in the MirrorDir, and at last commit your working tree content. The MirrorDir content can then updated then first removing all files, and then call git checkout --force which resynchronizes all files from the current version.

2. Time stamp of the files

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

3. Branches and Contribution

3.1. push the own work

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)

Now the 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.