Merge or Cherry-Pick?

[Dawit A]

On Tue, Feb 1, 2011 at 4:22 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Tuesday, February 1, 2011, Alexander Neundorf wrote:
>> On Monday 31 January 2011, Andreas Pakulat wrote:
>> > Hi,
>> >
>> > something that hasn't been written down as far as I can see (if I
>> > overlooked it, please point me to it) is what the policy on kdelibs is
>> > to be now wrt. merging vs. cherry-picking of changes in branches and
>> > master?
>> >
>> > Andreas
>>
>> Not replying to any particular response in this thread...
>>
>> I don't know whether I missed something, if so, please let me know.
>
> no, you didn't miss anything. right now i think everyone is very busy getting
> up to speed with the basics. for instance, i spent a good portion of the day
> today struggling with git.reviewboard.kde.org (sysadmin was very helpful, but
> things are still rough in places ..)
>
> there's also the issue that it appears that the 4.6 branch is unmergable with
> master, complicating things for the time being. in fact, it encourages cherry-
> picks when probably it should be merges.
>
> then i learned today to be extra vigilant about doing `git pull --rebase` and
> not just `git pull` so i don't accidentally throw merge commits in there while
> preping for a push.

I learned this the hard way, but it is even more problematic, at least
for me, when you attempt to learn how to adapt or re-learn how to do a
particular workflow with git. For example, let us take one of the
things Alexander mentioned in his email:

* for committing a trivial change to master/trunk

If you only had a single change that is already committed into your
local repo, then I guess it is simple enough and can be pushed to the
origin master branch by doing:

git pull --rebase
git push

But how would a similar work flow except there are multiple fixes
present in the local repo ? How would you push only a single fix in
such case ? It does not seem possible to me to do that... If that is
the case, does it mean we have to create separate branches for each
and every fix we work on since branches are cheap to create in git ?
Or simply wait until we are ready to push all the changes and do them
at once ? What if that is not desirable, i.e. an urgent fix that needs
to be committed ?

There is probably easier way to do things in git, but despite reading
several articles and documentation on git, it is not easy to figure
out the uses of git for own work flow for first time users like
myself. Perhaps compiling answers for the easiest way to handle the
most common work flows being discussed here would be a good starting
point for a guide that can be put on techbase...

Regards,
Dawit A.