git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Please discuss: what "git push" should do when you do not say what to push?

From
ASAndrew Sayers <andrew-git@pileofstuff.org>
Date
Mar 19, 2012, 20:11 UTC
Message-ID
<4F6792DE.80208@pileofstuff.org>
In-Reply-To
<7vipi1d9r7.fsf@alter.siamese.dyndns.org>
On 18/03/12 18:50, Junio C Hamano wrote:
Show 62 quoted lines
> Andrew Sayers <andrew-git@pileofstuff.org> writes:
> 
>> On 17/03/12 05:22, Junio C Hamano wrote:
>>> If the conclusion of the discussion is that we will change the default,
>>> the transition to the new default will go like this:
>>>
>>>  1. An announcement message to let the user communities know about the
>>>     future change will be distributed in a way similar to the previous
>>>     request-for-discussion message was distributed.
>>>
>>>  2. The first version of Git that is released after such an announcement
>>>     will start issuing a warning ...
>>>
>>>  3. We wait for a few release cycles.
>>>
>>>  4. The default changes. ... 
>>>     The warning message will be reworded ...
>>>     being the 'matching' in the future", it will say "has changed to X".
>>>
>>>  5. We wait for a few release cycles.
>>>
>>>  6. The warning is removed.
>>>
>>> A typical release cycle lasts for 8-10 weeks.
>>
>> Unfortunately, "a few release cycles" strikes me as a rather hopeful
>> description.  For example, a user installing the new Ubuntu LTS release
>> (due out next month) would feel completely justified in not upgrading
>> until 2017, whereas the rest of us would get rather bored disabling the
>> same old warning in every new repo we create for the next five years.
> 
> There is nothing hopeful about it.
> 
> The point of a release like LTS is to shield the users of the distribution
> from what happens in upstream, so it is up to the distro to help users. We
> do not have a way to help their users in a direct way, other than letting
> the distro know about the change, and educate the distros how they help
> their users.
> 
> If I were a user of such a distro whose sole point is a long term support,
> I would expect that a LTS that was originally released before point #2
> whose lifespan extends beyond point #6 to backport only the "warning"
> changes to such a release between #2 and #6 timespan as a point update to
> such a LTS release. Otherwise the distro is actively doing a disservice to
> its users.  Such a distro can also choose to revert the "warning removal"
> change #6 in their binary when they release a new LTS. If they did not
> backport "add warning" to their earlier LTS release, that is at least what
> they can do to help their users.
> 
> But again, that is not something we have direct control over, and it is
> not very useful to discuss this on this list. Ubuntu LTS support forum
> might be a better place, but in short, it is not a problem we can solve
> (nor we should be solving), as long as we have a reasonable migration plan
> and if the user is locked out of that migration plan---whoever is doing
> the locking-out is taking responsibility for these users who are out of
> our reach.
> 
> --
> 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
>

I take the point that distros have their own support infrastructure, so perhaps this would be a better example:

Many administrators in corporate environments will install git from source, because they don't trust RPM/need some feature in the latest version/are just that way inclined. Having installed it, they tend to sit on that version for a few years until they have to upgrade the system/need some feature in the new latest version/are still just that way inclined. Their justification for not upgrading is often that new versions of software tend to change behaviour in subtle ways that break the scripts they've bodged together over the years. Trying to argue that one particular bit of software will only hurt you if you wait for the wrong amount of time tends to be a losing battle, because administrators hate special cases just as much as programmers.

Having said all that, here's a slightly different argument for a slightly better solution:

When a user upgrades to a mid- or post-change version of git, I think it's a good idea for them to be warned about the change of behaviour. But new users, and old users with new repositories, gain nothing from the little history lesson. This should be solved in git itself, because two users of the same binary might expect different behaviour. An automatic `git config push.default <whatever>` at repository creation time would silence the noise without disrupting the signal. As an added bonus, this approach might take some heat out of the argument when the umpteenth "is it time to remove the warning yet?" thread kicks off.

	- Andrew
Previous: Sebastien DoucheNext: Junio C Hamano
Message 8 of 43 in “Please discuss: what "git push" should do when you do not say what to push?”
  1. Junio C HamanoMar 17, 2012
  2. Junio C HamanoMar 17, 2012
  3. Andrew SayersMar 17, 2012
  4. Junio C HamanoMar 18, 2012
  5. Ævar Arnfjörð BjarmasonMar 18, 2012
  6. Junio C HamanoMar 19, 2012
  7. Sebastien DoucheMar 19, 2012
  8. Andrew SayersMar 19, 2012
  9. Junio C HamanoMar 19, 2012
  10. demerphqMar 19, 2012
  11. Junio C HamanoMar 19, 2012
  12. Andreas EricssonMar 20, 2012
  13. Andrew SayersMar 19, 2012
  14. Junio C HamanoMar 19, 2012
  15. Andrew SayersMar 20, 2012
  16. Junio C HamanoMar 20, 2012
  17. Andrew SayersMar 20, 2012
  18. Junio C HamanoMar 21, 2012
  19. Martin LanghoffMar 20, 2012
  20. Junio C HamanoMar 20, 2012
  21. Martin LanghoffMar 20, 2012
  22. Jakub NarebskiMar 20, 2012
  23. Summary of discussion on "git push" default changeJunio C Hamano, Mar 21, 2012
  24. Matthieu MoyMar 21, 2012
  25. Joey HessMar 17, 2012
  26. Junio C HamanoMar 19, 2012
  27. fREW SchmidtMar 17, 2012
  28. H. Peter AnvinMar 18, 2012
  29. Marcus D. HanwellMar 18, 2012
  30. Sebastian SchuberthMar 18, 2012
  31. Peter KreftingMar 19, 2012
  32. Letting remote repositories override local configurationJonathan Nieder, Mar 19, 2012
  33. Peter KreftingMar 19, 2012
  34. Kevin BallardMar 19, 2012
  35. Antony MaleMar 20, 2012
  36. Jakub NarebskiMar 20, 2012
  37. Antony MaleMar 20, 2012
  38. Nathan GrayMar 20, 2012
  39. Ben TebulinMar 20, 2012
  40. Ben TebulinMar 20, 2012
  41. Ben TebulinMar 20, 2012
  42. Ben TebulinMar 20, 2012
  43. Filipe FernandesMar 20, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.