Re: Recommended work flow with git to send in patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 27, 2010, Tong Sun wrote:
> On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> 
> > Doesn't GRML have web page / wiki page for developers?
> 
> Yes, http://grml.org/git/, but it is kind of reference book style,
> doesn't cover much on the work flow, especially on the topic of
> no-writing-privilege user contributing back.

You could point lack of information for "leaf" contributors to them...

> > > - do initial git pull into grml-debootstrap
> > >
> > >   git pull git://git.grml.org/grml-debootstrap master
> >
> > Why not git-clone (possibly shallow, if you are working on one-shot
> > patch or patch series)?
> 
> Ok, to explain it, I have to touch upon my "life long story" of using
> git. Long story short on this, the recommended work flow that I
> searched and found from the Inet was to do 'git clone' from web then
> 'git clone' a local working copy. Here is my trying log:
> 
> # Download the latest version of the repository without downloading all the
> history, using "shallow checkouts".
> 
>   git clone --depth 1 git://git.grml.org/grml-debootstrap.git

O.K.
 
> create working repo:
> 
>   $ git-clone --depth 1 grml-debootstrap grml-debootstrap.working
>   Initialized empty Git repository in
> /export/repositories/gitwork/grml/grml-debootstrap.working/.git/
>   fatal: attempt to fetch/clone from a shallow repository
>   ^^^^^^^^^^^^^^^
> 
> Seeing that fatal error, and not knowing where to get help from, I
> just gave up the 'git clone' approach. Please be specific (with git
> commands), how would I use 'git clone' for working on one-shot patch
> or patch series.

I don't understand this second step.  Why do you want this second clone?
It is totally unnecessary.  The clone you make is working repository
you can make your contributions in.

In short, the workflow should look like this (I use here grml as example,
but in practice I used git repository as I know it is fairly small, so
the numbers, SHA-1 identifiers and branches won't match)

  $ cd <somewhere>
  $ git clone --depth 1 git://git.grml.org/grml-debootstrap.git
  Initialized empty Git repository in <somwehere>/grml-debootstrap/.git/
  [...]
  $ cd grml-debootstrap
  $ git branch -a
  * master
    remotes/origin/HEAD -> origin/master
    remotes/origin/master
  [...]

Now you have two choices: you can work on 'master' branch (reasonable
if you want to do only single thing), or you can create your own branch
(one branch for one independent unrelated feature).  Let's create new
branch off 'origin' == 'origin/master' == 'remotes/origin/master'

  $ git checkout -b t/my-working-branch origin
  Branch t/my-working-branch set up to track remote branch master from origin.
  Switched to a new branch 't/my-working-branch'

We could first setup git in such way, that it sets up to track upstream
via rebasing rather than via merge (using `branch.autosetuprebase` config
variable), but let's not complicate matters.

Now you work on branch

  [edit, edit, edit]
  [commit or commit --amend]
  [repeat as necessary]
  
Now, after some time you feel that your changes are ready for sending.
First, download any new changes, if any.

  $ git fetch

Then use interactive rebase to both update your changes to apply to most
recent upstream code, and also reorder and edit your patches (e.g. fix
typo in commit message, move fix commit and squash it with fixed commit,
etc.)

  $ git rebase --interactive origin
  [...]
  Successfully rebased and updated refs/heads/t/my-working-branch.

Then you need to generate patches.  If its more of them, I found it good
idea to save them in separate subdirectory, but it might be not necessary
for you

  $ git format-patch --cover-letter origin..

There are some situations where you don't need cover letter, e.g. if you
are sending single patch, but they are quite useful especially with longer
series.

  [edit '0000-cover-letter.patch' at least]
  [add comments to individual patches, if necessary]

Then you can either use your email client, or just

  $ git send-email --dry-run *.patch

(Here you see why saving patch series to separate subdirectory by
using '-o' option makes it easy to pick up relevant patches... ;-))

HTH
-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]