4 ms·
I'm one of those people that don't see a problem. I don't care what branch work happened on. I care whether it was merged or not. If I'm missing something, c
by wnoise 16y ago
I'm one of those people that don't see a problem. I don't care what branch work happened on. I care whether it was merged or not. If I'm missing something, could someone correct me? My responses would be as follows:
> A) I need to know which branch ab3e2afd was committed to know whether to include it in the change control review for the upcoming release;
Why? Is there more to it than you need to know whether it is going in this release, and whether it went in the last release?
> B) I need to know which change is the first change in the release branch because I'd like to start a new topic branch with that as my starting point so that I'll be as current as possible and still know that I can do a clean merge into master and release later;
You need the earliest on the release branch that has not also been on the master branch.
> C)I need to know where topic branch started so that I can gather all the patches up together and send them to a colleague for review.
You need to send them all the commits on the topic branch that aren't merged elsewhere.
git has nice syntax for specifying ranges of commits of these forms.
- stevelosh 16y agoHere are a few examples of where it's nice to have that extra information: - "Show me all commits by Jimmy, but don't bother with those he made on the i18n branch." - "Did Sally make this change on the 3.1 branch and then backport it to 3.0, or did she start on 3.0 and then merge forward into 3.1?" - "Show me all the changesets Steve has made on the 'stable' branch, so I can make sure he's only putting bugfixes there and not sneaking in new features."
- viraptor 16y agoFor example with situation C: with cherry-picking, merging and other actions done by many people - how do you tell which commits are on the topic branch but not merged? How can you tell apart from the commit message, which could've been changed? I think that this is his biggest issue. When the graph gets complex there is no way to tell what belongs to a topic branch, to some quick bugfix branch merged both ways, etc. etc.