Modify

Opened 16 years ago

Closed 9 years ago

#2633 closed enhancement (wontfix)

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

Reported by: jkp@… Owned by: Herbert Valerio Riedel
Priority: high Component: GitPlugin
Severity: major Keywords: branch git
Cc: Thijs Triemstra, lkraav, dobesv@…, stuge, Sigurd Hogsbro Trac Release: 0.12

Description

It would be best if you could see which branch a commit was made against in both the changeset view and the timeline view.

Attachments (0)

Change History (16)

comment:1 Changed 14 years ago by Thijs Triemstra

Cc: Thijs Triemstra added; anonymous removed
Priority: normalhigh
Severity: normalmajor

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.

comment:2 Changed 14 years ago by lkraav

Cc: lkraav added

comment:3 Changed 14 years ago by anonymous

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

comment:4 Changed 14 years ago by anonymous

Cc: dobesv@… added

comment:5 Changed 13 years ago by stuge

Cc: stuge added

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.

comment:6 Changed 13 years ago by anonymous

Cc: Sigurd Hogsbro added

comment:7 Changed 13 years ago by Herbert Valerio Riedel

Owner: changed from Herbert Valerio Riedel to anonymous
Status: newassigned

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?

comment:8 in reply to:  7 ; Changed 13 years ago by stuge

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.

comment:9 in reply to:  8 Changed 13 years ago by Herbert Valerio Riedel

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.

comment:10 Changed 13 years ago by Herbert Valerio Riedel

Owner: changed from anonymous to Herbert Valerio Riedel
Status: assignednew
Trac Release: 0.110.12

comment:11 Changed 13 years ago by Herbert Valerio Riedel

Status: newassigned

comment:12 Changed 13 years ago by dobesv@…

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.

comment:13 Changed 13 years ago by Herbert Valerio Riedel

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 :-)

comment:14 in reply to:  13 Changed 13 years ago by Herbert Valerio Riedel

comment:15 Changed 12 years ago by stuge

comment:16 Changed 9 years ago by Ryan J Ollos

Resolution: wontfix
Status: assignedclosed

GitPlugin is deprecated. Please upgrade to Trac 1.0 and use TracGit.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Herbert Valerio Riedel.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.