[RFC - draft] List of proposed future changes that are backward incompatible

[RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

Please use http://git.or.cz/gitwiki/ProjectContacts for this.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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.
> 
> Please use http://git.or.cz/gitwiki/ProjectContacts for this.

By the way, you could blog it^W^W write about it on your blog.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > 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.
>> 
>> Please use http://git.or.cz/gitwiki/ProjectContacts for this.
>
> By the way, you could blog it^W^W write about it on your blog.

Heh, I didn't think many people who need to know (or who would help with)
this follow mine, but it certainly wouldn't hurt.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Heikki Orsila]

On Sun, Feb 15, 2009 at 01:31:50PM -0800, Junio C Hamano wrote:
> * 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

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

disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 01:20:13AM +0200, Heikki Orsila wrote:

> > * 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
> 
> 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

Re: disallowing push to currently checked-out branch

[david]

On Sun, 15 Feb 2009, Jeff King wrote:

> On Mon, Feb 16, 2009 at 01:20:13AM +0200, Heikki Orsila wrote:
>
>>> * 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
>>
>> 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

Re: disallowing push to currently checked-out branch

[david]

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

Re: disallowing push to currently checked-out branch

[Julian Phillips]

On Sun, 15 Feb 2009, david@lang.hm wrote:

> 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.

Re: disallowing push to currently checked-out branch

[Jeff King]

On Sun, Feb 15, 2009 at 05:47:37PM -0800, david@lang.hm wrote:

> as I think about this more I'm puzzled as to why this is an issue.

For background, see:

  http://thread.gmane.org/gmane.comp.version-control.git/100339

  http://thread.gmane.org/gmane.comp.version-control.git/107758

  http://article.gmane.org/gmane.comp.version-control.git/108918

> 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

Re: disallowing push to currently checked-out branch

[Daniel Barkalow]

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*

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> 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".

"git checkout master^0" is shorter ;-)

For people who do not follow the git list regularly, a "HEAD contain the
actual commit" is often called "detached".

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

Junio C Hamano <gitster <at> pobox.com> writes:

> 
> Daniel Barkalow <barkalow <at> iabervon.org> writes:
> 
> > 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".
> 
> "git checkout master^0" is shorter 
> 
> For people who do not follow the git list regularly, a "HEAD contain the
> actual commit" is often called "detached".
> 


Could you have that done automatically?
Namely rather to denying push to a branch b where HEAD->b, when you get such
push you detach head?

Re: disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 10:17:01AM +0000, Sergio Callegari wrote:

> > For people who do not follow the git list regularly, a "HEAD contain the
> > actual commit" is often called "detached".
> 
> Could you have that done automatically?
> Namely rather to denying push to a branch b where HEAD->b, when you get such
> push you detach head?

See

  http://article.gmane.org/gmane.comp.version-control.git/108923

for discussion.

-Peff

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

Jeff King wrote:
> On Mon, Feb 16, 2009 at 10:17:01AM +0000, Sergio Callegari wrote:
>
>   
>>> For people who do not follow the git list regularly, a "HEAD contain the
>>> actual commit" is often called "detached".
>>>       
>> Could you have that done automatically?
>> Namely rather to denying push to a branch b where HEAD->b, when you get such
>> push you detach head?
>>     
>
> See
>
>   http://article.gmane.org/gmane.comp.version-control.git/108923
>
> for discussion.
>
> -Peff
>   
Thanks for the pointer!

However, wrt point 1)

> If you set 'detach' option, this clueless user is not helped; he will
>      happily keep working and would make tons of commits on detached HEAD,
>      and next time he switches to another branch, will lose all of them.
>   
I guess that git does not let you commit on a detached head without 
crying out loud.

Furthermore, one could do just a bit more than detaching, namely store 
the fact that head got detached and the name of the branch where the 
head was.
With this, when the unconscious user types git status or git commit the 
system could alert him that head got detached because someone updated 
the branch behind his shoulders from remote... and then suggest the 
option to either create a new branch from the detached head (I believe 
that this is what gets suggested anyway when one tries to commit from a 
detached head) or to stash the current tree status, get back onto the 
former branch and try applying the changes on the new head of the branch.
The flag triggering this warning at a git status or git commit command 
should then be cleared at the first occasion when the head is changed.

To me this seems natural and helpful. Am I missing something?

Sergio

Re: disallowing push to currently checked-out branch

[Matthieu Moy]

Sergio Callegari <sergio.callegari@gmail.com> writes:

> I guess that git does not let you commit on a detached head without
> crying out loud.

For some definition of "crying out loud" only ;-)

$ git branch
* (no branch)
  master
$ git commit -a -m foo
[detached HEAD b27b4e3] foo
 1 files changed, 1 insertions(+), 2 deletions(-)

-- 
Matthieu

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Mon, 16 Feb 2009, Sergio Callegari wrote:

> Jeff King wrote:
> 
> > If you set 'detach' option, this clueless user is not helped; he will 
> > happily keep working and would make tons of commits on detached HEAD, 
> > and next time he switches to another branch, will lose all of them.
>
> I guess that git does not let you commit on a detached head without 
> crying out loud.

Wrong.  It cries out loud when you detach, not when you commit to a 
detached HEAD.  For good reason: Already at the second commit it would 
stop being funny.

> Furthermore, one could do just a bit more than detaching, namely store 
> the fact that head got detached and the name of the branch where the 
> head was. With this, when the unconscious user types git status or git 
> commit the system could alert him that head got detached because someone 
> updated the branch behind his shoulders from remote...

And of course, you need a way to show the user all the updates the branch 
went through while the HEAD was detached, so that the user has a chance of 
understanding what happened in the meantime.

So much additional work, just to fix up the shortcomings of the 'detach' 
paradigm?  I take it as a clear mark of a not-so-elegant design.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Mon, Feb 16, 2009 at 12:43 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> And of course, you need a way to show the user all the updates the branch
> went through while the HEAD was detached, so that the user has a chance of
> understanding what happened in the meantime.
>
> So much additional work, just to fix up the shortcomings of the 'detach'
> paradigm?  I take it as a clear mark of a not-so-elegant design.

You did plant a seed in my head with PUSH_HEAD though, and I'm still
thinking about it. :-)

I think the right thing is *not to detach*, but rather when pushing
into a non-bare repo for it to go into refs/remotes. Too bad clone
doesn't set it up this way by default when cloning from a non-bare
repo[*]. That would probably make more sense for new users.

[*] Clone can't currently know it's cloning from a non-bare repo, at
least via git://, as I recall...

j.

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Mon, 16 Feb 2009, Jay Soffian wrote:

> I think the right thing is *not to detach*, but rather when pushing
> into a non-bare repo for it to go into refs/remotes.

I do not think that is consistent.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Mon, Feb 16, 2009 at 3:02 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 16 Feb 2009, Jay Soffian wrote:
>
>> I think the right thing is *not to detach*, but rather when pushing
>> into a non-bare repo for it to go into refs/remotes.
>
> I do not think that is consistent.

Not consistent with what?

So let's say I have a workstation and a laptop. The "sane" thing to do
is probably something like this:

workstation$ mkdir project && cd project && git init
workstation$ (add, commit, ...)
workstation$ git clone --bare . ../project.git
workstation$ git remote add origin ../project.git
laptop$ git clone ssh://workstation/~/project.git project

And now I have two non-bare working repos with the intermediate bare
repo. So at both ends I can push/pull in the way that the designers of
git had in mind. :-)

