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.
next prev parent 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