Our goal is to do a complete conversion of our Subversion repository and end up with a bare Git repository acceptable for sharing with others (privately or publicly). Bare repositories are ones without a local working checkout of the files available for modifications. They are the recommended format for shared repositories.
Our goal is to do a complete conversion of our Subversion repository and end up with a bare Git repository acceptable for sharing with others (privately or publicly). Bare repositories are ones without a local working checkout of the files available for modifications. They are the recommended format for shared repositories.
Our goal is to do a complete conversion of our Subversion repository and end up with a bare Git repository acceptable for sharing with others (privately or publicly). Bare repositories are ones without a local working checkout of the files available for modifications. They are the recommended format for shared repositories.
The magic is in the --patch argument to git-add(1). This instructs Git to display all changes to the files specified on a hunk-by-hunk basis and lets you choose one of the following options for each hunk
...
In this case, I staged (y) about half of the hunks (the ones that were bookmark related) and left the other hunks unstaged (n). Now my index has all of the changes to synchronize-bookmarks plus half of the changes made to models.rb.
Make git behave more like svn or a centralized repo on the server. Good advice.
There’s easy ways to share your changes with Git, but sometimes you want to push and pull from a repository instead. The best practice here is when you want to push changes, don’t push to a non-bare repository. In other words, from the GitFaq:
A quick rule of thumb is to never push into a repository that has a work tree attached to it, until you know what you are doing.
The lesson here is that if you’re going to push changes, make a bare repository clone with git clone --bare.