Hi Jeroen, Hi list (this might be useful for those who are new to Git), On Sunday 28 August 2011, Jeroen Asselman wrote: > The current converted svn to git is available at > https://github.com/gtk-gnutella/gtk-gnutella . Please do not fork > but check if everything looks alright.
Perfect! I really like it. > SVN revision ids are saved in a separate svn notes rep, if you want > to fetch them, you'll need to fetch the refs/notes/svn branch as > well. It's not exactly a branch, because it doesn't reside under refs/heads, so it won't show up in the branch list. For those of you who are not that fluent with git: You can fetch the notes with git fetch origin refs/notes/svn:refs/notes/svn (provided that you made a default clone, so that the remote's name is "origin") and then make them visible per default in "git log" and similar commands in addition to the "normal" notes with git config notes.displayRef refs/notes/svn On the other hand, you likely won't need the svn notes in the future. The next step after the transition would be for all developers to learn to make commits the Git way (made possible by the fact that "commit" and "push" are distinct operations, contrary to what svn does). These rules not only make the commit history easier to read, but also greatly increase the use of magic tools like "git bisect": - Don't put different things into one commit. Make multiple small commits instead. There are tools (like "git gui") that help you divide existing changes to one file into multiple commits. Rule of thumb: If your commit message is bulleted with asterisks, you should likely divide your commit, so that you don't need bullets. - Don't correct your previous commit with an "oops" commit if you have not yet pushed. Instead, correct the faulty commit directly, using something like "git commit --amend". If you notice your error after a number of unrelated commits, you can use something like "git rebase -i origin/master" to squash your oops into the faulty commit. As long as you did't push, you can do every trick to your history. - Use local branches a lot. Make a feature branch for every distinct feature that you are working on. Whenever you change the subject in your brain, you change branches at the same time (using git checkout). - Give your commit messages a short one-line subject. Several useful tools (like gitk) show only the first line of the message where appropriate. If your commit message needs a more elaborate message body, put the body after a blank line after the subject line. bye, Hauke ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
