From: Javier Domingo Cansino <javierdo1@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: Re: What is missing from Git v2.0
Date: Fri, 25 Apr 2014 04:22:23 +0200 [thread overview]
Message-ID: <CALZVapn0gEHc7t2fjk7YGd2o0yfpGLu0JCgUtdREvROC8_mqXg@mail.gmail.com> (raw)
In-Reply-To: <20140424195559.GA1336@luc-arch>
Felipe's
=======
= The publish tracking branch =
I still have problems getting upstream branches correctly configured
as to have this introduced, anyway, I suppose it's optional, so
nothing to add on that.
By the way, remote branch managing has improved a lot, one of the
best things I see for branching and remotes is the "git remote show"
command, but I think further work should be done. Help messages FTW!
= Reject non-fast-forward pulls by default =
Not having this introduced yet allows newbie people to use git with
just 4 commands, without bothering around with fetch and merge and so.
= Use "stage" instead of "index" =
Totally agree with this.
= Default aliases =
I hate aliases, make scripts more difficult to read and understand. I
would instead try to improve knowledge on this feature. I have to
agree with David Lang's first message, and
The cherry-pick => pick thing would be the only thing I would see with
good eyes, just because it's too long and has a dash.
Juno's
======
The idea about ~/.gitconfig seems incredible simple and effective to
me. I would however try to keep it simple, and minimize the form.
Mine
====
I have taught (or tried to) a lot of people Git. And this is some of
the stuff I have seen they have difficulties with:
- Remembering the commands, for example, remembering add, commit push
and pull, which I think we can all agree is the most core and simple
combination of Git commands.
- What command comes for what they need. If I want to share
everything, what should I do?
- Most of them, have real difficulties on remembering the flows. There
are too many commands for the start.
I wouldn't nevertheless suppress any of them, I would rather do a tuto
on-the-go.
Here are some ideas I have thought of:
== Command Output==
At the moment, there are several commands that don't output any help
text, and many others, that although they have become more verbose
with the years, they aren't too verbose yet.
One of the things I most recommend to anyone is to run "git status"
just before any command (push, commit, add, etc.) to get sure they are
doing what they thing they will.
For example, running git add won't tell you what you just added, nor
what you could do now. I would put some output there, maybe the git
status output or something similar that helps the user to know what
just happened.
Git status doesn't say much about remotes, and suggesting pushing if a
remote is outdated, would be fantastic.
Checkout command has decreased verbosity from a previous version,
where it stated which branch it came from and to which branch it was
switching to.
As an extreme thing, I would consider adding a configuration parameter
default, core.helptext=True that could switch off all this stuff.
==Running git==
This is a very basic idea, and I suppose it isn't too helpful or
realistic, but might give someone an idea.
I would first make that running git, just git, tell the user the
possibilities he has. I don't know of any power user that uses git to
remember the commands. At the moment, git[1] just tells many of the
commands available, without any classification, maybe classifying them
as "commiting" "branching" and "remote" could help a little.
Regards,
Javier Domingo Cansino
[1] git output:
----------------------------------------------------
javier@frodo:~$ git
usage: git [--version] [--help] [-C <path>] [-c name=value]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
grep Print lines matching a pattern
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
rebase Forward-port local commits to the updated upstream head
reset Reset current HEAD to the specified state
rm Remove files from the working tree and from the index
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify a tag object signed with GPG
'git help -a' and 'git help -g' lists available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
----------------------------------------------------
next prev parent reply other threads:[~2014-04-25 2:22 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-20 22:41 What is missing from Git v2.0 Felipe Contreras
2014-04-20 22:47 ` Felipe Contreras
2014-04-21 19:24 ` Sebastian Schuberth
2014-04-21 19:34 ` Felipe Contreras
2014-04-21 19:47 ` Sebastian Schuberth
2014-04-21 20:45 ` Theodore Ts'o
2014-04-21 20:46 ` Felipe Contreras
2014-04-22 7:23 ` Sebastian Schuberth
2014-04-22 8:15 ` Felipe Contreras
2014-04-21 19:39 ` Junio C Hamano
2014-04-22 7:19 ` Sebastian Schuberth
2014-04-22 8:11 ` Felipe Contreras
2014-04-22 18:33 ` Junio C Hamano
2014-04-22 19:23 ` Felipe Contreras
2014-04-22 20:22 ` Matthieu Moy
2014-04-22 21:01 ` Felipe Contreras
2014-04-22 22:19 ` Junio C Hamano
2014-04-22 21:30 ` Theodore Ts'o
2014-04-22 21:59 ` Felipe Contreras
2014-04-22 22:24 ` David Kastrup
2014-04-24 3:35 ` Felipe Contreras
2014-04-24 5:18 ` David Kastrup
2014-04-24 13:39 ` Andreas Krey
2014-04-24 18:31 ` Felipe Contreras
2014-04-24 19:16 ` David Kastrup
2014-04-22 22:25 ` David Lang
2014-04-24 3:37 ` Felipe Contreras
2014-04-24 3:51 ` David Lang
2014-04-24 3:58 ` Felipe Contreras
2014-04-24 4:16 ` James Denholm
2014-04-24 4:12 ` Felipe Contreras
2014-04-24 6:06 ` James Denholm
2014-04-24 7:19 ` Felipe Contreras
2014-04-24 7:39 ` David Kastrup
2014-04-24 8:23 ` Felipe Contreras
2014-04-24 9:01 ` David Kastrup
2014-04-24 18:28 ` Felipe Contreras
2014-04-24 19:20 ` David Lang
2014-04-24 13:41 ` Theodore Ts'o
2014-04-24 15:00 ` Stefan Beller
2014-04-24 15:47 ` tytso
2014-04-24 17:46 ` Stefan Beller
2014-04-24 18:02 ` Jonathan Nieder
2014-04-24 18:26 ` Felipe Contreras
2014-04-24 19:15 ` Jeff King
2014-04-24 18:25 ` Felipe Contreras
2014-04-24 18:17 ` Felipe Contreras
2014-04-25 6:59 ` Matthieu Moy
2014-04-25 7:35 ` Philippe Vaucher
2014-04-24 18:38 ` Felipe Contreras
2014-04-24 19:55 ` luc.linux
2014-04-25 2:22 ` Javier Domingo Cansino [this message]
2014-04-25 2:35 ` Felipe Contreras
2014-04-25 7:48 ` Philippe Vaucher
2014-04-25 7:52 ` Felipe Contreras
2014-04-25 13:35 ` Theodore Ts'o
2014-04-25 14:23 ` Philippe Vaucher
2014-04-25 14:40 ` Theodore Ts'o
2014-04-25 15:54 ` Philippe Vaucher
2014-04-25 17:50 ` Felipe Contreras
2014-04-25 17:45 ` Felipe Contreras
2014-04-25 18:24 ` Jeff King
2014-04-25 18:27 ` Felipe Contreras
2014-04-25 18:57 ` Jeff King
2014-04-25 18:57 ` Felipe Contreras
2014-04-25 19:12 ` Jeff King
2014-04-25 19:27 ` Felipe Contreras
2014-04-25 5:13 ` David Kastrup
2014-04-25 15:41 ` Jonathan Nieder
2014-04-25 15:59 ` David Kastrup
2014-04-25 16:14 ` Jonathan Nieder
2014-04-22 22:03 ` Junio C Hamano
2014-04-24 3:26 ` Felipe Contreras
2014-04-22 2:12 ` brian m. carlson
2014-04-22 5:10 ` Felipe Contreras
2014-04-22 5:19 ` David Aguilar
2014-04-22 5:38 ` 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=CALZVapn0gEHc7t2fjk7YGd2o0yfpGLu0JCgUtdREvROC8_mqXg@mail.gmail.com \
--to=javierdo1@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).