Re: Modifying mergemaster behavior
On Sat, 8 Feb 2003, Garance A Drosihn wrote: At 3:21 AM -0800 2/5/03, Doug Barton wrote: On Mon, 3 Feb 2003, Amit Rao wrote: Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? I decided to be more general, and added the DIFF_OPTIONS variable to the script, and an example of -I$FreeBSD:.*$ to the man page. Well, this gets into an interesting exercise in quoting... I think I really want: DIFF_OPTIONS='-I $FreeBSD:.*[$]' to get the behavior I wanted, because the pattern should match a literal $, and not have the $ be treated as to end-of-line. Good point. I've amended the example. I think my reasoning is correct there. It also seems to work right with or without the blank after the -I. It certainly should. :) I chose not to insert a blank to avoid future problems with quoted/unquoted output. Also note that the example in the man page expanded to: Argh. I thought of that, but didn't think cvs would be quite so... helpful. I will re-check the results this time. Thanks! Doug -- The last time France wanted more evidence, it rolled right through Paris with a German flag. - David Letterman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 3:21 AM -0800 2/5/03, Doug Barton wrote: On Mon, 3 Feb 2003, Amit Rao wrote: Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? I decided to be more general, and added the DIFF_OPTIONS variable to the script, and an example of -I$FreeBSD:.*$ to the man page. Well, this gets into an interesting exercise in quoting... I think I really want: DIFF_OPTIONS='-I $FreeBSD:.*[$]' to get the behavior I wanted, because the pattern should match a literal $, and not have the $ be treated as to end-of-line. I think my reasoning is correct there. It also seems to work right with or without the blank after the -I. Also note that the example in the man page expanded to: #DIFF_OPTIONS='-I$FreeBSD: src/usr.sbin/mergemaster/mergemaster.8,v 1.25 2003/02/05 11:03:05 dougb Exp $' # Ignores CVS Id tags which would probably baffle anyone who reads it! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Amit Rao wrote: Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? I decided to be more general, and added the DIFF_OPTIONS variable to the script, and an example of -I$FreeBSD:.*$ to the man page. For now I'm going to leave this as a power user ~/.mergemasterrc file option. Once people have a chance to use this and provide feedback on it, I may add a command line option for it. Thanks again for all the ideas, Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
Garance A Drosihn [EMAIL PROTECTED]:
I happen to be updating my system tonight, so when it came to the
mergemaster step I first modified the script. I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
worked the way I wanted it to work.
how about making this an option value to the `-c' option? `-c'
normally just switches to context-diffs, why not allow users to
specify his custom diff(1) options here and in the ~/.mergemasterrc?
clemens
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Doug Barton wrote:
[snip]
DB -I '$FreeBSD:.*$'
DB to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
DB worked the way I wanted it to work.
DB
DB What do you think mm should do if the only diff between two files is the
DB cvs ID? This comes up inside a branch if a change is checked in, then
DB backed out. Of course, it happens a lot when upgrading from 4 to 5 for
DB example.
Moreover, and possibly much more frequent, when upgrading between security
branches of -stable, e.g. RELENG_4_6 - RELENG_4_7
Not that it were major PITA, but avoiding it would simplify our lives ;-)
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Tue, 4 Feb 2003, Garance A Drosihn wrote:
At 10:36 PM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to
have worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.)
I do not care to see what the version-string is, and I certainly
don't need to see the two un-changing lines before and after the
version-string. When you also count the diff-output line which
gives the line numbers of the change, that's a total of six lines
which appear on the screen and which give me (IMO) very little
useful information.
Ok, thanks for that description.
Try -I and watch how it behaves.
I have, actually.
I suppose we should also change the 'absolute diff first' part
to include that, or people will be asked about merging a file,
only to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
There's a section of mergemaster that starts out with the comment
Do an absolute diff first to see if the files are actually different.
That's an option that users can enable, it's not the default behavior.
What I was saying is we should add the same -I argument to that
diff command,
That's not going to happen... the whole point of strict comparison mode is
that ALL differences are displayed, no matter what. Since users choose
this option, it's reasonable not to change its behavior.
In thinking about it now, I realize that I (personally) would
prefer that mergemaster would just install the file in that case,
but the result of adding the -I to that diff command is that the
file would be quietly skipped over. I could live with that too,
but I'd feel better to have it automatically installed. JMO.
I'm really, really hesitant to do this. The first time that this goes
wrong, the peasants will be after my ass with torches and pitchforks, and
they will be well justified. I'll give some thought to it though... it
may be worth adding this as an option, with a big fat warning.
If so, my gut reaction is that if a lot of FreeBSD users are
requesting this, then we should figure out how to make it
happen -- one way or another.
What I was getting at is that mergemaster is going to be run fairly
often by a significant number of freebsd users. If we need make some
changes to make that process more pleasant, then I think we should
feel free to do that.
My primary design goal, and the one that I've jealously guarded from
people clamoring for options that increase the pleasantness of the mm
experience is that running mergemaster should always be SAFE. It never
alters any existing file without explicit user input. The -i option is a
slight bastardization of my original design, but one that I was willing to
compromise on because it doesn't touch things that already exist.
I'm snipping your discussion about adding options to diff, since I can't
code mm to deal with diff options that don't exist yet. I already
added stat(1) to the base to deal with the demise of perl. :)
What I can do in the short term is make a couple small changes to mm in
order to make it possible to add your -I$FreeBSD to the DIFF_FLAG variable
in .mergemasterrc so that folks can test this behavior easily, then give
me further feedback on it.
Thanks again for your feedback, I appreciate you carefully describing what
you want, it makes it a lot easier for me to respond, and improve the
program.
Doug
--
If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 11:43 PM -0800 2/4/03, Doug Barton wrote: On Tue, 4 Feb 2003, Garance A Drosihn wrote: At 10:36 PM -0800 2/3/03, Doug Barton wrote: There's a section of mergemaster that starts out with the comment Do an absolute diff first to see if the files are actually different. That's an option that users can enable, it's not the default behavior. What I was saying is we should add the same -I argument to that diff command, That's not going to happen... the whole point of strict comparison mode is that ALL differences are displayed, no matter what. Since users choose this option, it's reasonable not to change its behavior. Oh, I didn't realize that was an optional behavior, I thought that was the default code path. That request is my mistake then, for skimming through the script a little too quickly. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Wed, 5 Feb 2003, Garance A Drosihn wrote: At 11:43 PM -0800 2/4/03, Doug Barton wrote: On Tue, 4 Feb 2003, Garance A Drosihn wrote: At 10:36 PM -0800 2/3/03, Doug Barton wrote: There's a section of mergemaster that starts out with the comment Do an absolute diff first to see if the files are actually different. That's an option that users can enable, it's not the default behavior. What I was saying is we should add the same -I argument to that diff command, That's not going to happen... the whole point of strict comparison mode is that ALL differences are displayed, no matter what. Since users choose this option, it's reasonable not to change its behavior. Oh, I didn't realize that was an optional behavior, I thought that was the default code path. That request is my mistake then, for skimming through the script a little too quickly. Yeah, I had the feeling that you thought it was the default... I meant to say something to that effect. I confess that the style isn't 100% readable to people who haven't spent as much time as I have working on it... my only defense is that when that script started, it was a whole lot simpler than it is now. :) Of course, there are some aspects of the style that I actually like, so I guess I'm not totally blameless here. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
Doug Barton [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. This is an oft-requested feature, but I'm not sure how best to implement it. Look up the -I option in the diff(1) man page. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Dag-Erling Smorgrav wrote: Doug Barton [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. This is an oft-requested feature, but I'm not sure how best to implement it. Look up the -I option in the diff(1) man page. I didn't say I don't know HOW to implement it, I said I didn't know how BEST to implement it. You snipped the part of my e-mail where I explained the issues. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Monday 03 February 2003 07:35 am, Dag-Erling Smorgrav wrote: Doug Barton [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. This is an oft-requested feature, but I'm not sure how best to implement it. Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
Doug Barton [EMAIL PROTECTED] writes: I didn't say I don't know HOW to implement it, I said I didn't know how BEST to implement it. You snipped the part of my e-mail where I explained the issues. I don't see the problem, you don't need to run diff twice... no more than you already do (any reason why you don't use cmp instead of diff on line 815?) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 9:12 AM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Dag-Erling Smorgrav wrote:
Doug Barton [EMAIL PROTECTED] writes:
On Tue, 28 Jan 2003, Garance A Drosihn wrote:
Well for one thing, if a given file has a lot of changes, then I
would like mergemaster to skip over the initial one-line change
that only tells me how some comment now has a new version-number
in it.
This is an oft-requested feature, but I'm not sure how best to
implement it.
Look up the -I option in the diff(1) man page.
I didn't say I don't know HOW to implement it, I said I didn't know
how BEST to implement it. You snipped the part of my e-mail where I
explained the issues.
I happen to be updating my system tonight, so when it came to the
mergemaster step I first modified the script. I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
worked the way I wanted it to work. From my skimming of the script,
I do not see how this change would cause problems for any other
processing. However, it's possible I'm missing something. If so, my
gut reaction is that if a lot of FreeBSD users are requesting this,
then we should figure out how to make it happen -- one way or another.
I suppose we should also change the 'absolute diff first' part to
include that, or people will be asked about merging a file, only
to be shown a file which apparently has zero changes.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen. Shouldn't that be moved
inside the
( ... ) | ${PAGER}
lines? And (IMO) delete one of the blank lines that are printed
out between the separator and the Displaying differences line.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Amit Rao wrote: On Monday 03 February 2003 07:35 am, Dag-Erling Smorgrav wrote: Doug Barton [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. This is an oft-requested feature, but I'm not sure how best to implement it. Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? That actually has promise... probably as a mergemasterrc option. I'll give it some thought. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
I happen to be updating my system tonight, so when it came to the
mergemaster step I first modified the script.
Cool... contrary to popular opinion, I do like UI feedback. :)
I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.) I also
think it's unlikely that you'd run into a version-string only diff in a
recent current - recent current upgrade. It's these that are the chief
problem I'm concerned about.
From my skimming of the script, I do not see how this change would cause
problems for any other processing. However, it's possible I'm missing
something.
What do you think mm should do if the only diff between two files is the
cvs ID? This comes up inside a branch if a change is checked in, then
backed out. Of course, it happens a lot when upgrading from 4 to 5 for
example.
If so, my gut reaction is that if a lot of FreeBSD users are requesting
this, then we should figure out how to make it happen -- one way or
another.
The request I actually get is that if the only diff is the cvs ID, that mm
should do X various things with it. Most commonly, just install the file
(which I'm opposed to on principle, and by fundamental mm design). Trying
to deal rationally with this scenario is why I'd have to add at least one
more diff to the process.
1. Are the cvs id's different?
2. If so, is that the only difference? --- new
3. If cvs ID is not the only diff, display that to the user.
I suppose we should also change the 'absolute diff first' part to
include that, or people will be asked about merging a file, only
to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen.
That's actually a good thing. The is for those cases where a diff is
smaller than one screenful. It was requested by users to give more visual
definition to that scenario, and also make logs of mm sessions easier to
parse. Passing it to PAGER when the diff already fills a page is a waste
of screen space.
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 10:36 PM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to
have worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.)
I do not care to see what the version-string is, and I certainly
don't need to see the two un-changing lines before and after the
version-string. When you also count the diff-output line which
gives the line numbers of the change, that's a total of six lines
which appear on the screen and which give me (IMO) very little
useful information.
Try -I and watch how it behaves. It isn't exactly what I was asking
for, but it is close enough that I think it would be a helpful step
forward from the present behavior.
From my skimming of the script, I do not see how this change would
cause problems for any other processing.
What do you think mm should do if the only diff between two files
is the cvs ID?
see below.
I suppose we should also change the 'absolute diff first' part
to include that, or people will be asked about merging a file,
only to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
There's a section of mergemaster that starts out with the comment
Do an absolute diff first to see if the files are actually different.
What I was saying is we should add the same -I argument to that
diff command, so that if a file only differs by the version string,
then the absolute diff will not consider it a change.
In thinking about it now, I realize that I (personally) would
prefer that mergemaster would just install the file in that case,
but the result of adding the -I to that diff command is that the
file would be quietly skipped over. I could live with that too,
but I'd feel better to have it automatically installed. JMO.
If so, my gut reaction is that if a lot of FreeBSD users are
requesting this, then we should figure out how to make it
happen -- one way or another.
What I was getting at is that mergemaster is going to be run fairly
often by a significant number of freebsd users. If we need make some
changes to make that process more pleasant, then I think we should
feel free to do that. If people aren't happy with how -I works, then
we should consider adding some different option to diff which will
do the job.
I would rather see a few lines added to diff, then having the
script do a bunch of back-flips and multiple runs of diff to get
the desired behavior. I'd also prefer those lines added to diff
than to say it's too hard to get the desired behavior, so let's
not bother.
The request I actually get is that if the only diff is the cvs ID,
that mm should do X various things with it. Most commonly, just
install the file (which I'm opposed to on principle, and by
fundamental mm design).
Mergemaster has the -'i' option to automatically install new files.
Perhaps the same option could control whether it automatically
installs files where the only change is to the version string
which is in a comment line.
Trying to deal rationally with this scenario is why I'd have to
add at least one more diff to the process.
1. Are the cvs id's different?
2. If so, is that the only difference? --- new
3. If cvs ID is not the only diff, display that to the user.
What I would ideally like is some option to diff where diff itself
understands what a version-string is, and it prints out a header
line that includes the version-string change. But the way -I
works is fairly close to what I want, and is probably less
objectionable than adding some rather specialized option to diff.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen.
That's actually a good thing. [...] Passing it to PAGER when the
diff already fills a page is a waste of screen space.
That line is more useful to me than the six lines of space used up
by telling me that the file is now 1.7.12 instead of 1.7.10. This
is my opinion. Other people have theirs, this one is mine.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Modifying mergemaster behavior
[Re-directing to -hackers] On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. Chances are mighty good that the cvs-ID comment tells me nothing that helps me decide what I want to do, and it wastes five or six valuable lines on the screen. This is an oft-requested feature, but I'm not sure how best to implement it. To satisfy all the possible combinations of things to display or not display would require running diffs at least twice every time we find something different. I'm not sure it's worth it to save 5 or 6 lines, especially when you're sending everything to $PAGER anyway. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
