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

Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Oct 30, 2007, 18:00 UTC
Message-ID
<Pine.LNX.4.64.0710301306210.7357@iabervon.org>
In-Reply-To
<7vfxztm2dx.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Oct 2007, Junio C Hamano wrote:
Show 14 quoted lines
> Steffen Prohaska <prohaska@zib.de> writes:
> 
> > git push now allows you pushing a couple of branches that have
> > advanced, while ignoring all branches that have no local changes,
> > but are lagging behind their matching remote refs. This is done
> > without reporting errors.
> >
> > Thanks to Junio C. Hamano <gitster@pobox.com> for suggesting to
> > report in the summary that refs have been ignored.
> 
> I do not think this is a good idea at all.  Furthermore, I never
> suggested anything about summary.  You are robbing the
> information from the pusher which ones are pushed and which ones
> are left behind.

I think this case should be a warning rather than an error, though. It is certainly true that the user isn't intending to update those remote refs, because there is no local change to update them with. And it is also true that those local refs being stale is no impediment to updating the refs which are not stale, which is what the user does intend to do. I can't see a workflow which would be hurt by this change, because we know that, if the user follows the instructions and then tries the push again, it will have no effect.

If the concern is robbing the user of information, we should simply provide the information, rather than interrupting the user's work to make them act on the information before completing the essentially independant operation they're attempting.

In any case, it's misleading to suggest that the user "pull first", because we know that there would be no effect to pushing again after merging. In this case, it would be more accurate to suggest that the user "pull instead". Perhaps the message should be "%s: nothing to push to %s, but you are not up-to-date and may want to pull"

	-Daniel
*This .sig left intentionally blank*
Previous: Wincent ColaiutaNext: Junio C Hamano
Message 46 of 53 in “improve refspec handling in push”
  1. 0/10 improve refspec handling in pushSteffen Prohaska, Oct 28, 2007
  2. 01/10 push: change push to fail if short refname does not existSteffen Prohaska, Oct 28, 2007
  3. 02/10 push: teach push new flag --createSteffen Prohaska, Oct 28, 2007
  4. 03/10 push: support pushing HEAD to real branch nameSteffen Prohaska, Oct 28, 2007
  5. 04/10 push: add "git push HEAD" shorthand for 'push current branch to default repo'Steffen Prohaska, Oct 28, 2007
  6. 05/10 rename ref_matches_abbrev() to ref_abbrev_matches_full_with_fetch_rules()Steffen Prohaska, Oct 28, 2007
  7. 06/10 add ref_abbrev_matches_full_with_rev_parse_rules() comparing abbrev with full ref nameSteffen Prohaska, Oct 28, 2007
  8. 07/10 push: use same rules as git-rev-parse to resolve refspecsSteffen Prohaska, Oct 28, 2007
  9. 08/10 push: teach push to accept --verbose optionSteffen Prohaska, Oct 28, 2007
  10. 09/10 push: teach push to pass --verbose option to transport layerSteffen Prohaska, Oct 28, 2007
  11. 10/10 push: teach push to be quiet if local ref is strict subset of remote refSteffen Prohaska, Oct 28, 2007
  12. Junio C HamanoOct 30, 2007
  13. Steffen ProhaskaOct 30, 2007
  14. Andreas EricssonOct 30, 2007
  15. Steffen ProhaskaOct 30, 2007
  16. Junio C HamanoOct 30, 2007
  17. Steffen ProhaskaOct 31, 2007
  18. Junio C HamanoOct 31, 2007
  19. Junio C HamanoOct 31, 2007
  20. Steffen ProhaskaOct 31, 2007
  21. Junio C HamanoOct 31, 2007
  22. Steffen ProhaskaOct 31, 2007
  23. Junio C HamanoOct 31, 2007
  24. Steffen ProhaskaNov 1, 2007
  25. Andreas EricssonNov 1, 2007
  26. Steffen ProhaskaNov 1, 2007
  27. Junio C HamanoNov 1, 2007
  28. Steffen ProhaskaNov 2, 2007
  29. Junio C HamanoNov 2, 2007
  30. Steffen ProhaskaNov 2, 2007
  31. Junio C HamanoNov 2, 2007
  32. Steffen ProhaskaNov 2, 2007
  33. Andreas EricssonNov 2, 2007
  34. Tom PrinceNov 2, 2007
  35. Andreas EricssonNov 2, 2007
  36. Steffen ProhaskaNov 2, 2007
  37. Junio C HamanoNov 2, 2007
  38. Junio C HamanoNov 2, 2007
  39. Andreas EricssonNov 1, 2007
  40. Steffen ProhaskaNov 1, 2007
  41. Andreas EricssonNov 1, 2007
  42. Wincent ColaiutaNov 2, 2007
  43. Johannes SchindelinNov 2, 2007
  44. Steffen ProhaskaNov 2, 2007
  45. Wincent ColaiutaNov 2, 2007
  46. Daniel BarkalowOct 30, 2007
  47. Junio C HamanoOct 30, 2007
  48. Steffen ProhaskaOct 30, 2007
  49. Junio C HamanoOct 30, 2007
  50. Junio C HamanoOct 30, 2007
  51. Junio C HamanoOct 30, 2007
  52. Steffen ProhaskaOct 30, 2007
  53. Junio C HamanoOct 30, 2007

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.