some git thoughts, personal and feature branches

[Leo Franchi]

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.


leo


> An alternative could be to hide (or have the option to, like
> SVN_SILENT) the merge commits from the commit mails. I'm sure Ian can
> come up with a technical solution.
>
> Bart
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel