From: "David Jeske" <jeske@google.com>
To: Brandon Casey <casey@nrlssc.navy.mil>
Cc: git@vger.kernel.org
Subject: Re: why is git destructive by default? (i suggest it not be!)
Date: Tue, 24 Jun 2008 16:41:59 -0000 [thread overview]
Message-ID: <willow-jeske-01l5xqJDFEDjCftd> (raw)
In-Reply-To: <U-ySqQANiPRpld4kgzdXbovGgsj6LfOEdRmtTDU2yyvITSG3LnZAsQ@cipher.nrlssc.navy.mil>
My takeaways from this thread:
- THANKS! to all of you for the detailed discussion, and for making git. Even
though it's still unfamiliar to me, I really enjoy (g)it!
- I don't think anyone here thinks git is beyond improvement. This discussion
did change my mind on a few things since my original post. I started this
discussion to share my "unacclimated usability suggestions", because after I
acclimate to git, I'll be telling new users that these idiosyncrasies are all
no big deal too. :) I still think there is value in this list of suggestions.
I'll work on submitting patches...
- improve the man page description of "reset --hard" (see below)
- standardize all the potentially destructive operations (after gc) on "-f /
--force" to override
- add "checkout" to the git-gui history right-click menu, and make the danger
of
"reset --hard" more obvious and require a confirmation dialog (the gui
equivilant of -f)
----------
a couple more specific responses below..
-- Rogan Dawes wrote:
> -- David wrote:
> > Let me guess, you're always running euid==0. :)
> Do you also ask the gnu coreutils folks to remove the -f option from their
utilities?
-- Johannes Gilger wrote:
> I think the name of the command "reset" itself is a name which should
> prompt everyone to read a manpage before using it. [snip ]
> Nobody complains about rm --force or anything.
Isn't it nice that they standardized on "-f" and "--force" across ALL commands?
I would be inclined to talk to coreutils if it was "rm -f", "cp -R" (vs cp -r),
and "mv --aggressive" to do the respective non-safe versions.
It would simplify git's command-line-ui and cognitive load if it did the same
thing. Pick one standard for "overriding dangerous commands", instead of
"danger caps" and "danger --reset" and "danger -f". Consider branch which has
both "branch -[MD]" and "branch -f" in the same subcommand. What's wrong with
"branch -[md] -f"?
Of course --hard encourages one to read the manpage. However, git is using a
bunch of new terms for things, and uses at least those three different methods
to indicate command danger. Lets look at the working on the manpage:
"Matches the working tree and index to that of the tree being
switched
to. Any changes to tracked files in the working tree since <commit>
are lost."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I interpreted this as "any [non committed changes] to tracked files in the
working tree since <commit> are lost." I don't this this was a naive
interpretation. I still think that's the way it reads after this whole
conversation.
I'll work on my first patch for git:
-> "References to any working tree changes, and pulled changes, AND COMMITTED
CHANGES to tracked files in the branch after <commit> will be dropped, causing
them to be removed at the next garbage collect.".
-- Brandon Casey wrote:
> After saying all of that, here is how I think you _should_ have done things.
> Notice I _did_not_ use 'reset --hard'.
I was told that I can safely do "git checkout origin/master" instead of "reset
--hard" to get back to the pull point, in case I didn't branch ahead of time.
The wrinkle being that my "master" branch-pointer still points to my local
changes, so I need to move onto a different branchname before I push if I want
to avoid those changes going to the server, which is fine..
> git clone <master_repo>
> cd master_repo
> git checkout -b feature1 # we create our feature branch immediately since
> # creating branches is so effortless in git. A
> # private feature branch should _always_ be created
> # and used for development.
I'm beginning to see why I would always work this way, though if "private
feature branches should always be created and used for development", then I'm
unclear about why this isn't the default. git could implicitly create them when
I checkin a change on the head of a pulled branch. (i.e. user/branchname/id, or
something else). I'm reaching here, I'll need to use git more with other
developers to understand this better.
-------------------
Thanks again for all the detailed responses and explanations!
- David
next prev parent reply other threads:[~2008-06-24 17:46 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l5PFjPFEDjCfzf-01l5oEswFEDjCZBN>
[not found] ` <willow-jeske-01l5oEsvFEDjCjRW>
2008-06-24 10:42 ` why is git destructive by default? (i suggest it not be!) David Jeske
2008-06-24 10:42 ` David Jeske
2008-06-24 15:29 ` Brandon Casey
2008-06-24 16:41 ` David Jeske
2008-06-24 16:41 ` David Jeske [this message]
2008-06-24 18:55 ` Brandon Casey
2008-06-25 12:20 ` Matthieu Moy
2008-06-25 17:56 ` Jing Xue
2008-06-25 18:06 Dmitry Potapov
-- strict thread matches above, loose matches on Subject: below --
2008-06-24 12:21 Olivier Galibert
2008-06-24 8:35 Björn Steinbrink
2008-06-24 4:59 Teemu Likonen
[not found] ` <e80d075a0806232201o3933d154he2b570986604c30a@mail.gmail.com>
2008-06-24 5:43 ` Teemu Likonen
[not found] <willow-jeske-01l5PFjPFEDjCfzf-01l5V7wbFEDjCX7V>
[not found] ` <jeske@willow=01l5V7waFEDjChmh>
2008-06-24 1:47 ` David Jeske
2008-06-24 1:47 ` David Jeske
2008-06-24 17:11 ` Boaz Harrosh
2008-06-24 17:19 ` Boaz Harrosh
2008-06-24 19:08 ` Jakub Narebski
2008-06-24 20:04 ` David Jeske
2008-06-24 20:04 ` David Jeske
2008-06-24 21:42 ` Brandon Casey
2008-06-24 22:13 ` David Jeske
2008-06-24 22:13 ` David Jeske
2008-06-24 22:54 ` Theodore Tso
2008-06-24 23:07 ` Junio C Hamano
2008-06-25 2:26 ` Theodore Tso
2008-06-25 8:58 ` Jakub Narebski
2008-06-25 9:14 ` Junio C Hamano
2008-06-26 15:13 ` Brandon Casey
2008-06-24 22:21 ` Steven Walter
2008-06-25 8:57 ` Boaz Harrosh
2008-06-24 18:18 ` Brandon Casey
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5V7wbFEDjCX7V@videotron.ca>
[not found] ` <willow-jeske-01l5cKsCFEDjC=91MX@videotron.ca>
2008-06-24 2:17 ` Nicolas Pitre
2008-06-24 3:18 ` David Jeske
2008-06-24 3:18 ` David Jeske
2008-06-24 8:14 ` Lea Wiemann
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5ciVtFEDjCaD9@videotron.ca>
[not found] ` <willow-jeske-01l5e9cgFEDjCh3F@videotron.ca>
2008-06-24 4:03 ` Nicolas Pitre
2008-06-24 4:40 ` David Jeske
2008-06-24 4:40 ` David Jeske
2008-06-24 5:24 ` Jan Krüger
[not found] ` <1978205964779154253@unknownmsgid>
2008-06-24 5:20 ` Avery Pennarun
2008-06-24 6:35 ` David Jeske
2008-06-24 7:24 ` Jeff King
2008-06-24 7:31 ` David Jeske
2008-06-24 8:16 ` Jeff King
2008-06-24 8:30 ` David Jeske
2008-06-24 9:39 ` Jakub Narebski
2008-06-24 8:30 ` David Jeske
[not found] ` <willow-jeske-01l5PFjPFEDjCfzf-01l5kv6TFEDjCj8S@brm-avmta-1.central.sun.com>
[not found] ` <willow-jeske-01l5lTEoFEDjCVta@brm-avmta-1.central.sun.com>
2008-06-24 10:01 ` Fedor Sergeev
2008-06-24 10:24 ` David Jeske
2008-06-24 13:13 ` Theodore Tso
2008-06-24 7:31 ` David Jeske
2008-06-24 6:35 ` David Jeske
2008-06-24 7:54 ` Jakub Narebski
2008-06-24 8:08 ` David Jeske
2008-06-24 11:22 ` Jakub Narebski
2008-06-24 11:29 ` David Jeske
2008-06-24 12:19 ` Rogan Dawes
2008-06-24 12:35 ` Johannes Gilger
2008-06-24 12:46 ` Rogan Dawes
2008-06-24 11:29 ` David Jeske
2008-06-24 12:21 ` Jakub Narebski
2008-06-24 12:13 ` Jakub Narebski
2008-06-24 8:08 ` David Jeske
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=willow-jeske-01l5xqJDFEDjCftd \
--to=jeske@google.com \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
/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