Re: Recommended work flow with git to send in patches

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 28, 2010, 16:49 UTC
Message-ID: <201007281849.47989.jnareb@gmail.com>
In-Reply-To: <AANLkTi=psuiq-GP9zV=pY6swNAUF-MwJt6COrNDVDLqu@mail.gmail.com>

On Tue, Jul 27, 2010, Tong Sun wrote:

Show 7 quoted lines

> On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski <jnareb@gmail.com> 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...

Show 16 quoted lines

> > > - 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.

Show 12 quoted lines

> 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