geda-developers team mailing list archive

[Markus Hitter <mah@xxxxxxxxxxx>]

Am 30.08.2013 20:03, schrieb Peter TB Brett:
> Both pcjc2 and I use stgit for our personal work.  I recommend it to
>  you, because it sounds like you might find it suits you (it's 
> certainly *way* nicer than using git's built in rebase and 
> cherry-pick commands).

In fact I find it interesting how you actually use the same
strategies as me, even with more than one developer in the same repo,
but vote so heftily against doing this in the central repo. If there
were regularly 3 to 5 developers jumping into each upcoming bug I'd
understand your arguments well, but we're currently not even close to this.


Am 30.08.2013 19:58, schrieb Peter TB Brett:

> There's a few things to consider:
> 
> 1) ... If your working practice makes regular use of `git push 
> --force', it's *very important* that you make that clear (because 
> otherwise people can base work on the tip of the branch and get the 
> rug pulled out from under them when they try and contribute it 
> back).

Agreed. In case there's a chance the development branch changed on the
remote side you have to git fetch instead of git pull and reorder the
commits.

> 2) how important is it for the branch to be "latest master + LP###" 
> rather than "latest state of LP###"?

I see "state of LP###" as a number of commits, no matter what they're
based on. Before picking (or merging) them into master they have to be
rebased to master, of course. Else you'd get conflicts at merge time.

> However, you could alternatively "squash" the branch into a single 
> patch, and add it as a single commit.

Look to me like regressions become more difficult to find this way.

> 5) if you decide that you definitely want feature branches to be 
> "latest master + LP###", then you can either regularly merge from 
> master to the feature branch, or you can regularly rebase the feature
> branch.  I would normally use the merging strategy.  This is because
> (a) it makes it much clearer how progress in developing the feature
> was affected by changes made in the master branch (via any merge
> conflicts that occur) and (b) it makes it easier for people who are
> using only basic git commands, and/or beginners who are scared by 
> rebase (I was!), to contribute. On the other hand, using the merging 
> strategy *does* mean that you get a lot of merge commits, and makes 
> your history look messy.  But commits are cheap.  And all git tools 
> cope really well with merges. And (as discussed above) you can squash
> it all into a single patch when the branch is fully cooked if you
> want things to look pretty.

If you rebase regularly, you keep just the essentials in the branch,
giving an ideal overview. Git rebase isn't difficult, 99 of 100 times it
runs just flawlessly and the 100th time you get conflicts you'd have to
solve when merging anyways. And there's always git rebase --abort :-)

> 6) When you're done with a branch (i.e. it's fully merged) you might
>  want to delete the branch (because it's all now included in the 
> master branch). Explicitly merging the branch back can make it easier
> to verify that yes, it's actually safe to delete the branch.

If you pick and rebase instead of merging, you end up with an empty
(zero commits) branch. Nice way to clearly see which parts are left.
More in detail, I'm often successful with picking the unambiguous parts
over to master first, then git rebase and rethink the remaining parts.
This way the devlopment branch gets thinner and thinner until it
dissolves into nothing.

> Did any of that make sense?

Yes, thank you. How about this small set of rules:

1. Don't change the history of master, a release branch or anything tagged.

2. In all other branches, do what you think is right. Local branches as
well as ones in the central repo.

3. If you didn't create the branch yourself, create your own or talk to
the person (bug discussion page!) who did.

4. Feel free to add as many branches as you need, ideally one per
development target (e.g. fixing a bug).

5. If you think you're done, rebase onto master and ask for testers.

6. If testing was successful (currently this means: nobody complained
for a while), rebase onto master again and cherry-pick all the commits
over to master or merge the branch into master (same result for
different tastes).

7. You can do 5. and 6. partially, i.e. pick only unambiguous commits
over to master, then iterate.

8. Delete the branch if the branchs' target is reached and there's
nothing left to keep.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/