Tong Sun <suntong@xxxxxxxx> writes:
> Just trying to put all jigsaw puzzle together here. Please correct me
> if I'm wrong.
>
> First of all, philosophy for version control with git:
>
> . While developing, small/independent commits are good thing, so that
> it's easy to decouple different changes.
>
> . But when integrating something in a main branch, commits should contain all
> logical/related changes.
I think that in final results, i.e. in patches that you send, or
commits that you send pull request for, you should have commits that
do one thing, and do it completely and without breaking. Nevertheless
having small commits that you publish / send to maintainer is a good
thing; it is always easy to review a few small patches, than one
mage-patch.
>
> Steps (using grml-debootstrap as an example):
>
> - 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)?
If you plan to continue working on this repository, and it is not
one-shot patch or patch series, it would be better (easier in the
future) to use "git remote add".
>
> - Go into grml-debootstrap and start a new branch
>
> git checkout -b t/my-working-branch
>
> - work on the code, commit, hack, commit, hack, commit -- commit often
> & commit small
You can always use 'git commit' + 'git commit --amend' if you want to
fix previous commit, instead of creating new commit.
>
> - when AOK and need to integrate patches into main branch, squash all
> patches into one
>
> git rebase -i origin/master
Reorder, edit, squash patches.
>
> - send in patches via email (to grml-devel@xxxxxxxxxxx)
>
> git format-patch origin
With larger patch series, it could possibly be of the form:
mkdir patches/
git format-patch -o patches/ --cover-letter
[edit cover letter, filling in template]
[edit patches if necessary, adding comments between "---" and diffstat]
> git send-email --to grml-devel@xxxxxxxxxxx ...
>
> Please correct me if anything above is wrong.
You can also use some patch management interface, like StGit, Guilt or
TopGit. I personally use StGit, so the above description is modified
in that there is 'stg init', there is 'stg new some-patch' and possibly
multiple 'stg refresh' when working on commit, there might be 'stg goto's
and 'stg push'es and 'stg pop's to go back and forth between patches,
and fix them.
It's a matter of taste whether to use some kind of patch management /
/ mail queue interface, or to use interactive rebase instead.
> Now, question, having done above, if I start to work some logically
> unrelated patches, what steps should I take? (I don't want 'git
> rebase' to pick up patches that I've already sent in).
If you want to start to work on some logically unrelated patches, you
should start a new branch for that.
Alternatively, when some or all patches are accepted upstream, you
download new changes using 'git pull' or 'git fetch' or 'git remote
update', and then rebase your branch on top of branch it is based on,
or to be more exact on top of branch your patches are now in. 'git
rebase' (or 'git pull --rebase' or even 'git pull', if configured
appropriately) would automatically skip patches that got applied
(sometimes you need to tell git to 'git rebase --skip' if it didn't
detect this).
It would be 'stg rebase <base branch>' (usually <base branch> is
'origin'='origin/master' or 'master'), and 'stg clean -a' to remove
empty applied patches.
P.S. Doesn't GRML have web page / wiki page for developers?
http://grml.org/git/
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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