From: "David A. Wheeler" <dwheeler@dwheeler•com>
To: Petr Baudis <pasky@ucw•cz>
Cc: git@vger•kernel.org
Subject: Re: Cogito nit: cg-update should default to "origin".
Date: Wed, 27 Apr 2005 23:57:48 -0400 [thread overview]
Message-ID: <42705F3C.1000208@dwheeler.com> (raw)
In-Reply-To: <20050428005337.GA3422@pasky.ji.cz>
I said:
>>Minor nit on Cogito: I think cg-update should default to "origin",
>>not the head, if you leave it unspecified. ... The origin seems (to me)
>>to be a MUCH more common situation (and thus the better default).
Petr Baudis replied:
> Actually, I wasn't too happy with the current update-to-HEAD special
> case...
Sounds like we're in agreement! Once the special case goes
away, cg-update in both concept & code essentially becomes:
cg-pull ${1:-origin} && cg-merge
which has the wonderful advantage of being really, really
easy to explain. ("cg-update ALWAYS pulls, then merges").
> I think people do this cg-update without arguments so seldom
> that changing this now shouldn't hurt much, right?
Absolutely! Indeed, I find myself doing:
cg-update {wait for something to happen} {oops} cg-update origin
> What about moving this special case
> to something like
> cg-restore
> and changing the defaulting of update and pull back to 'origin'?
...
> Another thing is to UI-wise maintain clear difference between cg-cancel
> and cg-restore. Do you think the names are distinctive enough? Any
> better naming ideas?
Good names for these operations seem to be tough to find.
"cg-cancel" seems odd anyway; you'd think you could
"cancel" a commit and then the commit would stop existing
(not true!).
I looked at a thesaurus; other options to cancel & restore
include: revert, recover, retrieve, reclaim, reclaim, undo.
You could even use the names cg-recover-deleted to recover
deleted files (what cg-update does now without parameters),
and use cg-cancel-edits or cg-cancel-changes to make
clearer commands. But in the end I have a different idea, hold on...
elsewhere Dan Holmsand said:
>How about making the restore thing a special case of cg-cancel instead?
>"Restore deleted files", and "restore deleted and modified files and
>unseek" are similar enough that people will now where to look.
>Something like "cg-cancel -C" (for careful), that only restores deleted
>files would do it, I think.
There's a big risk of not including the "-C" and suddenly losing
everthing. Since there's NO way to recover these files,
a somewhat safer interface would probably be a better idea.
But merging the concepts may make sense if we can find a single
command name that would help people figure this out.
How about "cg-revert" or "cg-restore"? The word "revert" is even
in the comments for cg-cancel, but now it makes sense to "revert"
or "restore" the existence of a file (whereas it's really odd
to "cancel" a file deletion).
A serious problem with cg-cancel (and previous cg-undo) is
big data loss, no recovery, of your recent work.... if it's
going to have less & more drastic operations, I'd sure hate
for the drastic operation to be the default. There's also
missing functionality currently: often I want to revert to the
unedited state for just a single file, or just restore a single file.
So, how about this:
cg-revert [FILE...] or
cg-revert [-d|--deleted]|[-a|--all]
Reverts some/all files back to the HEAD's state, eliminating changes
If given a list of 1 or more files, this reverts just the named files
to the HEAD state. If they were deleted, they are restored;
if they were edited, their edits are PERMANENTLY LOST.
If they haven't changed, nothing changes and there is no error.
If given -d or --deleted, it reverts all deleted files.
If given -a or --all, it reverts all files
(everything), resuling in loss of all edits and removals.
How's that for a reasonable UI, replacing both cg-cancel
and cg-update's current no-parameter functionality?
--- David A. Wheeler
next prev parent reply other threads:[~2005-04-28 3:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-27 4:43 I'm missing isofs.h Andrew Morton
2005-04-27 12:58 ` Jan Harkes
2005-04-27 13:58 ` Petr Baudis
2005-04-27 16:43 ` Jan Harkes
2005-04-27 16:45 ` Jan Harkes
2005-04-27 15:31 ` Steven Cole
2005-04-27 17:40 ` Steven Cole
2005-04-27 23:51 ` Petr Baudis
2005-04-28 0:19 ` Linus Torvalds
2005-04-28 0:32 ` Petr Baudis
2005-04-28 2:02 ` Junio C Hamano
2005-04-28 5:27 ` Junio C Hamano
2005-04-28 6:28 ` [PATCH] Make diff-cache and friends output more cg-patch friendly Junio C Hamano
2005-04-28 7:52 ` I'm missing isofs.h Petr Baudis
2005-04-28 23:39 ` David A. Wheeler
2005-04-28 14:42 ` Linus Torvalds
2005-04-28 16:11 ` Junio C Hamano
2005-04-28 16:28 ` Linus Torvalds
2005-04-28 0:32 ` Cogito nit: cg-update should default to "origin" David A. Wheeler
2005-04-28 0:53 ` Petr Baudis
2005-04-28 1:52 ` Dan Holmsand
2005-04-28 3:57 ` David A. Wheeler [this message]
2005-04-28 8:22 ` Dan Holmsand
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=42705F3C.1000208@dwheeler.com \
--to=dwheeler@dwheeler$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=pasky@ucw$(echo .)cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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