Listing of branch creation time?

I'm sure the git developers grow tired of working with addle-brained users, but I sometimes forget what the contents of a topic branch are, how old it is, etc. As to content, I can make better branch names, but I think it would be useful to be able to query git as to the creation time of all of my branches, perhaps sorted from newest to oldest.

Would it be reasonable to add an option to git-branch to do this?

Bill

With `--sort-by-date`, git-branch prints the refs sorted by date of the refs' tips (newest first). If this option is combined with `-v`, also print the dates of the tips.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Tue, 27 Mar 2007, Bill Lear wrote:

	> [...] I sometimes forget what the contents of a topic branch 
	> are, how old it is, etc.  As to content, I can make better 
	> branch names, but I think it would be useful to be able to query 
	> git as to the creation time of all of my branches, perhaps 
	> sorted from newest to oldest.

	This is only lightly tested, and I will not have time to work any 
	more on this. So, if this does not what you want, you will have to 
	fix it yourself.

 Documentation/git-branch.txt |    5 +++-
 builtin-branch.c             |   52 +++++++++++++++++++++++++++++++++--------
 2 files changed, 46 insertions(+), 11 deletions(-)

On Wednesday, March 28, 2007 at 01:03:57 (+0200) Johannes Schindelin writes:

Well, thank you kindly for your quick reply. I will patch this in to my git source tree, test it out and see if I can fix anything that comes up.

Bill

The flag "no_walk" is present in struct rev_info since a long time, but so far has been in use exclusively by "git show".

With this flag, you can see all your refs, ordered by date of the last commit:

$ git log --abbrev-commit --pretty=oneline --decorate --all --no-walk

which is extremely helpful if you have to juggle with a lot topic branches, and do not remember in which one you introduced that uber debug option, or simply want to get an overview what is cooking.

(Note that the "git log" invocation above does not output the same as

 $ git show --abbrev-commit --pretty=oneline --decorate --all --quiet

 since "git show" keeps the alphabetic order that "--all" returns the
 refs in, even if the option "--date-order" was passed.)

For good measure, this also adds the "--do-walk" option which overrides "--no-walk".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Tue, 27 Mar 2007, Bill Lear wrote:

	> On Wednesday, March 28, 2007 at 01:03:57 (+0200) Johannes Schindelin writes:
	> >...
	> >	This is only lightly tested, and I will not have time to work any 
	> >	more on this. So, if this does not what you want, you will have to
	> >	fix it yourself.
	> 
	> Well, thank you kindly for your quick reply.  I will patch this in to my 
	> git source tree, test it out and see if I can fix anything that comes 
	> up.

	Actually, I tested this a lot in recent times, especially since I 
	started to use topic branches a lot more, to keep Junio happy.

	And then I had an idea: Much better to let "git log" do the work, 
	since it already sorts the commits it shows by date.  There is a 
	flag in the revision machinery, named "no_walk" which would tell 
	it to not traverse all ancestors.

	Since I can make this an alias, it does not matter very much that 
	the command line is so long.  However, since you can use different 
	pretty formats, this might be much more useful than the 
	--sort-by-date option for "git branch".

 Documentation/git-rev-list.txt |    9 +++++++++
 revision.c                     |    8 ++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

On Tue, Mar 27, 2007 at 03:52:06PM -0600, Bill Lear wrote:

I'm not sure you can always accurately get that information. If you have reflogs turned on, you can look at the oldest reflog for the that ref; however, the reflog may have been pruned. You can also try looking at the commit graph, but then you need a reference branch ("when did I branch from master"), and even that's not entirely useful. You have to look at the latest merge-base, but that tells you the last time you merged with master, not necessarily the first time.

That being said, something like this should work:

-- >8 -- #!/bin/sh

branch_date() {
  git-rev-list -g --pretty=format:'%ct %cd' $1 | tail -n 1
}

