This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
   > point,

   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
   general.

If you cannot trust the ChangeLog entries, then that is a bug in the
review process.

   (*) 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]