leif writes: >> But if you want to actually make changes then this creates a new merge >> commit which furthermore is against the conventional order (where the >> feature branch is the first parent). So it makes the commit history harder >> to understand. > > I'd rather say "impossible", or more precisely, to later review exactly > the commits that belong to the ticket in question.
I'd say that's a Git tools question. Without flags, git log will show the individual commits in chronological order, but you can ask to do topsort or something. Personally, it seldom comes up for me, and when it has, I've been able to get by using the commit numbers given by Trac or searching through the log. Sure, I probably have not been involved in the most complicated tickets Sage has ever seen, though. >> I've heard arguments against "gratuitously" merging the ticket to >> newest release when e.g. just fixing a typo. But that seems to me to be >> a rather theoretical complaint, since the ticket will be merged later on >> anyway. > > Absolutely not, unless you're /creating/ a new / "the" branch on the > ticket. If you're taking an already existing branch from a ticket and > make changes to be pushed back later, you should *always* fetch, not > pull into whatever head you currently have locally. > > But maybe I just misunderstood you. "whatever head" is always develop, so I'm always pulling into the newest beta release. > For new branches, I think it's best to base them on the last *stable* > release (i.e., check out master before creating the new branch), unless > you really need fixes from later betas, or it's clear (or likely) that > you'd get merge conflicts with later betas if you base your branch on > master. (But you'd notice that sooner or later when looking at the > colour of the branch on the trac ticket -- unfortunately nobody ever > gets notified when the colour changes after trac's develop has been > updated to the next beta, something either trac or a patchbot could > implement.) > > If you always base your branches on the latest *beta*, others will just > get forced to pull and build the latter (with typically loads of > completely unrelated changes), no matter whether they fetch or pull your > branch. So in other words, you're (at least potentially) moving rebuild > load to others. I don't see why all developers shouldn't always be on the latest beta. It's also the only version that would make sense to base *all* future tickets on, though - as you say - many tickets might not care about the diff between master and develop. So in the interest of minimising compilation time for developers overall, I think we should base all tickets on the latest beta. Otherwise, when you jump between small-ticket-A and small-ticket-B, you might suddenly trigger a huge recompile since B happened to need one of the 100 tickets between master and develop, while A didn't. Without this or a similar schema, working on multiple tickets becomes absolutely unbearable for me due to compilation time. How do you guys cope with that? Best, Johan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