But I don't think this recipe is well documented for beginners. So
they end up w/o the intermediate bare repository, and all the ensues.

IOW, I think pushing into refs/remotes makes sense in the situation
where the user has two non-bare repos that they want to exchange
commits between.

j.

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Mon, 16 Feb 2009, Jay Soffian wrote:

> On Mon, Feb 16, 2009 at 3:02 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 16 Feb 2009, Jay Soffian wrote:
> >
> >> I think the right thing is *not to detach*, but rather when pushing 
> >> into a non-bare repo for it to go into refs/remotes.
> >
> > I do not think that is consistent.
> 
> Not consistent with what?

With pushing into bare repositories.  And worse, with the existing mode of 
operation.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> Not consistent with what?
>
> With pushing into bare repositories.  And worse, with the existing mode of
> operation.

I don't understand why pushing into a bare repo should have the same
behavior as pushing into a non-bare repo. They are different workflows
after-all.

j.

Re: disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 05:28:38PM -0500, Jay Soffian wrote:

> On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> Not consistent with what?
> >
> > With pushing into bare repositories.  And worse, with the existing mode of
> > operation.
> 
> I don't understand why pushing into a bare repo should have the same
> behavior as pushing into a non-bare repo. They are different workflows
> after-all.

Actually, I think it is pulling from the non-bare repo that will get
confusing.

You are proposing to push, when pushing into a non-bare repo, into a
push refspec like refs/incoming/ (for example). But what is your fetch
refspec?

If it fetches as usual from refs/heads/, then you have an asymmetry.
That is, if I do "git push" on one client, then "git pull" on another
won't fetch the changes. I have to wait for the non-bare repo to pull
them into its refs/heads/ hierarchy (one by one, if there are multiple
branches).

So you can try putting refs/incoming into your fetch refspec if it is a
non-bare repo. But there are two issues there:

  - how do you know the remote is non-bare?

  - now you have to "push" in the non-bare upstream in order to make
    commits available. So it no longer works to do:

       workstation$ cd repo && hack hack hack && commit commit commit
       laptop$ git clone workstation:repo

    since you will silently end up with stale results.

    In some ways, this is nicely rigorous: non-bare repos become
    essentially "uncontactable" remotely, and you have a de facto bare
    repo in the form of refs/incoming sitting in between. But I'm not
    sure it matches what most users want to do, and certainly it causes
    more breakage to their workflows than receive.denyCurrentBranch.

-Peff

Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Mon, Feb 16, 2009 at 5:52 PM, Jeff King <peff@peff.net> wrote:
> Actually, I think it is pulling from the non-bare repo that will get
> confusing.
>
> You are proposing to push, when pushing into a non-bare repo, into a
> push refspec like refs/incoming/ (for example). But what is your fetch
> refspec?
>
> If it fetches as usual from refs/heads/, then you have an asymmetry.
> That is, if I do "git push" on one client, then "git pull" on another
> won't fetch the changes. I have to wait for the non-bare repo to pull
> them into its refs/heads/ hierarchy (one by one, if there are multiple
> branches).
>
> So you can try putting refs/incoming into your fetch refspec if it is a
> non-bare repo. But there are two issues there:
>
>  - how do you know the remote is non-bare?
>
>  - now you have to "push" in the non-bare upstream in order to make
>    commits available. So it no longer works to do:
>
>       workstation$ cd repo && hack hack hack && commit commit commit
>       laptop$ git clone workstation:repo
>
>    since you will silently end up with stale results.
>
>    In some ways, this is nicely rigorous: non-bare repos become
>    essentially "uncontactable" remotely, and you have a de facto bare
>    repo in the form of refs/incoming sitting in between. But I'm not
>    sure it matches what most users want to do, and certainly it causes
>    more breakage to their workflows than receive.denyCurrentBranch.

My head is playing around with two ideas now that Dscho has mentioned:

receive.localBranches = (refuse | allow)

http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065

And PUSH_HEAD.

The idea would be for side-pushes never to update a local branch, but
to be recorded in PUSH_HEAD. You'd be able to rebase/merge local
branch on-top of changes in PUSH_HEAD. I'm trying to figure out what
can make sense when pulling from such a repo.

j.

PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Tue, 17 Feb 2009, Jay Soffian wrote:

> My head is playing around with two ideas now that Dscho has mentioned:
> 
> receive.localBranches = (refuse | allow)
> 
> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065

In the meantime, we have receive.denyCurrentBranch, which is much superior 
to the localBranches design: it tackles the _real_ issue -- the only 
reason why a current branch cannot be updated lightly is that it might 
have a working directory which would be forced out-of-sync.

> And PUSH_HEAD.
> 
> The idea would be for side-pushes never to update a local branch, but to 
> be recorded in PUSH_HEAD. You'd be able to rebase/merge local branch 
> on-top of changes in PUSH_HEAD. I'm trying to figure out what can make 
> sense when pulling from such a repo.

Sorry, I should clarify what I mean by PUSH_HEAD:

The idea is to have the _same_ as FETCH_HEAD, i.e. a simple file 
(.git/FETCH_HEAD) listing all the branch tips that have been pushed, _no 
matter_ if they were successfully stored as refs.

Just do this in a repository which is lagging behind origin a little:

	$ git fetch origin

and then see that a file .git/FETCH_HEAD exists.  As long as you are only 
interested in the first rev, you can even use "FETCH_HEAD" as a rev name:

	$ git show FETCH_HEAD

The important feature of this method is that FETCH_HEAD is not fetchable.  
Neither 'ls-remote' nor 'branch' will show it.

BTW a PUSH_HEAD could also help the issue that when updating of a ref was 
refused, all the objects will have to be transferred via the wire again 
when pushing somewhere else.

Having said all that, I can easily live without PUSH_HEAD.

Ciao,
Dscho

Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Tue, Feb 17, 2009 at 6:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> receive.localBranches = (refuse | allow)
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065
>
> In the meantime, we have receive.denyCurrentBranch, which is much superior
> to the localBranches design: it tackles the _real_ issue -- the only
> reason why a current branch cannot be updated lightly is that it might
> have a working directory which would be forced out-of-sync.

Hmpfh.

So both you and Junio have changed your mind since that thread then.
Because in that thread, you propose  receive.guardCurrentBranch, which
was quite similar to today's receive.denyCurrentBranch. Junio then
argues that treating just the checked-out branch as special, as
opposed to all local branches is not the right thing to do:

--- snip ---
http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

Step back a bit and think _why_ you wanted to prevent current branch tip
from getting updated in the first place.  There are two issues:

 * Why is it _current_ branch, and not _these branches_, that can be
   configured by the user to be protected from a push from sideways?

 * Why is it undesirable for the work tree and the index to go out of sync
   with respect to the branch tip to begin with?

The latter is simpler to answer, so let's deal with it first.  The reason
why it is bad is because allowing a push to the current branch interferes
with the work actively being done in the repository, using the work tree
contents.  There is a person, you, who is actively editing the work tree
in order to advance the tip of the branch by making commits.  If the
branch tip moves without your knowing, that destabilizes your working
environment.  Your work tree wanted to make a new commit on top of some
known state, but that state was moved underneath you.  Not good.

When you are using the repository for real work (i.e. advance the tips of
its branches), you want a stable environment.  You do not want its HEAD
bobbing around outside your control, and silently detaching to cause your
later commits to go to unnamed branch without your knowing is just as bad
(which you already correctly objected to).
--- snip ---

