This is the mail archive of the
mailing list for the GDB project.
Re: GIT and CVS
> I think you missunderstood me, if I am looking at a bug I wish to
> follow the changes done to something, usually a function. While
> log/annotate are useful to see what the tree looked like at some
Not just at some point. The [revision] parameter there can go back
in history which is why I also put it here in the former mail:
git annotate configure.ac 34dd72a9^
005efcbe (Joseph Myers 2010-03-23 16:05:34 +0000 1022) tic6x-*-*)
fe571c9f (Joseph Myers 2011-04-28 13:24:51 +0000 1023) noconfigdirs="$noconfigdirs gdb sim"
005efcbe (Joseph Myers 2010-03-23 16:05:34 +0000 1024) ;;
It could be made more convenient but GIT provides IMO the best such
feature+performance so far to make it feasible.
But this is still at one fixed point in time and requires me to figure
out which commit to look at. How can I see all changes to tic6x-*-*
in this files, or on a per tree basis?
> it doesn't help me follow how something has changed over a time
> period. ChangeLog makes this trivial.
ChangeLog is not usable for tracking such changes as I cannot trust
it wrt mistakes of its text vs. the real source changes. And
also/primarily the word description of the diff (*) there is too
If you cannot trust the ChangeLog entries, then that is a bug in the
(*) I do not understand why it makes sense to re-state by human
what is already present in the diff itself.
Scrolling through big diffs is not how I want to spend my time. :-)
> You could store the exact same information in the ChangeLog, git
I would need to have always up-to-date rsync copy for local access
- do you have? It is just easier with GIT, and working even for
projects where usually the rsync access is not provided (but no
other projects use CVS anymore).
On some machines I do have, using the rsync script I mentioned before.
I don't find it easier using git, or any other tool. But yes, the
project needs to make the CVSROOT accessible; which is the case with
the src/ tree.