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


   > While useful, they don't replace information of this type:
   > 
   >         * configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.

   git log -p:
      tic6x-*-*)
   -    noconfigdirs="$noconfigdirs gdb sim"
   +    noconfigdirs="$noconfigdirs sim"


   git annotate:
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
   34dd72a9        (     qiyao     2011-08-14 12:28:15 +0000       1023)    noconfigdirs="$noconfigdirs sim"
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;
   ->
   git show 34dd72a9

   What's wrong with it?  And if I search which commit changed it:
	   git log -p -Sgdb configure.ac

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, it doesn't help me follow how something has changed over a time
period.  ChangeLog makes this trivial.

   > You still have to store that information _somewhere_, be it in a file
   > or in the commit message.

   Still there should be stored + shown the associated mail which completely
   misses here and which is stored there by GIT.

You could store the exact same information in the ChangeLog, git
doesn't solve what you put in the ChangeLog/commit message. 

2011-07-22  Jakub Jelinek  <jakub@redhat.com>

	URL: http://sourceware.org/ml/binutils-cvs/2011-07/msg00116.html
 
	* dwarf2.h (DW_AT_GNU_macros): New.
	(enum dwarf_macro_record_type): New enum.  Add DW_MACRO_GNU_*.

Or, with a fictious bug ID:

2011-07-26  Tom Tromey  <tromey@redhat.com>

        Implement new DWARF macro proposal.  (Bug#123456)

        URL: http://sourceware.org/ml/gdb-patches/2011-07/msg00732.html

	* symfile.h (struct dwarf2_debug_sections) <macro>: New field.
....

   >   I just don't see how annotate/log replaces that here, maybe it
   > should? I don't know, but entries like that are super useful to
   > trace history of things.

   When I was a newbie to GDB I would not see the reason why string
   "gdb" was removed from variable "noconfigdirs".  I would like to
   find out the mail submit/reasoning/approval.  I tried now but I
   failed to find the mail.

I agree, such information is useful.  Several projects have started
adding it as part of the ChangeLog entry; like the examples above.


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