And you end up agreeing:

--- snip ---
http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

> Now think.  What if one of these operations you do in the repository to
> advance the tip was to merge from one of _your_ local branches?  Yes,
> you end up merging something you did not expect to merge if you allowed
> a push from sideways to affect that local branch, only because the
> branch happened to be un-checked-out and you implemented this protection
> to forbid only to current branch.  Allowing a push from sideways to any
> local branch destabilizes your work environment, not just the current
> one.

Okay, I am starting to see the light.

How about

	receive.localBranches = (refuse | allow)
--- snip ---

Then the thread died, with receive.localBranches going into TODO, but
never got an implementation. Sometime later, receive.denyCurrentBranch
came along, which is the original idea you proposed, Junio argued
against, and then you agreed.

So, I'm not sure what happened in the intervening time between the
receive.localBranches proposal and the receive.denyCurrentBranch
implementation that suddenly what is basically guardCurrentBranch
became a good idea.

But, I happen to agree with Junio's argument in gmane 77955.

j.

Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Jeff King]

On Tue, Feb 17, 2009 at 12:29:53PM -0500, Jay Soffian wrote:

> So both you and Junio have changed your mind since that thread then.
> Because in that thread, you propose  receive.guardCurrentBranch, which
> was quite similar to today's receive.denyCurrentBranch. Junio then
> argues that treating just the checked-out branch as special, as
> opposed to all local branches is not the right thing to do:

I have to admit, I found that thread a very interesting read, because I
somehow missed it the first time and it seemed the opposite of what
happened later.

> So, I'm not sure what happened in the intervening time between the
> receive.localBranches proposal and the receive.denyCurrentBranch
> implementation that suddenly what is basically guardCurrentBranch
> became a good idea.

I think what happened (partially) is that I never read the original,
then at GitTogether somebody (Sam?) was complaining about usability
issues, so I wrote the denyCurrentBranch patch. Why and how people
changed their minds is a mystery to me, though.

-Peff

PS I seem to have an uncanny knack for writing a patch, then finding out
that Dscho wrote the exact same patch months or years earlier. I think
this is the third time it has happened.

Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> So both you and Junio have changed your mind since that thread then.

At least I didn't.

I personally was not too worried about protecting either local branches
nor the current branch (and I do not lose sleep over them now either).
Either is about forbidding an end user who knows from doing an operation
we have allowed so far, only because an abuse of the feature by other end
users who either don't know what they are doing or are careless can result
in confusing the latter.  I do not particularly like that kind of safety
valve.

The current round of protecting only local branches is there because it is
of much lessor impact, with simpler code (and easier revertibility if
needed), than the full blown "protect these branches" one in which issues
in its design still has to be ironed out if we go that route (see my other
message from yesterday to Jeff --- we discuss exactly that in the context
of detached HEAD and other operations).  The need for "current branch
protection" this round implements also comes from an observed confusions
in real world users Dscho and others saw on #git and other places.  The
more general "protect these branches" is conceptually nicer but the need
for such safeguard is still under discussion as far as I understood what
was said in the recent discussions.

Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Tue, Feb 17, 2009 at 5:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> So both you and Junio have changed your mind since that thread then.
>
> At least I didn't.

Ah, I didn't mean to mischaracterize your intent from that thread then.

> I personally was not too worried about protecting either local branches
> nor the current branch (and I do not lose sleep over them now either).
> Either is about forbidding an end user who knows from doing an operation
> we have allowed so far, only because an abuse of the feature by other end
> users who either don't know what they are doing or are careless can result
> in confusing the latter.  I do not particularly like that kind of safety
> valve.
>
> The current round of protecting only local branches is there because it is
> of much lessor impact, with simpler code (and easier revertibility if
> needed), than the full blown "protect these branches" one in which issues
> in its design still has to be ironed out if we go that route (see my other
> message from yesterday to Jeff --- we discuss exactly that in the context
> of detached HEAD and other operations).  The need for "current branch
> protection" this round implements also comes from an observed confusions
> in real world users Dscho and others saw on #git and other places.  The
> more general "protect these branches" is conceptually nicer but the need
> for such safeguard is still under discussion as far as I understood what
> was said in the recent discussions.

Okay, that makes sense.

j.

Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Tue, 17 Feb 2009, Jay Soffian wrote:

> So both you and Junio have changed your mind since that thread then.

I never claimed to be unable to learn.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

Johannes Schindelin wrote:
> Wrong.  It cries out loud when you detach, not when you commit to a 
> detached HEAD.  For good reason: Already at the second commit it would 
> stop being funny.
>   
Right, I was wrong in expecting complaints. But... if it cried out at 
the first commit, for many people there would probably not be a second. 
Btw, I am ignorant on this: is there some case where one wants and has 
reasons to commit to a detached head before making a temporary branch on it?
>   
>> Furthermore, one could do just a bit more than detaching, namely store 
>> the fact that head got detached and the name of the branch where the 
>> head was. With this, when the unconscious user types git status or git 
>> commit the system could alert him that head got detached because someone 
>> updated the branch behind his shoulders from remote...
>>     
>
> And of course, you need a way to show the user all the updates the branch 
> went through while the HEAD was detached, so that the user has a chance of 
> understanding what happened in the meantime.
>   
> So much additional work, just to fix up the shortcomings of the 'detach' 
> paradigm?  I take it as a clear mark of a not-so-elegant design.
>   
Well not that much additional work...

when you push to the checked out branch, head gets detached and branch 
name (say /ref/heads/master) gets stored (say in .git/pre_push_branch).
when you run status or commit, you realize that there is a 
pre_push_branch and you give the warning, saying what the 
pre_push_branch was.
Now, since before the push you were at the tip of that branch, to know 
what happened it should be enough to ask the log (or the diff) from 
pre_push_branch to HEAD.
At the first user command that moves HEAD, pre_push_branch should get 
deleted.
Btw, what does happen now if you delete the branch the remote worktree 
is on? Don't you get a "dangling" head pointing to a non-existing branch 
and the system claiming that it is at the initial commit? Maybe, this 
too is a bit inelegant. In the other scenario, you would get a detached 
head and in pre_push_branch the info the name of a no more existing 
branch (mainig clear that you were on a branch that got deleted) and 
this info could be returned to the user.

Of course, I am not claiming that forbidding pushes to branches with 
checked out tree is bad. It is a good idea in my opinion.
I am just suggesting that one still wanting to allow that push in spite 
of all the potential consequences (namely wanting to mess with the 
relevant config variable), might prefer detaching head, storing the 
pre_push_branch and getting some info on status and commit rather than 
merely allowing the push.

In fact, I believe that the point is that with the current push-allowing 
behavior, when the push happens you loose the information about the 
precise commit against which the changes in the worktree were made. 
Which might be a useful piece of info.

Ciao,

Sergio

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Mon, 16 Feb 2009, Sergio Callegari wrote:

> Johannes Schindelin wrote:
> > Wrong.  It cries out loud when you detach, not when you commit to a 
> > detached HEAD.  For good reason: Already at the second commit it would 
> > stop being funny.
>
> Right, I was wrong in expecting complaints. But... if it cried out at 
> the first commit, for many people there would probably not be a second. 

What you are suggesting, though, is that the _pusher_ detaches the HEAD.  
So the _local_ user will never know.

> Btw, I am ignorant on this: is there some case where one wants and has 
> reasons to commit to a detached head before making a temporary branch on 
> it?

