From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:12
Here is a draft; please discuss items that are already on the list to
improve their wording, and propose changes you would want to add to the
list, so that I can send the final message out when I tag v1.6.2-rc2.
I originally considered to Cc: mailing list addresses of various projects
that use git when sending out the final message, but I do not think it is
practical, as I suspect some/many are subscriber only (and I am not, and
would not want to be, a subscriber to them).
So instead, I'd like people from the projects that use git to forward the
final message to the mailing lists they belong to, and we would want some
coordination among volunteers to avoid duplicated forwards.
Somebody, please volunteer to keep a list of <project name, volunteering
forwarder> tuples. It might be a good idea to create a new page that is
linked from http://git.or.cz/gitwiki/GitProjects for that purpose.
Thanks.
-- >8 -- cut here -- >8 --
To: git@vger.kernel.org
Subject: [RFC/WARNING] Proposed future changes that are backward incompatible
Here is a list of possible future changes to git that are backward
incompatible that are under discussion on the git mailing list.
None of them will be in the upcoming 1.6.2 release, but some of them are
likely to appear in future versions. If you think we should not introduce
some of the listed changes, here is a chance to voice your opinions and
make a convincing argument against them, so please do so. Many people
complained about the removal of many git-foo commands from user's PATH,
which was done in 1.6.0 based on user input, after it happened. You do
not want to see such a mess happen again.
Thanks.
* git-push to update the checked out branch will be refused by default
Make "git push" into a repository to update the branch that is checked
out fail by default.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* git-push to delete the current branch will be refused by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter.
http://article.gmane.org/gmane.comp.version-control.git/109790
* make core.quotepath=false the default
By default, "git diff" output quotes bytes in pathnames with high bit
set, primarily to avoid corruption during e-mail based transfer. This
however is inconvenient for human readers, and also makes some poorly
written user scripts that do not unquote them fail. Change the default
so that they are not quoted (note that control characters such as HT are
always quoted).
http://thread.gmane.org/gmane.comp.version-control.git/110033
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks out the current version, compiles it, publishes the compiled
version, sends an announcement, etc
if I am understanding the purpose of this change, you would prohibit the
update from taking place.
the message in the thread that you link to discusses how you want to be
careful about the change, but I have to hunt around through the rest of
the thread to figure out what the change really means (and I'm not sure I
really figured it out)
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter.
http://article.gmane.org/gmane.comp.version-control.git/109790
I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.
that being said, I don't think it's that significant to change the
default.
one thing that would help new users is if there was a way to create a git
config file that explicitly listed all the defaults. either as a sample
config, or to expand the existing config file with all the defaults
listed, but commented out.
I find that having such a config file helps me find config options I never
thought to look for.
David Lang
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that checks
out the current version, compiles it, publishes the compiled version, sends an
announcement, etc
So you have to set a config variable. Big deal.
Compared to that, the thousands of new Git users will no longer be bitten
by the "do not push to a non-bare repository" issue without a useful error
message.
Please, please, publicize that if there is somebody who is doing the same
as you (which I deem a dangerous workflow; I certainly do not use it
myself) that they will have to adjust their receive.denyCurrentBranch
variable.
Ciao,
Dscho
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks out the current version, compiles it, publishes the compiled
version, sends an announcement, etc
if I am understanding the purpose of this change, you would prohibit
the update from taking place.
No, you just have to configure it to enable it. In the meantime
(before the change) you would get warnings unless you configure it.
quoted
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter.
http://article.gmane.org/gmane.comp.version-control.git/109790
I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.
That is whay you should use --numbered (and I think it should be
default for --no-chain-reply-to), using [PATCH m/n] prefix.
Note that usually you would have problems if patch arrive out of
order, unless your enail client / news reader is able to rethread.
that being said, I don't think it's that significant to change the
default.
It is much, much nicer when there is discussion on the patches in
patch series to have 'shallow' threading (cover letter + patches
numbered being reply to cover letter).
Unless you don't get review of patches, then deep threading might look
as nice...
one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.
I find that having such a config file helps me find config options I
never thought to look for.
That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values. But
perhaps I am mistaken.
--
Jakub Narebski
Poland
ShadeHawk on #git
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that checks
out the current version, compiles it, publishes the compiled version, sends an
announcement, etc
So you have to set a config variable. Big deal.
Compared to that, the thousands of new Git users will no longer be bitten
by the "do not push to a non-bare repository" issue without a useful error
message.
Please, please, publicize that if there is somebody who is doing the same
as you (which I deem a dangerous workflow; I certainly do not use it
myself) that they will have to adjust their receive.denyCurrentBranch
variable.
since this repository isn't use for anything other than publishing for
public access, what's so dangerous about it?
what do you think that I should be doing instead?
David Lang
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:12
Hi,
On Sun, 15 Feb 2009, Jakub Narebski wrote:
david@lang.hm writes:
quoted
one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.
I find that having such a config file helps me find config options I
never thought to look for.
That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values. But
perhaps I am mistaken.
Of course, you have to ignore the fact that it would no longer possible to
update defaults for existing repositories.
For example, setting something like receive.denyCurrentBranch to a saner
default would not reach existing repositories.
And you would also have to ignore the fact that sometimes, config
variables are deprecated, and this _also_ would not reach existing
repositories. Of course, the same holds true if you set such a config
variable manually, but then you are _supposed_ to know the config
variable, and you are unlikely to learn the name of an obsolete variable.
Do keep in mind, too, that most of the variables are next to useless
without the proper documentation. And do you really want to replicate
Documentation/config.txt in the config file? If not, how do you want to
make sure that the two different documentations do not go out of sync?
Further, it would be much, much harder to see what is _actually_ set.
Summary: I do not like that idea.
Ciao,
Dscho
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks
out the current version, compiles it, publishes the compiled version,
sends an
announcement, etc
So you have to set a config variable. Big deal.
Compared to that, the thousands of new Git users will no longer be bitten
by the "do not push to a non-bare repository" issue without a useful error
message.
Please, please, publicize that if there is somebody who is doing the same
as you (which I deem a dangerous workflow; I certainly do not use it
myself) that they will have to adjust their receive.denyCurrentBranch
variable.
since this repository isn't use for anything other than publishing for public
access, what's so dangerous about it?
Hey, you do what you want...
I just keep in mind that it _is_ a working directory that can go dirty,
for whatever reasons.
Which is why _I_ do things like your workflow locally, even if that means
that I log onto another machine (which is then "local").
But again, it is your choice. And certainly, it will be possible in the
future, too, just more deprecated than it is already.
Ciao,
Dscho
one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.
I find that having such a config file helps me find config options I
never thought to look for.
That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values. But
perhaps I am mistaken.
if there isn't, wouldn't it be a good idea to make one?
Of course, you have to ignore the fact that it would no longer possible to
update defaults for existing repositories.
not if the defaults are put into the config file commented out.
this way you can see all the options (and default settings), but still
tell which ones are system defaults and which ones the user has set. I
have seen several projects that ship a config file that consists almost
entirely of commented out items.
also, the first option I listed was to create a new file on-command that
would contain the defaults
For example, setting something like receive.denyCurrentBranch to a saner
default would not reach existing repositories.
And you would also have to ignore the fact that sometimes, config
variables are deprecated, and this _also_ would not reach existing
repositories. Of course, the same holds true if you set such a config
variable manually, but then you are _supposed_ to know the config
variable, and you are unlikely to learn the name of an obsolete variable.
Do keep in mind, too, that most of the variables are next to useless
without the proper documentation.
in most cases the variable names are fairly descriptive. even if you have
to go to the documentation to figure out what to set it to, seeing the
name can point you to the right thing to search for in the documentation.
And do you really want to replicate
Documentation/config.txt in the config file? If not, how do you want to
make sure that the two different documentations do not go out of sync?
have one be auto-generated from the other and they won't be out of sync.
also note that I'm suggesting a git-config option that does this. not
having it set at git-init time, so that users can run it long after the
repository was created and see the defaults for the current version of
git.
Further, it would be much, much harder to see what is _actually_ set.
again, not if the defaults are put in as commented out options
Summary: I do not like that idea.
I'm not sure the idea you dislike so much is exactly what I proposed.
David Lang
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks
out the current version, compiles it, publishes the compiled version,
sends an
announcement, etc
So you have to set a config variable. Big deal.
the dashed names were the same way, but they definantly were a big deal.
quoted
quoted
Compared to that, the thousands of new Git users will no longer be bitten
by the "do not push to a non-bare repository" issue without a useful error
message.
Please, please, publicize that if there is somebody who is doing the same
as you (which I deem a dangerous workflow; I certainly do not use it
myself) that they will have to adjust their receive.denyCurrentBranch
variable.
since this repository isn't use for anything other than publishing for public
access, what's so dangerous about it?
Hey, you do what you want...
I just keep in mind that it _is_ a working directory that can go dirty,
for whatever reasons.
Which is why _I_ do things like your workflow locally, even if that means
that I log onto another machine (which is then "local").
But again, it is your choice. And certainly, it will be possible in the
future, too, just more deprecated than it is already.
please be careful with the term 'deprecated', just becouse you would do
something a different way doesn't make it 'deprecated', that term should
only be used for features that are on their way out of the product, but
haven't been removed yet.
David Lang
From: Jakub Narebski <hidden> Date: 2016-06-15 22:46:12
Hello!
On Mon, 16 Feb 2009, Johannes Schindelin wrote:
On Sun, 15 Feb 2009, Jakub Narebski wrote:
quoted
david@lang.hm writes:
quoted
one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.
I find that having such a config file helps me find config options I
never thought to look for.
That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values. But
perhaps I am mistaken.
Of course, you have to ignore the fact that it would no longer possible to
update defaults for existing repositories.
For example, setting something like receive.denyCurrentBranch to a saner
default would not reach existing repositories.
You missed that it would be a _sample_ config (or commented out sample
config), and not the default config installed when creating repository.
But...
And you would also have to ignore the fact that sometimes, config
variables are deprecated, and this _also_ would not reach existing
repositories. Of course, the same holds true if you set such a config
variable manually, but then you are _supposed_ to know the config
variable, and you are unlikely to learn the name of an obsolete variable.
Do keep in mind, too, that most of the variables are next to useless
without the proper documentation. And do you really want to replicate
Documentation/config.txt in the config file? If not, how do you want to
make sure that the two different documentations do not go out of sync?
Further, it would be much, much harder to see what is _actually_ set.
Summary: I do not like that idea.
... perhaps an alternate solution: add switch to git-config or git-var
which would list (only list, no description) all defaults. Hmmm?
--
Jakub Narebski
Poland
If this is implemented, it shouldn't, in my opinion, be a default
setting. I regularly push to checkout repos when I'm doing cross machine
development. However, I could live with a configurable setting as
proposed in the given URL. I think Git should not be too cautious about
following users instructions. The user knows what is best for him/her ;)
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 04:14:20PM -0800, david@lang.hm wrote:
quoted
Please, please, publicize that if there is somebody who is doing the same
as you (which I deem a dangerous workflow; I certainly do not use it
myself) that they will have to adjust their receive.denyCurrentBranch
variable.
since this repository isn't use for anything other than publishing for
public access, what's so dangerous about it?
what do you think that I should be doing instead?
What you are doing is not dangerous, because you are one of the clueful
users who understands that the repo is only for publishing, and has set
up a hook to (or is manually triggering) a checkout of the new contents.
It is the less clueful user who doesn't realize that his working tree
and index in the pushed-to repository contain totally bogus information
which can cause him to create bad commits or even lose work permanently.
Dealing with this is one of the most common FAQ's we see on the list.
So the proposal is about making you, the clueful user, set a config
option that promises you have a clue. Which is sad that this must impact
you, but unfortunately it is not a very good strategy to ask clueless
users to set a variable saying that they are so.
-Peff
If this is implemented, it shouldn't, in my opinion, be a default
setting. I regularly push to checkout repos when I'm doing cross machine
development. However, I could live with a configurable setting as
proposed in the given URL. I think Git should not be too cautious about
following users instructions. The user knows what is best for him/her ;)
It is already implemented; the proposal is about setting the default.
The plans for 1.6.2 are already to issue a warning and ask the user to
set the config variable to shut it up.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:
quoted
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter.
http://article.gmane.org/gmane.comp.version-control.git/109790
I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.
Is that the case? mutt at least orders by thread, but by rfc822 date
within a single level of thread. So as long as the date fields (set by
the sender) are correct, it looks right no matter what order they arrive
in.
Are there common readers that thread but do not order by date?
-Peff
If this is implemented, it shouldn't, in my opinion, be a default
setting. I regularly push to checkout repos when I'm doing cross machine
development. However, I could live with a configurable setting as
proposed in the given URL. I think Git should not be too cautious about
following users instructions. The user knows what is best for him/her ;)
It is already implemented; the proposal is about setting the default.
The plans for 1.6.2 are already to issue a warning and ask the user to
set the config variable to shut it up.
if this is going to be done the timeframe for making the change should be
quite long. think in terms of debian stable or RHEL, whatever version they
ship is what their users are going to use. it doesn't matter how many new
versions and what warnings you have the produce in the meantime, the users
won't see them.
to the progression needs to be
one upgrade cycle the user is using the old version with no warning.
next upgrade cycle the user is using a version with a warning.
the third upgrade cycle the user is using the version with the default
changed.
the problem is that these upgrade cycles are 3-5 years each, and it's not
unusual for the types of users that use dbian stable or RHEL to be running
these systems in places where they do not get patched during their
lifetime.
note that this isn't always stupid to do, if you are deploying them on a
network with no Internet access the stability of knowing that things are
_exactly_ what you tested may be worth more than updates that close bugs
that you don't hit or add features that you aren't using (or introduce
unexpected changes like spitting warnings or errors for things that the
old version didn't, which is exactly what is being proposed.
David Lang
as I think about this more I'm puzzled as to why this is an issue.
I see mentions of it messing up the index and causing users to loose data,
but how is it different to push into a repository that has a workdir (with
or without dirty state in the workdir or in the index) and doing a fetch
into that repository.
in both cases the new commits are added to the repository and the commit
pointed to by the branch changes, but if you do the fetch your HEAD and
the contents of the workdir and index aren't touched, why should a push do
something different?
I believe that if you fetch into a repository and someone else fetches
from you, they will get the content that's newer that what's in your dirty
workdir/index (I haven't tried it, but my understanding of the git
internals lead me to expect this to be the behavior)
a pull would try to update the index, HEAD, and workdir, but I've seen
many discussions about how push and pull are not symetrical, but push and
fetch are (along with the moaning about bad names for the commands and the
historical explination of how they got that way)
If there is some reason for the normal push to try and update the HEAD,
index, and workdir. instead of refusing the push, how about having it put
the commits in the repository and then fail to change the HEAD, index, and
workdir if any of them contain changes? (along with a warning that it's
doing so).
this should be safe to do because it will only flag on the particular
combination of events that will cause data loss rather than the broader
prohibition of "don't push if there is a workdir" that affects legitimate
uses as well
David Lang
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks out the current version, compiles it, publishes the compiled
version, sends an announcement, etc
if I am understanding the purpose of this change, you would prohibit the
update from taking place.
I didn't read the *entire* thread but I do believe prohibit
is too strong. It's only the default behaviour that is
being changed -- in your situation you'd just set
receive.denyCurrentBranch to either 'warn' (the current
default) or 'ignore'.
as I think about this more I'm puzzled as to why this is an issue.
I think that you have a slightly misunderstanding of what fetch is usually
configured to do.
I see mentions of it messing up the index and causing users to loose data,
but how is it different to push into a repository that has a workdir (with or
without dirty state in the workdir or in the index) and doing a fetch into
that repository.
in both cases the new commits are added to the repository and the commit
pointed to by the branch changes, but if you do the fetch your HEAD and the
contents of the workdir and index aren't touched, why should a push do
something different?
This isn't the case. A fetch will only update the refs that refer to
the state of the remote repository. It will not update any of your local refs
(unless you have a mirror setup - in which case a fetch is just as bad as
a push).
Say we have two repositories, and local is cloned from remote:
remote# git branch
* master
foo
local# git branch #what branches do we have to work on?
* master
foo
local# git branch -r #what branches do our remotes have?
remote/master
remote/foo
If we have updates on the master branch at remote, then "git fetch remote"
on local will update "remote/master", but will not affect "master" - the
currently checked out branch. To update "master" we then have to either
merge "remote/master" (pull) or rebase "master" onto the new head of
"remote/master" (pull --rebase).
However, if we have updates on the master branch at local, then "git push
remote master" will update "master" on the remote repository - the checked
out branch. At which point the user has to know what they are doing, or
risk confusion and lost work, as any commit made on the remote branch will
not take account of the changes made by the pushed commits unless care is
taken to update the wordir first (and it doesn't make any difference if
you didn't have dirty state before the push).
I believe that if you fetch into a repository and someone else fetches from
you, they will get the content that's newer that what's in your dirty
workdir/index (I haven't tried it, but my understanding of the git internals
lead me to expect this to be the behavior)
Unless they are also pulling your remote tracking branches (which is not
the default behaviour, and is a rather odd thing to do), then your fetch
will not change what they get from you as they only get your local
branches.
a pull would try to update the index, HEAD, and workdir, but I've seen many
discussions about how push and pull are not symetrical, but push and fetch
are (along with the moaning about bad names for the commands and the
historical explination of how they got that way)
They are symetrical in operation, but not in destination. Basically, the
assumption is that when fetching the user is on that machine and will
incorporate the updates themselves either using pull, or in a more manual
way. With push, the assumption is that there is no user on the remote
machine only a lonely old server process, and that the changes should be
immediately made available to anyone accessing the repository.
If there is some reason for the normal push to try and update the HEAD,
index, and workdir. instead of refusing the push, how about having it put the
commits in the repository and then fail to change the HEAD, index, and
workdir if any of them contain changes? (along with a warning that it's doing
so).
this should be safe to do because it will only flag on the particular
combination of events that will cause data loss rather than the broader
prohibition of "don't push if there is a workdir" that affects legitimate
uses as well
David Lang
--
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
--
Julian
---
Q: Does Bill Gates use public domain software?
A: Yes, as all of the public has become Bill Gates' domain.
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:
On 16 feb 2009, at 00:07, Jeff King wrote:
quoted
Are there common readers that thread but do not order by date?
Apple's Mail orders by date received, rather than date sent
Hmph. I guess it is a potential problem, then. If you use Apple Mail,
can you report on whether out of order threads have been a problem
(since earlier discussion revealed that both deep and shallow threads
are found in the wild)?
-Peff
From: Brian Gernhardt <hidden> Date: 2016-06-15 22:46:12
On Feb 15, 2009, at 9:43 PM, Jeff King wrote:
On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:
quoted
On 16 feb 2009, at 00:07, Jeff King wrote:
quoted
Are there common readers that thread but do not order by date?
Apple's Mail orders by date received, rather than date sent
Hmph. I guess it is a potential problem, then. If you use Apple Mail,
can you report on whether out of order threads have been a problem
(since earlier discussion revealed that both deep and shallow threads
are found in the wild)?
I have noticed patches listed out of order, but I simply just open
them according to the [PATCH N/M] in the subject. I wouldn't really
call it a problem.
~~ Brian
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 05:33:59PM -0800, david@lang.hm wrote:
quoted
It is already implemented; the proposal is about setting the default.
The plans for 1.6.2 are already to issue a warning and ask the user to
set the config variable to shut it up.
if this is going to be done the timeframe for making the change should be
I don't know that a particular timeframe for switching the default has
been chosen at this point. There is a short warning in 1.6.1, and a much
more comprehensive warning will be in 1.6.2 (which should be released
shortly).
quite long. think in terms of debian stable or RHEL, whatever version they
ship is what their users are going to use. it doesn't matter how many new
versions and what warnings you have the produce in the meantime, the users
won't see them.
Sadly, Debian 5.0 just shipped with git 1.5.6.5, which has no warning
(and dashed commands!).
note that this isn't always stupid to do, if you are deploying them on a
network with no Internet access the stability of knowing that things are
_exactly_ what you tested may be worth more than updates that close bugs
that you don't hit or add features that you aren't using (or introduce
unexpected changes like spitting warnings or errors for things that the
old version didn't, which is exactly what is being proposed.
I'm not sure I understand your argument here. If you have a machine that
needs to do _exactly_ what you have tested, then wouldn't you be
concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
you are probably looking at a more macro-level, upgrading Debian 5.0 to
Debian 6.0?
-Peff
It is already implemented; the proposal is about setting the default.
The plans for 1.6.2 are already to issue a warning and ask the user to
set the config variable to shut it up.
if this is going to be done the timeframe for making the change should be
I don't know that a particular timeframe for switching the default has
been chosen at this point. There is a short warning in 1.6.1, and a much
more comprehensive warning will be in 1.6.2 (which should be released
shortly).
quoted
quite long. think in terms of debian stable or RHEL, whatever version they
ship is what their users are going to use. it doesn't matter how many new
versions and what warnings you have the produce in the meantime, the users
won't see them.
Sadly, Debian 5.0 just shipped with git 1.5.6.5, which has no warning
(and dashed commands!).
quoted
note that this isn't always stupid to do, if you are deploying them on a
network with no Internet access the stability of knowing that things are
_exactly_ what you tested may be worth more than updates that close bugs
that you don't hit or add features that you aren't using (or introduce
unexpected changes like spitting warnings or errors for things that the
old version didn't, which is exactly what is being proposed.
I'm not sure I understand your argument here. If you have a machine that
needs to do _exactly_ what you have tested, then wouldn't you be
concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
you are probably looking at a more macro-level, upgrading Debian 5.0 to
Debian 6.0?
two points
1. someone running Debian 5 who then upgrades to Debian 6 should get the
warning, not the refusal, then when they go to Debian 7 the refusal can be
the standard (and substatute redhat enterprise version numbers for debian
if you want)
2. you can't count on users upgrading any faster than I tak about in
#1. Debian shipped 1.5.6.5 in 5.0, when users upgrade to Debian 6.0, you
can't assume that they _ever_ patched the system, so even if you released
a 1.5.6.6 today that had the warning in it, you can't assume that users
saw it and so it's safe to remove the dashed commands in the version that
will ship with Debian 6.0.
so a warning can go in at any time, but changing the default in a way
that's not backwards compatible needs to be done over a _very_ long
timeframe. so long that it's worth questioning if it's worth changing (as
opposed to either just leaving the warning, or trying to figure out a
different way)
David Lang
in both cases the new commits are added to the repository and the commit
pointed to by the branch changes, but if you do the fetch your HEAD and
the contents of the workdir and index aren't touched, why should a push do
something different?
The short answer to your confusion is that fetch stores the updates in
"remote tracking refs" (in refs/remotes/) but push pushes directly into
the refs/heads/ hierarchy.
Note that you could set up an alternate push refspec in your client that
pushes into refs/remotes/. But then people fetching from it would have
to know to fetch from their instead of the regular refs/heads/ portion.
I believe that if you fetch into a repository and someone else fetches
from you, they will get the content that's newer that what's in your dirty
workdir/index (I haven't tried it, but my understanding of the git
internals lead me to expect this to be the behavior)
No, they won't. Because when you fetch, your "refs/heads/master" branch
(for example) is not updated. Your "refs/remotes/origin/master" branch
is.
If there is some reason for the normal push to try and update the HEAD,
index, and workdir. instead of refusing the push, how about having it put
the commits in the repository and then fail to change the HEAD, index, and
workdir if any of them contain changes? (along with a warning that it's
doing so).
The question is where would it "put" the commits if not in the branch
you asked for, which is the one pointed to by "HEAD"?
this should be safe to do because it will only flag on the particular
combination of events that will cause data loss rather than the broader
prohibition of "don't push if there is a workdir" that affects legitimate
uses as well
It's not "don't push if there is a workdir". It's "don't push into the
ref that is pointed to by HEAD". Which is the exact situation that
causes problems.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:
quoted
I'm not sure I understand your argument here. If you have a machine that
needs to do _exactly_ what you have tested, then wouldn't you be
concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
you are probably looking at a more macro-level, upgrading Debian 5.0 to
Debian 6.0?
two points
1. someone running Debian 5 who then upgrades to Debian 6 should get the
warning, not the refusal, then when they go to Debian 7 the refusal can be
the standard (and substatute redhat enterprise version numbers for debian
if you want)
So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?
What about people who skip straight from 5 to 7? It's OK for them not to
see the warning, because two major versions means they should read the
release notes and re-test?
so a warning can go in at any time, but changing the default in a way
that's not backwards compatible needs to be done over a _very_ long
timeframe. so long that it's worth questioning if it's worth changing (as
opposed to either just leaving the warning, or trying to figure out a
different way)
There has been a lot of questioning, and a lot of discussion of
alternatives already. Please check the list archive for some of it.
I don't think there is a timetable set at this point.
-Peff
On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:
quoted
quoted
I'm not sure I understand your argument here. If you have a machine that
needs to do _exactly_ what you have tested, then wouldn't you be
concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since
you are probably looking at a more macro-level, upgrading Debian 5.0 to
Debian 6.0?
two points
1. someone running Debian 5 who then upgrades to Debian 6 should get the
warning, not the refusal, then when they go to Debian 7 the refusal can be
the standard (and substatute redhat enterprise version numbers for debian
if you want)
So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?
when was the last time you read the release notes for an entire distro?
they will test behavior, but if things that used to work just fail it's
not good.
What about people who skip straight from 5 to 7? It's OK for them not to
see the warning, because two major versions means they should read the
release notes and re-test?
for the 'enterprise distros' you would need to upgrade from 5 to 6 to 7 to
remain supported. if you go directly from 5 to 7 you have been in
unsupported territory for quite some time (probably measured in years).
and it's not a matter of reading the release notes. it's a matter of them
running a version that gives them a warning before you feed them a version
that will cause their existing stuff to fail.
I recognise that not all software is concerned about backwards
compatibility, but if git wasn't concerned with backwards compatibility
and a graceful upgrade process, this thread wouldn't exist.
David Lang
quoted
so a warning can go in at any time, but changing the default in a way
that's not backwards compatible needs to be done over a _very_ long
timeframe. so long that it's worth questioning if it's worth changing (as
opposed to either just leaving the warning, or trying to figure out a
different way)
There has been a lot of questioning, and a lot of discussion of
alternatives already. Please check the list archive for some of it.
I don't think there is a timetable set at this point.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:
quoted
So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?
when was the last time you read the release notes for an entire distro?
Since you ask, I track Debian unstable and I read the release notes
(NEWS.Debian) for every package that I upgrade, and skim the changelogs
for perhaps half.
But yes, I realize that is not common; I don't expect that every user
reads every release note.
My point is that things _are_ going to change in a major version OS
upgrade. It is up to the user to make the tradeoff of how much time they
want to spend researching those changes versus the likelihood and
severity of breakage. If I have a mission critical system running git,
I'm going to read git's release notes. If I don't, then I will probably
accept that something could break, and fix it if it does.
and it's not a matter of reading the release notes. it's a matter of them
running a version that gives them a warning before you feed them a version
that will cause their existing stuff to fail.
The warning is not a panacea:
1. It might actually cause breakage. Less likely than a straight
change in behavior, but still possible.
2. Users don't necessarily see the warning. By definition, it is not
changing the behavior. So unless they are examining the output
(which might not be the case for an unattended system), it can go
unnoticed.
So all of the problems you are talking about are still possible even
with an extremely long change cycle.
I recognise that not all software is concerned about backwards
compatibility, but if git wasn't concerned with backwards compatibility
and a graceful upgrade process, this thread wouldn't exist.
I think git is much better about backwards compatibility than most
packages I have seen. But there is a cost to maintaining it completely
and forever, in that you are either hampered in what you can do (i.e.,
there are enhancements you would like to make but can't) or you pay an
awful burden in development cost maintaining two diverging codebases.
Based on the numbers in your last email, you seem to be advocating a
9-15 year lag on making any behavior changes in git. I'm sorry, but I
have no interest in waiting that long to see enhancements I work on in
git make it into a released version.
I think Junio is doing a fine job at dealing with backwards
compatibility and keeping things moving at a reasonable pace. If you
think it should go slower, you are certainly welcome to fork and release
an "ultra-stable" version of git that reverts any backwards incompatible
changes while keeping up with other new features.
-Peff
On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:
quoted
quoted
So people doing major version upgrades of their OS don't need to read
release notes or re-test behavior?
when was the last time you read the release notes for an entire distro?
Since you ask, I track Debian unstable and I read the release notes
(NEWS.Debian) for every package that I upgrade, and skim the changelogs
for perhaps half.
But yes, I realize that is not common; I don't expect that every user
reads every release note.
My point is that things _are_ going to change in a major version OS
upgrade. It is up to the user to make the tradeoff of how much time they
want to spend researching those changes versus the likelihood and
severity of breakage. If I have a mission critical system running git,
I'm going to read git's release notes. If I don't, then I will probably
accept that something could break, and fix it if it does.
in that case there's no reason for any warning time. just change the
default and put a comment about it in the changelog.
that worked well for the dashed names didn't it.
quoted
and it's not a matter of reading the release notes. it's a matter of them
running a version that gives them a warning before you feed them a version
that will cause their existing stuff to fail.
The warning is not a panacea:
1. It might actually cause breakage. Less likely than a straight
change in behavior, but still possible.
2. Users don't necessarily see the warning. By definition, it is not
changing the behavior. So unless they are examining the output
(which might not be the case for an unattended system), it can go
unnoticed.
So all of the problems you are talking about are still possible even
with an extremely long change cycle.
quoted
I recognise that not all software is concerned about backwards
compatibility, but if git wasn't concerned with backwards compatibility
and a graceful upgrade process, this thread wouldn't exist.
I think git is much better about backwards compatibility than most
packages I have seen. But there is a cost to maintaining it completely
and forever, in that you are either hampered in what you can do (i.e.,
there are enhancements you would like to make but can't) or you pay an
awful burden in development cost maintaining two diverging codebases.
Based on the numbers in your last email, you seem to be advocating a
9-15 year lag on making any behavior changes in git. I'm sorry, but I
have no interest in waiting that long to see enhancements I work on in
git make it into a released version.
two cycles of changes, not three, so 6-10 years for changes that break
existing bahavior without a _really_ pressing reason. so new functions,
new commands, new flags don't have to wait at all. it's only if you want
to change something that will cause grief for users if they get a new
version and run their existing tools against it.
I think Junio is doing a fine job at dealing with backwards
compatibility and keeping things moving at a reasonable pace. If you
think it should go slower, you are certainly welcome to fork and release
an "ultra-stable" version of git that reverts any backwards incompatible
changes while keeping up with other new features.
I am not interested in forking git. but I am saying that a backwards
incompatible change had better _really_ be worth it, and not just be worth
it for the people who live an breath git, but for the users as well (this
is a test that the dashed name elimination failed. in spite of a volcal
few saying that all the commands in the path were causing problems, most
people couldn't understand why the git people wanted to remove them)
for anything less than a fairly critical bug, if it's in a public
interface you really don't want to change it (in part becouse the
timeframe to properly depriciate it, with warnings, needs to happen on
timescales measured in years)
and I agree that Junio is doing a good job with this. he's the one who
started this thread to discuss the possible changes after all.
David Lang
From: Jeff King <hidden> Date: 2016-06-15 22:46:12
On Sun, Feb 15, 2009 at 09:55:24PM -0800, david@lang.hm wrote:
two cycles of changes, not three, so 6-10 years for changes that break
existing bahavior without a _really_ pressing reason. so new functions,
new commands, new flags don't have to wait at all. it's only if you want
to change something that will cause grief for users if they get a new
version and run their existing tools against it.
I think you have to think about _how much_ grief it will cause, too.
Yes, some git enhancements are purely new functions and features that
will not affect anyone who does not opt into them. But many
enhancements cover cases that _must_ change behavior. Even bugfixes fall
into this category. Who is to say somebody is not relying on the buggy
behavior? So there must be some discretion for the maintainer to say
"Anyone relying on this behavior is probably crazy".
And so there is some degree of cost-benefit. How much pain will this
cause versus how much good will it do?
I am not interested in forking git. but I am saying that a backwards
incompatible change had better _really_ be worth it, and not just be worth
it for the people who live an breath git, but for the users as well (this
is a test that the dashed name elimination failed. in spite of a volcal
few saying that all the commands in the path were causing problems, most
people couldn't understand why the git people wanted to remove them)
Have you read the related threads in the archive? I think there is a
significant sentiment that this change _is_ really worth it. The current
behavior is hurting new users. I think the general consensus is that the
default should change; the question is how and when.
The dashed-names change didn't go so well. You can argue whether or not
it was a good change in the first place, but that is beside the point.
The lesson to be learned there is that _how_ it was done could have been
better. One of the things we are trying differently is having the
warning. Another is that Junio is putting together a contact list for
major projects using git. If you have a suggestion for another
technique, I'm sure people will be open to it.
And as I said, I don't think a timetable has been set. But I would be
surprised if it ends up in the 6-10 year range.
-Peff
From: SZEDER Gábor <hidden> Date: 2016-06-15 22:46:12
Hi,
On Sun, Feb 15, 2009 at 07:07:32PM -0500, Jeff King wrote:
On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:
quoted
I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.
Is that the case? mutt at least orders by thread, but by rfc822 date
within a single level of thread. So as long as the date fields (set by
the sender) are correct, it looks right no matter what order they arrive
in.
Are there common readers that thread but do not order by date?
If I understand this one, it will cause grief for quite a few people.
I have a public repository that I push to and then have a trigger that
checks out the current version, compiles it, publishes the compiled
version, sends an announcement, etc
if I am understanding the purpose of this change, you would prohibit the
update from taking place.
In the "non-bare" FAQ entry, there's a link to a post-update hook that
tries to resolve pushes to the branch head referenced by HEAD, and
at least on #git, there were people that preferred using that hook
instead of setting up a bare repo. So you're probably not the only one
with such a setup.
How about having the default in the code being a warning, but the
default for new repos being "reject"? IOW, set receive.denyCurrentBranch
accordingly in the .git/config file for new non-bare repos? That way,
for your existing repos, you get a warning with instruction that you can
set a config entry to kill the warning or to forbid the potentially
destructive operation. So it's just a new warning, and your existing
setups don't break.
But for new repos, you get the rejection behaviour and have to change
the config if you really want to push to the current branch, along with
setting up the hook and whatever else you need, so it's just one more
step you need to take now.
Björn
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:46:12
On Sun, 15 Feb 2009, david@lang.hm wrote:
If there is some reason for the normal push to try and update the HEAD, index,
and workdir. instead of refusing the push, how about having it put the commits
in the repository and then fail to change the HEAD, index, and workdir if any
of them contain changes? (along with a warning that it's doing so).
A push cannot help but update HEAD, because HEAD is generally literally
"ref: refs/heads/<current-branch>"; it doesn't store its own value, and
the storage that it references is the storage that push is updating.
In fact, if you expect to be pushing to a non-bare repository, you
probably want to have HEAD contain the actual commit currently checked out
(instead of a reference to externally mutable storage), which you can do
with "git checkout refs/heads/master".
-Daniel
*This .sig left intentionally blank*
On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:
quoted
On 16 feb 2009, at 00:07, Jeff King wrote:
quoted
Are there common readers that thread but do not order by date?
Apple's Mail orders by date received, rather than date sent
Hmph. I guess it is a potential problem, then. If you use Apple Mail,
can you report on whether out of order threads have been a problem
(since earlier discussion revealed that both deep and shallow threads
are found in the wild)?
Yes, I use Apple Mail and I often see out-of-order threads.
But frankly, this is a total non-problem with absolutely zero impact
(given that most people use numbered subject lines and it is easy to
see the order in which the patches should be read).
Cheers,
Wincent
In my workflows (and let me remark it, in mine, which might well be mine only or
even very stupid), what would be nice would be the possibility of triggering the
following scenario:
- When you push to a repo which is not bare, if you push to a checked out
branch, the branch gets updated, the worktree is not touched, the head becomes
detached, the branch the head was on gets saved somewhere, and when someone
tries asking for status or committing on the repo he gets a message like:
"The branch has been changed behind your shoulders from remote. Your work tree
changes are anyway safe. Head has been detached, your former branch was .... You
can either:
- start a new branch with the changes that are currently in your worktree with
command so and so...
- stash the current status, peek at the new head of your former branch, try
applying your current changes there."
Also it would be nice to be able to store my "standard initial setup" in
.gitinit or something like this, so that whenever I git init I have my own
defaults (which is not the same as having global config info).
...thanks for pre-announcing incompatible changes.
Sergio
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:12
Hi,
On Sun, 15 Feb 2009, david@lang.hm wrote:
please be careful with the term 'deprecated', just becouse you would do
something a different way doesn't make it 'deprecated', that term should
only be used for features that are on their way out of the product, but
haven't been removed yet.
It is not deprecated because I do not like it. Actually, I am pretty
indifferent about the pushing into a non-bare repository.
It is deprecated because a lot of people active in the Git community spend
a real lot of time explaining to a whole bunch of new users on IRC and
recently even on this list why their pushing into a non-bare repository
does not work, and why their suggestions how to solve the issue does not
work either.
Hth,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:12
Hi,
On Sun, 15 Feb 2009, david@lang.hm wrote:
I am not interested in forking git. but I am saying that a backwards
incompatible change had better _really_ be worth it, and not just be
worth it for the people who live an breath git, but for the users as
well (this is a test that the dashed name elimination failed. in spite
of a volcal few saying that all the commands in the path were causing
problems, most people couldn't understand why the git people wanted to
remove them)
Nope. It was not just because we could. It was an explicit request by
more than one person that we do not put 110+ commands into /usr/bin/.
As for your argument that it should be worth for the users: if you are
really thinking about the users, and not just yourself, you will see that
the receive.denyCurrentBranch change is required.
BTW there is a timeline. Junio said already that it will be in 1.7 and
not earlier.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:12
Hi,
On Mon, 16 Feb 2009, Jeff King wrote:
On Sun, Feb 15, 2009 at 09:55:24PM -0800, david@lang.hm wrote:
quoted
two cycles of changes, not three, so 6-10 years for changes that break
existing bahavior without a _really_ pressing reason. so new
functions, new commands, new flags don't have to wait at all. it's
only if you want to change something that will cause grief for users
if they get a new version and run their existing tools against it.
I think you have to think about _how much_ grief it will cause, too.
Exactly.
BTW I already get angry questions by Git users why this bug -- as they
think about it -- is not fixed in the next Git release, and I patiently
explain that a lot of existing users would get hurt by that change.
And on this list I get flak when pushing for Git users' needs (who will
never be subscribed to the Git list because of the sheer volume).
I guess if both camps would just start to think a little bit about the
other camp's needs, everybody would get a little calmer.
Ciao,
Dscho
From: Martin Mares <mj@ucw.cz> Date: 2016-06-15 22:46:12
Hello, world!\n
Is that the case? mutt at least orders by thread, but by rfc822 date
within a single level of thread. So as long as the date fields (set by
the sender) are correct, it looks right no matter what order they arrive in.
Actually, it matters, because the Date field has limited precision
and it frequently happens that the sender produces several mails
within a single second.
Have a nice fortnight
--
Martin `MJ' Mares [off-list ref] http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Press any key to quit or any other key to continue
please be careful with the term 'deprecated', just becouse you would do
something a different way doesn't make it 'deprecated', that term should
only be used for features that are on their way out of the product, but
haven't been removed yet.
It is not deprecated because I do not like it. Actually, I am pretty
indifferent about the pushing into a non-bare repository.
It is deprecated because a lot of people active in the Git community spend
a real lot of time explaining to a whole bunch of new users on IRC and
recently even on this list why their pushing into a non-bare repository
does not work, and why their suggestions how to solve the issue does not
work either.
if it is the correct thing to do with some workloads, it's not being
deprecated. if it was deprecated then it is a capability that would be
scheduled for complete removal, and nobody should ever use. not just the
case where it needs to be used carefully, and you are putting in a warning
about it.
David Lang
On Mon, Feb 16, 2009 at 16:33, [off-list ref] wrote:
if it is the correct thing to do with some workloads, it's not being
deprecated. if it was deprecated then it is a capability that would be
scheduled for complete removal, and nobody should ever use. not just the
case where it needs to be used carefully, and you are putting in a warning
about it.
Nitpicking much? The reasons why the warning/default-to-disallow are
being put in place have been explained, what value did your message
above add to the discussion? From my point of view it didn't add much,
if anything at all. It might be a good idea to end this thread here,
as Junio requested. If you feel the undying need to continue this
discussion, please do not do so in this thread.
Thank you.
--
Cheers,
Sverre Rabbelier
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:46:13
Jeff King wrote:
On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:
quoted
quoted
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter.
http://article.gmane.org/gmane.comp.version-control.git/109790
I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.
Is that the case? mutt at least orders by thread, but by rfc822 date
within a single level of thread. So as long as the date fields (set by
the sender) are correct, it looks right no matter what order they arrive
in.
Are there common readers that thread but do not order by date?
Thunderbird does it. I haven't found an option to sort by "date sent"
inside threads, .
FWIW, I like this change either way. Deep threading is nice for up to
five or so patches. After that it becomes messy. Shallow threading
simply scales much better, so it's easier to be consistent if that's
the default.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:46:13
Martin Mares wrote:
Hello, world!\n
quoted
Is that the case? mutt at least orders by thread, but by rfc822 date
within a single level of thread. So as long as the date fields (set by
the sender) are correct, it looks right no matter what order they arrive in.
Actually, it matters, because the Date field has limited precision
and it frequently happens that the sender produces several mails
within a single second.
There's no need to have the date field be set to the time the mails were
actually sent though. AFAIR, they get the AUTHOR_DATE now, and I doubt more
than one commit can be authored every second.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Martin Mares <mj@ucw.cz> Date: 2016-06-15 22:46:13
Hello, world!\n
There's no need to have the date field be set to the time the mails were
actually sent though. AFAIR, they get the AUTHOR_DATE now, and I doubt more
than one commit can be authored every second.
Is it really so? Last time I have used git send-email, they got the current
date. It was in Git 1.5.5, though, so it is possible that it has changed since
then.
Have a nice fortnight
--
Martin `MJ' Mares [off-list ref] http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"All that is necessary for the triumph of evil is that good men do nothing." -- E. Burke
From: Jeff King <hidden> Date: 2016-06-15 22:46:13
On Tue, Feb 17, 2009 at 10:06:18AM +0100, Martin Mares wrote:
quoted
There's no need to have the date field be set to the time the mails
were actually sent though. AFAIR, they get the AUTHOR_DATE now, and
I doubt more than one commit can be authored every second.
Is it really so? Last time I have used git send-email, they got the
current date. It was in Git 1.5.5, though, so it is possible that it
has changed since then.
send-email does write a new date header. Which is actually desirable,
IMHO, because otherwise rebased patches would get sent with their
original date, which might very well long in the past (and not only is
that confusing, but it would probably trip spam filters).
-Peff