From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:33
Nicolas Pitre [off-list ref] writes:
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
From: Jeff King <hidden> Date: 2016-06-15 22:47:33
On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
I am personally undecided on this issue (my "this is the best option"
was the best of "a -f switch to commit, an 'expert' config option', or a
session-based option to commit").
But we really seem to have reached an impasse with how to proceed with
git ui.
People like Dscho are fed up with user complaints about parts of git
that can be unfriendly to new users. And I can understand that. There
_is_ a perception that git is hard for beginners to use, and I don't
think that perception is entirely without merit. We expect the user to
understand the basic concepts of git, like history graphs, named refs
versus detached heads, tracking refs, the index, etc.
At the same time, I think that is what many of us _like_ about git. It
is based around simple and powerful concepts, and it doesn't get in your
way when you want to use those concepts in a powerful and flexible
manner. And I can understand resistance to making those features hard or
inconvenient to access; detached HEADs were invented for a reason, and
we want to use them.
So what is the right way to mediate between those desires? We have tried
or suggested several options, including:
1. Educate users. Keep exposing them to the concepts, but make
messages more clear. Improve documentation. This is largely the
route taken with the index. Has it worked? I think there is still a
perception among new users that the index is confusing.
2. Use configuration options to differentiate behavior. This comes in
the form of the sometimes-requested "expert/beginner mode" option.
But it can also mean a config option for a specific behavior. The
argument against it I have seen is that it can make git
unpredictable for new versus old users. An old-timer helping a new
person is more out-of-touch with what the new person's setup will
do (which hurts when sitting at their terminal or when giving them
advice online).
3. Make a new porcelain interface that wraps the git plumbing. We have
seen some examples of this. Obviously cogito was the first, and it
has fallen by the wayside as people moved towards core git. That
may be an artifact of its timing, though, as core git was a rapidly
moving target, and power users wanted to use the new features. More
recently we've had 'eg'. I don't know how many people are using it,
but it is certainly not discussed on this list much. There are also
GUIs wrapping git. I think these are subject to the same argument
as (2), but even more so. An entirely new interface like 'eg' is
really splitting the user base. As a git old-timer, I can keep up
with what newbie options might impact git's behavior. But I haven't
a clue how to do anything in 'eg'.
4. Hide potentially dangerous behavior behind "-f" or similar options,
or make it even more inaccessible. We have done this with some
obviously dangerous cases, like "push -f" or "checkout -f", which
can throw away data. But I think in cases where the behavior is
simply confusing and not dangerous, we tend not to do this (at
least I couldn't think of any examples off the top of my head). The
obvious argument against it is that it inconveniences more
experienced users. Dscho advocated "the good of the many" versus
"the good of the few". And I can see some logic in that. At the
same time, open source is about scratching itches. Is anyone really
interested in doing something that makes our own itch worse?
Everytime you use it, won't you be thinking about scratching?
So I don't know what the solution is. And maybe this is just useless
pontificating. But I feel like we have this discussion over and over,
every few months, about a different feature. I wish there were some way
to fix that.
Out of ideas,
-Peff
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:47:33
On Wed, 14 Oct 2009, Jeff King wrote:
On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
quoted
Nicolas Pitre [off-list ref] writes:
quoted
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
I am personally undecided on this issue (my "this is the best option"
was the best of "a -f switch to commit, an 'expert' config option', or a
session-based option to commit").
But we really seem to have reached an impasse with how to proceed with
git ui.
People like Dscho are fed up with user complaints about parts of git
that can be unfriendly to new users. And I can understand that.
People like Dscho have to grow a thicker skin then. There will _always_
be user complaints regardless of how balanced you try to make a UI.
There _is_ a perception that git is hard for beginners to use, and I
don't think that perception is entirely without merit. We expect the
user to understand the basic concepts of git, like history graphs,
named refs versus detached heads, tracking refs, the index, etc.
Sure. That's part of it, and beginners must get over with that
perception. Git is a professional tool and not a toy project anymore.
Like any professional grade tool, there is a greater effort needed from
beginners before being comfortable with the tool.
At the same time, I think that is what many of us _like_ about git. It
is based around simple and powerful concepts, and it doesn't get in your
way when you want to use those concepts in a powerful and flexible
manner. And I can understand resistance to making those features hard or
inconvenient to access; detached HEADs were invented for a reason, and
we want to use them.
Right. Removing features That _are_ being used sounds a bit backward.
Just because they happen to be confusing to beginners is not a good
justification to remove/cripple them IMHO.
So what is the right way to mediate between those desires? We have tried
or suggested several options, including:
1. Educate users. Keep exposing them to the concepts, but make
messages more clear. Improve documentation. This is largely the
route taken with the index. Has it worked? I think there is still a
perception among new users that the index is confusing.
Well, New users won't be new forever. And Git is different from most
other SCMs. Eventually that difference is well understood by most
not-so-new-anymore Git users. Right now I have to deal with Perforce at
$work and I find it _terribly_ confusing and obnoxious to use. So it's
only a question of getting used to something different.
IMHO this patch proposed by Daniel about the detached head is probably a
good compromise. It makes "confusing" operations more verbose to give
new users a better feeling while keeping the flexibility intact. And
increased verbosity is less annoying than decreased flexibility.
Nicolas
From: Jeff King <hidden> Date: 2016-06-15 22:47:33
On Wed, Oct 14, 2009 at 11:08:59PM -0400, Nicolas Pitre wrote:
IMHO this patch proposed by Daniel about the detached head is probably a
good compromise. It makes "confusing" operations more verbose to give
new users a better feeling while keeping the flexibility intact. And
increased verbosity is less annoying than decreased flexibility.
And I don't think there is as much opposition to a config option to
silence verbosity, because it isn't really a change in behavior. We
already have advice.*, and if the new message is too annoying, we can
get advice.commitDetachedHead.
-Peff
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:33
Hi,
On Wed, 14 Oct 2009, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
At some point, when you try to teach something that people (i.e. more than
one person) do not get easily, you cannot do anything but admit that what
you try to teach is crap. Obviously you did not have that experience.
Maybe you are just more picky than me when it comes to who you try to
teach. But of course, that does not make what you try to teach less crap.
In this particular case, I cannot help but notice that commits performed
on a detached HEAD will get lost _unless_ they are somehow put onto a
named branch eventually. So the only question is whether you restrict
flexibility by requiring to name the branch first before committing,
instead of committing and then naming the branch.
So you are talking about "retaining flexibility" in favor of making the
tool less user-friendly, when all it would take from the few power-users
is to name the branch before committing to it, instead of the other way
round.
You must be kidding me.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:33
Hi,
On Wed, 14 Oct 2009, Nicolas Pitre wrote:
On Wed, 14 Oct 2009, Jeff King wrote:
quoted
On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
quoted
Nicolas Pitre [off-list ref] writes:
quoted
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
I am personally undecided on this issue (my "this is the best option"
was the best of "a -f switch to commit, an 'expert' config option', or a
session-based option to commit").
But we really seem to have reached an impasse with how to proceed with
git ui.
People like Dscho are fed up with user complaints about parts of git
that can be unfriendly to new users. And I can understand that.
People like Dscho have to grow a thicker skin then. There will _always_
be user complaints regardless of how balanced you try to make a UI.
You are seriously misreading my intentions, then. Or my intelligence.
It is not about growing a thicker skin towards unmerited complaints.
It is about shedding the thick skin when there are merited complaints, and
some people are just too used to the old ways to understand that some of
the complaints have _a lot_ of merit.
It is just like with the olden days when only a precious few could drive
cars, and maintained that it _is_ hard to drive a car, and _not_ everybody
can do it _because_ you will have a breakdown with the car and you _have_
to be able to fix it yourself.
Fast-forward a hundred years.
None of this is true any longer.
None.
Guess what? In these days, we do not need a hundred years. Four is
plenty enough. We have a lot of Git users who do not understand the inner
workings of Git. And why should they need to?
Who are you to say they should?
We, the old Gits need to change. Not the many other people.
Remember: you do not know how exactly the clutch interacts with the 2nd
cylinder of the engine. And you do not _need_ to.
Neither should Git users need to.
Ciao,
Dscho
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:47:33
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
We, the old Gits need to change. Not the many other people.
Remember: you do not know how exactly the clutch interacts with the 2nd
cylinder of the engine. And you do not _need_ to.
Really, the detached HEAD concept can't be _that_ hard. It is not like
if we were asking our users to fully grok the blob/tree/commit hierarchy
and delta compression heuristics to be able to work with Git.
Neither should Git users need to.
What you're asking for, though, is more comparable to asking old Gits to
give up on their clutch and manual gearbox because most American Git
users are expecting automatic transmissions. Maybe that's not the case
in Germany, but over here automatic transmissions are by far the norm
and a manual gearbox can be obtained only in limited cases if at all.
Nicolas
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:33
Hi,
On Thu, 15 Oct 2009, Nicolas Pitre wrote:
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
quoted
We, the old Gits need to change. Not the many other people.
Remember: you do not know how exactly the clutch interacts with the 2nd
cylinder of the engine. And you do not _need_ to.
Really, the detached HEAD concept can't be _that_ hard.
You are trying to educate the users to use the double-clutch. Rather than
making the double-clutch obsolete.
That's what I call "BlameTheWrongThing".
quoted
Neither should Git users need to.
What you're asking for, though, is more comparable to asking old Gits to
give up on their clutch and manual gearbox because most American Git
users are expecting automatic transmissions. Maybe that's not the case
in Germany, but over here automatic transmissions are by far the norm
and a manual gearbox can be obtained only in limited cases if at all.
Your point being? You really think Git is already at the stage where it
has automatic transmission and all you have to do is hit the gas or the
brake? No, Nico, you are too intelligent to believe that.
Besides, Git is not even at the stage of a manual gearbox.
Just recently, I had a user request (a very valid one, mind you) where the
user does not want to provide a commit message, and wants to just commit
all the current changes. In that particular case, it is very sensible to
ask for these things. It is something utterly simple to ask for. Yet, it
is utterly hard with Git, especially if I have to explain it.
Maybe the core Git developers should spend a month explaining the core
principles of Git to some random software developers, just so all of us
get an idea just how wrong we are on the account of how intuitive Git is.
Ciao,
Dscho
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:33
Johannes Schindelin [off-list ref] writes:
In this particular case, I cannot help but notice that commits performed
on a detached HEAD will get lost _unless_ they are somehow put onto a
named branch eventually. So the only question is whether you restrict
flexibility by requiring to name the branch first before committing,
instead of committing and then naming the branch.
You are forgetting another important case. You may not even want to keep
what you will be committing to the throw-away temporary state.
That is why I liked the proposal by James to introduce a third state
(i.e. not on local branch, but cannot commit) at the conceptual level,
even though as Daniel pointed out and Nico and I concurred later, the
implementation may need to be based on the detached HEAD to avoid "git
fetch" surprises.
You can of course fix it in different ways. The third state could be
implemented by pointing at a non local branch ref with HEAD, and then by
making fetch refuse to update, just like we refuse a push from side to
make the working tree state inconsistent.
Either way, confusion arising from accidental (or unintended) detaching
would be removed for new users, and that won't have to harm people who
need to (because they _are_ used to) be able to work on detached HEAD, no?
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:47:33
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
Hi,
On Thu, 15 Oct 2009, Nicolas Pitre wrote:
quoted
On Fri, 16 Oct 2009, Johannes Schindelin wrote:
quoted
We, the old Gits need to change. Not the many other people.
Remember: you do not know how exactly the clutch interacts with the 2nd
cylinder of the engine. And you do not _need_ to.
Really, the detached HEAD concept can't be _that_ hard.
You are trying to educate the users to use the double-clutch. Rather than
making the double-clutch obsolete.
That's what I call "BlameTheWrongThing".
I just can't convince myself to share that point of view. Doesn't mean
that I'm right though, but that's how I see it given the alternative.
quoted
quoted
Neither should Git users need to.
What you're asking for, though, is more comparable to asking old Gits to
give up on their clutch and manual gearbox because most American Git
users are expecting automatic transmissions. Maybe that's not the case
in Germany, but over here automatic transmissions are by far the norm
and a manual gearbox can be obtained only in limited cases if at all.
Your point being? You really think Git is already at the stage where it
has automatic transmission and all you have to do is hit the gas or the
brake? No, Nico, you are too intelligent to believe that.
No, Git is not at the automatic transmission level, and I _don't_ want
it to, ever. That would not be _my_ choice.
Besides, Git is not even at the stage of a manual gearbox.
Here I disagree.
Just recently, I had a user request (a very valid one, mind you) where the
user does not want to provide a commit message, and wants to just commit
all the current changes. In that particular case, it is very sensible to
ask for these things. It is something utterly simple to ask for. Yet, it
is utterly hard with Git, especially if I have to explain it.
I hope this is a bad example. I just can't imagine how "very sensible"
you may consider messageless commits. I've dealt with them too many
times in my life.
But still, if someone just can't be bothered at all then the
"workaround" is easy: just use '-m.' or any other meaningless character
of your choice. At least _I_ will be able to identify those commits as
being purposely messageless and make a better informed opinion on that
committer instead of blaming it on ignorance.
Maybe the core Git developers should spend a month explaining the core
principles of Git to some random software developers, just so all of us
get an idea just how wrong we are on the account of how intuitive Git is.
Sorry but I don't share that feeling of hopelessness that seems to
affect those random software developers you might have tried to teach
Git to. Well, actually I do have to deal with hopeless software
developers once in a while which are simply total idiots, and they
certainly shine at depicting Git, or any other tool at their disposal
for that matter, as utter crap. But fortunately for me, the few people
to whom I've explained Git so far simply got it in very little time.
In my opinion, the most important concept to explain first is Git
branching. Everything else is kinda secondary. Worked for me pretty
well so far.
Nicolas
From: Sean Estabrooks <hidden> Date: 2016-06-15 22:47:34
On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
Johannes Schindelin [off-list ref] wrote:
Just recently, I had a user request (a very valid one, mind you) where the
user does not want to provide a commit message, and wants to just commit
all the current changes. In that particular case, it is very sensible to
ask for these things. It is something utterly simple to ask for. Yet, it
is utterly hard with Git, especially if I have to explain it.
Hey Johannes,
It's actually easy, but maybe hard to find:
$ git commit --cleanup=verbatim -m ""
Cheers,
Sean
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:37
Hi,
On Sat, 17 Oct 2009, Sean Estabrooks wrote:
On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
Johannes Schindelin [off-list ref] wrote:
quoted
Just recently, I had a user request (a very valid one, mind you) where
the user does not want to provide a commit message, and wants to just
commit all the current changes. In that particular case, it is very
sensible to ask for these things. It is something utterly simple to
ask for. Yet, it is utterly hard with Git, especially if I have to
explain it.
Hey Johannes,
It's actually easy, but maybe hard to find:
$ git commit --cleanup=verbatim -m ""
Of course that leaves out the main part. But it is simple once you
know it (I did not): git add -A (we even went out of our way _not_ to name
the long option --addremove, but --all -- it does not seem to be an
expressive-enough option name to me, but what does my impression
matter...)
So I retract my claim that it is utterly hard to do with Git (but not the
rest).
Ciao,
Dscho
On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
Johannes Schindelin [off-list ref] wrote:
quoted
Just recently, I had a user request (a very valid one, mind you) where
the user does not want to provide a commit message, and wants to just
commit all the current changes. In that particular case, it is very
sensible to ask for these things. It is something utterly simple to
ask for. Yet, it is utterly hard with Git, especially if I have to
explain it.
Hey Johannes,
It's actually easy, but maybe hard to find:
$ git commit --cleanup=verbatim -m ""
Of course that leaves out the main part. But it is simple once you
know it (I did not): git add -A (we even went out of our way _not_ to name
the long option --addremove, but --all -- it does not seem to be an
expressive-enough option name to me, but what does my impression
matter...)
So I retract my claim that it is utterly hard to do with Git (but not the
rest).
Last week, Junio gave this comment to your message.
I suspect the above is another example of your needing to do
a better job explaining yourself here, but from "just commit
all the changes without saying message", my knee-jerk
reaction is "git commit -a -m 'no message'".
You would need to justify why -m 'no message' does not fit
the bill better than just saying "is very sensible to ask for
these things", as I highly suspect that I misunderstood what
"these things" are in your five lines to come up with that
"solution" that you are now going to explain why that is not
what the end user wanted. And in this case, I do not think
it is that me being disconnected from the real world, but
that your explanation is insufficient.
I'm also curious about the situation when a commit with no message
is useful, but unfortunately I don't think I saw you explained
clearly enough what this user request wanted to achieve or what
"these things" in your message were for us to understand why it is
a sensible and valid thing to ask. Did I miss some messages in the
thread?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:37
Hi,
[culling the Cc: list, as this subthread is probably irrelevant most of
the previous members]
On Tue, 27 Oct 2009, Nanako Shiraishi wrote:
Quoting Johannes Schindelin [off-list ref]
[actually not, Nanako quoted Junio here, I guess]
quoted
I suspect the above is another example of your needing to do a better
job explaining yourself here, but from "just commit all the changes
without saying message", my knee-jerk reaction is "git commit -a -m
'no message'".
quoted
You would need to justify why -m 'no message' does not fit the bill
better than just saying "is very sensible to ask for these things", as
I highly suspect that I misunderstood what "these things" are in your
five lines to come up with that "solution" that you are now going to
explain why that is not what the end user wanted. And in this case, I
do not think it is that me being disconnected from the real world, but
that your explanation is insufficient.
I'm also curious about the situation when a commit with no message is
useful, but unfortunately I don't think I saw you explained clearly
enough what this user request wanted to achieve or what "these things"
in your message were for us to understand why it is a sensible and valid
thing to ask.
I am sure that your creative mind does not need my concrete example to
come up with a situation where an empty commit message is useful.
Anyhow, here it is: one of my users refused to touch SCMs _at all_, for
decades. There was only one choice: have a Git branch with a purely
linear history that contains the copy of the working tree at the end of
the day, with whatever changes accumulated over the day, or no history at
all.
Sure, some people will now argue that it should be easy to educate that
user to use Git properly. But that is as naive as it would be to try to
educate those people so they know how unrealistic educating users is.
Not because users are not intelligent -- they are -- but because they want
to spend their time in a more efficient manner than to learn how to
operate a version control system.
You know, when there is a hurdle half of the people you see cannot get
over, there are some who make the hurdle half as high, and there are
others who put more hurdles there and call it a sport.
In this case, I would have preferred to make the hurdle half as high, but
I think I just have to wait a couple of years; reality will take care of
things.
Ciao,
Dscho
On Tue, Oct 27, 2009 at 6:33 AM, Johannes Schindelin
[off-list ref] wrote:
Anyhow, here it is: one of my users refused to touch SCMs _at all_, for
decades. There was only one choice: have a Git branch with a purely
linear history that contains the copy of the working tree at the end of
the day, with whatever changes accumulated over the day, or no history at
all.
[...]
You know, when there is a hurdle half of the people you see cannot get
over, there are some who make the hurdle half as high, and there are
others who put more hurdles there and call it a sport.
In this case, I would have preferred to make the hurdle half as high, but
I think I just have to wait a couple of years; reality will take care of
things.
In this case, what would you have preferred to change in order to make
the hurdle half as high?
Thanks,
Avery