Yes.  When you try fixups on a commit you just jumped to, for example.  Or 
when bisecting.

I often use the detached HEAD as kind of a stash during a bisect.  I try 
to fix it there, at the bad commit, and then cherry-pick HEAD@{1} into 
the branch after resetting the bisect.

> > > Furthermore, one could do just a bit more than detaching, namely 
> > > store the fact that head got detached and the name of the branch 
> > > where the head was. With this, when the unconscious user types git 
> > > status or git commit the system could alert him that head got 
> > > detached because someone updated the branch behind his shoulders 
> > > from remote...
> >
> > And of course, you need a way to show the user all the updates the branch
> > went through while the HEAD was detached, so that the user has a chance of
> > understanding what happened in the meantime.
> >
> > So much additional work, just to fix up the shortcomings of the 
> > 'detach' paradigm?  I take it as a clear mark of a not-so-elegant 
> > design.
>   
> Well not that much additional work...
> 
> when you push to the checked out branch, head gets detached and branch name
> (say /ref/heads/master) gets stored (say in .git/pre_push_branch).
> when you run status or commit, you realize that there is a pre_push_branch and
> you give the warning, saying what the pre_push_branch was.

Of course, you assume there that it was only one push between detaching 
the HEAD and inspecting the mess.

> Now, since before the push you were at the tip of that branch, to know 
> what happened it should be enough to ask the log (or the diff) from 
> pre_push_branch to HEAD. At the first user command that moves HEAD, 
> pre_push_branch should get deleted.

And you call that not much work?

> Btw, what does happen now if you delete the branch the remote worktree 
> is on?

See the related discussion of receive.denyDeleteCurrent.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Jay Soffian]

On Mon, Feb 16, 2009 at 3:09 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> What you are suggesting, though, is that the _pusher_ detaches the HEAD.
> So the _local_ user will never know.

I'm going to be presumptuous here and say that I think that you're
thinking about this the wrong way.

I would wager that when someone is pushing into a non-bare repo, it is
very likely that the pusher and the local user are the same person.
i.e., there are two common combinations: 1) a shared bare repo; 2) an
individual (non-shared) non-bare repo.

I think it is the shared non-bare repo which is rather uncommon, and
used mostly by advanced users or for specialized situations like
publishing web-roots.

If I'm right, then I still think that what might better sense is:


non-bare repo                     non-bare repo
-------------------               ---------------------
refs/heads            ---push-->  refs/remotes/incoming
   ^                                     |
   |                                   merge
 merge                                   |
   |                                     v
refs/remotes/origin   <--fetch--  refs/heads


Yes, you can set this up, but it is quite a few extra steps to do so.
The defaults assume there is a bare repo that you're pulling/pushing
from/to, hence the confusion for new users when that's not the
scenario they are in.

But instead of all this talk, maybe I should pony up some RFC patches. :-)

j.

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

Johannes Schindelin wrote:
> What you are suggesting, though, is that the _pusher_ detaches the HEAD.  
> So the _local_ user will never know.
>
>   
I am not sure that I get what you mean.  But if I get it right, the only 
reason why the local
user cannot know is precisely because "git commit" does not complain if 
you call it from a detached head.
Otherwise the local user would find out that a push happened behind his 
shoulder right at the first "status" or "commit", as he was expecting to 
be on a branch and he finds himself off it.
>> Btw, I am ignorant on this: is there some case where one wants and has 
>> reasons to commit to a detached head before making a temporary branch on 
>> it?
>>     
>
> Yes.  When you try fixups on a commit you just jumped to, for example.  Or 
> when bisecting.
>
> I often use the detached HEAD as kind of a stash during a bisect.  I try 
> to fix it there, at the bad commit, and then cherry-pick HEAD@{1} into 
> the branch after resetting the bisect.
>
>   
Interesting.  But it is sort of abusing the detached head thing, isn't 
it? You use it as a temporary unnamed branch, and it becomes the tip of 
a short-lived development burst... It is not anymore just a way to peek 
at some status as I remember it was initially introduced, is it?
>>>> Furthermore, one could do just a bit more than detaching, namely 
>>>> store the fact that head got detached and the name of the branch 
>>>> where the head was. With this, when the unconscious user types git 
>>>> status or git commit the system could alert him that head got 
>>>> detached because someone updated the branch behind his shoulders 
>>>> from remote...
>>>>         
>>> And of course, you need a way to show the user all the updates the branch
>>> went through while the HEAD was detached, so that the user has a chance of
>>> understanding what happened in the meantime.
>>>
>>> So much additional work, just to fix up the shortcomings of the 
>>> 'detach' paradigm?  I take it as a clear mark of a not-so-elegant 
>>> design.
>>>       
>>   
>> Well not that much additional work...
>>
>> when you push to the checked out branch, head gets detached and branch name
>> (say /ref/heads/master) gets stored (say in .git/pre_push_branch).
>> when you run status or commit, you realize that there is a pre_push_branch and
>> you give the warning, saying what the pre_push_branch was.
>>     
>
> Of course, you assume there that it was only one push between detaching 
> the HEAD and inspecting the mess.
>   
After the first push, the head is already detached, so pre_push_branch 
does not get touched by the second, the third, the forth push, etc...
Which I guess is what the local user should want. He expected to be at 
some commit at the tip of some branch and he needs to find out what has 
happened between that commit and the new tip of that branch. Does he 
really need to know in how many and what precise push operations the 
branch tip moved?

>> Now, since before the push you were at the tip of that branch, to know 
>> what happened it should be enough to ask the log (or the diff) from 
>> pre_push_branch to HEAD. At the first user command that moves HEAD, 
>> pre_push_branch should get deleted.
>>     
>
> And you call that not much work?
>
>   
>> Btw, what does happen now if you delete the branch the remote worktree 
>> is on?
>>     
>
>   
I tried.  With current git 1.6.1.3,  head remains pointing at a non 
existent branch and git status thinks that you need to do your initial 
commit.
When you commit, the deleted branch is immediately recreated from 
scratch and you loose the history that got you at that status.

Which brings me back to my former consideration.

I initially thought of detaching head because it looks like a way to 
save a bit of info that I would like to see preserved.  When someone 
pushes in my repo, if my current branch tip moves, at the first action 
that I attempt on the repo I would like to see a big alert that it did 
and have an easy way to find out at what commit I was before the push 
happened.  Otherwise, I cannot really find out what the push precisely 
changed, I cannot easily revert it if it was wrong, etc.

Sergio

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Tue, 17 Feb 2009, Sergio Callegari wrote:

> Johannes Schindelin wrote:
>
> > What you are suggesting, though, is that the _pusher_ detaches the 
> > HEAD.  So the _local_ user will never know.
>
> the only reason why the local user cannot know is precisely because "git 
> commit" does not complain if you call it from a detached head.

No, the only reason is that you sneakily detached the HEAD behind his 
back.  It is not possible in physical life -- at least not without the 
owner of the head noticing -- and it should not be possible with Git, 
either.

All this "we need more complaining" is just a fix up for a failed design.

> > > Btw, I am ignorant on this: is there some case where one wants and 
> > > has reasons to commit to a detached head before making a temporary 
> > > branch on it?
> >
> > Yes.  When you try fixups on a commit you just jumped to, for example.  
> > Or when bisecting.
> >
> > I often use the detached HEAD as kind of a stash during a bisect.  I 
> > try to fix it there, at the bad commit, and then cherry-pick HEAD@{1} 
> > into the branch after resetting the bisect.
>
> Interesting.  But it is sort of abusing the detached head thing, isn't 
> it? You use it as a temporary unnamed branch,

