git-svn users: please squash commits on branch merge

[Nikolaj Hald Nielsen]

I am not sure why committing stuff from a git branch should be treated
any different than "normal" commits.

In general, when working on a git branch, I make a commit at the same
time that I would have made an svn commit if I was hacking on trunk.
As such the commits represents a history and flow of the work I have
done, the only difference being that when I finally do dcommit,the
commits show up all at once rather than over the span of days/weeks.

I really like being able to look at the individual changes at a later
time when the original git branch is long dead, and squashing
everything together would make this impossible.

- Nikolaj

On 7/5/09, Téo Mrnjavac <teo.mrnjavac at gmail.com> wrote:
> I have to agree with Leo here, personally I find huge commits a pain to
> read.
> Also, for us GSoC students, who have to send weekly reports but
> sometimes dcommit more rarely than once a week it's important to
> preserve history in trunk to monitor and verify our progress.
>
> So I'll certainly see to it that I squash trivial commits (I already
> did that, though inconsistently), but I'd rather keep relevant commits
> intact.
>
> Téo
>
> On Sun, Jul 5, 2009 at 12:07 PM, Seb Ruiz<ruiz at kde.org> wrote:
>> Unfortunately the problem with squashing branch merges is that a
>> massive commit wont get reviewed. As discrete commits, individual
>> commit emails are more likely to be browsed over and scanned by other
>> developers.
>>
>> If you think that squahing big branch merges then it might be worth
>> bringing up a proper code review.
>>
>> Play it case by case.
>>
>> Seb
>>
>> On 05/07/2009, Soren Harward <stharward at gmail.com> wrote:
>>> For those of you what are using git-svn, when you merge a branch back
>>> into the main tree to get it ready for an SVN commit, could you please
>>> squash your merge history so that you don't end up with a new SVN
>>> commit for each git commit?  I really don't think it's necessary to
>>> have the entire work history of your private branch put into the
>>> public SVN; that's kind of the point of the private branch.  Just big
>>> commit is a lot easier to review, and is kinder to SVN.
>>>
>>> If you don't know what I'm talking about, here's what your workflow
>>> probably looks like:
>>>
>>> [finish work on mybranch]
>>> git checkout master
>>> git merge mybranch
>>> git svn dcommit
>>>
>>> Please do this instead:
>>>
>>> [finish work on mybranch]
>>> git checkout master
>>> git merge --squash mybranch
>>> [edit the commit message so that it's appropriate the whole commit]
>>> git svn dcommit
>>>
>>> --
>>> Soren Harward
>>> [who tips his hat to Ian who posted this tip on the Git development
>>> page in the first place].
>>> _______________________________________________
>>> Amarok-devel mailing list
>>> Amarok-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>
>>
>>
>> --
>> Seb Ruiz
>>
>> http://www.sebruiz.net/
>> http://amarok.kde.org/
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>