Re: [PATCH] gitk: add Update menu item.
- From
Paul Mackerras <paulus@samba.org>
- Date
- Sep 21, 2005, 23:46 UTC
- Message-ID
- <17201.61667.465005.53654@cargo.ozlabs.ibm.com>
- In-Reply-To
- <20050920122423.GA4228MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege writes:
> Update will redraw the commits if any commits have been added to any > of the selected heads. The new commits appear on the top.
I like the idea but I am not sure if you have implemented it the best way.
Are we sure that all the commits we had before doing the update will still be there after the update? What if I had checked in some changes and run gitk, and then decided that the commit I just created was wrong, and so I set HEAD to HEAD^1 and did a git prune, then told gitk to update - shouldn't I see the top commit disappear?
Maybe it would be better to just clean out everything and re-read all the commits from scratch.
Also, I'm not convinced that doing ^$id for all tags, heads and other refs is correct. Although we have read the reference and know the ID, that doesn't mean we have seen that commit and displayed it.
The more general problem is to provide a way for the user to change the set of commits displayed using a dialog box. That would require gitk to understand its command-line arguments so that the elements of the dialog box could be initialized properly, though.
Some other comments:
> + .bar.file add command -label "Update" -command "updatecommits [list $rargs]"
This would be better as:
.bar.file add command -label "Update" -command [list updatecommits $rargs]
> + rereadrefs
We don't need the redrawing part of rereadrefs, just the bit that unsets tagids etc. and calls readrefs.
Regards, Paul.