Alex Rønne Petersen Wrote: > >>>> Isn't the merge commit connected with the branch it was merged from? So > >>>> if you want history of the branch, it's still there, it's just not > >>>> main's history. > >>> > >>> An example from Fossil: > >>> 20 recent commits: http://www.fossil-scm.org/index.html/timeline > >>> 20 recent commits in trunk: > >>> http://www.fossil-scm.org/index.html/timeline?r=trunk > >> > >> That only makes sense if you keep the branches around after they're > >> 'dead', which is considered a bad practice, as it will eventually grow > >> confusing. > > > > They're not dead. They're history. > > I don't understand what point you're trying to argue. :) > > - Alex
You are both correct, but due to git's high level once you do a merge you don't see the history as multiple branches. A merge commit will reference both branch data as its parent. The branch name can then be removed and its history remain part of the master branch. Also if you merge in a branch that is a direct descendant the merge is a "Fast-Forward" which just means make master point to ____ commit. This makes it common to always commit non-master branch, and still a merge commit isn't required.
