It should be possible to see the branch in the timeline and for each changeset

I found it very confusing to distinguish branches and the head (which is displayed in the browser) in the timeline view. +1 for this feature.

What does the timeline show currently - all commits in the repository, for all branches ?

Related to this there's the matter of multirepo Trac.

At libusb.org we have a couple of personal repositories which are all shown in Trac. This is nice and all, except that when a commit exists both in a personal repo and in the main repo, that commit is shown twice in the timeline. It makes perfect sense, but it looks pretty ugly.

Maybe the UI solution would be to simply list other repositories with the same commit after each other at the end of the line. The two commits would have to be collapsed somewhere, and I can't say where that would be. Messing with the database seems unneccessary. One extra hit to the table of commits is maybe not so bad.

Since the commit is identical, all such "common" commits should always be after one another, so maybe it would be very easy to just coalesce them in the frontend code. *crosses fingers* :) I would still very much like to configure the order in which repositories are listed after a "common" commit.

I'd really like to implement this one, but I'm still a bit confused ;)

How exactly is it defined, which branch a commit pertains to?

Can it only be one branch?

Is it simply by reachability of the branch-head via children pointers?

If so, it would mean that the initial root commit would be in all branches?

Replying to hvr:

I'd really like to implement this one,

Great!

but I'm still a bit confused ;)

I'll try to help.

How exactly is it defined, which branch a commit pertains to?

A new commit is always made on only one branch. When pushing commits into a remote repo the receiver will always know which branch each commit belongs to.

Can it only be one branch?

It depends on how you look at it. A git repository is a graph, consider this commit history:

                 E (branch topic)
                /
A -- B -- C -- D -- F (branch master)

The commit log for branches topic and master will both have A..D, and following that they will have E and F respectively. If master has already been pushed into a remote repo, and topic is pushed, then only E will be sent.

Is it simply by reachability of the branch-head via children pointers?

Hm, sorry, I don't understand this.

If so, it would mean that the initial root commit would be in all branches?

When it is created, the first commit in a repo is only on one branch. But yes, when other branches are created, their history will also include previous commits, but those commits aren't sent again if they already exist in a receiving repository.

Replying to peter@stuge.se:

How exactly is it defined, which branch a commit pertains to?

A new commit is always made on only one branch. When pushing commits into a remote repo the receiver will always know which branch each commit belongs to.

yes, but that would mean that we had to record they way commits were pushed into a repository. In some configurations we simply can't record this kind of information.

Can it only be one branch?

It depends on how you look at it. A git repository is a graph, consider this commit history: {{{ E (branch topic) / A -- B -- C -- D -- F (branch master) }}}

Let's make it a bit more complicated:

                          K ----------------- L -- M (branch topic2)
                         /                     \
                  E --- G -- H (branch topic)   \
                 /       \                       \
 A -- B -- C -- D -- F -- I --------------------- J(branch master)

The commit log for branches topic and master will both have A..D, and following that they will have E and F respectively. If master has already been pushed into a remote repo, and topic is pushed, then only E will be sent.

Is it simply by reachability of the branch-head via children pointers?

Hm, sorry, I don't understand this.

In the graph above, the children commits of J would be L and I.

Thus, If I lose all information about the order in which E and F were pushed, I couldn't really decide whether B is on branch 'topic', 'topic2', or on branch 'master'.

The only safe answer would be to say it is on all three, since it is reachable by all three branches.

This also is the way gitk answers the question which branches a commit is on.

I think the branch remembers the commit it was forked from so you could stop traversing at that point which avoids having the root commit in all branches problem. So a commit is on a branch if it is between the head and the base commit of the branch. Think about git rebase... it knows which commits to reapply, these are the ones logically part of that branch. I do think merges can allow a commit to be on multiple branches logically.

IMHO, git rebase doesn't need to know if the H commit was branched off master or topic2. It just needs to know the most recent common point in the commit history (= the old base), in order to try to replay all commits not yet contained at the new base we're trying to rebase to.

However, I've implemented for the meantime the gitk/git branch --contains logic for inferring the branches for a given commit;

It's available in http://github.com/hvr/gitplugin/tree/v0.12.0.4; With that implementation, Trac 0.12.x shows little colored box-labels in the timeline view containing the branch name. Branch tip commits are colored different.

Hope this helps for the mean time until we get a more advanced branch-inferring logic :-)

Replying to hvr:

It's available in http://github.com/hvr/gitplugin/tree/v0.12.0.4

the url has changed: http://github.com/hvr/trac-git-plugin/tree/v0.12.0.4