Git development
 help / color / mirror / Atom feed
From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Elijah Newren <newren@gmail.com>
Cc: Scott Chacon <schacon@gmail.com>, git list <git@vger.kernel.org>
Subject: Re: EasyGit Integration
Date: Tue, 9 Jun 2009 23:18:06 +0200	[thread overview]
Message-ID: <20090609211806.GC13781@atjola.homenet> (raw)
In-Reply-To: <51419b2c0906091340i11965efcr5cf5bb4a71108fa6@mail.gmail.com>

On 2009.06.09 14:40:33 -0600, Elijah Newren wrote:
> Hi,
> 
> 2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
> >> * breaks the various things that 'checkout' does into separate
> >> commands - moves 'revert' to doing what 'checkout -- path' does
> >
> > Looking through the "eg revert" docs [1], I can't seem to find how you can
> > do "checkout -- path" with it at all. "eg revert foo" seems to be "git
> > checkout HEAD -- foo".
> 
> If you want to revert only the unstaged changes to path:
>   "checkout -- path" OR "revert --unstaged path"
> If you want to revert both staged and unstaged changes to foo:
>   "checkout HEAD -- foo" OR "revert foo"

OK, so --unstaged doesn't just select the destination, but also the
source, unless you explicitly override it, right?

eg revert [--since HEAD] path
  ==> source: HEAD, destination: working tree, index

eg revert --unstaged path
  ==> source: index, destination: working tree

eg revert --unstaged --since HEAD path
  ==> source: HEAD, destination: working tree


> 
> > The "eg revert" looks really confusing to me.
> > "eg revert --unstaged --in HEAD~8". Hu? Revert unstaged changes in
> > HEAD~8? Am I missing something?
> 
> Hmm.  Bad ordering, I guess -- it's revert changes in HEAD~8 to the
> working copy only (by default, revert tries to apply changes to both
> the working copy and the index).  Yeah, it doesn't read very well.
> 
> I'm not sure I like having "--in" as part of revert, partially because
> of this confusion (and partially because I don't think it's
> implementation is correct anyway).  However, I do occasionally really
> like being able to revert the change _to a single file_ made in some
> previous commit, so I haven't removed it from eg (yet?).  *shrug*

I'm not sure that "--in" is the worst thing here. To me, --unstaged is
worse, because I apply the attribute "unstaged" to the changes to be
reverted. And that makes no sense when I supply a commit, a commit
cannot have unstaged changes. I guess that if --unstaged wasn't used to
select the destination, I might have come up with "eg revert --unstaged"
myself, just from seeing the options. But seeing that --unstaged can be
used with a commit confused me.

Björn

  reply	other threads:[~2009-06-09 21:18 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09 18:59 EasyGit Integration Scott Chacon
2009-06-09 19:43 ` Nicolas Pitre
2009-06-09 19:52 ` Avery Pennarun
2009-06-09 20:37   ` Björn Steinbrink
2009-06-09 20:42     ` Avery Pennarun
2009-06-10 12:13       ` Björn Steinbrink
2009-06-09 20:49     ` Elijah Newren
2009-06-10  1:09   ` Miles Bader
2009-06-09 20:12 ` Björn Steinbrink
2009-06-09 20:40   ` Elijah Newren
2009-06-09 21:18     ` Björn Steinbrink [this message]
2009-06-09 21:27 ` Björn Steinbrink
2009-06-09 21:36   ` Junio C Hamano
2009-06-09 21:48   ` Elijah Newren
2009-06-09 22:00 ` Elijah Newren
2009-06-10 12:52   ` Matthieu Moy
2009-06-09 22:14 ` Linus Torvalds
2009-06-09 22:30   ` Elijah Newren
2009-06-09 22:40     ` Linus Torvalds
2009-06-10  0:40       ` Mark Lodato
2009-06-10  3:11       ` Miles Bader
2009-06-10  3:32       ` Theodore Tso
2009-06-10  4:03         ` Linus Torvalds
2009-06-10 22:31           ` Felipe Contreras
2009-06-10 23:04             ` Linus Torvalds
2009-06-10 23:57               ` Scott Chacon
2009-06-11  0:15                 ` Jakub Narebski
2009-06-11  0:30                   ` Felipe Contreras
2009-06-11  0:42                     ` Jakub Narebski
2009-06-12 20:57                       ` Felipe Contreras
2009-06-12 21:21                         ` Jakub Narebski
2009-06-12 21:48                           ` Felipe Contreras
2009-06-12 22:05                             ` Jakub Narebski
2009-06-12 22:30                               ` Felipe Contreras
2009-06-13  1:24                                 ` Björn Steinbrink
2009-06-11  0:18               ` Felipe Contreras
2009-06-10  4:20         ` Elijah Newren
2009-06-10 14:40       ` Matthieu Moy
2009-06-10  1:25   ` Sam Vilain
2009-06-10  1:59     ` Linus Torvalds
2009-06-10  2:18     ` Junio C Hamano
2009-06-10  2:52       ` Sam Vilain
2009-06-10  6:43         ` Jakub Narebski
2009-06-10  3:27       ` Nicolas Pitre
2009-06-10 20:47         ` Junio C Hamano
2009-06-10 22:28           ` Elijah Newren
2009-06-10 16:48       ` Scott Chacon
2009-06-10 22:15       ` Felipe Contreras
2009-06-10 22:04 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090609211806.GC13781@atjola.homenet \
    --to=b.steinbrink@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=schacon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox