mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pat Ferrel <pat.fer...@gmail.com>
Subject Re: master branch history and Git commits - please DO squash your working branches before merging in
Date Sat, 14 Jun 2014 16:52:15 GMT
OK, just did another push closing #18. I checked the logs and saw only one commit message and
no graph additions.

Looking at other people squash logs shows their commit messages all inline with one master
commit. commit 8c529ccff23d419c4cb5191b0435de40d6a9831c shows 4 grouped messages corresponding
to the branch commits I assume. I had branch commits too but they are not squashed into the
log. Is this as expected?
 
On Jun 13, 2014, at 2:42 PM, Dmitriy Lyubimov <dlieu.7@gmail.com> wrote:

And finally, since github is open to anyone, note that pushing to github
means collaboration whether you want it or not. So even if I don't plan to
work with anyone on github, someone may be pulling off my github branch
without me realizing it (like it more or less happened with me and Pat),
and if I were pushing rebases to my branch, i'd screw his branch to no end.
This may be incredibly frustrating (ask me how i know :)


On Fri, Jun 13, 2014 at 2:35 PM, Dmitriy Lyubimov <dlieu.7@gmail.com> wrote:

> Sure. there are exceptions. If i got exactly one commit and it has a
> proper message, rebase would do.
> 
> But let's look at pferrel/mahout MAHOUT-1464 PR. There are couple dozen of
> working branch commits there. I'd say in such situation squash is a must
> (even if they are rebased on top).
> 
> Also keep in mind that rebase of a remote working branch will screw
> collaboration (in case there's more than one person working on an issue via
> github working branch). Since pushing rebases would imply rewriting remote
> history (exactly the reason infra doesn't allow it in git-wip-us). So any
> way you look at rebase benefits, it looks like there are increasingly rare
> exceptions to admit it to happen in any remote repo and even consider its
> worth beyond the boundaries of one's own git repo on local FS.
> 
> 
> 
> 
> On Fri, Jun 13, 2014 at 2:27 PM, Ted Dunning <ted.dunning@gmail.com>
> wrote:
> 
>> I would accept that argument except that there will be exceptions.
>> 
>> Thus, I would phrase it as a strongly suggested guideline rather than a
>> hard and fast rule.
>> 
>> 
>> 
>> 
>> On Fri, Jun 13, 2014 at 11:20 AM, Dmitriy Lyubimov <dlieu.7@gmail.com>
>> wrote:
>> 
>>> in fact, i'd argue we don't want more than 1 commit per issue -- unless
>>> there's a reopening -- and definitely do not want more than 1 commit
>> per PR
>>> 
>>> 
>>> On Fri, Jun 13, 2014 at 11:18 AM, Dmitriy Lyubimov <dlieu.7@gmail.com>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Fri, Jun 13, 2014 at 11:14 AM, Ted Dunning <ted.dunning@gmail.com>
>>>> wrote:
>>>> 
>>>>> I think that rebasing cleanly would help at least as much as
>> squashing.
>>>>> Both are probably good.
>>>>> 
>>>> 
>>>> Rebasing doesn't get rid of intermediate commits, it only gets rid of
>>>> merges. which means you will be left with commits like below sitting
>> in
>>>> your history anyway as actual commits without clean attribution -- and
>>> I'd
>>>> argue we don't want that
>>>> 
>>>> * | commit cc9a70ebbdaceb8d5c2fcecd1a8cd9bee67e323e
>>>> |/  Author: pferrel <pat@occamsmachete.com>
>>>> |   Date:   Sat Jun 7 13:36:12 2014 -0700
>>>> |
>>>> |       added .DS_Store to gitignore for pushes from mac
>>>> |
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> 


Mime
View raw message