That is exactly what a detached HEAD is.

> > Of course, you assume there that it was only one push between 
> > detaching the HEAD and inspecting the mess.
>
> After the first push, the head is already detached, so pre_push_branch 
> does not get touched by the second, the third, the forth push, etc...

Oh, so the user should be really fscked for not realizing just how much 
happened in the meantime?

> > > Now, since before the push you were at the tip of that branch, to 
> > > know what happened it should be enough to ask the log (or the diff) 
> > > from pre_push_branch to HEAD. At the first user command that moves 
> > > HEAD, pre_push_branch should get deleted.
>
> > And you call that not much work?

That point is still valid.  If you have to do too much to make your idea 
work, if you have to bolt on this and that, it is a sure sign that the 
design is borked.

> > > Btw, what does happen now if you delete the branch the remote 
> > > worktree is on?
>
> I tried.  With current git 1.6.1.3, head remains pointing at a non 
> existent branch and git status thinks that you need to do your initial 
> commit. When you commit, the deleted branch is immediately recreated 
> from scratch and you loose the history that got you at that status.

As I remarked already, this is a bug that is actively being squashed.

Of course, you can go on and on and on with the detached HEAD ide, but so 
far you haven't convinced me that this is a sensible thing to do.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

Johannes Schindelin wrote:
> Of course, you can go on and on and on with the detached HEAD ide, but so 
> far you haven't convinced me that this is a sensible thing to do.
>   
I will not... it's time to sleep where I am! And I am just a user of git 
and you are a developer, which makes me think that you might know much 
better.
But the exchange was insightful, thanks.

Rather, I'll turn again the question...

Let us assume that I am working on branch B and that my worktree is 
based on commit XYZ. Let's also assume that someone pushes behind my 
shoulders and moves the tip of B (or even deletes B alltogether) either 
in one or in multiple pushes.  Is there an easy way so that I can now 
find out at what commit (XYZ) I was before the push(es)?  That would 
already make me quite satisfied, because with this I can write wrappers 
or aliases that can check the HEAD against that commit on every 
status/commit operation and warn the user just in case.

Sergio

> Ciao,
> Dscho
>
>   

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Tue, 17 Feb 2009, Sergio Callegari wrote:

> Let us assume that I am working on branch B and that my worktree is based on
> commit XYZ. Let's also assume that someone pushes behind my shoulders and
> moves the tip of B (or even deletes B alltogether) either in one or in
> multiple pushes.  Is there an easy way so that I can now find out at what
> commit (XYZ) I was before the push(es)?

Nope.  There was code flying around at some stage to record in the index 
what commit it was based on.

I forgot why it was thrown out again; you'll have to look up the 
discussion yourself.

Ciao,
Dscho

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Nope.  There was code flying around at some stage to record in the index 
> what commit it was based on.
>
> I forgot why it was thrown out again; you'll have to look up the 
> discussion yourself.

A good starting point may be:

    http://article.gmane.org/gmane.comp.version-control.git/67089/
    http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508

It is frustrating that I cannot seem to find a way to tell gmane to "jump
to approximately this timeperiod", but right now, the thread appears at
around 635th page from the tip.  By the time you read this message you may
have to flip a bit more pages, though ;-)

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Sergio Callegari <sergio.callegari@gmail.com> writes:

> Johannes Schindelin wrote:
>> Of course, you can go on and on and on with the detached HEAD ide,
>> but so far you haven't convinced me that this is a sensible thing to
>> do.
>>
> I will not... it's time to sleep where I am! And I am just a user of
> git and you are a developer, which makes me think that you might know
> much better.
> But the exchange was insightful, thanks.
>
> Rather, I'll turn again the question...
>
> Let us assume that I am working on branch B and that my worktree is
> based on commit XYZ. Let's also assume that someone pushes behind my
> shoulders and moves the tip of B (or even deletes B alltogether)
> either in one or in multiple pushes.  Is there an easy way so that I
> can now find out at what commit (XYZ) I was before the push(es)?

I am afraind that you are going on-and-on-and-on Dscho warned you about.

What commit XYZ your next commit should build on is already recorded by
HEAD (which in turn often refers to the tip of the branch you have checked
out by pointing at it).

HEAD (and the tip of the branch) is *supposed* to be updated by operations
you do from the work tree *alone*, not by push from sideways.  Therefore
there is no such duplicated information kept.

The index is an obvious place to save that duplicated information if you
really wanted to, and you are welcome to try it again, but I have to warn
you that we have already tried this once and the fallout was not very
pretty.

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Sergio Callegari <sergio.callegari@gmail.com> writes:

> ... is there some case where one wants
> and has reasons to commit to a detached head before making a temporary
> branch on it?

Absolutely. I do it all the time for minor fix-ups after applying other's
patches on a newly created topic branch.

If you want a push to the current branch of _your_ repository detach HEAD
automatically and record which branch it was pointing at before you
detached, I am reasonably sure you can do that in post-receive hook, no?

I do not think it is such a bad thing to have a new value 'detach' to
receive.denyCurrentBranch as a possible non-default choice per-se, but the
earlier discussion Jeff pointed out is only showing that detaching alone
is not enough to help the user recover from the resulting state, and Dscho
discussed in this thread that detaching and recording the original branch
may not be enough either.  IOW, we do not know yet precisely what needs to
happen other than detaching HEAD when the configuration tells us to
'detach' to be useful.

So how about you experiment the workflow by setting the configuration to
'ignore', setting up a hook to detach _and do some other useful things_ as
necessary, and help all of us figuring out what other information is
useful to record when you receive such a push, and what new indications
you could give users to reduce the possibility of confusion?  Once we know
what we want to happen, we can have it as one of the canned choices and it
would help users.

Re: disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 01:43:03PM -0800, Junio C Hamano wrote:

> Sergio Callegari <sergio.callegari@gmail.com> writes:
> 
> > ... is there some case where one wants
> > and has reasons to commit to a detached head before making a temporary
> > branch on it?
> 
> Absolutely. I do it all the time for minor fix-ups after applying other's
> patches on a newly created topic branch.

This question got me thinking. At the time that detached HEAD was
introduced, I argued for a loud warning message, claiming that for most
users, commiting on a detached HEAD was dangerous and unintentional and
there _should_ be a big warning message. And like then, committing on a
detached HEAD is still not something I generally do.

But then I realized there is actually one time: during interactive
rebase, which detaches HEAD during the rebase processs, and then puts
the final detached value back into the branch ref for you (or not, if
you abort).

Which made me think how such a process interacts with pushing into a
non-bare repo. If we are detached, the push cannot, by definition, touch
the ref pointed to by HEAD, since ther isn't one. But there is still
some sense of "current branch" recorded by rebase; after the rebase is
completed, it attempts to put a new value in the ref.

So this is still some conflict possible even with the current safety
valves. Fortunately, the ref update is smart enough to realize the value
has changed behind our back:

  $ git rebase --continue
  error: Ref refs/heads/master is at 5836aa51b217a1c88f32107cbcd606bece018657 but expected d2d7bf3fcaa927ef997dbcdaf9d9a9e176d6a8d0
  fatal: Cannot lock the ref 'refs/heads/master'.

But that doesn't give any hint to the user about what happened, or how
to fix it.

