Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: ams@gnu.org (Alfred M. Szmidt)
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: pmuldoon@redhat.com, joseph@codesourcery.com, gdb@sourceware.org
Subject: Re: GIT and CVS
Date: Fri, 14 Oct 2011 06:51:00 -0000	[thread overview]
Message-ID: <E1REbcH-00086b-FO@fencepost.gnu.org> (raw)
In-Reply-To: <20111014055530.GA8886@host1.jankratochvil.net> (message from Jan	Kratochvil on Fri, 14 Oct 2011 07:55:30 +0200)

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


  reply	other threads:[~2011-10-14  6:51 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-13 19:37 Phil Muldoon
2011-10-13 20:21 ` Joseph S. Myers
2011-10-13 20:55   ` Phil Muldoon
2011-10-13 21:33     ` DJ Delorie
2011-10-13 21:44       ` Phil Muldoon
2011-10-13 21:43     ` Alfred M. Szmidt
2011-10-13 21:51       ` Jan Kratochvil
2011-10-13 22:08         ` Eli Zaretskii
2011-10-13 22:25           ` Jan Kratochvil
2011-10-13 22:41             ` Alfred M. Szmidt
2011-10-13 22:44             ` Alfred M. Szmidt
2011-10-14 10:31             ` Eli Zaretskii
2011-10-13 22:19         ` Alfred M. Szmidt
2011-10-13 22:45           ` Jan Kratochvil
2011-10-13 23:37             ` Alfred M. Szmidt
2011-10-14  5:56               ` Jan Kratochvil
2011-10-14  6:51                 ` Alfred M. Szmidt [this message]
2011-10-13 23:03       ` Phil Muldoon
2011-10-13 23:51         ` Alfred M. Szmidt
2011-10-14  6:01           ` Jan Kratochvil
2011-10-14  6:52             ` Alfred M. Szmidt
2011-10-14  7:01               ` Jan Kratochvil
2011-10-14  7:13                 ` Alfred M. Szmidt
2011-10-14 15:39                 ` Joseph S. Myers
2011-10-14 15:49                   ` Jan Kratochvil
2011-10-13 21:51     ` Joseph S. Myers
2011-10-13 21:59       ` Jan Kratochvil
2011-10-13 22:08         ` Joseph S. Myers
2011-10-13 22:17         ` Eli Zaretskii
2011-10-14  5:03           ` Joel Brobecker
2011-10-14  8:04             ` Eli Zaretskii
2011-10-13 23:14       ` Phil Muldoon
2011-10-13 23:56         ` Joseph S. Myers
2011-10-14  6:04           ` Jan Kratochvil
2011-10-13 21:58 ` Eli Zaretskii
2011-10-13 23:20   ` Phil Muldoon
2011-10-14  8:13     ` Eli Zaretskii
2011-10-14 10:23       ` Mark Kettenis
2011-10-14 10:55         ` Eli Zaretskii
2011-10-14 14:09           ` Li, Rongsheng
2011-10-14 12:54         ` Jan Kratochvil
2011-10-14 13:07           ` Jonas Maebe
2011-10-14 14:26           ` Eli Zaretskii
2011-10-14 14:32             ` Jan Kratochvil
2011-10-14 15:05             ` Phil Muldoon
2011-10-14 15:21               ` Eli Zaretskii
2011-10-14 14:52         ` Phil Muldoon
     [not found]           ` <83zkh3k419.fsf@gnu.org>
2011-10-14 15:47             ` Jonas Maebe
2011-10-14 16:12             ` Andreas Schwab
2011-10-14 16:20             ` Andreas Schwab
2011-10-14 16:25               ` Eli Zaretskii
2011-10-14 17:06                 ` Matt Rice
2011-10-14 17:25                   ` Eli Zaretskii
2011-11-11 21:00         ` Steinar Bang
2011-11-12  8:30           ` Eli Zaretskii
2011-11-12 15:30             ` Steinar Bang
2011-10-14  5:10 ` Joel Brobecker
2011-10-14 15:38   ` Joseph S. Myers
2011-10-14 12:36 ` André Pönitz
2011-10-14 14:19   ` Eli Zaretskii
2011-10-14 15:02     ` Phil Muldoon
2011-10-14 15:16       ` Eli Zaretskii
2011-10-14 16:59     ` André Pönitz
2011-10-14 14:58   ` Phil Muldoon
2011-10-14 15:02     ` Paul_Koning
2011-10-16 15:04       ` Ralf Corsepius
2011-10-14 16:10     ` André Pönitz
2011-11-11 22:50 ` Pedro Larroy
2011-11-12  8:28   ` Steinar Bang
2011-11-13  0:05     ` John Hein
2011-11-15 15:02   ` Tom Tromey
2011-11-16 16:59     ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1REbcH-00086b-FO@fencepost.gnu.org \
    --to=ams@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=pmuldoon@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox