Versions Compared

Old Version 6

changes.mady.by.user Scott Prater

Saved on

compared with

New Version 7

changes.mady.by.user Aaron Birkland

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • linked to a JIRA issue:
    No Format
    FCREPO-780: NPE thrown on disseminations

Fix for the following bug: Fedora throws a null pointer exception if 
you call a disseminator that fronts a web service whose response does 
not contain a "Content-type" header.

https://jira.duraspace.org/browse/FCREPO-780
  • general issue:
    No Format
    Create .gitattributes file to normalize line feeds

Create .gitattributes file requesting all text files normalised to LF.
Will be ignored by git versions < 1.7.2

See https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
for more information.

Pulling and pushing to master

All pull or merge operations from remote/master into the local master branch should be fast-forward. Do not perform development in the master branch, periodically update with pull, and then push your local master. Instead, perform local commits in a separate branch, and merge (or rebase and merge) with master right before pushing it.

git pull -ff-only can be used to assure that a pull is fast-forward only. If a fast-forward pull is not possible, this flag will cause git to exit with an error, and leave the local branch untouched.

Development directly in master

This should be avoided for all but the simplest commits that are immediately pushed. If you have several un-pushed commits, and then use git pull to merge in remote changes, that pull will be non-fast-forward. In other words, git pull will automatically create a merge commit which merges origin/master into your local branch. A subsequent push will publish your local master to the central repository, and the presence of the merge commit with origin/master might make a confusing-looking history. In fact, github 'network view' of github will make it appear that commits that were merged in with git pull came from another branch!

As an example, suppose there are three active developers working simultaneously - Tom, Dick, and Harry. Harry develops directly in master for some time before pushing his changes.

  • Tom commits his changes to master, and pushes immediately. His commits are {1,2,3,4,5}
  • Dick commits changes to a local, unpublished branch. His commits are {a,b}. After he is done developing locally, he merges his branch into master and pushes immediately, resulting in commit 6.
  • Harry commits his changes to his local master branch. His commits are {A, B} Periodically, he uses git pull to bring in changes from the remote master branch, resulting in auto-generated merge commits {P1, P2, and P3}. At the end, he pushes his changes to the repository.

Harry's practice can cause some unintuitive-looking history graphs. His workflow looks something like:

  • (master) git pull
  • (master) git commit -m "A"
  • (master) git pull (results in a silent, automatic merge P1)
  • (master) git pull (results in another silent, automatic merge P2)
  • (master) git commit -m "A"
  • (master) git pull (Yet another merge P3)
  • (master) git push (The repository master now is identical to his local master)

Image Added

In this graph, Harry's local commits and pull merges appear to have occured in master. Tom's commits (which were always pushed immediately to master) appear to have occured in a separate branch.