On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: > W. Trevor King wrote: > > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: > > > W. Trevor King wrote: > > > > Fast-forward $current_branch by $count commits to $repository > > > > $refpec? > > > > > > Why would anyone say 'no' to this one? > > > > Because the want explicit merges when they bring in topic > > branches? > > If that was the case the user wouls have run `git merge > --no-ff`. Only expereinced users would answer 'no'. Folks who are setting any ff options don't need any of these training wheels. My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” > > > > and have a chance to bail out if you saw: > > > > > > > > Merge 1003 commits from git://example.net/main.git master into my-feature? > > > > > > > > because you forgot which branch you were on. > > > > > > Yes, that might be nice. But we still need to change the defaults. > > > > So I should submit an orthogonal patch with -i/--interative/--prompt? > > I'm not entirely sure what would be the ideal behavior. > > For example, I'm thinking that by default when the a fast-forward is > possible, just do it, … But just because a ff is possible doesn't mean it's what the user/project wants. It may be the most likely guess, but why guess when they've explicitly asked for a prompt? > when it's not, ask if the user wants to do a merge or a rebase, if > the user just press 'enter' a merge is attempted. I'll just mimic however mergetool currently handles prompt accept/decline. > In addition a summary of the commits ahead behind would be helpful. Good idea. > If the user wants to cancel the operation, he can just do CTRL+C. I'll just mimic mergetool. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature