4 ms·

Open `git glog` and look at the tree is exactly what I ment by manually tracking parents of a commit. I shouldn't have to do that. That means that to see commi

Open `git glog` and look at the tree is exactly what I ment by manually tracking parents of a commit. I shouldn't have to do that. That means that to see commits that were done in a particular feature branch I need to do some magic that walks up the commit tree from a given merge commit, guesses which one of the parents is the master and which one is the feature branch, remembers the commit ids, keeps track of merge commits it hits and makes sure it is still tracking the right branch (merges of master into a feature branch are common, merges of feature branches into other feature branches are occasional), etc. All because gits branches aren't really branches at all. As to fast forwarding a feature branch onto master, I can't believe anyone would actually do that. You might as well be developing on the master branch from the beginning there, what's the point of having branches if they disappear from history?

philwelch 14y ago
I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway. It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches. If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master".
- Anderkent 14y ago
  >I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? I shouldn't have manually filter the commit history to get the information that interests me. >The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway. But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like. >It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches. Sure, if the rebase is clean, but conflicts are common. >If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master". Unless you use the github UI, in which case it will say 'Merge pull request ...'. Or you had to hotfix something on master - it happens.
  - philwelch 14y ago
    > But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like. Which benefits? To me, the main benefits of branching happen as I'm developing a feature. I can work on something and quickly context-switch either back to master or to a different feature branch. For instance, if I'm working on a feature but a high-priority bug fix needs to be done first, I can switch back to master, check out a bug fix branch, and keep my feature work separate from it. When the bug fix is done, I merge it in and rebase my feature branch from it. The only thing I really care about historically is that features land in master all-at-once, which squashing, rebasing, and fast-forwarding does for you. > Sure, if the rebase is clean, but conflicts are common. You have to resolve conflicts either way though. > Unless you use the github UI, in which case it will say 'Merge pull request ...'. Still a recognizable pattern. > Or you had to hotfix something on master - it happens. That's called "not being disciplined about using feature branches". I suspect you run into this problem because you're suffering under a self-imposed constraint that branch names have to be globally unique and meaningful throughout your version history. This isn't a problem unless you want to enforce a workflow where you always merge to master--the rebase/squash/ff workflow wouldn't actually pose a problem here, since all ancestor commits to master were deliberately put on master. My point is, if you follow an inconsistent workflow, no wonder your history is difficult to look through.

philwelch 14y ago

I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway. It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches. If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master".

Anderkent 14y ago
>I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? I shouldn't have manually filter the commit history to get the information that interests me. >The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway. But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like. >It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches. Sure, if the rebase is clean, but conflicts are common. >If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master". Unless you use the github UI, in which case it will say 'Merge pull request ...'. Or you had to hotfix something on master - it happens.
- philwelch 14y ago
  > But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like. Which benefits? To me, the main benefits of branching happen as I'm developing a feature. I can work on something and quickly context-switch either back to master or to a different feature branch. For instance, if I'm working on a feature but a high-priority bug fix needs to be done first, I can switch back to master, check out a bug fix branch, and keep my feature work separate from it. When the bug fix is done, I merge it in and rebase my feature branch from it. The only thing I really care about historically is that features land in master all-at-once, which squashing, rebasing, and fast-forwarding does for you. > Sure, if the rebase is clean, but conflicts are common. You have to resolve conflicts either way though. > Unless you use the github UI, in which case it will say 'Merge pull request ...'. Still a recognizable pattern. > Or you had to hotfix something on master - it happens. That's called "not being disciplined about using feature branches". I suspect you run into this problem because you're suffering under a self-imposed constraint that branch names have to be globally unique and meaningful throughout your version history. This isn't a problem unless you want to enforce a workflow where you always merge to master--the rebase/squash/ff workflow wouldn't actually pose a problem here, since all ancestor commits to master were deliberately put on master. My point is, if you follow an inconsistent workflow, no wonder your history is difficult to look through.