From: David Kastrup <hidden> Date: 2016-06-15 23:00:48
Felipe Contreras [off-list ref] writes:
James Denholm wrote:
quoted
Felipe Contreras wrote:
quoted
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power users either.
Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
two groups (I suggest) are the most immediately relevant - one calls for
change, and the other would be negatively impacted.
Nobody would be negatively impacted. Who would be impacted negatively
by having default aliases?
The people having to read and understand scripts written in the
expectation of default aliases.
And I have showed they are not problems.
You managed to convince yourself, so feel free to put aliases in every
Git you use and distribute.
--
David Kastrup
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:48
David Kastrup wrote:
Felipe Contreras [off-list ref] writes:
quoted
James Denholm wrote:
quoted
Felipe Contreras wrote:
quoted
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power users either.
Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
two groups (I suggest) are the most immediately relevant - one calls for
change, and the other would be negatively impacted.
Nobody would be negatively impacted. Who would be impacted negatively
by having default aliases?
The people having to read and understand scripts written in the
expectation of default aliases.
Which are imaginary.
quoted
And I have showed they are not problems.
You managed to convince yourself, so feel free to put aliases in every
Git you use and distribute.
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
--
Felipe Contreras
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
Felipe,
It's clear that you've not been able to produce evidence that can
convince most of the people on this thread. Simply repeating the same
assertions over and over again, in a shrill fashion, is not likely to
convince those of us who that this would not be a good idea for git
v2.0.
Creating a ~/.gitconfig file if one doesn't already is one I agree
with, and at least on Unix systems, telling them that the config file
lives in ~/.gitconfig, or where ever it might happen to be on other
platforms, is a good one. If it's in some really weird place on
Windows, then sure, we can tell them about "git config -e". But the
point is to let the user look at the default .gitconfig file, where we
can put in comments to help explain what is going on, and perhaps have
links to web pages for more information.
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
We can just tell the user that we have created a default .gitconfig
file, and tell them how they can take a look at it.
In the long term, if the worry is how to bridge the gap between
complete newbies, one way of dealing with this is to have a tutorial
mode (off by default, on in the default .gitconfig) which despenses
some helpful hints at certain strategic points (i.e., after five
commits, give a message that introduces git log --oneline, after the
third merge commit is created by the user, give a message which
introduces git log --merge, and so on). The challenge is not strawing
over the line to the point where the hints become as annoying as
"clippy", but that is what UX labs are for, to tune the experience for
completely new users to git.
Without doing a formal UX experiment, all of us are going to making
assertions without formal evidence --- at best some of us who have
tutored a few newbies might have some anecdates, but remember the old
saying about the plural of anecdote not being data.
Cheers,
- Ted
From: Stefan Beller <hidden> Date: 2016-06-15 23:00:49
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)
2014-04-24 15:41 GMT+02:00 Theodore Ts'o [off-list ref]:
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
quoted
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
Felipe,
It's clear that you've not been able to produce evidence that can
convince most of the people on this thread. Simply repeating the same
assertions over and over again, in a shrill fashion, is not likely to
convince those of us who that this would not be a good idea for git
v2.0.
Creating a ~/.gitconfig file if one doesn't already is one I agree
with, and at least on Unix systems, telling them that the config file
lives in ~/.gitconfig, or where ever it might happen to be on other
platforms, is a good one. If it's in some really weird place on
Windows, then sure, we can tell them about "git config -e". But the
point is to let the user look at the default .gitconfig file, where we
can put in comments to help explain what is going on, and perhaps have
links to web pages for more information.
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
We can just tell the user that we have created a default .gitconfig
file, and tell them how they can take a look at it.
In the long term, if the worry is how to bridge the gap between
complete newbies, one way of dealing with this is to have a tutorial
mode (off by default, on in the default .gitconfig) which despenses
some helpful hints at certain strategic points (i.e., after five
commits, give a message that introduces git log --oneline, after the
third merge commit is created by the user, give a message which
introduces git log --merge, and so on). The challenge is not strawing
over the line to the point where the hints become as annoying as
"clippy", but that is what UX labs are for, to tune the experience for
completely new users to git.
Without doing a formal UX experiment, all of us are going to making
assertions without formal evidence --- at best some of us who have
tutored a few newbies might have some anecdates, but remember the old
saying about the plural of anecdote not being data.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
quoted
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)
But that's no worse than what we have today. What if we print what
the defaults were, which might help encourage the user to actually run
the "git config -e" command?
- Ted
From: Stefan Beller <hidden> Date: 2016-06-15 23:00:49
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=[off-list ref]"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
2014-04-24 17:47 GMT+02:00 [off-list ref]:
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
quoted
quoted
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)
But that's no worse than what we have today. What if we print what
the defaults were, which might help encourage the user to actually run
the "git config -e" command?
- Ted
From: Jonathan Nieder <hidden> Date: 2016-06-15 23:00:49
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=[off-list ref]"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
Not true. But you do get a big wall of text when you make your
first commit without an EMAIL envvar or configured [user] section,
including
| You can suppress this message by setting them explicitly:
|
| git config --global user.name "Your Name"
| git config --global user.email you@example.com
|
| After doing this, you may fix the identity used for this commit with:
|
| git commit --amend --reset-author
Ciao,
Jonathan
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
tytso@ wrote:
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
quoted
quoted
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)
But that's no worse than what we have today. What if we print what
the defaults were, which might help encourage the user to actually run
the "git config -e" command?
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=[off-list ref]"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
That's not true, that's only the case if you don't have a fully qualified
hostname, like 'localhost', but if you do, like localhost.redhat, then Git
assumes your email is user@localhost.redhat, and it's valid.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
Jonathan Nieder wrote:
Stefan Beller wrote:
quoted
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=[off-list ref]"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
Not true. But you do get a big wall of text when you make your
first commit without an EMAIL envvar or configured [user] section,
including
Only if you don't have a fully qualified hostname.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
Theodore Ts'o wrote:
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
quoted
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
It's clear that you've not been able to produce evidence that can
convince most of the people on this thread.
Which only proves you don't want to be convinced, no evidence could convince
you.
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Most systems don't have a configured $EMAIL, so those defautls would be wrong.
It's so evident that no evide could convince you that you don't even bothere to
answer my question:
Why does Mercurial, Bazaar, Subversion, CVS, and pretty much everything uses
aliases?
Since you are conveniently not answering, I'll answer for you:
Because such hypothetical problems wouldn't actually occur in reality with Git,
just like they don't occur in other tools.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 23:00:49
On Thu, Apr 24, 2014 at 01:26:33PM -0500, Felipe Contreras wrote:
Jonathan Nieder wrote:
quoted
Stefan Beller wrote:
quoted
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=[off-list ref]"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
Not true. But you do get a big wall of text when you make your
first commit without an EMAIL envvar or configured [user] section,
including
Only if you don't have a fully qualified hostname.
No, we alway warn if the values weren't explicitly provided:
$ git config --global --unset user.email
$ git commit --allow-empty -m foo
[master 1e987ba] foo
Committer: Jeff King [off-list ref]
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name "Your Name"
git config --global user.email you@example.com
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
but we will consider several sources explicit, like
$GIT_COMMITTER_EMAIL, $EMAIL, and of course user.email:
$ EMAIL=whatever@example.com git commit --allow-empty -m foo
[master e75f17a] foo
We die when the values are implicitly derived from the system _and_ they
look bogus:
$ sudo rm /etc/mailname
$ sudo hostname bogus
$ git commit --allow-empty -m foo
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'peff@bogus.(none)')
-Peff
On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
Creating a ~/.gitconfig file if one doesn't already is one I agree
with, and at least on Unix systems, telling them that the config file
lives in ~/.gitconfig, or where ever it might happen to be on other
platforms, is a good one. If it's in some really weird place on
Windows, then sure, we can tell them about "git config -e". But the
point is to let the user look at the default .gitconfig file, where we
can put in comments to help explain what is going on, and perhaps have
links to web pages for more information.
I think the idea of a commented gitconfig is a good solution. We could
include default aliases commented, so that a new user would just have to
uncomment them. That way, he will understand they are aliases and not
commands, learn how to tune them to its own needs and it won't annoy
anyone because they will be commented by default, ideally with explicit
commentaries around them.
Furthermore, this could be a good way to show a new user all the
possibilities of git, or at least its configuration. Documentation is a
good thing when you know what you are looking for, but when you are
beginning, you don't know what can be done, and reading a complete and
commented example configuration could be a good way to discover it.
From: Javier Domingo Cansino <hidden> Date: 2016-06-15 23:00:49
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.
----------------------------------------------------
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
Javier Domingo Cansino wrote:
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.
I did so too, until I patch `git branch -v` to be useful.
= 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.
I don't understand what you are trying to say. There is no change for those
people, when the pull fails they would be told to use `git pull --merge` if not
sure.
= Use "stage" instead of "index" =
Totally agree with this.
= Default aliases =
I hate aliases, make scripts more difficult to read and understand.
You are assuming that everyone will start to use aliases in scripts, which is
not going to happen enough to be a problem.
Try to find svn or hg scripts with aliases, let's see how many you find.
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.
I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.
The real problem is that the core developers of Git don't acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.
--
Felipe Contreras
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:00:49
quoted
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.
Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)
Yes, try to guess a good default but let the user change it if he
wants to, and if he presses enter the default is used. It's not a big
deal to have to press enter a few times the first time you use git.
That or make a new "git setup" command which interactively sets up
your .gitconfig.
Philippe
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:00:49
I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.
I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
The real problem is that the core developers of Git don't acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.
I think most people agree with these interfaces issues but it's a hard
problem to solve, so they are reluctant to talk about it because they
fear the can of worm. If someone came with a good solution most people
would be willing to consider it.
I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.
Philippe
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:49
Philippe Vaucher wrote:
quoted
I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.
I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
The real problem is that the core developers of Git don't acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.
I think most people agree with these interfaces issues but it's a hard
problem to solve, so they are reluctant to talk about it because they
fear the can of worm. If someone came with a good solution most people
would be willing to consider it.
I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.
Yes, it would be good to document these issues, but it wouldn't matter if the
developers ignore them.
For example the move away from the 'index' name was backed up by literally
everyone, except Junio, so it doesn't matter if the issue is documented, and
there are patches with good solutions, if Junio thinks it's not an issue; it's
ignored.
--
Felipe Contreras
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
One caution: The term "stage/staged" is already a little overloaded.
We generally use the word "staged" to refer to changes that are in the
index, but the term "stage" as a noun generally refers to referencing
the different versions of a file during a merge operation (cf "git
ls-files --stage").
I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.
And it would be nice if the issues were discussed in a way that
acknowledged that all changes have tradeoffs, both positive and
negative, and to clearly articulate whether the concern is just
someone going "uh, 'index' is a wierd term", but once they learn it,
it's pretty clear, versus a case where there is continuous confusion
due to overloaded meanings, or for people for whom English might not
be the first language.
And most importantly, to avoid rheteroic. In fact, given that strong
use of rhetoric is often used to disguise a weakness of a position
that can't be defended using logic and data, someone who tries to win
arguments using the "last post wins" style of discourse, and a heavy
use of rhetoric, may find that people just simply decide that it's a
better use of their time not to engage and to just kill the entire
thread.
Regards,
- Ted
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:00:49
quoted
I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
One caution: The term "stage/staged" is already a little overloaded.
We generally use the word "staged" to refer to changes that are in the
index, but the term "stage" as a noun generally refers to referencing
the different versions of a file during a merge operation (cf "git
ls-files --stage").
I agree, but I think it's better than "index" tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.
quoted
I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.
And it would be nice if the issues were discussed in a way that
acknowledged that all changes have tradeoffs, both positive and
negative, and to clearly articulate whether the concern is just
someone going "uh, 'index' is a wierd term", but once they learn it,
it's pretty clear, versus a case where there is continuous confusion
due to overloaded meanings, or for people for whom English might not
be the first language.
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.
And most importantly, to avoid rheteroic. In fact, given that strong
use of rhetoric is often used to disguise a weakness of a position
that can't be defended using logic and data, someone who tries to win
arguments using the "last post wins" style of discourse, and a heavy
use of rhetoric, may find that people just simply decide that it's a
better use of their time not to engage and to just kill the entire
thread.
Unfortunately yes, I see many people being silly in order to win
arguments, both in the pro-changes and against-changes side of the
discussion. I'd be much simpler to simply gather arguments on some
wiki and eventually do a vote when the list is complete about the
proposed change.
Philippe
On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote:
I agree, but I think it's better than "index" tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.
There is a big difference between being used in a difference sense
than other software --- there is a one-time learning curve after which
point people can generally understand that a term in a given context
has a single meaning --- and when we have two very easily confused
terms (i.e., "stage versus staged") or a single identical term,
overloaded within a single context. So I'm much more worried about
the git documentation using the same term or two closely related terms
in an overloaded fashion, much more than I am with "index" meaning one
thing for databases, and another thing for book publishers, and yet
another for compilers.
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.
And renaming one of a term also has costs, especially if it is one
that is in use in large amounts of documentation, both in the git man
pages, and in web pages across the web.
And my plea for data extends even here. For example, things like
this:
www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q
Unfortunately yes, I see many people being silly in order to win
arguments, both in the pro-changes and against-changes side of the
discussion. I'd be much simpler to simply gather arguments on some
wiki and eventually do a vote when the list is complete about the
proposed change.
Voting is not a good way to do software development. That way lies
people wanting to whip up clueless folks using rhetoric (exhibit one:
Fox News) to "vote" and so it's not necessarily the best way to make
thoughtful decisions. Using hard data, including possibly formal UX
experiments, is a much better way to make such decisions.
Cheers,
- Ted
From: Philippe Vaucher <hidden> Date: 2016-06-15 23:00:49
quoted
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.
And renaming one of a term also has costs, especially if it is one
that is in use in large amounts of documentation, both in the git man
pages, and in web pages across the web.
It's just impossible to change terms and have previous documentation
still be valid. Sure, you can list it in the "cons" section as an
argument, but it's not very convincing in itself because it applies to
pretty much any interface changes. I think the main idea is to
_improve_ the interface, which means rename things so it is more
consistent and so concepts are easier for new comers to grasp. We
could still support old terms for a while and eventually deprecate
them.
Unfortunately yes, I see many people being silly in order to win
arguments, both in the pro-changes and against-changes side of the
discussion. I'd be much simpler to simply gather arguments on some
wiki and eventually do a vote when the list is complete about the
proposed change.
Voting is not a good way to do software development. That way lies
people wanting to whip up clueless folks using rhetoric (exhibit one:
Fox News) to "vote" and so it's not necessarily the best way to make
thoughtful decisions. Using hard data, including possibly formal UX
experiments, is a much better way to make such decisions.
Interesting, but then who's to say which data is more important than
anothers? For example, I consider improving the interface to be more
important than having old documentation on blogs/tutorial for a while
until people catch up, but maybe you consider old documentation to be
more important... who decides what really counts? I guess it's a mix
of general consensus and old timers credibility.
Anyway, having some data as a list of pros/cons would greatly simplify
the debate.
Philippe
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:50
Theodore Ts'o wrote:
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
quoted
I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
One caution: The term "stage/staged" is already a little overloaded.
We generally use the word "staged" to refer to changes that are in the
index, but the term "stage" as a noun generally refers to referencing
the different versions of a file during a merge operation (cf "git
ls-files --stage").
quoted
I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.
And it would be nice if the issues were discussed in a way that acknowledged
that all changes have tradeoffs, both positive and negative,
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:50
Philippe Vaucher wrote:
quoted
quoted
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.
And renaming one of a term also has costs, especially if it is one
that is in use in large amounts of documentation, both in the git man
pages, and in web pages across the web.
It's just impossible to change terms and have previous documentation
still be valid. Sure, you can list it in the "cons" section as an
argument, but it's not very convincing in itself because it applies to
pretty much any interface changes. I think the main idea is to
_improve_ the interface, which means rename things so it is more
consistent and so concepts are easier for new comers to grasp. We
could still support old terms for a while and eventually deprecate
them.
From: Jeff King <hidden> Date: 2016-06-15 23:00:50
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
When I say literally everbody agreed to move away from the name "index" (except
Junio and another guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.
With reference to my name, your email says:
Jeff King:
"staging area" makes perfect sense
But here's that statement in context[1]:
So the term "staging area" makes perfect sense to me; it is where we
collect changes to make a commit. I am willing to accept that does not
to others (native English speakers or no), and that we may need to
come up with a better term. But I think just calling it "the stage" is
even worse; it loses the concept that it is a place for collecting and
organizing.
In other words, I was saying that the term makes sense to me, and
primarily comparing favorably to a worse proposal. I am not commenting
at all on a plan to change names, which is what you are claiming above.
I do think the term "staging area" is fine, but picking a term is only
step one of a plan. The rest is deciding how to make the change, and
whether it is worth it. I remain undecided on the latter bits. Please
don't quote me out of context in a way that implies that I am decided.
-Peff
[1] http://article.gmane.org/gmane.comp.version-control.git/168012
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:50
Jeff King wrote:
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
quoted
When I say literally everbody agreed to move away from the name "index" (except
Junio and another guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.
With reference to my name, your email says:
Jeff King:
"staging area" makes perfect sense
But here's that statement in context[1]:
So the term "staging area" makes perfect sense to me; it is where we
collect changes to make a commit. I am willing to accept that does not
to others (native English speakers or no), and that we may need to
come up with a better term. But I think just calling it "the stage" is
even worse; it loses the concept that it is a place for collecting and
organizing.
In other words, I was saying that the term makes sense to me, and
primarily comparing favorably to a worse proposal. I am not commenting
at all on a plan to change names, which is what you are claiming above.
I do think the term "staging area" is fine, but picking a term is only
step one of a plan. The rest is deciding how to make the change, and
whether it is worth it. I remain undecided on the latter bits. Please
don't quote me out of context in a way that implies that I am decided.
I specifically said everybody agreed to "move away from the name 'index'", I
didn't say everybody agreed on the "staged area" although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.
I think I was clear.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 23:00:50
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
I specifically said everybody agreed to "move away from the name 'index'", I
didn't say everybody agreed on the "staged area" although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.
I think I was clear.
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index. I am
specifically saying that your "everyone" includes my name explicitly,
and that I do not agree with the statement you are attributing to it.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:50
Jeff King wrote:
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
quoted
I specifically said everybody agreed to "move away from the name 'index'", I
didn't say everybody agreed on the "staged area" although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.
I think I was clear.
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that "the index" is a bad name, and you agree "staging area" is a
better name, yet you don't agree we should move away from the term "index"?
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 23:00:50
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
quoted
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that "the index" is a bad name, and you agree "staging area" is a
better name, yet you don't agree we should move away from the term "index"?
I don't agree that "the index" is a "bad" name, because that implies
some objective level of "bad".
I do think the name "staging area" is fine, and I think it may even be
better than "index", if we were picking a name out of the blue.
I am undecided on whether we should move away from the term "index". The
way you have phrased it seems like you are trying to create a logical
contradiction: A is bad, B is good, therefore we should move from A to
B. But that neglects the cost of moving.
Frankly, I am not that interested in discussing it with you. I _am_
interested in you not using my name to claim that I believe things I do
not.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 23:00:50
Jeff King wrote:
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
quoted
quoted
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that "the index" is a bad name, and you agree "staging area" is a
better name, yet you don't agree we should move away from the term "index"?
I don't agree that "the index" is a "bad" name, because that implies
some objective level of "bad".
I do think the name "staging area" is fine, and I think it may even be
better than "index", if we were picking a name out of the blue.
The way you have phrased it seems like you are trying to create a logical
contradiction: A is bad, B is good, therefore we should move from A to B.
A _is_ bad, and B _is_ good. That's what I, and many people, have argued, and
that's what the vast majority of people have agreed.
But that neglects the cost of moving.
And you neglect the benefits of moving.
It is very clear that the costs of moving are negligible in comparison to the
benefits.
But you *always* resist any change, so of course you wouldn't agree on change.
And that's why nothing ever changes.
--
Felipe Contreras