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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

Pierre Habouzit <madcoder@debian.org> writes:

>   And AFAICT, the kernel works in the very same way. What gets rebased
> though, are the bugfixes patches that come by 2 or 3, and that add no
> value when added as a specific branch. Usually those in git.git are
> applied on top of the 'maint' branch (aka the maintenance branch) and
> then merged back into master, and then back into 'next' (where the devel
> happens).
>   IOW, it depends, and if you work on a new _feature_ it's really rarely
> rebased.

Right. Well said.

This however doesn't changes the value of logical changes. I doubt
git.git people would accept patches like:

"Now it compiles again"
"Ouch! Syntax error"
"First try to get it done"

It's much nicer to have something like:

"Implements the basis for feature 'foo'"
"Changes code to use new feature 'foo'"

and avoid all the messy commits done in the way.

Besides that, I guess that even when you rebase something against git.git
or linus tree, you'll end up being out to date and a merging being
done since the volume of commits is too high to allow fast-forward
merging only.

Personaly, when I'm working on any branch I try to keep it against
current version (be it maint or next or whatever) rebased. When
merging, I don't worry if it'll be a merging or a fast-forward
one. It'll only depends on how long the branch took to get merged.

>> I vote for clean history and a bissectable tree, and I think it is worth the
>> effort.  But I am no dpkg developer, this is a thing you guys have to find
>> an agreement among yourselves.
>   You vote for the mad route. Sorry, but it makes absolutely no sense to
> me. Ian's work was done at some point, tested from that point, and it
> makes sense to remember that fact. Actually it's insane to forget that
> fact. And rebasing is just pretending that fact never existed. It's just
> wrong.

Please see my commit about the logs above.

As I said, it's much more about commit logs (for me at least) then

If Ian is OK to make it in logical pieces, it would be ok for me to merge.

        O T A V I O    S A L V A D O R
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Reply to: