...
This
...
page
...
describes
...
conventions
...
and
...
best
...
practices
...
applicable
...
to
...
the
...
Fedora
...
Git
...
repository.
...
| Table of Contents |
|---|
Line endings
All text files must be normalized so that lines terminate in the unix style (LF).
...
Please
...
do
...
not
...
commit
...
files
...
that
...
terminate
...
in
...
CRLF
...
!
...
Configuring
...
git
...
to
...
enforce
...
LF
...
normalization
...
There
...
are
...
several
...
way
...
to
...
enforce
...
LF
...
normalization.
...
Each
...
method
...
carries
...
some
...
consequences,
...
and
...
the
...
consequences
...
&
...
methods
...
differ
...
between
...
versions
...
of
...
Git.
autocrlf property
Normalization rules for all text files can be addressed by the 'autocrlf' configuration property. There are two useful values for this property, depending on your platform
- autocrlf = input. Use on unix-like platforms. This will perform no conversion upon checkout, but will normalize any crlf files upon commit.
- autocrlf = true. Use only on Windows platforms. This will have the effect of converting all text files into dos-style (CRLF) in the working copy upon checkout. Upon commit, all files will be normalized to LF on their way into the repository, but remain in CRLF in the local working copy directory.
This property can be set globally for all local git repositories, or locally for a single git repository.
The autocrlf property can be set globally via the command line. For example:
| Code Block |
|---|
h5. {{autocrlf}} property Normalization rules for all text files can be addressed by the 'autocrlf' configuration property. There are two useful values for this property, depending on your platform * autocrlf = input. Use on unix-like platforms. This will perform no conversion upon checkout, but will normalize any crlf files upon commit. * autocrlf = true. Use *only* on Windows platforms. This will have the effect of converting all text files into dos-style (CRLF) in the working copy upon checkout. Upon commit, all files will be normalized to LF on their way into the repository, but remain in CRLF in the local working copy directory. This property can be set globally for all local git repositories, or locally for a single git repository. The {{autocrlf}} property can be set *globally* via the command line. For example: {code} git config --global core.autocrlf input {code} |
Executing
...
this
...
command
...
is
...
identical
...
to
...
editing
...
your
...
~/.gitconfig
...
file
...
and
...
adding:
| Code Block |
|---|
} [core] autocrlf=input {code} The {{autocrlf}} property |
The autocrlf property can also be set locally for a given git repository, such as the local clone of the fcrepo. For example, from within the local working directory:
| Code Block |
|---|
can also be set *locally* for a given git repository, such as the local clone of the fcrepo. For example, from within the local working directory: {code} git config core.autocrlf input {code} |
Executing
...
this
...
command
...
is
...
identical
...
to
...
editing
...
the
...
.git/config
...
file
...
within
...
the
...
git
...
working
...
directory
...
and
...
adding:
| Code Block |
|---|
} [core] autocrlf=input {code} h5. {{.gitattributes}} file The presence of a committed {{.gitattributes}} file within the code can also be used to apply line-ending rules. This has the benefit of being part of the managed sources (and this part of a given branch, tag, etc), but is not understood by all versions of git. The fedora master branch has a .gitattributes file containing {\* text=auto}, which instructs git to detect text files, and normalize to LF at each commit. h5. Git 1.7.1 and earlier Earlier versions of git do not understand the necessary directives in {{.gitattributes}} file, so {{autocrlf}} is the only way to assure compliance with the LF normanlization. Thus * Unix and mac users should set {{autocrlf = input}} either globally or locally * Windows users should set {{autocrlf = auto}} either globally or locally. These versions of git may apply/detect autocrlf settings to all files in the working copy immediately. Thus, if checking out older branches/tags/commits that still have crlf files in the repository, these files will be seen as automatically 'modified' when doing a 'git status'. This may have confusing side-effects. h5. Git 1.7.2\+ These versions of git heed the {{.gitattributes}} directive, so it is not strictly necessary to set autocrlf, but it is recommended. These versions of git will apply the autocrlf setting to *new* files - preventing the introduction of non-normalized crlf files into the repository, but ignoring existing crlf files. h4. Working with older branches h2. Quick Start Guide for Fedora Developers/Committers # Get the repository: {code} |
.gitattributes file
The presence of a committed .gitattributes file within the code can also be used to apply line-ending rules. This has the benefit of being part of the managed sources (and this part of a given branch, tag, etc), but is not understood by all versions of git. The fedora master branch has a .gitattributes file containing * text=auto, which instructs git to detect text files, and normalize to LF at each commit.
Git 1.7.1 and earlier
Earlier versions of git do not understand the necessary directives in .gitattributes file, so autocrlf is the only way to assure compliance with the LF normanlization. Thus
- Unix and mac users should set
autocrlf = inputeither globally or locally - Windows users should set
autocrlf = autoeither globally or locally.
These versions of git may apply/detect autocrlf settings to all files in the working copy immediately. Thus, if checking out older branches/tags/commits that still have crlf files in the repository, these files will be seen as automatically 'modified' when doing a 'git status'. This may have confusing side-effects.
Git 1.7.2+
These versions of git heed the .gitattributes directive, so it is not strictly necessary to set autocrlf, but it is recommended.
These versions of git will apply the autocrlf setting to new files - preventing the introduction of non-normalized crlf files into the repository, but ignoring existing crlf files.
Working with older branches
Quick Start Guide for Fedora Developers/Committers
- Get the repository:
Code Block git clone git@github.com:fcrepo/fcrepo.git cd fcrepo
...
- Create the branch where you'll
...
- do
...
- your
...
- work:
...
Code Block
...
git branch fcrepo-780 git checkout fcrepo-780
...
Thecheckoutcommand makes whatever branch you specify the local active branch. Make your changes, test...- Add your edited/new files, then commit your branch:
Code Block git add myfile.java git commit myfile.java
...
- Push the branch back up to github
Code Block git push origin fcrepo-780
...
- Merge the branch into master (formerly known as 'trunk')
...
Code Block
...
git checkout master git merge fcrepo-780
...
Resolve
...
- any
...
- conflicts,
...
- and
...
- test
...
- again.
...
If any time has passed since you cloned master from github and merged your branch into your local copy of master, make sure that you also merge any upstream changes to master into your local copy:Code Block git fetch origin master
...
Examine
...
- the
...
- changes:
...
Code Block git diff origin master
...
then:
...
Code Block git merge origin/master
...
(The
...
- command
...
git
...
pull
...
- does
...
- a
...
- combined
...
- fetch-and-merge,
...
- but
...
- read
...
...
- on
...
- why
...
- that's
...
- a
...
- bad
...
- idea.)
...
Merges are automatically committed locally.- Update master on github
Code Block git push origin master
...
- Once you've
...
- received
...
- word
...
- that
...
- the
...
- build
...
- has
...
- completed
...
- correctly,
...
- delete
...
- the
...
- branch
...
Code Block
...
git push origin :fcrepo-780
...
You
...
can
...
run
...
git
...
status
...
at
...
any
...
time
...
to
...
get
...
a
...
snapshot
...
of
...
your
...
current
...
state.
...
You
...
can
...
also
...
examine
...
your
...
differences
...
with
...
the
...
master
...
branch
...
on
...
github
...
at
...
any
...
time
...
by
...
executing
...
these
...
two
...
commands:
| Code Block |
|---|
}git fetch origin master git diff origin master{code} |