How to get more useful branch diagrams in git? -

i struggle trying see going on in history of git repositories, great tools sourcetree branch diagrams can confusing. main problem me can't tell branches commits made on, , string of commits on single branch displayed on different visual lines number of concurrent branches , people working on branches increases , decreases.

my initial thoughts along lines of "what if git stored branch name commit made on? diagram generators group commits on same line". question: why git not store branch name part of commit? asks same thing (but different reasons) , after reading , other links realised storing branch name wouldn't solve issue anyway. example when multiple people making alternating commits on local branches same branch-name, trying display these on same line technically wrong.

anyway, on questions...

1. is there way infer correct historic branching structure , produce nice looking diagram of - perhaps looking "merge master branchx" style commit messages?
2. is there valid case feature within git helps preserve of workflow information (i.e. context under work done), or possible , doing wrong?

---

regarding question 2: thinking perhaps named "work-stream". when creating branch optionally provide work-stream name (or 'inherit' work-stream name of current branch), , when switching branches current work-stream change. each commit therefore made in context of work-stream , information either stored in commit or separate meta-data in git repo. don't know inner workings of git there may other/better ways achieve this. branch diagrams visually obvious (such different background colour) see how commit-chains flowed between different work-streams.

keep in mind git self-proclaimed "stupid content tracker." doesn't want smarter needs be, because keeps highly flexible, , therefore powerful. commits text files, , nothing more that. literally this:

tree 68cd5b298858425fd8b5c2c0adfa62249b4eb650 parent c9ac0bb0d74d59b1ccb5aa8c498c33314b16948e author aperson <aperson@somecompany.com> 1368010332 -0700 committer aperson <aperson@somecompany.com> 1368010332 -0700  add test module widget.py 

tree points hashed text file lists contents of project folder, , listing can contain other trees, recursively, , blobs, hashed contents of files. parent hash of commit - again, text file one. author , committer lines have unix timestamps gmt offsets. rest of file commit message. commit - text file - answers 5 meta-questions itself: (author/committer), (pointer tree), when (timestamps), (parent commit(s)), , why (commit message). tree , parent (parent can more 1 line of parents represent merge commits) pointers. "that tree describes commit's snapshot," , "that commit/those commits is/are came from."

you could in theory keep branch name, branches pointers. if you're on master branch, there's text file called master in .git/refs/heads contains hash (i.e. 40-digit number) names commit you're on. fact you're on branch (also called "head") line in .git/head text file - pointer - reads ref: refs/heads/master, points @ master filename in heads folder under refs. it's pointers, more importantly, it's fluid.

git wants dumb branches matter. branch commit created on isn't useful - or perhaps better put, unstable thing attempt make useful - because can move commits around @ leisure. i've done things how want them.

i realized making general , project-specific commits , forth on project branch - let's call mixedbranch - , project stuff deserved own branch, interactively rebased unzip them. i.e. did git branch projectname add second branch head pointing same commit mixedbranch pointing (but didn't switch it), did git rebase -i <commit before started mixing things>. in text editor popped up, deleted of project-specific commit lines, saved, , quit. rebuilt branch under current name, without project-based commits (it's keep commits granular enough allow easily, several reasons beyond this).

then did git checkout projectname switch new branch head, still holding position @ tip of mixed commits, , did same thing in reverse - git rebase -i <that same old commit before mixing occurred>, deleted non-project specific lines time. rebuilt new branch using original branch commits, sans non-project commits, , pointed projectname newly rebased head. neither branch pointed original, interleaved set of commits, disappeared view, , looked a-a-b-b-a-b-b-a-b-a<--mixed had become a-a-a-a<--nonmixed , b-b-b-b-b<--project. storing branch things had been created on mess. it's "smart" thing trusted, git - "the stupid content tracker" - doesn't try.

in terms of following trail of commits on branches, of done backwards, because commits - text files - store references parent(s). can figure out lineage past. when merge, create new commit, snapshot of entire, merged tree. branch you're on (or otherwise merging into) considered first parent, , branch merging in second. if there other branches being merged in well, they'd third, fourth, etc. in way, git can follow primary commits keep track of - , visually indicate - commits were, say, master branch. when switch branch , make commit, git log --oneline --graph --decorate --all, see (from vim easymotion plugin):

* 4fb1af8 (origin/develop, develop) update jumplist when moving cursor *   fe9f404 merge branch 'master' develop |\   | *   667a668 (head, tag: 1.3, origin/master, origin/head, master) merge pull request #34 layzie/master | |\   | | * 06826d7 fix easymotion#inithl arguments | |/   | *   afd0e42 merge branch 'release/1.3' | |\   * | \   44c6bfd merge branch 'release/1.3' develop |\ \ \   | | |/   | |/|    | * | c4863f8 update vim docs | * | 8dc93e6 update readme |/ /   * | c1f1926 update default leader key <leader><leader> * | 6f0c9b9 move of code autoload/ 

even without benefit of color, it's easy see what's going on. develop branch committed-to, it's shown @ top. if follow line down left side of graph, primary commits of develop , origin/develop branches. 'merged-in' branches come in right. develop branch has merge commit master merged in. can follow right side of merge master branch (667a668), merge commit, pulled in layzie/master (06826d7), developed on top of afd0e42 (which on master branch (follow line straight see first-parent commit of master includes it) - context necessary in graph). merge commit (667a668) tells branch - lazie/master, 06826d7 master branch layzie remote repo.

this suggest workflow habit - leave commit messages merged in alone when merging. that's how can - , should, imo - know commits were on branches (current heads being mechanism telling commits are on branches). merge says "on left destination branch of branch i'm merging in. on right branch i'm merging in. in commit message name branch i'm merging in called @ time merged in" (important point implied here: can replace branch names @ while working, , have).

by not making branch names part of commits can cherry-pick , rebase things around without trying reason ever-changing placement of commits, hard, , not helpful. commit full-tree snapshot, metadata created it, when, , fits dag of interconnected commits. lets pull commits other branches, , other people's repos. i've used power merge disparate repos together, interleaving commits (the opposite of mentioned in first example). i've used power pull in history of particular file repo onto new branch, merge in, track development in more sensible place. threw out original, junk-filled repo didn't want anymore. can see examples here of how liquid git's commits are, , how can them because of it.

if cherry-pick in commit coworker's 'dev' branch, don't care on coworker/dev. want work in current branch. commit metadata show committed is, , coworker authored it, , when each did things. it's changes on branch aren't trying figure out they're on branch, used on branch. mess trying track in such flexible system, , you'd end incorrect info system trying smart (maybe not, seems hard problem). let merges tell want branches called, , let git sort first-parent histories left you. can i've had no problem following history dozens of branches @ time (and we've had terrible repos @ work many parallel branches don't fit across widescreen monitor).