Johan S. H. Rosenkilde wrote: > 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.
Well, probably it's just me, but I always (also) review tickets on trac (i.e., via what git-o-lite gives); the whole branch, but also each individual commit. You just need a browser to do so. Having a Sage installation at hand, it's even more tedious to do so on the command line when the relevant commits are "out-of-order" / mixed with unrelated commits. >>> 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. Well, that doesn't make much of a difference, unless the ticket is incidentally based on the same (which is rarely the case, since most tickets live longer than a single beta-release cycle). And as said, whether you pull or fetch is only relevant if you push back changes. I guess you review and test many more tickets than you actually push reviewer changes to. For trivial changes, you can also put inline patches onto trac the owner of the ticket / branch can easily apply, and for more complex changes, you can always create a new branch on trac *without* changing the ticket's branch to that. Then the owner of the original branch can cherry-pick from your branch, if it's based on something else. (With different Sage installations, you could do similar locally of course, i.e., "backport" the changes you made on top of your develop to master+fetched original branch, say, and push the resulting branch. I personally often first make changes in some random Sage installation, then moving them around, later pushing to trac from a "suited" one.) >> 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. Time? Resources? Note that many, I guess, have Sage installations here and there, and most likely don't or cannot keep each of them always what you'd call "up-to-date", but rather at one of the previous "stable" releases, or something inbetween. > 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. [Random insertion: Wasn't it you who [had to] upgrade[d] to Ubuntu 16.04 just to get the next version of Emacs? ;-) ] Obviously, there are more "recent" beta releases than stable ones. And as mentioned, tickets and their branches age. So you'll never have all tickets (not even a large percentage) based on the latest beta. It's easier if you keep one Sage installation at master, and another at some later beta. The problem (if tickets are based on the latest beta) IMHO is that one is too often forced to "upgrade" for no reason, at least if one forgets to first check what release a branch was based on. If people keep pushing back "rebased" branches, the situation just worsens. > 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? moar coars? ;-) More seriously, different Sage installations, trying to pick the most suited when going to actually build a fetched branch. But sometimes at least, you also want to test on a specific machine (hardware, OS/distro, compiler, whatever). -leif -- 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.
