Conrad Irwin writes:
> -i::
> --include::
> - Before making a commit out of staged contents so far,
> - stage the contents of paths given on the command line
> - as well. This is usually not what you want unless you
> - are concluding a conflicted merge.
> + In addition to
On Sat, Oct 6, 2012 at 12:07 PM, Jeff King wrote:
> Are you sure? Does "--only" mean "only the changes I am about to mark"
> or "only the paths I am about to tell you about"? Without partial hunk
> selection (i.e., "commit -p"), they were the same; a path you mention is
> a path which will be eit
On Sun, Oct 07, 2012 at 03:23:31PM -0700, Junio C Hamano wrote:
> >> Yeah, I agree with the reasoning. This is an unessential feature
> >> that is with the problem for a long time, so let's go the route #1
> >> first before we do anything else.
> >
> > OK. I think Conrad's patch takes us most of
Jeff King writes:
> On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Which is obviously one of:
>> >
>> > 1. Keep defaulting to "--include", as that is what we have been doing.
>> >
>> > 2. Forbid the cases where it would matter (i.e., when the
On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes. The more we talk about it, the more turned off I am by the idea.
> > Above I posed my questions as "what _should_ we do when...". And I still
> > think we _should_ default to --only with interactive, i
Jeff King writes:
> Yes. The more we talk about it, the more turned off I am by the idea.
> Above I posed my questions as "what _should_ we do when...". And I still
> think we _should_ default to --only with interactive, if we can find
> sane semantics. But until we can find them, it obviously do
On Sat, Oct 06, 2012 at 11:32:51AM -0700, Conrad Irwin wrote:
> I think I messed up sending somehow:
Thanks for resending.
> > What state should the "add -p" interaction start from for path F?
> > Should you be picking from a patch between the state you previously
> > "git add"ed to the index an
I think I messed up sending somehow:
On Fri, Oct 5, 2012 at 11:26 PM, Junio C Hamano wrote:
> Suppose you have two paths E and F, both of which have differences
> between HEAD and the index, and the index and the working tree file
> (i.e. you earlier edited E and F, did "git add E F" and further
On Sat, Oct 06, 2012 at 11:22:50AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Another option is to leave it with "-i" semantics in the meantime, which
> > are at least easy to explain: it is simply a shorthand for running "git
> > add -p && git commit". That may be inconsistent with
Jeff King writes:
> Another option is to leave it with "-i" semantics in the meantime, which
> are at least easy to explain: it is simply a shorthand for running "git
> add -p && git commit". That may be inconsistent with other aspects of
> commit, but people have (apparently) been happy with it,
On Fri, Oct 05, 2012 at 11:26:47PM -0700, Junio C Hamano wrote:
> In the case of "add/commit --interactive", it is much more clear
> what state the index is in when the command gave interactive control
> to the user. The short-cut "add/commit -p" interface, however, does
> not give you an access
Jeff King writes:
> Actually, I am not sure that thread or feature is to blame. Certainly it
> would have been an opportune time to notice the problem. But this issue
> goes back much further for "git commit --interactive", which has always
> assumed "-i" rather than "-o". This even predates the
On Fri, Oct 05, 2012 at 03:29:10PM -0700, Junio C Hamano wrote:
> Assuming that the last step of what Horst did was "git commit -pm",
> I think Git is wrong in this case. When you tell "git commit" what
> to commit, unless you give "-i" (aka "also") option, the command
> makes a commit to record
"Frans Klaver" writes:
> On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
> wrote:
>
>> What I did:
>>
>> - New file images/coins.asy ~~-> 'git add images/coins.asy'
>> - Started adding new stuff to fg.tex
>> - Noticed a old bug in fg.tex, fixed that one
>> - Did 'git -pm "Some message"' a
On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand
wrote:
What I did:
- New file images/coins.asy ~~-> 'git add images/coins.asy'
- Started adding new stuff to fg.tex
- Noticed a old bug in fg.tex, fixed that one
- Did 'git -pm "Some message"' and selected just the bugfix
But git create
What I did:
- New file images/coins.asy ~~-> 'git add images/coins.asy'
- Started adding new stuff to fg.tex
- Noticed a old bug in fg.tex, fixed that one
- Did 'git -pm "Some message"' and selected just the bugfix
But git created a commit _including_ the new file. Tried to go back:
- 'git reset
16 matches
Mail list logo