So:

  1. How can we improve this situation?

     One option is including "the branch we are rebasing on" in the list
     of refs to deny. I don't like that, though, because that becomes an
     ever-growing list of places for receive-pack to look, some of which
     are not even part of core git.

     I think the best bet is just detecting the situation (which we
     already do) and giving a sane recipe for resolution. Probably
     something like:

        git branch incoming master ;# stash newly pushed changes
        git branch -f master $old_sha1 ;# restore previous state
        git rebase --continue ;# finish the rebase
        git merge incoming ;# pull in the pushed changes

  2. Are there other "we are implicitly assuming $ref won't change
     behind our backs" long-term commands?

-Peff

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>   1. How can we improve this situation?

The situation you described is all about "don't allow a push that is NOT
CONTROLLED BY YOU and that can interfere with what you are doing into a
live repository", and you are right, we have operations that deliberately
detach the HEAD and expect nobody mucks with the branch.

But is this something even worth considering about in the same context as
the denyCurrentBranch?  The same thing can happen even if you are not
detaching HEAD.

For example, I sometimes end up with an ugly series on a branch, whose
endpoint is a good looking tree.  And a refactoring I would want to do
would be too cumbersome for the interactive rebase (I could do it, but the
machinery does not help as much as it would for a simpler case).  In such
a case, often I would just say:

	$ git branch -f goal
        $ git reset --hard master
        : repeat from here until "diff HEAD goal" becomes empty
        ... cherry-pick $a_commit_in_goal_branch, or
        ... edit "show $a_commit_in_goal_branch" output and apply, or
        ... edit the files in place.
        ... make a commit, perhaps using -c $a_commit_in_goal_branch
	: repeat up to here

I would not push into this repository to update the branch "goal" while I
am doing this, as it will obviously screw up the whole process.  I think
it is the same thing that you would not push from elsewhere to update the
branch you are in the middle of interactively rebasing.  Mucking with the
same repository from two different places at the same time, when you know
there can be only one version of a work tree that is checked out, is
simply insane.

It's just a common sense thing.  What denyCurrentBranch protects you from
is a push from elsewhere *while* you are not there, and then next day,
getting confused by what such a push did in the receiving repository.  In
that scenario, you are not mucking with the receiving repository from two
places at the same time, but still you can get your repository into a
confusing state, and it is worth protecting new people from.

Obviously you can tell receive-pack to refuse pushing into a non-bare
repository, with a "I know what I am doing" configuration, but I think at
that point the whole "you could break things this way, so let's prevent a
new user from making such mistake" goes into the realm of absurdity.

Re: disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 03:23:00PM -0800, Junio C Hamano wrote:

> >   1. How can we improve this situation?
> 
> The situation you described is all about "don't allow a push that is NOT
> CONTROLLED BY YOU and that can interfere with what you are doing into a
> live repository", and you are right, we have operations that deliberately
> detach the HEAD and expect nobody mucks with the branch.

I don't agree that it has to be a push not controlled by you. I have
many times left a rebase-in-progress sitting in a repository, either
accidentally because I meant to "--abort" it after a conflict but
forgot, or because I got interrupted during an interactive edit and
needed to come back to it.

So the problem is simply that the repository you're pushing into is not
in the state you think it is (either because you forgot what state you
left it in, didn't realize what state you left it in, or because it is
somebody else's repo).

> But is this something even worth considering about in the same context as
> the denyCurrentBranch?  The same thing can happen even if you are not
> detaching HEAD.

I don't think it's the same, but I think it is a related problem. I
don't think the solutions are related, though.

> For example, I sometimes end up with an ugly series on a branch, whose
> endpoint is a good looking tree.  And a refactoring I would want to do
> would be too cumbersome for the interactive rebase (I could do it, but the
> machinery does not help as much as it would for a simpler case).  In such
> a case, often I would just say:
> 
> 	$ git branch -f goal
>         $ git reset --hard master
>         : repeat from here until "diff HEAD goal" becomes empty
>         ... cherry-pick $a_commit_in_goal_branch, or
>         ... edit "show $a_commit_in_goal_branch" output and apply, or
>         ... edit the files in place.
>         ... make a commit, perhaps using -c $a_commit_in_goal_branch
> 	: repeat up to here
> 
> I would not push into this repository to update the branch "goal" while I
> am doing this, as it will obviously screw up the whole process.  I think

OK, that is a good example of how this is basically impossible to
protect from fully (and a good argument why pushing into a repo used for
work is probably not a good idea in general). I think the rebase example
is a little worse because:

  - It's subtle. with denyCurrentBranch, we generally protect the user
    from pushing into the current branch and messing things up. But
    during a rebase we don't, and the only way the user would realize
    that is if they understand that rebasing happens on a detached HEAD.

  - the error message is confusing, and there is no clear way out of the
    error case. You can "rebase --abort" which throws away your rebase
    work _and_ the push.  But what you probably want to do, I described
    earlier.

> It's just a common sense thing.  What denyCurrentBranch protects you from
> is a push from elsewhere *while* you are not there, and then next day,
> getting confused by what such a push did in the receiving repository.  In

See above for why I think this can happen while you are not there. It is
about repo state for long-running workflows. I'm not too concerned with
somebody pushing in the exact half second while you are making running
"git commit".

> Obviously you can tell receive-pack to refuse pushing into a non-bare
> repository, with a "I know what I am doing" configuration, but I think at
> that point the whole "you could break things this way, so let's prevent a
> new user from making such mistake" goes into the realm of absurdity.

I think that is insane, too. This is not all that likely to happen
compared to the possible benefits of pushing into a non-bare repo. And
as you say, in most cases common sense rules: don't push into something
you are actively working on.

I am really just proposing that the "ref was not what we expected"
message to better indicate what is going on, and how the user might get
out of it. Do you not agree with that?

-Peff

Re: disallowing push to currently checked-out branch

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Feb 16, 2009 at 03:23:00PM -0800, Junio C Hamano wrote:
>
>> >   1. How can we improve this situation?
>> 
>> The situation you described is all about "don't allow a push that is NOT
>> CONTROLLED BY YOU and that can interfere with what you are doing into a
>> live repository", and you are right, we have operations that deliberately
>> detach the HEAD and expect nobody mucks with the branch.
>
> I don't agree that it has to be a push not controlled by you. I have
> many times left a rebase-in-progress sitting in a repository, either
> accidentally because I meant to "--abort" it after a conflict but
> forgot, or because I got interrupted during an interactive edit and
> needed to come back to it.

That sounds similar to saying "I left my editor open without saving my
changes, and accidentally opened another instance of an editor from a
different terminal and edited the same file, the result is a mess".  The
editors protect users from such a situation by locking the file they are
editing.

Perhaps operations that detaches HEAD (rebase and perhaps sequencer) can
all agree to use a single marker file that says "Do not mess with these
refs via push or fetch" and make receive-pack and fetch honor that?  Then
the issue you raised in your earlier message about receive-pack having to
know random states random set of tools leave will be alleviated.  We need
to make sure that the marker is cleaned up correctly when the command is
done with the lock, of course.

If we were to go that route, I think the same receive.denyCurrentBranch
configuration variable can and should be used to control this, even though
its name originally comes from the most visible operation that can cause
the confusion (i.e. "pushing into the current branch").  It is about
protecting the person who is currently using the work tree, or who will
use the work tree next.

> I am really just proposing that the "ref was not what we expected"
> message to better indicate what is going on, and how the user might get
> out of it. Do you not agree with that?

The recovery recipe you described looked good.

Re: disallowing push to currently checked-out branch

[Jeff King]

On Mon, Feb 16, 2009 at 04:43:03PM -0800, Junio C Hamano wrote:

> That sounds similar to saying "I left my editor open without saving my
> changes, and accidentally opened another instance of an editor from a
> different terminal and edited the same file, the result is a mess".  The
> editors protect users from such a situation by locking the file they are
> editing.

It is definitely similar.

> Perhaps operations that detaches HEAD (rebase and perhaps sequencer) can
> all agree to use a single marker file that says "Do not mess with these
> refs via push or fetch" and make receive-pack and fetch honor that?  Then
> the issue you raised in your earlier message about receive-pack having to
> know random states random set of tools leave will be alleviated.  We need
> to make sure that the marker is cleaned up correctly when the command is
> done with the lock, of course.

I think such a marker is a fine idea in general, because it would be
nice to be able to say "what is all state in the repo that I might care
about" (which I think has been talked about several times). In fact, I
have had a similar problem _without_ pushing just by leaving and coming
back in the middle of operations, especially failed ones (e.g., "git
am", realize the patch doesn't apply, forget to --abort, then make more
commits, realize only when you try to "git am" something else, but now
aborting will intermediate work).

I'm not sure that supporting it in receive-pack is necessary. The
current rebase code already detects the situation; it just doesn't
handle it as gracefully as it might. And it doesn't close _all_
possibility for danger, as the example you gave previously shows; the
user can still be surprised by the ref changing.

Whereas improving the local tool support for "rebase --abort" and "am
--abort" to help a user recover from such a situation means that we help
not only the situation of somebody pushing, but also local "I forgot
and changed the repo" situations.

> > I am really just proposing that the "ref was not what we expected"
> > message to better indicate what is going on, and how the user might get
> > out of it. Do you not agree with that?
> 
> The recovery recipe you described looked good.

OK. I'll look at working up a patch.

-Peff

Re: disallowing push to currently checked-out branch

[Jeff King]

On Sun, Feb 15, 2009 at 05:33:59PM -0800, david@lang.hm wrote:

>> 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

Re: disallowing push to currently checked-out branch

[david]

On Sun, 15 Feb 2009, Jeff King wrote:

>>> 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?

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

Re: disallowing push to currently checked-out branch

[Jeff King]

On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:

>> 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

Re: disallowing push to currently checked-out branch

[david]

On Sun, 15 Feb 2009, Jeff King wrote:

> On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:
>
>>> 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

>> 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
>

Re: disallowing push to currently checked-out branch

[Jeff King]

On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:

>> 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

Re: disallowing push to currently checked-out branch

[david]

On Sun, 15 Feb 2009, Jeff King wrote:

> On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:
>
>>> 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.

>> 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.

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

> -Peff
>

Re: disallowing push to currently checked-out branch

[Jeff King]

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

Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

Hi,

On Mon, 16 Feb 2009, Jeff King wrote:

> 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.

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

dashed commands, was Re: disallowing push to currently checked-out branch

[Johannes Schindelin]

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[david]

On Sun, 15 Feb 2009, Junio C Hamano wrote:

> 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

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Johannes Schindelin]

