You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Rall <dl...@collab.net> on 2007/05/31 20:30:41 UTC
Name change for "--merge-sensitive" to account for more general usage
[Re-posting with meaningful subject line.]
The root of the problem pointed out here is that
'svn merge --merge-sensitive' looks odd.
On Tue, 29 May 2007, David James wrote:
> On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> >On Thu, 24 May 2007, Karl Fogel wrote:
> >
> >> "David James" <ja...@cs.toronto.edu> writes:
> >> > I know this is a bikeshed, but, how about "--merge-smart"? This flag
> >> > makes the merge command smarter -- it teaches the merge command to
> >> > look at your merge history and figure out what revisions to merge.
> >> > Without this flag, the merge command acts dumb and doesn't guess.
> >> >
> >> > This flag name could work for "svn info" and "svn log" as well.
> >>
> >> Then just "--smart", maybe?
> >>
> >> http://pink.bikeshed.com/
> >
> >"smart" doesn't give a nod to the fact that we're adhering to merge
> >history.
>
> How about "--track-merge-history" or "--smart-merge-tracking" then?
> These names are longer than "--merge-smart" and "--smart" but might
> indicate the purpose of the flag a bit better.
"--track-merge-history" is a perfect description for the use cases
we're currently targeting, implemented via the following subcommands:
blame
log
merge
It's only 4 characters longer than "--merge-sensitive", and we have a
short option ("-g"). Would anyone be adverse to switching, or does
anyone have a better suggestion?
Re: Name change for "--merge-sensitive" to account for more general usage
Posted by David James <ja...@cs.toronto.edu>.
On 5/31/07, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 31 May 2007, Mark Phippard wrote:
>
> > On 5/31/07, Daniel Rall <dl...@collab.net> wrote:
> > >[Re-posting with meaningful subject line.]
> > >
> > >The root of the problem pointed out here is that
> > >'svn merge --merge-sensitive' looks odd.
> > >
> > >On Tue, 29 May 2007, David James wrote:
> > >
> > >> On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> > >> >On Thu, 24 May 2007, Karl Fogel wrote:
> > >> >
> > >> >> "David James" <ja...@cs.toronto.edu> writes:
> > >> >> > I know this is a bikeshed, but, how about "--merge-smart"? This flag
> > >> >> > makes the merge command smarter -- it teaches the merge command to
> > >> >> > look at your merge history and figure out what revisions to merge.
> > >> >> > Without this flag, the merge command acts dumb and doesn't guess.
> > >> >> >
> > >> >> > This flag name could work for "svn info" and "svn log" as well.
> > >> >>
> > >> >> Then just "--smart", maybe?
> > >> >>
> > >> >> http://pink.bikeshed.com/
> > >> >
> > >> >"smart" doesn't give a nod to the fact that we're adhering to merge
> > >> >history.
> > >>
> > >> How about "--track-merge-history" or "--smart-merge-tracking" then?
> > >> These names are longer than "--merge-smart" and "--smart" but might
> > >> indicate the purpose of the flag a bit better.
> > >
> > >"--track-merge-history" is a perfect description for the use cases
> > >we're currently targeting, implemented via the following subcommands:
> > >
> > > blame
> > > log
> > > merge
> > >
> > >It's only 4 characters longer than "--merge-sensitive", and we have a
> > >short option ("-g"). Would anyone be adverse to switching, or does
> > >anyone have a better suggestion?
> >
> > I think the problem is that ultimately the usage of this option in the
> > merge scenario is a little different than the others. That being
> > said, I am still in favor of trying to use one option.
> >
> > I personally still prefer --merge-sensitive to the other propsals, but
> > do not feel strongly and agree it could be better. How about
> > --follow-merge-history or --use-merge-history instead of --track?
>
> Of those, I pefer --use-merge-history. I also think it leaves less
> possibility for ambiguity, in relation to --track-merge-history (and
> is also more brief).
+1. Go for it!
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Name change for "--merge-sensitive" to account for more general usage
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 31 May 2007, Mark Phippard wrote:
> On 5/31/07, Daniel Rall <dl...@collab.net> wrote:
> >[Re-posting with meaningful subject line.]
> >
> >The root of the problem pointed out here is that
> >'svn merge --merge-sensitive' looks odd.
> >
> >On Tue, 29 May 2007, David James wrote:
> >
> >> On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> >> >On Thu, 24 May 2007, Karl Fogel wrote:
> >> >
> >> >> "David James" <ja...@cs.toronto.edu> writes:
> >> >> > I know this is a bikeshed, but, how about "--merge-smart"? This flag
> >> >> > makes the merge command smarter -- it teaches the merge command to
> >> >> > look at your merge history and figure out what revisions to merge.
> >> >> > Without this flag, the merge command acts dumb and doesn't guess.
> >> >> >
> >> >> > This flag name could work for "svn info" and "svn log" as well.
> >> >>
> >> >> Then just "--smart", maybe?
> >> >>
> >> >> http://pink.bikeshed.com/
> >> >
> >> >"smart" doesn't give a nod to the fact that we're adhering to merge
> >> >history.
> >>
> >> How about "--track-merge-history" or "--smart-merge-tracking" then?
> >> These names are longer than "--merge-smart" and "--smart" but might
> >> indicate the purpose of the flag a bit better.
> >
> >"--track-merge-history" is a perfect description for the use cases
> >we're currently targeting, implemented via the following subcommands:
> >
> > blame
> > log
> > merge
> >
> >It's only 4 characters longer than "--merge-sensitive", and we have a
> >short option ("-g"). Would anyone be adverse to switching, or does
> >anyone have a better suggestion?
>
> I think the problem is that ultimately the usage of this option in the
> merge scenario is a little different than the others. That being
> said, I am still in favor of trying to use one option.
>
> I personally still prefer --merge-sensitive to the other propsals, but
> do not feel strongly and agree it could be better. How about
> --follow-merge-history or --use-merge-history instead of --track?
Of those, I pefer --use-merge-history. I also think it leaves less
possibility for ambiguity, in relation to --track-merge-history (and
is also more brief).
Re: Name change for "--merge-sensitive" to account for more general usage
Posted by Mark Phippard <ma...@gmail.com>.
On 5/31/07, Daniel Rall <dl...@collab.net> wrote:
> [Re-posting with meaningful subject line.]
>
> The root of the problem pointed out here is that
> 'svn merge --merge-sensitive' looks odd.
>
> On Tue, 29 May 2007, David James wrote:
>
> > On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> > >On Thu, 24 May 2007, Karl Fogel wrote:
> > >
> > >> "David James" <ja...@cs.toronto.edu> writes:
> > >> > I know this is a bikeshed, but, how about "--merge-smart"? This flag
> > >> > makes the merge command smarter -- it teaches the merge command to
> > >> > look at your merge history and figure out what revisions to merge.
> > >> > Without this flag, the merge command acts dumb and doesn't guess.
> > >> >
> > >> > This flag name could work for "svn info" and "svn log" as well.
> > >>
> > >> Then just "--smart", maybe?
> > >>
> > >> http://pink.bikeshed.com/
> > >
> > >"smart" doesn't give a nod to the fact that we're adhering to merge
> > >history.
> >
> > How about "--track-merge-history" or "--smart-merge-tracking" then?
> > These names are longer than "--merge-smart" and "--smart" but might
> > indicate the purpose of the flag a bit better.
>
> "--track-merge-history" is a perfect description for the use cases
> we're currently targeting, implemented via the following subcommands:
>
> blame
> log
> merge
>
> It's only 4 characters longer than "--merge-sensitive", and we have a
> short option ("-g"). Would anyone be adverse to switching, or does
> anyone have a better suggestion?
I think the problem is that ultimately the usage of this option in the
merge scenario is a little different than the others. That being
said, I am still in favor of trying to use one option.
I personally still prefer --merge-sensitive to the other propsals, but
do not feel strongly and agree it could be better. How about
--follow-merge-history or --use-merge-history instead of --track?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org