www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Git Contributors Guide (Was: Re: destructor order)

reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/26 Steven Schveighoffer <schveiguy yahoo.com>:

 Steve, if you could point out what I need to do I'll be glad to do it
 right now. Better yet, feel free to try your hand at a git commit. It's =




fun!

 *sweats nervously* I don't know, I'd like to read about how git works bef=


ore

 doing a commit. =C2=A0I don't really understand it at all, I had the same=


 problem

 with subversion when I started using it.


This seems like a good time for a quick git-contributors guide. There
are plenty of guides in other places, but anyways; (this is for Linux
and the native Git). I do not know about how to work with other
versions such as Tortoise, or on other platforms, but it should be
very similar.

One-time thing for first-time git; tell git who you are:
  $ git config --global user.name "John Doe"
  $ git config --global user.email "john.doe server.com"

1. Clone out a fresh copy of the project from github, i.e.
  $ git clone git://github.com/D-Programming-Language/druntime.git
2. Do your thing. Change whatever file you need.
3. Stage your changes with "git add <file>" for any added or changed file.
  $ git add "path/myfile"
4. Commit with "git commit". Your editor will pop up asking for a
commit-message.
  $ git commit

** Short-path **: If there are no _new_ files in the commit, you can
skip step 3, and "git commit -a" without the "git add"-stage. This
will make the commit-command work like in Subversion.
** GUI-alternative **: For step 3 and 4, please try out the excellent
"git gui" command, which let's you pick individual lines in files to
commit. Great for splitting up work into logical patches. Also has
support for amending the last patch in line, fixing typos and such.

Your commit is now done. You can examine it with the command "git log"
which will show you the commit-history, and "git show", which will
show you the last commit in detail.
** GUI-alternative **: I find "gitk" to be immensely useful to review
things before submitting or publishing them. It allows all sorts of
niceties, reviewing both changes and snapshotted trees from history,
comparing revisions and following changes to a single file.

There are now many ways to now submit the patch.
 The BEST way is probably publishing your branch in some public place
like github, and send a notification to the respective mailing-list,
or bug-tracker. It is described at github itself.
 Another way is of course generating a plain old git diff, but that
does not retain authorship or time. Nor is it practical for series of
patches.
The way I will show here is to gather up your changes in a so-called
"bundle", which can then be sent by mail or attached in a bug-tracker.
First, some terms that might need explaining.
  :origin: A repository usually has "neighboring" repositories, friend
whom you often communicate with. "origin" is the default-name of the
repository you originally cloned. "upstream" so to speak.
  :master: In each repository, there can be many branches. "master" is
by default the name of the "trunk", in SVN-terms.

So, when one speaks about "origin/master", one is basically saying
"trunk of upstream". Now, creating your bundle is as simple as:

the double-dots.
This tells git to bundle up all revisions on my current branch, that
aren't in "upstream". This will generate the file "mypatch.gitbundle",
which can be sent to for review.

The reviewer then "pulls" from it by:


The changes will now be merged into the reviewers tree, in a special
review-branch, where verification can be made, tests can be run and,
possibly small fixes to the patch can be appended. When done, change
to master-branch and merge the changes (if they are acceptable).

(or some other branch if integration should happen there instead)



Hope this helps. For more advanced, and continual work, you should
probably setup a private fork, described at
http://help.github.com/forking/.

Happy Git:ing!
Jan 26 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Ulrik Mikaelsson:


 This seems like a good time for a quick git-contributors guide.


Thank you for your explanation :-)

Bye,
bearophile
Jan 26 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson  
<ulrik.mikaelsson gmail.com> wrote:


 The way I will show here is to gather up your changes in a so-called
 "bundle", which can then be sent by mail or attached in a bug-tracker.
 First, some terms that might need explaining.


Many open-source projects that use git use patches generated by the  
format-patch command. Just type "git format-patch origin". Unless you have  
a LOT of commits, patches are better than binary bundles, because they are  
still human-readable (they contain the diff), and they also preserve the  
metadata (unlike diffs).

You can even have git e-mail these patches to the project's mailing list.  
The second and following patches are sent as a "reply" to the first patch,  
so they don't clutter the list when viewed in threading mode.

   http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
   http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 27 2011
parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/27 Vladimir Panteleev <vladimir thecybershadow.net>:

 On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson
 <ulrik.mikaelsson gmail.com> wrote:


 The way I will show here is to gather up your changes in a so-called
 "bundle", which can then be sent by mail or attached in a bug-tracker.
 First, some terms that might need explaining.


 Many open-source projects that use git use patches generated by the
 format-patch command. Just type "git format-patch origin". Unless you have a
 LOT of commits, patches are better than binary bundles, because they are
 still human-readable (they contain the diff), and they also preserve the
 metadata (unlike diffs).

 You can even have git e-mail these patches to the project's mailing list.
 The second and following patches are sent as a "reply" to the first patch,
 so they don't clutter the list when viewed in threading mode.


True. The only problem with this, I think, is getting the patch out
from web-based mail-readers. Key-parts of the metadata about the
commit lies in the mail-header, which might not always be easily
accessible in web-readers. Also, send-email is for some reason no
longer included in the git-version that comes with Ubuntu 10.10.
Perhaps it's been removed in later versions of git.
Jan 27 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 27 Jan 2011 19:17:50 +0200, Ulrik Mikaelsson  
<ulrik.mikaelsson gmail.com> wrote:


 2011/1/27 Vladimir Panteleev <vladimir thecybershadow.net>:

 On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson
 <ulrik.mikaelsson gmail.com> wrote:


 The way I will show here is to gather up your changes in a so-called
 "bundle", which can then be sent by mail or attached in a bug-tracker.
 First, some terms that might need explaining.


 Many open-source projects that use git use patches generated by the
 format-patch command. Just type "git format-patch origin". Unless you  
 have a
 LOT of commits, patches are better than binary bundles, because they are
 still human-readable (they contain the diff), and they also preserve the
 metadata (unlike diffs).

 You can even have git e-mail these patches to the project's mailing  
 list.
 The second and following patches are sent as a "reply" to the first  
 patch,
 so they don't clutter the list when viewed in threading mode.


 True. The only problem with this, I think, is getting the patch out
 from web-based mail-readers. Key-parts of the metadata about the
 commit lies in the mail-header, which might not always be easily
 accessible in web-readers. Also, send-email is for some reason no
 longer included in the git-version that comes with Ubuntu 10.10.
 Perhaps it's been removed in later versions of git.


You can have send-email attach the patch as an attachment (see the  
git-format-patch man page).

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-26 23:26, Ulrik Mikaelsson wrote:

 ** GUI-alternative **: I find "gitk" to be immensely useful to review
 things before submitting or publishing them. It allows all sorts of
 niceties, reviewing both changes and snapshotted trees from history,
 comparing revisions and following changes to a single file.


For anyone using Mac OS X I recommend gitx (http://gitx.frim.nl/).


-- 
/Jacob Carlborg
Jan 27 2011