Hi,

On Sun, 15 Feb 2009, david@lang.hm wrote:

> On Sun, 15 Feb 2009, Junio C Hamano wrote:
> 
> > 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
> 
> 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Sun, 15 Feb 2009, david@lang.hm wrote:
>
>> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>> 
>> > 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
>> 
>> 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.

Yuck.  I wasn't expecting a discussion itself here.  This was a request
for help and comment for a future message that will ask to start the
discussion.

No need to *stop* discussing, but please retitle the thread so that we can
later see which ones are discussion of a particular topic, and which ones
are proposal for addition of new items.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[david]

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

> On Sun, 15 Feb 2009, david@lang.hm wrote:
>
>> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>>
>>> 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
>>
>> 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Johannes Schindelin]

Hi,

On Sun, 15 Feb 2009, david@lang.hm wrote:

> On Mon, 16 Feb 2009, Johannes Schindelin wrote:
> 
> > On Sun, 15 Feb 2009, david@lang.hm wrote:
> >
> > > On Sun, 15 Feb 2009, Junio C Hamano wrote:
> > >
> > > > 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
> > >
> > > 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[david]

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

> On Sun, 15 Feb 2009, david@lang.hm wrote:
>
>> On Mon, 16 Feb 2009, Johannes Schindelin wrote:
>>
>>> On Sun, 15 Feb 2009, david@lang.hm wrote:
>>>
>>>> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>>>>
>>>>> 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
>>>>
>>>> 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.

>>> 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

david@lang.hm writes:

> On Mon, 16 Feb 2009, Johannes Schindelin wrote:
>
>>>> So you have to set a config variable.  Big deal.
>
> the dashed names were the same way, but they definantly were a big deal.

Dscho, why do you think you saw the message you are responding to?  If it
were not a big deal, I wouldn't have bothered.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Johannes Schindelin]

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[david]

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

> 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.

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Sverre Rabbelier]

On Mon, Feb 16, 2009 at 16:33,  <david@lang.hm> 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

disallowing push to currently checked-out branch

[Jeff King]

On Sun, Feb 15, 2009 at 04:14:20PM -0800, david@lang.hm wrote:

>> 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

Re: disallowing push to currently checked-out branch

[Sergio Callegari]

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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Jakub Narebski]

david@lang.hm writes:

> On Sun, 15 Feb 2009, Junio C Hamano wrote:
> 
> > 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
> 
> 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.

> > * 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Johannes Schindelin]

Hi,

On Sun, 15 Feb 2009, Jakub Narebski wrote:

> david@lang.hm writes:
> 
> > 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Jakub Narebski]

Hello!

On Mon, 16 Feb 2009, Johannes Schindelin wrote:
> On Sun, 15 Feb 2009, Jakub Narebski wrote:
>> david@lang.hm writes:
>> 
>>> 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[david]

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

> Hi,
>
> On Sun, 15 Feb 2009, Jakub Narebski wrote:
>
>> david@lang.hm writes:
>>
>>> 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

send-email sending shallow threads by default

[Jeff King]

On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:

>> * 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

Re: send-email sending shallow threads by default

[Pieter de Bie]

On 16 feb 2009, at 00:07, Jeff King wrote:

> Are there common readers that thread but do not order by date?

Apple's Mail orders by date received, rather than date sent

Re: send-email sending shallow threads by default

[Jeff King]

On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:

> On 16 feb 2009, at 00:07, Jeff King wrote:
>
>> 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

Re: send-email sending shallow threads by default

[Brian Gernhardt]

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:
>
>> On 16 feb 2009, at 00:07, Jeff King wrote:
>>
>>> 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

Re: send-email sending shallow threads by default

[Wincent Colaiuta]

El 16/2/2009, a las 3:43, Jeff King escribió:

> On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:
>
>> On 16 feb 2009, at 00:07, Jeff King wrote:
>>
>>> 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

Re: send-email sending shallow threads by default

[SZEDER Gábor]

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:
> > 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?

Gmane.

