Junio C Hamano writes: > I do not think so. --no-progress should imply --no-cr ;-) > > I do not think it makes much sense to pollute your non-terminal with 100 > lines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns. It > may be another knob to tweak, but it's a kind of thing you implement > because you could, not because it makes sense. I would be mildly against > no-cr. Good point. I'll drop the --no-cr as redundant. Johannes Schindelin writes: > Hi, > > On Fri, 23 Jan 2009, Brent Goodrick wrote: > > > - Bare minimum: Add a new --no-cr option > > I do not see any value of this over "--progress | tr '\r' '\n'". (The > --progress option being the natural counterpart to --no-progress, > _forcing_ the display of the progress.) Agreed. Both --progress and --no-progress are the only options to be implemented for this. > Just have a > look at 7d1864c(Introduce is_bare_repository() and core.bare configuration > variable). Note that I'm coming from a CVS and Perforce user background but am still new to git usage. How do I "take a look" at "7d1864c"? I will take a closer look at the list of things you explained in your "Basically, you'll have to" list. While I'm at it, what is the standard procedure for submitting git patches for review once I've cooked up and validated it on my end? I'm guessing posting the patch into this mailing list is part of the answer to that question. Thanks, Brent -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
