Johan S. H. Rosenkilde wrote: > Volker Braun writes: > >> Thats ok for reviewing tickets, and implemented as "git trac try >> <ticketno>". > > OK. I had a chat with Thierry Monteil and we agreed there were some > subtle differences I don't remember - but I'll take a look at "git trac > try". > >> 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'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. 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. -leif > I agree with the problem with the merge order which can be annoying. I > don't know if there is an obscure Git command for changing that. But if > the alternative is to spend tons of time recompiling every time I'm > checking out a ticket, I'm not sure I'll do the trade ;-) > > 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.
