[Bug 1087087] Re: "git fetch" performance regression

Jonathan Nieder jrnieder at gmail.com
Thu Dec 6 22:29:51 UTC 2012


According to the description presented in the web UI, Invalid means "Not
a bug. May be a support request or spam."  Perhaps you misread the
request or meant "won't fix".

I've updated the description to explain how it relates to the SRU
guidelines.

Thanks for looking it over,
Jonathan

** Description changed:

- Hi,
+ [Impact]
  
- Updating git from lucid to precise brings in the change
+ Updating git from lucid to precise brought in the change
  
-   6b67e0dc068d fetch: verify we have everything we need before updating
+   6b67e0dc068d fetch: verify we have everything we need before updating
  our ref
  
  which caused a speed regression:
  
-  http://thread.gmane.org/gmane.comp.version-
+  http://thread.gmane.org/gmane.comp.version-
  control.git/191626/focus=193228
  
+ This has been preventing some users from updating the git package to the version
+ in precise.
+ 
  The fix is d21c463d558a "fetch/receive: remove over-pessimistic
- connectivity check".  Would it be possible to update git in precise to
- 1.7.9.7 to get that and other fixes?
+ connectivity check".
  
- Thanks,
- Jonathan
+ I believe it falls in the category
+ 
+  "Bugs which do not fit under above categories, but (1) have an obviously safe
+   patch and (2) affect an application rather than critical infrastructure
+   packages (like X.org or the kernel)."
+ 
+ as the impact of this regression fix would be isolated to git alone.
+ 
+ [Test Case]
+ 
+ "time git fetch".  See the link above for details.
+ 
+ [Regression Potential]
+ 
+ Barring toolchain breakage, this fix should not produce a regression.  It is a
+ simple patch that makes sense and has been well tested upstream.
+ 
+ With toolchain breakage, anything can happen, naturally.  The git command could
+ stop working completely or subtly misbehave.  Git has an extensive test suite so
+ this would be most likely to result in a build failure, but it's also possible
+ that the build and basic manual testing would not catch a problem, in which case
+ it would show up in user reports.
+ 
+ Git repositories are by the nature of how they are used almost always replicated,
+ limiting potential data loss in ordinary cases to changes that have not been
+ pushed yet.
+ 
+ [Other Info]
+ 
+ This is my first SRU request.  I admit I'm a bit surprised at how quickly it seems
+ to have labelled as invalid.

** Changed in: git (Ubuntu)
       Status: Invalid => New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to git in Ubuntu.
https://bugs.launchpad.net/bugs/1087087

Title:
  "git fetch" performance regression

Status in “git” package in Ubuntu:
  New

Bug description:
  [Impact]

  Updating git from lucid to precise brought in the change

    6b67e0dc068d fetch: verify we have everything we need before
  updating our ref

  which caused a speed regression:

   http://thread.gmane.org/gmane.comp.version-
  control.git/191626/focus=193228

  This has been preventing some users from updating the git package to the version
  in precise.

  The fix is d21c463d558a "fetch/receive: remove over-pessimistic
  connectivity check".

  I believe it falls in the category

   "Bugs which do not fit under above categories, but (1) have an obviously safe
    patch and (2) affect an application rather than critical infrastructure
    packages (like X.org or the kernel)."

  as the impact of this regression fix would be isolated to git alone.

  [Test Case]

  "time git fetch".  See the link above for details.

  [Regression Potential]

  Barring toolchain breakage, this fix should not produce a regression.  It is a
  simple patch that makes sense and has been well tested upstream.

  With toolchain breakage, anything can happen, naturally.  The git command could
  stop working completely or subtly misbehave.  Git has an extensive test suite so
  this would be most likely to result in a build failure, but it's also possible
  that the build and basic manual testing would not catch a problem, in which case
  it would show up in user reports.

  Git repositories are by the nature of how they are used almost always replicated,
  limiting potential data loss in ordinary cases to changes that have not been
  pushed yet.

  [Other Info]

  This is my first SRU request.  I admit I'm a bit surprised at how quickly it seems
  to have labelled as invalid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1087087/+subscriptions




More information about the foundations-bugs mailing list