git-show-ref --heads |
  while read sha1 branch; do
    echo "$branch `branch_date $branch`"
  done |
  sort -k 2nr |
  while read branch timestamp date; do
    printf '%20s %s\n' ${branch#refs/heads/} "$date"
  done
-- >8 --

Unfortunately, there is a bug in git-rev-list; I've just posted a patch, but the one-liner fix is:

On Tuesday, March 27, 2007 at 19:35:52 (-0400) Jeff King writes:

Ok, thank you. I will try this out and keep this in mind as I test out the patch Johannes posted.

Bill

On Tue, Mar 27, 2007 at 06:00:04PM -0600, Bill Lear wrote:

This is, btw, completely different than what Johannes posted. His patch shows you the date of the _tip_ of each of the branches. My script shows the _oldest_ reflog for the branch. So it depends on whether you want them in order of "last worked on" or "created" (you said "created", but I wonder if "last worked on" is actually more useful).

-Peff

On Tuesday, March 27, 2007 at 20:01:49 (-0400) Jeff King writes:

Ah, yes, good point. I think this all falls under the topic of branch management, and it would be good to have a full suite of reports for people with a rats' nest of branches to keep track of. I'm up to ten topic branches and plan on needing a few more soon.

Queries that help me answer the question of "did I merge this branch?", "when did I merge it?" (i.e., "Can I delete this branch?"), along with creation times and last modified times, I think would be helpful.

Thank you again.

Bill

On Tue, Mar 27, 2007 at 06:08:07PM -0600, Bill Lear wrote:

I find that a nice 'gitk branch...origin' answers most of those for me (it's everything in both branches going back to the last time they merged).

-Peff

On Tuesday, March 27, 2007 at 20:10:27 (-0400) Jeff King writes:

Hmm, perhaps I should learn to use gitk more, though I must admit to being somewhat of an anti-GUI bigot (i.e., lazy).

Bill

On Tue, 27 Mar 2007, Bill Lear wrote:

given that we had someone post a tool to the list that creates ascii-art merge diagrams, I wonder if it would scratch anyone's itch to make an ascii output version of gitk?

the code posted was limited to 26 merges, but it would probably be easy enough to do two-letter nodes (although at that point do you _really_ want it on a text screen ;-)

David Lang

On Tue, Mar 27, 2007 at 03:51:36PM -0800, David Lang wrote:

I don't like using a GUI either, but I have to admit that the output of gitk is so superior that it's worth it.

However, check out the curses line-drawing support that is in tig now...it just recently has gotten good enough that I might switch to it.

-Peff

On Tue, 27 Mar 2007, Bill Lear wrote:

The reflog is your friend for such questions.

Nicolas

On Tue, 27 Mar 2007, Jeff King wrote:

I think "last worked on" is the only thing that makes sense. Anything else is completely ambigous, especially in the presence of forks and merges. And eventually all reflogs will have about the same age when they extend past the expiration period, at which point the "oldest reflog" is not meaningful anymore.

However Johannes' patch uses the author date for sorting. I think branches really should be sorted by committer's date though. The committer's date is a much better indicator of when a given branch has been updated while the author's date might be any time in the past.

Nicolas

On Tue, 27 Mar 2007, Jeff King wrote:

Well, if you know which branch it is a branch off of, don't use merge-base, just do

	git log --reverse -1 origin..branch

which should pick up the first commit that is on that branch but haven't been merged back to the original branch.

The merge-base is the right thing to do for *merging*, but if you keep merging into the branch you are developing on (to keep up-to-date), the above "what is on the branch but not in the origin" is definitely the right thing to do.

Of course, people already pointed out "gitk". And I agree. Quite often, it's worth the full graphical output to do

	gitk origin..branch

to see the big picture. But if you want to work on the command line, the above "git log" command line isn't really that bad to type..

(Personally, if I didn't want the graphical version, I'd likely just do

	git log origin..branch

and then do '>' in the pager to get to the bottom. That way I can then scroll up and down if I decide I want to get a bigger picture)

		Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

I suspect you fell into the common trap of confused interaction between --max-count and --reverse here. This will show the latest one commit on the branch that is still not in origin.

Similarly, "git log --reverse -1 master" is _not_ the way to find the root commit of the project.

What I use myself is git-topic.perl script from the 'todo' branch. It essentially is:

	for topic
        do
        	git [short]log --no-merges master..$topic
	done

with frills.

On Tue, Mar 27, 2007 at 06:06:11PM -0700, Linus Torvalds wrote:

Of course you're right, I must have had afternoon brain impairment when I wrote that other message.

-Peff