(e.g. http://thread.gmane.org/gmane.comp.version-control.git/110068)

Regards,
Gábor

Re: send-email sending shallow threads by default

[Martin Mares]

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                          <mj@ucw.cz>   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

Re: send-email sending shallow threads by default

[Andreas Ericsson]

Martin Mares wrote:
> 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.
> 

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

Re: send-email sending shallow threads by default

[Martin Mares]

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                          <mj@ucw.cz>   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

Re: send-email sending shallow threads by default

[Jeff King]

On Tue, Feb 17, 2009 at 10:06:18AM +0100, Martin Mares wrote:

> > 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

Re: send-email sending shallow threads by default

[Eric W. Biederman]

Jeff King <peff@peff.net> writes:

> On Tue, Feb 17, 2009 at 10:06:18AM +0100, Martin Mares wrote:
>
>> > 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).

Can we ensure that all of the messages sent differ in date by 1 second?
Keeping them in order for anyone who looks at the transmit date.

I know at one point I started using --change-reply-to because of the problem
of threads showing up in the wrong order, and making it hard to read.

Eric

Re: send-email sending shallow threads by default

[Jeff King]

On Thu, Feb 19, 2009 at 07:03:27PM -0800, Eric W. Biederman wrote:

> > 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).
> 
> Can we ensure that all of the messages sent differ in date by 1 second?
> Keeping them in order for anyone who looks at the transmit date.

I think it already does:

  $ git show a5370b16
  commit a5370b16c34993c1d0f65171d5704244901e005b
  Author: Eric Wong <normalperson@yhbt.net>
  Date:   Sat Mar 25 03:01:01 2006 -0800

      send-email: try to order messages in email clients more correctly

      If --no-chain-reply-to is set, patches may not always be ordered
      correctly in email clients.  This patch makes sure each email
      sent from a different second.

-Peff

Re: send-email sending shallow threads by default

[Eric W. Biederman]

Jeff King <peff@peff.net> writes:

> On Thu, Feb 19, 2009 at 07:03:27PM -0800, Eric W. Biederman wrote:
>
>> > 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).
>> 
>> Can we ensure that all of the messages sent differ in date by 1 second?
>> Keeping them in order for anyone who looks at the transmit date.
>
> I think it already does:
>
>   $ git show a5370b16
>   commit a5370b16c34993c1d0f65171d5704244901e005b
>   Author: Eric Wong <normalperson@yhbt.net>
>   Date:   Sat Mar 25 03:01:01 2006 -0800
>
>       send-email: try to order messages in email clients more correctly
>
>       If --no-chain-reply-to is set, patches may not always be ordered
>       correctly in email clients.  This patch makes sure each email
>       sent from a different second.

Well that date's my experiments with git-send-email.  And yes looking at the
code the transmit date still appears to be computed that way.

$time = time - scalar $#files;
my $date = format_2822_time($time++);

So it appears that problem has been solved if a person simply sorts by
transmit date.

So it sounds like a good change in defaults to me.

Eric

Re: send-email sending shallow threads by default

[Andreas Ericsson]

Jeff King wrote:
> On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:
> 
>>> * 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Sitaram Chamarty]

On 2009-02-15, david@lang.hm <david@lang.hm> wrote:
> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>> * 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
>
> 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'.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Björn Steinbrink]

On 2009.02.15 15:53:50 -0800, david@lang.hm wrote:
> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>
>> 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
>
> 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

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Junio C Hamano]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> How about having the default in the code being a warning, but the
> default for new repos being "reject"?

To reserve time to manage git itself, I will try not to point people to
previous discussions, but I'd like help from people who've already seen
the previous discussions to do so.  This is one of the things that was
proposed and already shot down.

Re: [RFC - draft] List of proposed future changes that are backward incompatible

[Björn Steinbrink]

On 2009.02.16 00:49:52 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> 
> > How about having the default in the code being a warning, but the
> > default for new repos being "reject"?
> 
> To reserve time to manage git itself, I will try not to point people to
> previous discussions, but I'd like help from people who've already seen
> the previous discussions to do so.  This is one of the things that was
> proposed and already shot down.

OK, I'm sorry. Seems that my quick look through the other thread was too
quick :-(

Björn

[RFC - draft #2] List of proposed future changes that are backward incompatible

[Junio C Hamano]

Let's scrap the first thread and try again, this time a bit more careful
wording, so that premature and unwanted discussions would not cloud out
what really needs to happen in response to this request.

Here is a draft of a message I am preparing to send out around 1.6.2-rc2
is tagged to this mailing list, and mailing list of the projects that use
git to track their changes, to announce possible future changes that may
affect the users in a backward incompatible way, and solicit comments.

I am asking three things now from the readership:

 - For items that are already on the list, help improve the way the
   planned/proposed changes are explained.  Discussion on the desirability
   of the change itself is NOT WELCOME in this thread.  That is for the
   discussion that follows the final version of this document.

 - If a change, that was discussed on this list recently and saw general
   consensus that such a change is desirable, is missing from this
   document, please send in updates in a similar format as you see below.

 - If your favourite project that uses git is not listed in:

   http://git.or.cz/gitwiki/ProjectContacts

   or it does not have "Forwarder" field filled in, please add the project
   with an appropriate address for the message to be sent.

   Be careful NOT to list a mailing list address that non-subscribers
   cannot send messages to.  For such mailing lists, we need to find a
   subscribed volunteer to forward it.  If you are volunteering, great.

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.  You can countermand this default by setting a
  configuration variable in the receiving repository.

  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.  You can countermand this default by
  setting a configuration variable in the receiving repository.

  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.  You can countermand this by setting a
  configuration variable.

  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).  You can countermand this by setting a configuration
  variable.

  http://thread.gmane.org/gmane.comp.version-control.git/110033

Re: [RFC - draft #2] List of proposed future changes that are backward incompatible

[Jeff King]

On Sun, Feb 15, 2009 at 06:42:50PM -0800, Junio C Hamano wrote:

> * 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.  You can countermand this default by setting a
>   configuration variable in the receiving repository.
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

It might be too subtle that "checked out" here implies a non-bare
repository (that is, somebody might think the HEAD branch in their bare
repo is "checked out"). So you might want to specifically mention
non-bare in the summary.

> * make core.quotepath=false the default

I have a comment on this, but I'll put it in a new thread. ;P

-Peff

Re: [RFC - draft #2] List of proposed future changes that are backward incompatible

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Here is a draft of a message I am preparing to send out around 1.6.2-rc2
> is tagged to this mailing list, and mailing list of the projects that use
> git to track their changes, to announce possible future changes that may
> affect the users in a backward incompatible way, and solicit comments.

>  - If your favourite project that uses git is not listed in:
> 
>    http://git.or.cz/gitwiki/ProjectContacts
> 
>    or it does not have "Forwarder" field filled in, please add the project
>    with an appropriate address for the message to be sent.
> 
>    Be careful NOT to list a mailing list address that non-subscribers
>    cannot send messages to.  For such mailing lists, we need to find a
>    subscribed volunteer to forward it.  If you are volunteering, great.

First, I have send announcements about Git User's Survey 2007 and 2008
to mailing list of various projects using git. I can find which didn't
bounced back with 'waiting for moderation', or 'subscribe only' and
provide you (on private or here on git mailing list) with the list of
addresses of mailing list which at least seem public.

Second, you can ask major git hosting sites: repo.or.cz, gitorious and
GitHub (and perhaps also Ohloh software metric site) to announce this
information about future incompatibilities somewhere public on the
site, or alternatively either in news section of a site, or in blog
(or announcements section) if there is any.


P.S. Hmmm... you can try asking on Stackoverflow how to announce and
propagate backward incompatibile changes for packaged OSS project,
like git :-)

-- 
Jakub Narebski
Poland
ShadeHawk on #git