some git thoughts, personal and feature branches

[Bart Cerneels]

On Tue, Aug 11, 2009 at 17:48, Leo Franchi<lfranchi at kde.org> wrote:
> On Tuesday 11 August 2009 02:20:48 Bart Cerneels wrote:
>> On Tue, Aug 11, 2009 at 10:30, Mark Kretschmann<kretschmann at kde.org> wrote:
>> > On Wed, Aug 5, 2009 at 10:50 AM, Ian Monroe<ian at monroe.nu> wrote:
>> >> First off I don't really understand why everyone went and made
>> >> personal repos, its like people thought they were required (most seem
>> >> unused). I think its just causing confusion. Unless you want a pretty
>> >> handy way to share your work as you work on it, just commit and push
>> >> to the mainline repo. Its more straightforward and also a handy way to
>> >> share your work. :)
>> >>
>> >> So to define (at least how I use these words):
>> >> mainline: the new trunk
>> >> personal branch: basically this is your local work that you decided to
>> >> publish. No one else has commit rights to it. Likely you'll merge the
>> >> work here relatively quickly into mainline.
>> >> feature branch: working on some new feature with 1 or more other
>> >> developers. Might go weeks or months without merging into mainline.
>> >>
>> >> But anyways, on a personal branch, where remote 'origin' is Amarok
>> >> mainline. to sync with master:
>> >> git checkout personal-branch
>> >> git remote update
>> >> git rebase origin/master
>> >> git push -f
>> >>
>> >> push -f is needed since rebase changes history. push -f is bad if
>> >> other people are making commits to your personal branch, since they
>> >> will be pretty screwed if. But then its not a personal branch, its a
>> >> feature branch by definition. :)
>> >>
>> >> so to merge master on a feature branch:
>> >> git checkout somefeature
>> >> git remote update
>> >> git merge origin/master
>> >> git push
>> >>
>> >> And then weeks later when you finish the feature branch, and let
>> >> everyone else know:
>> >> git remote update
>> >> git rebase origin/master
>> >> git push -f #update feature branch
>> >> git push origin somefeature:master #merge into mainline
>> >>
>> >> So push -f still isn't requried for merging into mainline isn't
>> >> required (which is good, since its impossible) since rebase has only
>> >> been editing the history of commits that aren't in mainline.
>> >>
>> >> The key is to not mix up whether its a personal branch or a feature
>> >> branch. :) You can't rebase and then expect a plain 'push' to work to
>> >> your personal branch. And if this is all really confusing for you,
>> >> stop publishing your personal branches and just use mainline. :P
>> >
>> > Bump! I still see a lot of "Merge branch master" commit logs. It would
>> > be nice to get a consensus on the "rebase vs merge" debate.
>> >
>> > Please read Ian's mail if you haven't, I think he managed to put it
>> > all into perspective :)
>> >
>> > --
>> > Mark Kretschmann
>>
>> I also don't agree with the "I don't want to rebase because it
>> rewrites history"-sentiment but willing to discuss this.
>
> Well, you can't rewrite the history of master. That would screw up everyone
> else who has a checkout. So it's not a matter of sentiments, but rather a
> necessity for working together. So push -f is disabled for this reason--so you
> don't accidentally rewrite history and cause some havok for everyone else.
>
> Of course, with your own clone, you can do whatever you want.
>

Sorry, I didn't make myself clear enough in light of git complexity.

I've heard some people complain that the rebase process rewrites the
commit times of local commit, rewriting local history. So I was
talking about rewriting local history, specifically the commit times.

Bart