Manoj Srivastava <[EMAIL PROTECTED]> writes: > Now, in this specific case, since there has been only one commit > to the bug####-rra branches each, this is not an issue -- I can just > look at the commit. But if you ever add another change to any of these > branches, one would have to do > git diff bb27c26983818b9fd4ee8bcca705c0381c47010a bug172436-rra > to see what changed. > > I also note that master seems to have the change present on the > branch bug367984-rra; but it is not obvious that it came from > bug367984-rra (well, the commit message subject is the same, but ..). > Perhaps this merge --squash is not a good idea; I think it is nicer to > see gitk --all display the merge even if we get to see _all_ the > history. What do you think?
I would be very happy to just merge everything all the time. I don't really understand the Git dislike of that workflow; merging everything captures all of the history and also lets us delete old branches (like bug367984-rra) without Git complaining that the changes haven't been merged. If that sounds good, I'll merge from master into all the pending bug branches and change the wiki to suggest a simple merge onto master when a bug is finalized. I suppose the primary objection is that it makes for a messy branch history, but with Policy I expect to be deleting the branches once they're merged anyway, so I don't think that applies. >> Should we call this upcoming version 3.8.0.0? I think it has enough >> substantial changes to warrant the larger version bump. > > Sounds good to me. I'll make that change in the repository. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
