Re: Recommended work flow with git to send in patches

From: Tong Sun <suntong@cpan.org>
Date: Jul 28, 2010, 22:40 UTC
Message-ID: <AANLkTikkXQNiaagPGN5cYCDg6hfvojpLcEePWF6UbUDV@mail.gmail.com>
In-Reply-To: <m3y6cwkew7.fsf@localhost.localdomain>

On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 14 quoted lines

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

Yeah, that's actually exactly what I believed before getting feedbacks from grml developers for squashed patches. It's an interesting topic to me, so let's dig deeper into it.

Say that I need to add a feature to a CLI program. I would instinctively divide it into 3 logical steps/patches, 1st to the user interface (the command line handling), 2nd to the implementation, and 3rd to the document.

Do you think 3 small patches is the way to go, or a single patch is, since all 3 are logically related?

Now back to our topic, thanks for your work flow explanation, I'll answer/ask in this single message.

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

> I don't understand this second step.  Why do you want this second clone?

That's what I searched and found from the Inet when I was looking for the recommended work flow, which was to do 'git clone' from web once then 'git clone' several local working copies to work on several independent unrelated features. Now I know creating my own local branches is the way to go.

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

Could you elaborate more on this with git commands please, so that I can have a full picture?

Thanks again for your clearly explanations, I think I don't any further questions for the moment.

cheers,