Re: Repo with only one file
Am 8/8/2013 23:11, schrieb Phil Hord: On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote: On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of these scripts and I'd like to keep the commit history. Ok, so: % find -type f ! -iname webban.pl | while read f; do git filter-branch -f --index-filter git rm --cached --ignore-unmatch $f HEAD ; done Which basically did it. But, I've got this one commit that seems to be orphaned - it doesn't change any files. Try this: git filter-branch HEAD -- webban.pl % git filter-branch HEAD -- webban.pl Cannot create a new backup. A previous backup already exists in refs/original/ Force overwriting the backup with -f % git filter-branch -f HEAD -- webban.pl Rewrite 1e04b18c256c996312f167be808733bcc755f1e3 (9/9) WARNING: Ref 'refs/heads/master' is unchanged I think you can ignore the warning. Maybe you want to create a new branch which only has this file in it now. $ git checkout -b webban I'm not sure. On second thought, my suggested command is not sufficient. It does remove the empty commits, but it does not remove the other files. So, Shawn's original filter-branch invocations are still needed. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk: Can't parse git log output: { }
Hi!
In my local clone of git.git, currently with the v1.8.4-rc2 tag
checked out and built (and installed on the system), starting up gitk
yields an empty window, with a dialog in front of it:
error
Can't parse git log output: { }
[ OK ]
Has anyone else seen this, and know what might have happened? I do not
get the behaviour in other repositories (including other clones of
git.git), only this particular one.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] builtin/config.c: compilation fix
On Thu, Aug 8, 2013 at 10:38 PM, Kyle J. McKay mack...@gmail.com wrote: + const char usage[] = test-urlmatch-normalization [-p | -l] url1 Looks good to me except that there seems to be a missing part of the patch. Did you also mean to include: diff --git a/test-urlmatch-normalization.c b/test-urlmatch-normalization.c index 2603899b..39017c20 100644 --- a/test-urlmatch-normalization.c +++ b/test-urlmatch-normalization.c @@ -42,7 +42,7 @@ int main(int argc, char **argv) } if (opt_p || opt_l) - die(usage); + die(%s, usage); That's not terribly important here since we know the string will never contain any '%' characters, but the comment on the patch led me to believe that test-urlmatch-normalization would also get the die() change. It appears that const char usage[] = ... is enough to convince Gcc that usage _is_ a constant and can never contain anything funky. But I agree that the usage string could be updated, and I agree that it is prudent to do the same die(%s, ...) there. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/8/2013 23:11, schrieb Phil Hord: On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote: On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of these scripts and I'd like to keep the commit history. Ok, so: % find -type f ! -iname webban.pl | while read f; do git filter-branch -f --index-filter git rm --cached --ignore-unmatch $f HEAD ; done I'm not sure. On second thought, my suggested command is not sufficient. It does remove the empty commits, but it does not remove the other files. So, Shawn's original filter-branch invocations are still needed. Yeah, I have tried this and haven't gotten any closer. I can either remove all of the history or that one commit that has nothing to do with my file is there. This is also reproducable in a new repo. Is this a bug with filter-branch or git? This doesn't seem like a feature (or how things should act). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
Am 8/9/2013 8:33, schrieb shawn wilson: On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/8/2013 23:11, schrieb Phil Hord: On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote: On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of these scripts and I'd like to keep the commit history. Ok, so: % find -type f ! -iname webban.pl | while read f; do git filter-branch -f --index-filter git rm --cached --ignore-unmatch $f HEAD ; done I'm not sure. On second thought, my suggested command is not sufficient. It does remove the empty commits, but it does not remove the other files. So, Shawn's original filter-branch invocations are still needed. Yeah, I have tried this and haven't gotten any closer. I can either remove all of the history or that one commit that has nothing to do with my file is there. This is also reproducable in a new repo. Is this a bug with filter-branch or git? This doesn't seem like a feature (or how things should act). Let's check: After running your command above to remove other files, does the command git filter-branch -f HEAD webban.pl remove the empty commit (if necessary, replace HEAD by the branch name that you are interested in)? -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull l10n updates for 1.8.4 round 2
Hi, Junio The following changes since commit fb5657082148297b61fbca7e64d51c1e7870309a: Sync with maint to grab trivial doc fixes (2013-08-05 13:00:20 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 4402f301555feeada2de68c4576aa15acfe40b46: l10n: de.po: translate 5 messages (2013-08-09 06:53:44 +0200) Jiang Xin (2): l10n: git.pot: v1.8.4 round 2 (5 new, 3 removed) l10n: zh_CN.po: translate 5 messages (2135t0f0u) Peter Krefting (1): l10n: Update Swedish translation (2135t0f0u) Ralf Thielow (3): l10n: de.po: switch from pure German to German+English l10n: de.po: translate 99 new messages l10n: de.po: translate 5 messages Tran Ngoc Quan (1): l10n: vi.po(2135t): v1.8.4 round 2 Wieland Hoffmann (1): l10n: de.po: Fix a typo po/de.po| 5156 --- po/git.pot | 335 ++-- po/sv.po| 3365 -- po/vi.po| 356 +++-- po/zh_CN.po | 346 ++-- 5 files changed, 5144 insertions(+), 4414 deletions(-) -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk: Can't parse git log output: { }
Peter Krefting pe...@softwolves.pp.se writes:
Hi!
In my local clone of git.git, currently with the v1.8.4-rc2 tag
checked out and built (and installed on the system), starting up gitk
yields an empty window, with a dialog in front of it:
error
Can't parse git log output: { }
[ OK ]
Has anyone else seen this, and know what might have happened? I do not
get the behaviour in other repositories (including other clones of
git.git), only this particular one.
Have you tried moving away .git/gitk.cache?
If that fixes it, perhaps you can share it for inspection.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nike air max 2013 women
nike air max 2013 women http://www.kaufenschuhenikeonline.eu/nike-air-max/nike-air-max-2013-neu Einige Geräte andere Add-ons für PHP 13000 MITTWOCH, 23. Februar, 2011 eingetragen. UnknownP. Derek Umsatz oder vielleicht Forschung von der Industrie ESCLUSIVAMENTE überwinden weitere gute Kritiken überwinden hinteren Ende her und zusätzlich zu anderen Headsets finden, um die minimale zusätzliche Maiglöckchen priceMonster Kopfhörer zu finden, schlug Dr. Dre Studio Kopfhörer die Ur-Ur-Ur-Ur-Reise Turbo Monster Frau Gaga , bea große SOLO. p90x TS, neben den großen beats by dre hochqualitative Ausführung des letzten Schatten. Sobald ich an der Dr. Dre Tonstudio aussehen Übertrifft Headsets dies ist die Art von lebendigen Sound expect.Monster können zusammen mit Arzt. Dre entwickelt diese zu den Gehörgang Headsets endete als so, dass jemand anderes als Sie und zusätzlich mich persönlich hören konnte verfolgt genau, welche Art von Lieferanten zusammen mit Entwickler es sehen. Jeder Mechanismus, jede einzelne Stimme so erstaunlich klar das es eine völlig neue Erkenntnis ist. Die gesamte Produkt-Container und Anzeigen in Monster Beats Tonstudio Tätigkeit tragen genau das gleiche Zitat von Dre, der sagt: Die Menschen sind nicht Anhörung der verschiedenen Musik Mit Musik, die Menschen besuchen bemerken die Musiker zu hören, und hören die Aufnahmen Aktivität Aktivität, wo die tat Paar sollte auf: Der Weg beats by dre canada tue ich wirklich. Dre und Iovine auch mieten einen völligen von sechzig Jahren der Expertise und dem Erfolg zusätzlich rechts durch den Vergnügungspark Unternehmen, um sicherzustellen, dass sie vielleicht wollen, wie die Dinge erscheinen muss lernen. Heute sind wir, nachdem wir sagen, wie das Hören genau das, was Dre wird sagen, wir haben bekommen hatte weitgehend Leser spielen, beobachten kostenlos Filme im Internet, bei der Haltung konzentriert oben auf Aufnahmen auf unsere Geschäfte PCs. Wie ist es eine Möglichkeit, dass die meisten von uns haben gerade diese extrem modische Kopfhörer vergessen bis heute? Produkt Gesamtkosten NewEgg.com Inserate der Sounds Studio-Kopfhörer für $ 299,95 mit kostenlosem Transport Boden. Amazon.com verkauft in der Regel diese Art der Sounds für die vergleichbaren Kosten, weil Newegg, trotzdem hat es noch sie für $ 259,99 mit kostenlosem Boden oder vielleicht prime Versandkosten unbestimmte Zyklus zu bekommen. Monster bietet die Beats Studio-Kopfhörer für $ 349,95 mit kostenlosem Boden Transport thru dazu spezifische Website. Klingt Dr Dre Monster durch Dr. Dre Dre Tonstudio Superman Dwight Howard Bläuliche Preiswert Aktionen Musik ist eine komplexe Sounds by Dre Klingt Verkauf system.Inexpensive, No TaxCheap Verkauf, Music by Dr. Dre Monster Music By Dre In-Ear Weiß Monster Rhianna Hoch Perf CHEAPBEATSBYDRE110 Artikel 1 6. Juni Beats by Dre neue Arten out now. Sounds By Dre Kopfhörer Heartbeats durch. Pixie Lott sind, Informationen und Sounds von dr wirtschaftlichen liefern. Sunday, 17. Juni 2012 RSS. Frau Gaga Heartbeats 2.0 mit ein paar Schatten Entscheidungen. nike air max 2013 herren http://www.kaufenschuhenikeonline.eu/nike-air-max/nike-air-max-2013-neu sind das Flaggschiff im Moment gibt Musik von Dr. Dre Monster Bereich, der Anbieter für die Aktie der Klangqualität Verkabelung wirklich bewusst, dass Sie innerhalb des Kabels, die zusammen über eine reiche rötlich sehen diese Kopfhörer sind. Das ganze klingt Ranke soll Ihnen die folgende Erfahrung, die Sie im Tonstudio klingen, und auch ohne Erfahrung aus erster Hand, ich gebe zu, dass ich nicht verlangen, wow über die Bild zusammen mit dem ersten Test. - nike air max 1 women nike air max 1 sale -- View this message in context: http://git.661346.n2.nabble.com/nike-air-max-2013-women-tp7593489.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] parse-options: fix clang opterror() -Wunused-value warning
a469a1019352b8ef (silence some -Wuninitialized false positives; 2012-12-15) triggered unused value warnings when the return value of opterror() and several other error-related functions was not used. 5ded807f7c0be10e (fix clang -Wunused-value warnings for error functions; 2013-01-16) applied a fix by adding #if !defined(__clang__) in cache.h and git-compat-util.h, but misspelled it as #if !defined(clang) in parse-options.h. Fix this. This mistake went unnoticed because existing callers of opterror() utilize its return value. 1158826394e162c5 (parse-options: add OPT_CMDMODE(); 2013-07-30), however, adds a new invocation of opterror() which ignores the return value, thus triggering the unused value warning. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- parse-options.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/parse-options.h b/parse-options.h index aeab9aa..8736006 100644 --- a/parse-options.h +++ b/parse-options.h @@ -182,7 +182,7 @@ extern NORETURN void usage_msg_opt(const char *msg, extern int optbug(const struct option *opt, const char *reason); extern int opterror(const struct option *opt, const char *reason, int flags); -#if defined(__GNUC__) ! defined(clang) +#if defined(__GNUC__) ! defined(__clang__) #define opterror(o,r,f) (opterror((o),(r),(f)), -1) #endif -- 1.8.4.rc1.428.gcd48621 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Beats by Dre Solo
Beats by Dre Solo http://www.beatsbydreschweizshop.eu/ erschwingliche Angebote kaufen können auf Verkaufsartikel bei autorisierten Unternehmer oder im Internet zu finden fühlen. Bestes Layout auch so spannend Preisschild hält die idealste Air Jordan Turnschuhe, die Sie anbieten. Vielleicht ist es einfach nur ein geradeaus von Schuhen oder vielleicht Schuhe eingestellt, aber fast jeder einzelne Luft Nike Air Jordan Fersen nz Schuhe oder Stiefel hat einfach ist tief Interpretation. Air Jordan 1 wird von Nike entwickelt und zusätzlich abgeschlossen herauf Sein Jordan allererste Schuhe oder Stiefel, was können Sie, damit sie diese Art von irgendeiner Art iconic Schuhe zu sein. Air Jordan XI ist genial und zusätzlich durch Jordan verwendet werden, wie er dieses Wiederauftauchen erstellt und zusätzlich erworben, dass Meisterschaft, sowie andere. Also, was sind Sie in der Tat bereit und wartet, gehen und auch noch zusätzlich greifen die persönlichen Gruppe von Jordan Sneakers und zusätzlich auch das Spiel genießen, zeigen Sie die individuellen Design und auch der Rahmen des menschlichen Gehirns in Richtung der Basketball und auch Sport. Was könnte herausfinden rund um unsere Unternehmen erschwinglich und außerdem auch farbige Air Jordan Schuhe? Warten Sie nicht jede Art von mehr finden Sie in unserem Unternehmen Firmen-Website, sind Sie gehen, um gute Angebote und zusätzlich freie Fahrt zu bekommen. Nur mögen die wesentliche geeigneten Air Jordan Schuhe für die Situation und auch zusätzlich können Sie den Fokus des Gerichtssaals zu werden. Heute Air Jordan XX für die meisten Schuhe Fans, nie etwas erstaunlich. Gegründet im Jahr 2005 mit der Auslegung des Air Jordan XX, muss ständig Leser vergessen. Für alle von uns, Air Jordan XX top Muster ist definitiv eine zusätzliche Behauptung im Hintergrund, teilte es die bestehende zwanzig enthält den Wind und auch regen, und auch aufgezeichnet, butJordan und wie der Air Jordan TV-Serie vor kurzem zwanzig hochgeladen brillant. Die Mehrheit hat bekommen hatte von Chris Pauls Eifer für schnelle Fahrzeuge wurden zusammen mit dem Los Angeles Street-Racing-Display inspiriert. Die Packung ist sichtbar gründlich oben und zusätzlich auch mit hellen Farbvarianten einschließlich neon grün, heiß orangish sowie zusätzlich metallisches Silber. Der Jordan CP3.VI? Nitro Transport? Geplant ist ein Los Angeles-exklusive Release auf 21. Oktober, die fühlen sich verbunden mit einer breiteren Release im November Air Jordan 3 Montana werden. Die Erde Jordans Sammlung von Leichtathletik Schuhe oder vielleicht Schuhe oder Schuhe sind tatsächlich in einer Weise, die bessere Polsterung bietet dem Fuß mit der zusätzlichen Luft, die direkt in die Sohlen der Schuhe entworfen. Das könnte sicherlich zu den Features, die Air Jordans, ein beliebtes Motiv unter vielen für erfahrene Leichtathletik Stiefel use.Nike 's air technologies in Air Jordans verwendet hinzugefügt haben verhindert nicht wirklich unbedingt unversucht bei der Versorgung des größten Komfort, Polsterung, Zähigkeit und zusätzlich zusätzlich Flexibilität und ist auch wirklich ein starkes abnorme Tandem, um in so wenig wie über jeden Marke innerhalb erhalten die market.What 's ein gutes Geschäft attraktiver innerhalb der Air Jordans Tätigkeit ist bei weitem die in der Ferne mögen von Farben, Kunst und zusätzlich auch Arten, die wird stoßen, um sich mit ihren individuellen Vorlieben und auch fantastisch Romanfigur. Beats by Dre Schweiz http://www.beatsbydreschweizshop.eu/ XIV Endure getroffen hat bekam bekommen hatte bekommen hatte zusätzlich zu verkaufen sind, diese ausgezeichnete klassische weiß rot gefärbt und zusätzlich auch schwarz gefärbt Auswahl Farbstoffe Farben des Planeten Jordan XIV tatsächlich noch beobachten up. Einer hat eine Abdeckung sicher, die reinigt und hält auch mit der ständigen Pflege, die in der Regel bezahlt wird fünfundzwanzig jd ein 30 Tage und das entspricht über 30 $. Innerhalb des Jahres 1917 hatte die Converse war die sehr aufstrebendes Unternehmen zur Verbesserung der Fahne in ihm die Turnschuhe Produktion. Kensington Levels Optiker sind tatsächlich in der Tat in der Tat häufig auf dem Markt der Fokus-Objektiv zusammen mit Fenster Gewebe rund ein einem Jahrzehnt zusammen mit den dishing weg Optiker vermitteln viel viel mehr im Vergleich zu Fünfzehn unzähligen Jahren Erfahrung. - nike air max 1 women nike air max 1 sale -- View this message in context: http://git.661346.n2.nabble.com/Beats-by-Dre-Solo-tp7593492.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/9/2013 8:33, schrieb shawn wilson: On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/8/2013 23:11, schrieb Phil Hord: On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote: On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of these scripts and I'd like to keep the commit history. Ok, so: % find -type f ! -iname webban.pl | while read f; do git filter-branch -f --index-filter git rm --cached --ignore-unmatch $f HEAD ; done I'm not sure. On second thought, my suggested command is not sufficient. It does remove the empty commits, but it does not remove the other files. So, Shawn's original filter-branch invocations are still needed. Yeah, I have tried this and haven't gotten any closer. I can either remove all of the history or that one commit that has nothing to do with my file is there. This is also reproducable in a new repo. Is this a bug with filter-branch or git? This doesn't seem like a feature (or how things should act). Let's check: After running your command above to remove other files, does the command git filter-branch -f HEAD webban.pl Ahha, no but: git filter-branch -f HEAD -- webban.pl did Thanks. The question still stands though - why is that unassociated commit left there? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
Am 8/9/2013 12:03, schrieb shawn wilson: The question still stands though - why is that unassociated commit left there? Because your command did not remove it. filter-branch does not know that it is unassociated when you ask it to follow all commits beginning at HEAD. But when you say 'HEAD -- webban.pl', you ask it to follow only commits that touch webban.pl, which automatically skips that commit. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] parse-options: fix clang opterror() -Wunused-value warning
On Fri, Aug 09, 2013 at 05:06:17AM -0400, Eric Sunshine wrote: a469a1019352b8ef (silence some -Wuninitialized false positives; 2012-12-15) triggered unused value warnings when the return value of opterror() and several other error-related functions was not used. 5ded807f7c0be10e (fix clang -Wunused-value warnings for error functions; 2013-01-16) applied a fix by adding #if !defined(__clang__) in cache.h and git-compat-util.h, but misspelled it as #if !defined(clang) in parse-options.h. Fix this. This mistake went unnoticed because existing callers of opterror() utilize its return value. 1158826394e162c5 (parse-options: add OPT_CMDMODE(); 2013-07-30), however, adds a new invocation of opterror() which ignores the return value, thus triggering the unused value warning. Oops. Patch looks obviously correct. Thanks for a nice explanation of what happened. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug about Japanese' Documentation
On Wed, Aug 07, 2013 at 09:56:42PM +0900, a a wrote: I find 2 bug about Japanese' Documentation . There are Documentation - Book 's url. ( Please see the details below). I want to bug-fix about this misspell. Do you have Documentation (about Japanese language) on the GitHub? The documentation at http://git-scm.com comes from the Pro Git book. You can file issues and make pull requests here: https://github.com/progit/progit See the README for details. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Fri, Aug 09, 2013 at 01:34:48AM +0530, Ramkumar Ramachandra wrote: Certainly. A push will never use an existing pack as-is, as it's very highly unlikely that the server requested exactly what gc --auto packed for us locally. Sure, undeltified objects in the pack are probably better for push performance, but I'm talking about the majority: deltified objects. Don't you need to apply the deltas (ie. explode the pack), before you can recompute the deltas for the information you're sending across for the push? It depends on what each side has it, doesn't it? We generally try to reuse on-disk deltas when we can, since they require no computation. If I have object A delta'd against B, and I know that the other side wants A and has B (or I am also sending B), I can simply send what I have on disk. So we do not just blit out the existing pack as-is, but we may reuse portions of it as appropriate. Of course we may have to reconstruct deltas for trees in order to find the correct set of objects (i.e., the history traversal). But that is a separate phase from generating the pack's object content, and we do not reuse any of the traversal work in later phases. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Huge possible memory leak while cherry-picking.
Hi, I have tried to cherry-pick a range of ~200 commits from one branch to another. And you can't imagine how I was surprised when the git process ate 8 Gb of RAM and died - before cherry-picking was complete. I downloaded git sources from master and built it with gperftools support (-ltcmalloc). After running `git cherry-pick some hash` with a heap-leak checker enabled I got this: Have memory regions w/o callers: might report false leaks Leak check _main_ detected leaks of 42838782 bytes in 257986 objects These objects are allocated at read-cache.c:1340: struct cache_entry *ce = xmalloc(cache_entry_size(len)); After looking in the code, I found a comment in the function `static void remove_dir_entry(...)`: /* * Release reference to the directory entry (and parents if 0). * * Note: we do not remove / free the entry because there's no * hash.[ch]::remove_hash and dir-next may point to other entries * that are still valid, so we must not free the memory. */ So, this objects are never freed - by design? Is it a real issue, or do I just misunderstand something? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reproducible, corrupt packfile after fresh git-svn checkout message
Hello everybody! I have some _very interesting_ news regarding this issue! Here is the deal: 1. I was able to *reproduce the error on a machine of a coworker!* 2. I was able to rule out - HDD: It's reproducible from /dev/shm - Memory: Memory tests works fine now the interesting part: 3. Occurs on Linux kernels 3.7.10, 3.8.x, 3.9.11, 3.10.5 _but not on:_ 3.6.11, 3.5.7 and 2.6.32 Both machines showing this problem are »Dell Latitude E6330« with an »i5-3340M @ 2.70GHz« CPU. Mine running stock kernels, coworker using plain Ubuntu 13.04. Furthermore I need to stress, that we never had any issues with our devices during daily _at all_. So what to do best now? - Ben Am 08.08.2013 19:38, schrieb Junio C Hamano: Can you try to reproduce with a version older than v1.8.3? E.g. v1.8.2.3. It seems to run 'much better' v1.8.2.3 : 3/10 runs do fail fb56570 : 9/10 runs do fail [..] They always fail on a big blob (39MB) as I wrote in my first e-mail: ben@n179 /tmp/project.git $ ~/projects/git.git/git-show 49cdd0b21a351f3366008615d2cf8d03ca943978 | wc -c error: sha1 mismatch 49cdd0b21a351f3366008615d2cf8d03ca943978 fatal: bad object 49cdd0b21a351f3366008615d2cf8d03ca943978 0 ben@n179 /tmp/project.git $ ~/projects/git.git/git-show 49cdd0b21a351f3366008615d2cf8d03ca943978 | wc -c 39517156 Hmm, from this, and a later one ... ... I am reading that (1) the packfile and repository is basically OK, (2) reading that object sometimes fails, and (3) the symptom is not limited to fsck but anything that reads the object with parse_object(). And that symptom exists only on that single machine (I am assuming that the repository was bit-for-bit copied, not cloned, for the purpose of testing it on the other machine). That makes me suspect something outside the control of Git (e.g. faulty memory or disk controller cable). Are there other big blobs in the repository, and would show | wc fail if you attempt to read it on that machine? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GUILT] add FreeBSD support
From: Zheng Liu gnehzuil@gmail.com
Currently guilt doesn't support FreeBSD platform. This commit tries to
add this support. The file called 'os.FreeBSD' is copied from os.Darwin
due to these two platforms have almost the same command tools.
Signed-off-by: Zheng Liu gnehzuil@gmail.com
---
Hi all,
After applied this patch, the regression test 010 and 060 will fail because
of the output format. After fixing these issues, all the regression tests
will pass.
P.S. I don't subscribe git@ mailing list. So please put my email address
in Cc list. Thanks!
Regards,
- Zheng
os.FreeBSD | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 os.FreeBSD
diff --git a/os.FreeBSD b/os.FreeBSD
new file mode 100644
index 000..3f23121
--- /dev/null
+++ b/os.FreeBSD
@@ -0,0 +1,70 @@
+# usage: touch_date unix ts file
+touch_date()
+{
+ touch -t `date -r $1 +%Y%m%d%H%M.%S` $2
+}
+
+# usage: last_modified file
+last_modified()
+{
+ stat -f %m $1
+}
+
+# usage: format_last_modified file
+format_last_modified()
+{
+ stat -f %Sm -t %Y-%m-%d %H:%M:%S %z $1
+}
+
+# usage: head_n [count]
+head_n()
+{
+ if [ $1 -gt 0 ]; then
+ head -n $1
+ fi
+}
+
+# usage: sha1 [file]
+sha1()
+{
+ if [ $# = 1 ]
+ then
+ openssl dgst -sha1 $1 | sed s,SHA1.\(.*\).= \(.*\),\2 \1,
+ else
+ openssl dgst -sha1 | sed 's,\(.*= \)*\(.*\),\2 -,'
+ fi
+}
+
+# usage: cp_a src dst
+cp_a()
+{
+ cp -pR $1 $2
+}
+
+# usage: _tac
+_tac()
+{
+ sed -e '1!G;h;$!d'
+}
+
+_seq()
+{
+ (
+ if [ $# -eq 1 ]
+ then
+ /usr/bin/jot $1
+ elif [ $# -eq 2 ]
+ then
+ n1=$((${2} - ${1} + 1))
+ n2=$1
+ /usr/bin/jot $n1 $n2
+ elif [ $# -eq 3 ]
+ then
+ num1=$1
+ incr=$2
+ num2=$3
+ /usr/bin/awk -v n1=$num1 -v n2=$num2 -v add=$incr
'BEGIN{ for(i=n1; i=n2; i+=add) print i;}' | /usr/bin/sed -E '/e/s/^.+e.+$/0/'
+ fi
+ )
+ return 0
+}
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git status resets permissions on index file -- Ubuntu 12.04 64b
Justin Collum jcol...@gmail.com writes: sudo chmod 644 ./.git/index That doesn't make sense. If you are the owner of the file, why do you need sudo??? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] gc: reject if another gc is running, unless --force is given
On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano gits...@pobox.com wrote: When we see a recent lockfile created by a gc running elsewhere, we do not set should_exit. Is that a good thing? I am wondering if the last two lines should be: - !strcmp(locking_host, my_host) - !kill(pid, 0); + (strcmp(locking_host, my_host) || !kill(pid, 0)); instead. Yes I think it should (we still have the 12-hour check to override stale locks anyway). Should I send another patch or you do it yourself (seeing that you have this chunk pasted here, you might have it saved somewhere already) -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reproducible, corrupt packfile after fresh git-svn checkout message
On 08/09/2013 02:27 PM, Ben Tebulin wrote: Hello everybody! I have some _very interesting_ news regarding this issue! Here is the deal: 1. I was able to *reproduce the error on a machine of a coworker!* 2. I was able to rule out - HDD: It's reproducible from /dev/shm - Memory: Memory tests works fine now the interesting part: 3. Occurs on Linux kernels 3.7.10, 3.8.x, 3.9.11, 3.10.5 _but not on:_ 3.6.11, 3.5.7 and 2.6.32 Both machines showing this problem are »Dell Latitude E6330« with an »i5-3340M @ 2.70GHz« CPU. Mine running stock kernels, coworker using plain Ubuntu 13.04. Furthermore I need to stress, that we never had any issues with our devices during daily _at all_. So what to do best now? Maybe include the kernel mailing list, they know what's up ;) Linking to the start of the discussion $gmane/33602 Maybe you could also run git through strace and diff the output of a faulty machine with a correct machine? Stefan signature.asc Description: OpenPGP digital signature
Re: git status resets permissions on index file -- Ubuntu 12.04 64b
Andreas Schwab sch...@linux-m68k.org writes: Justin Collum jcol...@gmail.com writes: sudo chmod 644 ./.git/index That doesn't make sense. If you are the owner of the file, why do you need sudo??? I suspect that some over-use of sudo resulted in files or directories belonging to root. What does find . -user 0 say? (As a developer, you should never need sudo. You should only need in as an administrator of your machine.) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 12/19] read-cache: read index-v5
Duy Nguyen pclo...@gmail.com writes:
On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
Duy Nguyen pclo...@gmail.com writes:
[..]
+static int read_entries(struct index_state *istate, struct
directory_entry **de,
+ unsigned int *entry_offset, void **mmap,
+ unsigned long mmap_size, unsigned int *nr,
+ unsigned int *foffsetblock)
+{
+ struct cache_entry *head = NULL, *tail = NULL;
+ struct conflict_entry *conflict_queue;
+ struct cache_entry *ce;
+ int i;
+
+ conflict_queue = NULL;
+ if (read_conflicts(conflict_queue, *de, mmap, mmap_size) 0)
+ return -1;
+ for (i = 0; i (*de)-de_nfiles; i++) {
+ if (read_entry(ce,
+ *de,
+ entry_offset,
+ mmap,
+ mmap_size,
+ foffsetblock) 0)
+ return -1;
+ ce_queue_push(head, tail, ce);
+ *foffsetblock += 4;
+
+ /*
+* Add the conflicted entries at the end of the index file
+* to the in memory format
+*/
+ if (conflict_queue
+ (conflict_queue-entries-flags CONFLICT_CONFLICTED)
!= 0
+ !cache_name_compare(conflict_queue-name,
conflict_queue-namelen,
+ ce-name, ce_namelen(ce))) {
+ struct conflict_part *cp;
+ cp = conflict_queue-entries;
+ cp = cp-next;
+ while (cp) {
+ ce = convert_conflict_part(cp,
+ conflict_queue-name,
+ conflict_queue-namelen);
+ ce_queue_push(head, tail, ce);
+ conflict_part_head_remove(cp);
+ }
+ conflict_entry_head_remove(conflict_queue);
+ }
I start to wonder if separating staged entries is a good idea. It
seems to make the code more complicated. The good point about conflict
section at the end of the file is you can just truncate() it out.
Another way is putting staged entries in fileentries, sorted
alphabetically then by stage number, and a flag indicating if the
entry is valid. When you remove resolve an entry, just set the flag to
invalid (partial write), so that read code will skip it.
I think this approach is reasonably cheap (unless there are a lot of
conflicts) and it simplifies this piece of code. truncate() may be
overrated anyway. In my experience, I git add path as soon as I
resolve path (so that git diff shrinks). One entry at a time, one
index write at a time. I don't think I ever resolve everything then
git add -u ., which is where truncate() shines because staged
entries are removed all at once. We should optimize for one file
resolution at a time, imo.
Thanks for your comments. I'll address the other ones once we decided
to do with the conflicts.
It does make the code quite a bit more complicated, but also has one
advantage that you overlooked.
I did overlook, although my goal is to keep the code simpler, not more
comlicated. The thinking is if we can find everything in fileentries
table, the code here is simplified, so..
We wouldn't truncate() when resolving
the conflicts. The resolve undo data is stored with the conflicts and
therefore we could just flip a bit and set the stage of the cache-entry
in the main index to 0 (always once we got partial writing). This can
be fast both in case we resolve one entry at a time and when we resolve
a lot of entries. The advantage is even bigger when we resolve one
entry at a time, when we otherwise would have to re-write the index for
each conflict resolution.
If I understand it correctly, filentries can only contain stage-0 or
stage-1 entries, stage 0 entries are stored in conflict data. Once
a conflict is solved, you update the stage-1 entry in fileentries,
turning it to stage-0 and recalculate the entry checksum. Conflict
data remains there to function as the old REUC extension. Correct?
First of all, if that's true, we only need 1 bit for stage in fileentries
table.
Secondly, you may get away with looking up to conflict data in this
function by storing all stages in fileentries (now we need 2-bit
stage), replicated in conflict data for reuc function. When you
resolve conflict, you flip stage-1 to stage-0, and flip (a new bit) to
mark stage-2 entry invalid so the code knows to skip it. Next time the
index is rewritten, invalid entries are removed, but we still have old
stage entries in conflict data. The flipping business is pretty much
what you plan
Re: [RFC PATCH] During a shallow fetch, prevent sending over unneeded objects
On Fri, Aug 9, 2013 at 12:10 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
I fail to see the point here. There are two different things: what we
want to send, and what we can make deltas against. Shallow boundary
affects the former. What the recipient has affects latter. What is the
twist about?
do_rev_list() -- mark_edges_uninteresting() -- show_edge() callchain
that eventually does this:
static void show_edge(struct commit *commit)
{
fprintf(pack_pipe, -%s\n, sha1_to_hex(commit-object.sha1));
}
was what I had in mind.
Now I see. Thanks.
mark_edges_uninteresting() actually calls
mark_edge_parents_uninteresting(), which calls show_edge(). The middle
function is important because after calculating new depth, upload-pack
calls register_shallow() for all both old and new shallow roots and
those commits will have their 'parents' pointer set to NULL, which
renders mark_edge_parents_uninteresting() no-op. So show_edge() is
never called on shallow points' parents.
As for considering objects before shallow boundary uninteresting, I
have a plan for it: kill upload-pack.c:do_rev_list(). The function is
created to make a cut at shallow boundary,...
Hmph, that function is not primarily about shallow boundary but does
all packing in general.
The edge hinting in there is for thin transfer where the sender
sends deltas against base objects that are known to be present in
the receiving repository, without sending the base objects.
OK but edge hinting is the same in pack-objects.c:get_object_list() so
the plan might still work, right? I still need to study about
extra_edge_obj in upload-pack.c though. That's something knowledge
that pack-objects won't have.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
Jeff King wrote: It depends on what each side has it, doesn't it? We generally try to reuse on-disk deltas when we can, since they require no computation. If I have object A delta'd against B, and I know that the other side wants A and has B (or I am also sending B), I can simply send what I have on disk. So we do not just blit out the existing pack as-is, but we may reuse portions of it as appropriate. I'll raise some (hopefully interesting) points. Let's take the example of a simple push: I start send-pack, which in turn starts receive_pack on the server and connects its stdin/stdout to it (using git_connect). Now, it reads the (sha1, ref) pairs it receives on stdin and spawns pack-objects --stdout with the right arguments as the response, right? Overall, nothing special: just pack-objects invoked with specific arguments. How does pack-objects work? ll_find_deltas() spawns some worker threads to find_deltas(). This is where this get fuzzy for me: it calls try_delta() in a nested loop, trying to find the smallest delta, right? I'm not sure whether the interfaces it uses to read objects differentiates between packed deltas versus packed undeltified objects versus loose objects at all. Now, the main problem I see is that a pack has to be self-contained: I can't have an object bar which is a delta against an object that is not present in the pack, right? Therefore no matter what the server already has, I have to prepare deltas only against the data that I'm sending across. Of course we may have to reconstruct deltas for trees in order to find the correct set of objects (i.e., the history traversal). But that is a separate phase from generating the pack's object content, and we do not reuse any of the traversal work in later phases. I see. Are we talking about tree-walk.c here? This is not unique to packing at all; we need to do this kind of traversal for any git operation that digs into older history, no? I recall a discussion about using generation numbers to speed up the walk: I tried playing with your series (where you use a cache to keep the generation numbers), but got nowhere. Does it make sense to think about speeding up the walk (how?). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] configure.ac: move the private git m4 macro to a dedicated directory
Git use, as many project that use autoconf, private m4 macros.
When not using automake, and just relying on autoconf, the macro
files are not picked up by default.
A possibility, as git do today, is to put the private m4 macro
in the configure.ac file, so they will copied over the final configure
when calling autoreconf(that call also autocon). But this makes configure.ac
difficult
to read and maintain, especially if you want to introduce new macros later.
Starting from version 2.58, autoconf provide the macro AC_CONFIG_MACRO_DIR
to declare where additional macro files are to be put and found.
The argument passed to this macro is commonly m4.
This macro, for the longest time, has been used only by libtool
starting from version 2.0, to identify where to copy its own macro files
when using libtoolize --copy.
Starting from version 1.13, automake augments autoconf with a macro
called AC_CONFIG_MACRO_DIRS, that provides a space-separated list
of directories to use for looking up m4 files.
The same macro will be available as part of autoconf 2.70,
actually in development. Anyway also this version permit
to use AC_CONFIG_MACRO_DIR and not need automake.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
configure.ac | 139 +-
m4/git.m4| 139 ++
2 files changed, 140 insertions(+), 138 deletions(-)
create mode 100644 m4/git.m4
diff --git a/configure.ac b/configure.ac
index 2f43393..b686c10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,150 +1,13 @@
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
-## Definitions of private macros.
-
-# GIT_CONF_SUBST(VAL, VAR)
-#
-# Cause the line VAR=VAL to be eventually appended to ${config_file}.
-AC_DEFUN([GIT_CONF_SUBST],
-[AC_REQUIRE([GIT_CONF_SUBST_INIT])
-config_appended_defs=$config_appended_defs${newline}dnl
-$1=m4_if([$#],[1],[${$1}],[$2])])
-
-# GIT_CONF_SUBST_INIT
-# ---
-# Prepare shell variables and autoconf machine required by later calls
-# to GIT_CONF_SUBST.
-AC_DEFUN([GIT_CONF_SUBST_INIT],
-[config_appended_defs=; newline='
-'
-AC_CONFIG_COMMANDS([$config_file],
- [echo $config_appended_defs $config_file],
- [config_file=$config_file
-config_appended_defs=$config_appended_defs])])
-
-# GIT_ARG_SET_PATH(PROGRAM)
-# -
-# Provide --with-PROGRAM=PATH option to set PATH to PROGRAM
-# Optional second argument allows setting NO_PROGRAM=YesPlease if
-# --without-PROGRAM version used.
-AC_DEFUN([GIT_ARG_SET_PATH],
-[AC_ARG_WITH([$1],
-[AS_HELP_STRING([--with-$1=PATH],
-[provide PATH to $1])],
-[GIT_CONF_APPEND_PATH([$1], [$2])],
-[])])
-
-# GIT_CONF_APPEND_PATH(PROGRAM)
-# -
-# Parse --with-PROGRAM=PATH option to set PROGRAM_PATH=PATH
-# Used by GIT_ARG_SET_PATH(PROGRAM)
-# Optional second argument allows setting NO_PROGRAM=YesPlease if
-# --without-PROGRAM is used.
-AC_DEFUN([GIT_CONF_APPEND_PATH],
-[m4_pushdef([GIT_UC_PROGRAM], m4_toupper([$1]))dnl
-if test $withval = no; then
- if test -n $2; then
- GIT_UC_PROGRAM[]_PATH=$withval
- AC_MSG_NOTICE([Disabling use of GIT_UC_PROGRAM])
- GIT_CONF_SUBST([NO_]GIT_UC_PROGRAM, [YesPlease])
- GIT_CONF_SUBST(GIT_UC_PROGRAM[]_PATH, [])
- else
- AC_MSG_ERROR([You cannot use git without $1])
- fi
-else
- if test $withval = yes; then
- AC_MSG_WARN([You should provide path for --with-$1=PATH])
- else
- GIT_UC_PROGRAM[]_PATH=$withval
- AC_MSG_NOTICE([Setting GIT_UC_PROGRAM[]_PATH to $withval])
- GIT_CONF_SUBST(GIT_UC_PROGRAM[]_PATH, [$withval])
- fi
-fi
-m4_popdef([GIT_UC_PROGRAM])])
-
-# GIT_PARSE_WITH(PACKAGE)
-# ---
-# For use in AC_ARG_WITH action-if-found, for packages default ON.
-# * Set NO_PACKAGE=YesPlease for --without-PACKAGE
-# * Set PACKAGEDIR=PATH for --with-PACKAGE=PATH
-# * Unset NO_PACKAGE for --with-PACKAGE without ARG
-AC_DEFUN([GIT_PARSE_WITH],
-[m4_pushdef([GIT_UC_PACKAGE], m4_toupper([$1]))dnl
-if test $withval = no; then
- NO_[]GIT_UC_PACKAGE=YesPlease
-elif test $withval = yes; then
- NO_[]GIT_UC_PACKAGE=
-else
- NO_[]GIT_UC_PACKAGE=
- GIT_UC_PACKAGE[]DIR=$withval
- AC_MSG_NOTICE([Setting GIT_UC_PACKAGE[]DIR to $withval])
- GIT_CONF_SUBST(GIT_UC_PACKAGE[DIR], [$withval])
-fi
-m4_popdef([GIT_UC_PACKAGE])])
-
-# GIT_PARSE_WITH_SET_MAKE_VAR(WITHNAME, VAR, HELP_TEXT)
-# -
-# Set VAR to the value specied by --with-WITHNAME.
-# No verification of arguments is performed, but
Re: [GUILT] add FreeBSD support
On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
From: Zheng Liu gnehzuil@gmail.com
Currently guilt doesn't support FreeBSD platform. This commit tries to
add this support. The file called 'os.FreeBSD' is copied from os.Darwin
due to these two platforms have almost the same command tools.
Out of curiosity, is it identical? I eyeballed it, and they do look
identical. There's probably a better way to do this whole os-specific
thing, but this will work well enough for now.
Jeff.
Signed-off-by: Zheng Liu gnehzuil@gmail.com
---
Hi all,
After applied this patch, the regression test 010 and 060 will fail because
of the output format. After fixing these issues, all the regression tests
will pass.
P.S. I don't subscribe git@ mailing list. So please put my email address
in Cc list. Thanks!
Regards,
- Zheng
os.FreeBSD | 70
++
1 file changed, 70 insertions(+)
create mode 100644 os.FreeBSD
diff --git a/os.FreeBSD b/os.FreeBSD
new file mode 100644
index 000..3f23121
--- /dev/null
+++ b/os.FreeBSD
@@ -0,0 +1,70 @@
+# usage: touch_date unix ts file
+touch_date()
+{
+ touch -t `date -r $1 +%Y%m%d%H%M.%S` $2
+}
+
+# usage: last_modified file
+last_modified()
+{
+ stat -f %m $1
+}
+
+# usage: format_last_modified file
+format_last_modified()
+{
+ stat -f %Sm -t %Y-%m-%d %H:%M:%S %z $1
+}
+
+# usage: head_n [count]
+head_n()
+{
+ if [ $1 -gt 0 ]; then
+ head -n $1
+ fi
+}
+
+# usage: sha1 [file]
+sha1()
+{
+ if [ $# = 1 ]
+ then
+ openssl dgst -sha1 $1 | sed s,SHA1.\(.*\).= \(.*\),\2 \1,
+ else
+ openssl dgst -sha1 | sed 's,\(.*= \)*\(.*\),\2 -,'
+ fi
+}
+
+# usage: cp_a src dst
+cp_a()
+{
+ cp -pR $1 $2
+}
+
+# usage: _tac
+_tac()
+{
+ sed -e '1!G;h;$!d'
+}
+
+_seq()
+{
+ (
+ if [ $# -eq 1 ]
+ then
+ /usr/bin/jot $1
+ elif [ $# -eq 2 ]
+ then
+ n1=$((${2} - ${1} + 1))
+ n2=$1
+ /usr/bin/jot $n1 $n2
+ elif [ $# -eq 3 ]
+ then
+ num1=$1
+ incr=$2
+ num2=$3
+ /usr/bin/awk -v n1=$num1 -v n2=$num2 -v add=$incr
'BEGIN{ for(i=n1; i=n2; i+=add) print i;}' | /usr/bin/sed -E
'/e/s/^.+e.+$/0/'
+ fi
+ )
+ return 0
+}
--
1.8.3.4
--
Research, n.:
Consider Columbus:
He didn't know where he was going.
When he got there he didn't know where he was.
When he got back he didn't know where he had been.
And he did it all on someone else's money.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
On Fri, Aug 9, 2013 at 6:03 AM, shawn wilson ag4ve...@gmail.com wrote: On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt j.s...@viscovery.net wrote: Let's check: After running your command above to remove other files, does the command git filter-branch -f HEAD webban.pl Ahha, no but: git filter-branch -f HEAD -- webban.pl did Thanks. The question still stands though - why is that unassociated commit left there? Maybe you need --prune-empty. Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GUILT] add FreeBSD support
在 2013-8-9，下午10:46，Josef 'Jeff' Sipek jef...@josefsipek.net 写道：
On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
From: Zheng Liu gnehzuil@gmail.com
Currently guilt doesn't support FreeBSD platform. This commit tries to
add this support. The file called 'os.FreeBSD' is copied from os.Darwin
due to these two platforms have almost the same command tools.
Out of curiosity, is it identical? I eyeballed it, and they do look
identical. There's probably a better way to do this whole os-specific
thing, but this will work well enough for now.
Yes, it is identical. Sorry, I am a newbie for guilt, but I am happy to
improve this os-specific thing.Any idea?
Regards,
- Zheng
Jeff.
Signed-off-by: Zheng Liu gnehzuil@gmail.com
---
Hi all,
After applied this patch, the regression test 010 and 060 will fail because
of the output format. After fixing these issues, all the regression tests
will pass.
P.S. I don't subscribe git@ mailing list. So please put my email address
in Cc list. Thanks!
Regards,
- Zheng
os.FreeBSD | 70
++
1 file changed, 70 insertions(+)
create mode 100644 os.FreeBSD
diff --git a/os.FreeBSD b/os.FreeBSD
new file mode 100644
index 000..3f23121
--- /dev/null
+++ b/os.FreeBSD
@@ -0,0 +1,70 @@
+# usage: touch_date unix ts file
+touch_date()
+{
+touch -t `date -r $1 +%Y%m%d%H%M.%S` $2
+}
+
+# usage: last_modified file
+last_modified()
+{
+stat -f %m $1
+}
+
+# usage: format_last_modified file
+format_last_modified()
+{
+stat -f %Sm -t %Y-%m-%d %H:%M:%S %z $1
+}
+
+# usage: head_n [count]
+head_n()
+{
+if [ $1 -gt 0 ]; then
+head -n $1
+fi
+}
+
+# usage: sha1 [file]
+sha1()
+{
+if [ $# = 1 ]
+then
+openssl dgst -sha1 $1 | sed s,SHA1.\(.*\).= \(.*\),\2 \1,
+else
+openssl dgst -sha1 | sed 's,\(.*= \)*\(.*\),\2 -,'
+fi
+}
+
+# usage: cp_a src dst
+cp_a()
+{
+cp -pR $1 $2
+}
+
+# usage: _tac
+_tac()
+{
+sed -e '1!G;h;$!d'
+}
+
+_seq()
+{
+(
+if [ $# -eq 1 ]
+then
+/usr/bin/jot $1
+elif [ $# -eq 2 ]
+then
+n1=$((${2} - ${1} + 1))
+n2=$1
+/usr/bin/jot $n1 $n2
+elif [ $# -eq 3 ]
+then
+num1=$1
+incr=$2
+num2=$3
+/usr/bin/awk -v n1=$num1 -v n2=$num2 -v add=$incr 'BEGIN{
for(i=n1; i=n2; i+=add) print i;}' | /usr/bin/sed -E '/e/s/^.+e.+$/0/'
+fi
+)
+return 0
+}
--
1.8.3.4
--
Research, n.:
Consider Columbus:
He didn't know where he was going.
When he got there he didn't know where he was.
When he got back he didn't know where he had been.
And he did it all on someone else's money.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GUILT] add FreeBSD support
On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote: �� 2013-8-9��10:46��Josef 'Jeff' Sipek jef...@josefsipek.net д On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote: From: Zheng Liu gnehzuil@gmail.com Currently guilt doesn't support FreeBSD platform. This commit tries to add this support. The file called 'os.FreeBSD' is copied from os.Darwin due to these two platforms have almost the same command tools. Out of curiosity, is it identical? I eyeballed it, and they do look identical. There's probably a better way to do this whole os-specific thing, but this will work well enough for now. Yes, it is identical. Sorry, I am a newbie for guilt, but I am happy to improve this os-specific thing.Any idea? So, I'm a bit torn between some build-time checking that generates something like an os file based on what it detects and something that happens at runtime. I like that currently there's nothing to do - you just clone the repo and you're set. At the same time, the more code can be avoided executing the faster (in theory) guilt gets. Feel free to experiment. Jeff. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
post-rewrite hook doesn't run
for git pull --rebase. I see it run when I do git rebase -i Is this a bug or feature? It's with git version 1.7.11.7. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] gc: reject if another gc is running, unless --force is given
Duy Nguyen pclo...@gmail.com writes: On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano gits...@pobox.com wrote: When we see a recent lockfile created by a gc running elsewhere, we do not set should_exit. Is that a good thing? I am wondering if the last two lines should be: - !strcmp(locking_host, my_host) - !kill(pid, 0); + (strcmp(locking_host, my_host) || !kill(pid, 0)); instead. Yes I think it should (we still have the 12-hour check to override stale locks anyway). Should I send another patch or you do it yourself (seeing that you have this chunk pasted here, you might have it saved somewhere already) The above was typed in my MUA ;-), but it is an easy update I can do so will do so anyway. Thanks for double-checking. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] gc: reject if another gc is running, unless --force is given
On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This may happen when `git gc --auto` is run automatically, then the
user, to avoid wait time, switches to a new terminal, keeps working
and `git gc --auto` is started again because the first gc instance has
not clean up the repository.
This patch tries to avoid multiple gc running, especially in --auto
mode. In the worst case, gc may be delayed 12 hours if a daemon reuses
the pid stored in gc.pid.
kill(pid, 0) support is added to MinGW port so it should work on
Windows too.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
this patch is getting cooler:
- uname() is dropped in favor of gethostbyname(), which is supported
by MinGW port.
- host name is stored in gc.pid as junio suggested so...
- now we can say gc is already running on _this host_ with _this pid_...
Documentation/git-gc.txt | 6 -
builtin/gc.c | 67
compat/mingw.c | 6 +
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 2402ed6..e158a3b 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -9,7 +9,7 @@ git-gc - Cleanup unnecessary files and optimize the local
repository
SYNOPSIS
[verse]
-'git gc' [--aggressive] [--auto] [--quiet] [--prune=date | --no-prune]
+'git gc' [--aggressive] [--auto] [--quiet] [--prune=date | --no-prune]
[--force]
DESCRIPTION
---
@@ -72,6 +72,10 @@ automatic consolidation of packs.
--quiet::
Suppress all progress reports.
+--force::
+ Force `git gc` to run even if there may be another `git gc`
+ instance running on this repository.
+
Configuration
-
diff --git a/builtin/gc.c b/builtin/gc.c
index 6be6c8d..99682f0 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -167,11 +167,69 @@ static int need_to_gc(void)
return 1;
}
+/* return NULL on success, else hostname running the gc */
+static const char *lock_repo_for_gc(int force, pid_t* ret_pid)
+{
+ static struct lock_file lock;
+ static char locking_host[128];
+ char my_host[128];
+ struct strbuf sb = STRBUF_INIT;
+ struct stat st;
+ uintmax_t pid;
pid_t is always an signed type, therefore unintmax_t does not make
sense as a catch all value
fork() returns -1 on failure, and its return type is pid_t. i don't
know what fantasy unix system has an unsigned pid_t
+ FILE *fp;
+ int fd, should_exit;
+
+ if (gethostname(my_host, sizeof(my_host)))
+ strcpy(my_host, unknown);
+
+ fd = hold_lock_file_for_update(lock, git_path(gc.pid),
+ LOCK_DIE_ON_ERROR);
+ if (!force) {
+ fp = fopen(git_path(gc.pid), r);
+ memset(locking_host, 0, sizeof(locking_host));
+ should_exit =
+ fp != NULL
+ !fstat(fileno(fp), st)
+ /*
+* 12 hour limit is very generous as gc should
+* never take that long. On the other hand we
+* don't really need a strict limit here,
+* running gc --auto one day late is not a big
+* problem. --force can be used in manual gc
+* after the user verifies that no gc is
+* running.
+*/
+ time(NULL) - st.st_mtime = 12 * 3600
+ fscanf(fp, %PRIuMAX %127c, pid, locking_host) ==
2
similar comment wrt PRIuMAX
+ !strcmp(locking_host, my_host)
+ !kill(pid, 0);
+ if (fp != NULL)
+ fclose(fp);
+ if (should_exit) {
+ if (fd = 0)
+ rollback_lock_file(lock);
+ *ret_pid = pid;
+ return locking_host;
why not exponential backoff?
+ }
+ }
+
+ strbuf_addf(sb, %PRIuMAX %s,
+ (uintmax_t) getpid(), my_host);
+ write_in_full(fd, sb.buf, sb.len);
+ strbuf_release(sb);
+ commit_lock_file(lock);
+
+ return NULL;
+}
+
int cmd_gc(int argc, const char **argv, const char *prefix)
{
int aggressive = 0;
int auto_gc = 0;
int quiet = 0;
+ int force = 0;
+ const char *name;
+ pid_t pid;
struct option builtin_gc_options[] = {
OPT__QUIET(quiet, N_(suppress progress reporting)),
@@ -180,6 +238,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
PARSE_OPT_OPTARG, NULL, (intptr_t)prune_expire },
OPT_BOOLEAN(0, aggressive,
[PATCH 1/2] remote-hg: add shared repo upgrade
From: Felipe Contreras felipe.contre...@gmail.com
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial to upgrade to the new organization by copying the Mercurial
repo from one of the remotes (e.g. 'origin'), so let's do so. If we
can't find any existing repo, we create an empty one.
Reported-by: Joern Hees d...@joernhees.de
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..1897327 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -391,11 +391,22 @@ def get_repo(url, alias):
os.makedirs(dirname)
else:
shared_path = os.path.join(gitdir, 'hg')
-if not os.path.exists(shared_path):
-try:
-hg.clone(myui, {}, url, shared_path, update=False, pull=True)
-except:
-die('Repository error')
+
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if os.path.exists(shared_path) and not os.path.exists(hg_path):
+repos = os.listdir(shared_path)
+for x in repos:
+local_hg = os.path.join(shared_path, x, 'clone', '.hg')
+if os.path.exists(local_hg):
+shutil.copytree(local_hg, hg_path)
+break
+
+# setup shared repo (if not there)
+try:
+hg.peer(myui, {}, shared_path, create=True)
+except error.RepoError:
+pass
if not os.path.exists(dirname):
os.makedirs(dirname)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] configure.ac: move the private git m4 macro to a dedicated directory
Elia Pinto gitter.spi...@gmail.com writes: Git use, as many project that use autoconf, private m4 macros. When not using automake, and just relying on autoconf, the macro files are not picked up by default. A possibility, as git do today, is to put the private m4 macro in the configure.ac file, so they will copied over the final configure when calling autoreconf(that call also autocon). But this makes configure.ac difficult to read and maintain, especially if you want to introduce new macros later. Starting from version 2.58, autoconf provide the macro AC_CONFIG_MACRO_DIR to declare where additional macro files are to be put and found. The argument passed to this macro is commonly m4. This macro, for the longest time, has been used only by libtool starting from version 2.0, to identify where to copy its own macro files when using libtoolize --copy. Starting from version 1.13, automake augments autoconf with a macro called AC_CONFIG_MACRO_DIRS, that provides a space-separated list of directories to use for looking up m4 files. The same macro will be available as part of autoconf 2.70, actually in development. Anyway also this version permit to use AC_CONFIG_MACRO_DIR and not need automake. Signed-off-by: Elia Pinto gitter.spi...@gmail.com That explains why you created a separate directory to for the new file and why you needed to use AC_CONFIG_MACRO_DIR while doing so. But in the above explanation, I fail to see the reason why we would want to create that new file out of the existing file, only to include it in the original file. Why is it needed? Why is it a good idea? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git status resets permissions on index file -- Ubuntu 12.04 64b
That doesn't make sense. If you are the owner of the file, why do you need sudo??? I've just never seen a chmod command without sudo. I assumed it was needed. Is this relevant to the bug that I'm seeing? On Fri, Aug 9, 2013 at 5:40 AM, Andreas Schwab sch...@linux-m68k.org wrote: Justin Collum jcol...@gmail.com writes: sudo chmod 644 ./.git/index That doesn't make sense. If you are the owner of the file, why do you need sudo??? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git for the Windows 1.8.3, GIT Bash icon issue
There is a standard command prompt icon in taskbar for GIT Bash instead of GIT icon Steps to reproduce: Select Taskbar Properties, Taskbar buttons, set to Never combine Run GIT Bash Best regards, Dmitry Kuzminov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] submodule: fix confusing variable name
Fredrik Gustafsson wrote: On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote: But we'll have to use sm_path here (like everywhere else in the submodule script), because we'll run into problems under Windows otherwise (see 64394e3ae9 for details). Apart from that the patch is fine. We're still using path= in the foreach-script. Or rather, we're setting it. From what I can see and from the commit message 64394e3ae9 it could possible be a problem. Please do not use a $path variable in any script intended to be run on windows; those poor souls who would otherwise have to fix the bugs will thank you! :-D Actually, it's not so much the use of a $path variable, rather the act of _exporting_ such a variable that causes the problem. (Which is why using $path with eval_gettext[ln] is such a problem, of course.) As noted in the above commit, $path is unfortunately a documented part of the public API for the foreach subcommand. However, the foreach subcommand is (mostly) fine; given the fact that the user script is eval-ed in a context in which $path is not exported. The reason for the 'mostly' is simply that the user could shoot himself in the foot by export-ing $path in their script, so that something like: $ git submodule foreach 'export path; echo $path `git rev-parse HEAD`' will indeed fail (ie git rev-parse will not execute). Not sure how to solve it though... Just a simple correction would break all script depending on that. $path is part of the public API, so we can't just remove it. It would require a deprecation period, etc,. (Adding/documenting $sm_path as an alternative *may* be worth doing. dunno.) HTH ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote-hg: fix path when cloning with tilde expansion
The current code fixes the path to make it absolute when cloning, but doesn't consider tilde expansion, so that scenario fails throwing an exception because /home/myuser/~/my/repository doesn't exists: $ git clone hg::~/my/repository cd repository git fetch Expand the tilde when checking if the path is absolute, so that we don't fix a path that doesn't need to be. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Shouldn't that be the job of the shell? (s/~/$HOME/) I'm not sure what you mean here. Does it mean that I should stop cloning using ~ ? I also send this patch as I think it makes more sense to keep the ~ in the path, but just make sure we don't build invalid absolute path. By the way, I don't exactly understand why: abs_url = urlparse.urljoin(%s/ % os.getcwd(), orig_url) is done right after instead of: abs_url = os.path.abspath(orig_url) Cheers, Antoine contrib/remote-helpers/git-remote-hg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 1897327..861c498 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -1135,7 +1135,7 @@ def do_option(parser): def fix_path(alias, repo, orig_url): url = urlparse.urlparse(orig_url, 'file') -if url.scheme != 'file' or os.path.isabs(url.path): +if url.scheme != 'file' or os.path.isabs(os.path.expanduser(url.path)): return abs_url = urlparse.urljoin(%s/ % os.getcwd(), orig_url) cmd = ['git', 'config', 'remote.%s.url' % alias, hg::%s % abs_url] -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remove old forgotten command: whatchanged
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
It is meant to teach them if you want to do your own 'git log', you
can do so with 'rev-list' piped to 'diff-tree --stdin'. Changing
'whatchanged' to 'log' in the latter statement is an improvement,
but dropping 'can be done by combining rev-list and diff-tree' goes
against the objective of the whole document.
Then, we can keep the In fact, together with the 'git rev-list'
program ... sentence, but drop A trivial (but very useful)
script ..., which is both technically incorrect (whatchanged is not a
script anymore) and misleading because it advertises whatchanged.
That would look like this:
Yeah, but I think we further can strip it down and remove git log
invocation that is done without argument. This document is not
about teaching the command you use to view the history is 'log'
(the new tutorial and the user manuals are), and this subsection is
about diff-tree (in the section about Inspecting Changes with
plumbing in the diff family).
How about doing it like this?
-- 8 --
Subject: core-tutorial: trim the section on Inspecting Changes
Back when the core tutorial was written, `log` and `whatchanged`
were scripted Porcelains. In the Inspecting Changes section that
talks about the plumbing commands in the diff family, it made sense
to use `log` and `whatchanged` as good examples of the use of these
plumbing commands, and because even these scripted Porcelains were
novelty (there wasn't the new end-user tutorial written), it made
some sense to illustrate uses of the `git log` (and `git
whatchanged`) scripted Porcelain commands.
But we no longer have scripted `log` and `whatchanged` to serve as
examples, and this document is not where the end users learn what
`git log` command is about. Stop at briefly mentioning the
possibility of combining rev-list with diff-tree to build your own
log, and leave the end-user documentation of `log` to the new
tutorial and the user manual.
Also resurrect the last version of `git-log`, `git-whatchanged`, and
`git-show` to serve as examples to contrib/examples/ directory.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/gitcore-tutorial.txt | 39 +++--
contrib/examples/git-log.sh | 15 ++
contrib/examples/git-whatchanged.sh | 28 ++
3 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt
b/Documentation/gitcore-tutorial.txt
index f538a87..3e83e1e 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -534,42 +534,9 @@ all, but just show the actual commit message.
In fact, together with the 'git rev-list' program (which generates a
list of revisions), 'git diff-tree' ends up being a veritable fount of
-changes. A trivial (but very useful) script called 'git whatchanged' is
-included with Git which does exactly this, and shows a log of recent
-activities.
-
-To see the whole history of our pitiful little git-tutorial project, you
-can do
-
-
-$ git log
-
-
-which shows just the log messages, or if we want to see the log together
-with the associated patches use the more complex (and much more
-powerful)
-
-
-$ git whatchanged -p
-
-
-and you will see exactly what has changed in the repository over its
-short history.
-
-[NOTE]
-When using the above two commands, the initial commit will be shown.
-If this is a problem because it is huge, you can hide it by setting
-the log.showroot configuration variable to false. Having this, you
-can still show it for each command just adding the `--root` option,
-which is a flag for 'git diff-tree' accepted by both commands.
-
-With that, you should now be having some inkling of what Git does, and
-can explore on your own.
-
-[NOTE]
-Most likely, you are not directly using the core
-Git Plumbing commands, but using Porcelain such as 'git add', `git-rm'
-and `git-commit'.
+changes. You can emulate `git log` with a trivial script that pipes
+the output of `git rev-list` to `git diff-tree --stdin`, which was
+exactly how early versions of `git log` were implemented.
Tagging a version
diff --git a/contrib/examples/git-log.sh b/contrib/examples/git-log.sh
new file mode 100755
index 000..c2ea71c
--- /dev/null
+++ b/contrib/examples/git-log.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Linus Torvalds
+#
+
+USAGE='[--max-count=n] [since..limit] [--pretty=format] [git-rev-list
options]'
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
+
+revs=$(git-rev-parse --revs-only --no-flags --default HEAD $@) || exit
+[ $revs ] || {
+ die No HEAD ref
+}
+git-rev-list --pretty $(git-rev-parse --default HEAD $@) |
+LESS=-S ${PAGER:-less}
diff --git a/contrib/examples/git-whatchanged.sh
b/contrib/examples/git-whatchanged.sh
new file mode 100755
index 000..1fb9feb
--- /dev/null
+++
Re: [PATCH] git exproll: steps to tackle gc aggression
Ramkumar Ramachandra artag...@gmail.com writes: I'll raise some (hopefully interesting) points. Let's take the example of a simple push: I start send-pack, which in turn starts receive_pack on the server and connects its stdin/stdout to it (using git_connect). Now, it reads the (sha1, ref) pairs it receives on stdin and spawns pack-objects --stdout with the right arguments as the response, right? Overall, nothing special: just pack-objects invoked with specific arguments. How does pack-objects work? ... You've been here long enough to know that you can and should learn things yourself instead of repeating tell me tell me ;-) threads to find_deltas(). This is where this get fuzzy for me: it calls try_delta() in a nested loop, trying to find the smallest delta, right? Yes. I'm not sure whether the interfaces it uses to read objects differentiates between packed deltas versus packed undeltified objects versus loose objects at all. Yes, but that happens way before that. Start reading from pack-heuristics document to get the general overall feel of what goes on, and then go back to the source. Now, the main problem I see is that a pack has to be self-contained: I can't have an object bar which is a delta against an object that is not present in the pack, right? Therefore no matter what the server already has, I have to prepare deltas only against the data that I'm sending across. There is a --thin option to allow deltas against base objects that are known to exist on the other end to be used in the pack without including the base objects. The receiving end then re-adds the base objects to the received data to complete the pack. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] gc: reject if another gc is running, unless --force is given
Andres Perera andre...@zoho.com writes:
+/* return NULL on success, else hostname running the gc */
+static const char *lock_repo_for_gc(int force, pid_t* ret_pid)
+{
+ static struct lock_file lock;
+ static char locking_host[128];
+ char my_host[128];
+ struct strbuf sb = STRBUF_INIT;
+ struct stat st;
+ uintmax_t pid;
pid_t is always an signed type, therefore unintmax_t does not make
sense as a catch all value
Good eyes.
+ !strcmp(locking_host, my_host)
+ !kill(pid, 0);
+ if (fp != NULL)
+ fclose(fp);
+ if (should_exit) {
+ if (fd = 0)
+ rollback_lock_file(lock);
+ *ret_pid = pid;
+ return locking_host;
why not exponential backoff?
If the other guy is doing a GC, and we decide that we should exit,
it is *not* because we want to wait until the other guy is done. It
is because we know we do not have to do the work --- the other guy
is doing what we were about to do, and it will do it for us anyway.
So I do not think it makes any sense to do exponential backoff if
gc --auto is asking should we exit to this logic.
An explicit gc, on the other hand, may benefit from backoff, but
then the user can choose to do so himself, and more importantly, the
user can see ah, another one is running so enough cruft will be
cleaned up anyway and choose not to run it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] configure.ac: move the private git m4 macro to a dedicated directory
2013/8/9 Junio C Hamano gits...@pobox.com: Elia Pinto gitter.spi...@gmail.com writes: Git use, as many project that use autoconf, private m4 macros. When not using automake, and just relying on autoconf, the macro files are not picked up by default. A possibility, as git do today, is to put the private m4 macro in the configure.ac file, so they will copied over the final configure when calling autoreconf(that call also autocon). But this makes configure.ac difficult to read and maintain, especially if you want to introduce new macros later. Starting from version 2.58, autoconf provide the macro AC_CONFIG_MACRO_DIR to declare where additional macro files are to be put and found. The argument passed to this macro is commonly m4. This macro, for the longest time, has been used only by libtool starting from version 2.0, to identify where to copy its own macro files when using libtoolize --copy. Starting from version 1.13, automake augments autoconf with a macro called AC_CONFIG_MACRO_DIRS, that provides a space-separated list of directories to use for looking up m4 files. The same macro will be available as part of autoconf 2.70, actually in development. Anyway also this version permit to use AC_CONFIG_MACRO_DIR and not need automake. Signed-off-by: Elia Pinto gitter.spi...@gmail.com That explains why you created a separate directory to for the new file and why you needed to use AC_CONFIG_MACRO_DIR while doing so. But in the above explanation, I fail to see the reason why we would want to create that new file out of the existing file, only to include it in the original file. Thanks. For those who use the gnu build tool is good practice to separate the private macros, very equilalent to an external library of C, from the main configure.ac file. Readability, maintainability are in general the reason in the same measure that everyone use external libraries or external includes in C to simplify the writing of a program. Just for a simple example, if I want to introduce new test macros for understeand in a portable way what are the C flags that a compiler understand - for QA, memory checker ecc - is much more readable and easy to update a separate file that to update the main configure.ac file that is not intended to contain the declaration of m4 macro and can grow larger. In fact from my experience it is difficult to find many program that not use a separate macro dir and use the gnu build tool. Sorry if I was not clear, perhaps it is due to the fact that i have the habit of using the gnu build tool always and i think that something is obvious but often it is not so obvious to everyone. Thanks and best regards Why is it needed? Why is it a good idea? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/git-merge-file: document option --diff3
The option --diff3 was added to git merge-file in e0af48e (xdiff-merge: optionally show conflicts in diff3 -m style) but it was never documented in Documentation/git-merge-file.txt. Add documentation for this option. Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- Documentation/git-merge-file.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index d7db2a3..d2fc12e 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git merge-file' [-L current-name [-L base-name [-L other-name]]] [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=n] - current-file base-file other-file + [--[no-]diff3] current-file base-file other-file DESCRIPTION @@ -66,6 +66,9 @@ OPTIONS -q:: Quiet; do not warn about conflicts. +--diff3:: + Show conflicts in diff3 style. + --ours:: --theirs:: --union:: -- 1.8.4.rc1.29.g4402f30 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] .mailmap organization
Hello, Patch 1 is fixing up the mistakes of the previous series. Patch 2 should really be discussed as I am unsure about the approach. During the time trying to get the .mailmap file in shape I wrote lots of emails. There have been many bounces, because some addresses are no longer valid. Sometimes even all email addresses of one name bounced. These people cannot be contacted easily, but we can also not be sure, whether these are one person or indeed 2 persons with the same name having different mail addresses. So that patch is a proposal to just mark those authors in the .mailmap as unreachable via a comment. Stefan Beller (2): .mailmap: fixup entries .mailmap: mark bouncing email addresses .mailmap | 31 +-- 1 file changed, 29 insertions(+), 2 deletions(-) -- 1.8.4.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] .mailmap: fixup entries
This patch adds no new names, but fixes the mistakes I made in the previous commits. (94b410bba8, f4f49e225, c07a6bc57, 2013-07-12, .mailmap: Map email addresses to names). These mistakes are double white spaces between name and surname, different capitalization in email address, or just the email address set as name. Also I forgot to include James Knight to the mailmap file. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/.mailmap b/.mailmap index dfa2e65..840abf7 100644 --- a/.mailmap +++ b/.mailmap @@ -14,6 +14,7 @@ Alex Riesen raa.l...@gmail.com r...@steel.home Alex Vandiver a...@chmrr.net ale...@mit.edu Alexander Gavrilov angavri...@gmail.com Alexey Shumkin alex.crez...@gmail.com zap...@mail.ru +Alexey Shumkin alex.crez...@gmail.com alex.crez...@gmail.com Anders Kaseorg ande...@mit.edu ande...@ksplice.com Anders Kaseorg ande...@mit.edu ande...@mit.edu Aneesh Kumar K.V aneesh.ku...@gmail.com @@ -31,6 +32,7 @@ Christian Stimming stimm...@tuhh.de chs@ckiste.goetheallee Csaba Henk cs...@gluster.com cs...@lowlife.hu Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com h...@deathvalley.cswitch.com +Dana L. How dana...@gmail.com Dana How Daniel Barkalow barka...@iabervon.org David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net @@ -65,6 +67,7 @@ J. Bruce Fields bfie...@citi.umich.edu bfie...@fieldses.org J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org Jakub Narębski jna...@gmail.com +James Y Knight jkni...@itasoftware.com f...@fuhm.net Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com @@ -92,8 +95,8 @@ Junio C Hamano gits...@pobox.com ju...@pobox.com Junio C Hamano gits...@pobox.com ju...@twinsun.com Junio C Hamano gits...@pobox.com jun...@cox.net Junio C Hamano gits...@pobox.com jun...@twinsun.com -Karl Wiberg k...@treskal.com Karl Hasselström k...@treskal.com -Karl Wiberg k...@treskal.com Karl Hasselström k...@yoghurt.hemma.treskal.com +Karl Wiberg k...@treskal.com Karl Hasselström +Karl Wiberg k...@treskal.com k...@yoghurt.hemma.treskal.com Karsten Blees bl...@dcon.de karsten.bl...@dcon.de Karsten Blees bl...@dcon.de karsten.bl...@gmail.com Kay Sievers kay.siev...@vrfy.org kay.siev...@suse.de @@ -177,6 +180,7 @@ Robin Rosenberg robin.rosenb...@dewire.com robin.rosenberg.li...@dewire.com Ryan Anderson r...@michonline.com r...@google.com Salikh Zakirov salikh.zaki...@gmail.com salikh.zaki...@intel.com Sam Vilain s...@vilain.net sam.vil...@catalyst.net.nz +Sam Vilain s...@vilain.net s...@vilain.net Santi Béjar sa...@agolina.net sbe...@gmail.com Sean Estabrooks seanl...@sympatico.ca Sebastian Schuberth sschube...@gmail.com sschube...@visageimaging.com @@ -191,6 +195,7 @@ Stefan Sperling s...@elego.de s...@stsp.name Stephen Boyd bebar...@gmail.com sb...@codeaurora.org Steven Drake sdr...@xnet.co.nz sdr...@ihug.co.nz Steven Grimm kor...@midwinter.com sgrimm@sgrimm-mbp.local +Steven Grimm kor...@midwinter.com kor...@midwinter.com Steven Walter stevenrwal...@gmail.com swal...@lexmark.com Steven Walter stevenrwal...@gmail.com swal...@lpdev.prtdev.lexmark.com Sven Verdoolaege sk...@kotnet.org sven.verdoola...@cs.kuleuven.ac.be -- 1.8.4.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] .mailmap: mark bouncing email addresses
We cannot be sure whether these are the same person, hence we will not map their different mail addresses to one person. However this commit documents, some bouncing mail addresses, so these need not be tried again, when somebody continues the .mailmap cleanup. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 22 ++ 1 file changed, 22 insertions(+) diff --git a/.mailmap b/.mailmap index 840abf7..3b235b5 100644 --- a/.mailmap +++ b/.mailmap @@ -18,6 +18,10 @@ Alexey Shumkin alex.crez...@gmail.com alex.crez...@gmail.com Anders Kaseorg ande...@mit.edu ande...@ksplice.com Anders Kaseorg ande...@mit.edu ande...@mit.edu Aneesh Kumar K.V aneesh.ku...@gmail.com +# The 2 following authors are probably the same person, +# but both emails bounce. +Amos Waterland a...@rossby.metr.ou.edu +Amos Waterland a...@us.ibm.com Ben Walton bdwal...@gmail.com bwal...@artsci.utoronto.ca Bernt Hansen be...@norang.ca be...@alumni.uwaterloo.ca Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil @@ -34,6 +38,10 @@ Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com h...@deathvalley.cswitch.com Dana L. How dana...@gmail.com Dana How Daniel Barkalow barka...@iabervon.org +# The 2 following authors are probably the same person, +# but both emails bounce. +Daniel Trstenjak daniel.trsten...@online.de +Daniel Trstenjak trs...@science-computing.de David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net David Kågedal dav...@lysator.liu.se @@ -68,11 +76,19 @@ J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org Jakub Narębski jna...@gmail.com James Y Knight jkni...@itasoftware.com f...@fuhm.net +# The 2 following authors are probably the same person, +# but both emails bounce. +Jason McMullan jason.mcmul...@timesys.com +Jason McMullan mcmul...@netapp.com Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com Jeff King p...@peff.net p...@github.com Jeff Muizelaar jmuizel...@mozilla.com j...@infidigm.net +# The 2 following authors are probably the same person, +# but both emails bounce. +Jens Axboe ax...@suse.de +Jens Axboe jens.ax...@oracle.com Jim Meyering j...@meyering.net meyer...@redhat.com Joachim Berdal Haga cjh...@fys.uio.no Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de @@ -144,6 +160,8 @@ Michele Ballabio barra_c...@katamail.com Miklos Vajna vmik...@frugalware.org vmik...@suse.cz Namhyung Kim namhy...@gmail.com namhyung@lge.com Namhyung Kim namhy...@gmail.com namhy...@kernel.org +# The 2 following authors are probably the same person, +# but both emails bounce. Nanako Shiraishi nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com Nelson Elhage nelh...@mit.edu nelh...@mit.edu @@ -177,6 +195,10 @@ Robert Fitzsimons robf...@273k.net Robert Shearman robertshear...@gmail.com r...@codeweavers.com Robert Zeh robert.a@gmail.com Robin Rosenberg robin.rosenb...@dewire.com robin.rosenberg.li...@dewire.com +# The 2 following authors are probably the same person, +# but both emails bounce. +Rutger Nijlunsing rut...@nospam.com +Rutger Nijlunsing g...@tux.tmfweb.nl Ryan Anderson r...@michonline.com r...@google.com Salikh Zakirov salikh.zaki...@gmail.com salikh.zaki...@intel.com Sam Vilain s...@vilain.net sam.vil...@catalyst.net.nz -- 1.8.4.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git for the Windows 1.8.3, GIT Bash icon issue
From: Dmitry Kuzminov dkuzmi...@yandex-team.ru Dmitry, The Git for Windows development list is at msys...@googlegroups.com. Is this git for Windows or one of the other git versions on windows, and their installers? There is a standard command prompt icon in taskbar for GIT Bash instead of GIT icon Steps to reproduce: Select Taskbar Properties, Taskbar buttons, set to Never combine Run GIT Bash Best regards, Dmitry Kuzminov -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git for the Windows 1.8.3, GIT Bash icon issue
Philip, Yes, this is msysgit, version 1.8.3. Now I switched back to 1.7.11 -- there is no such issue in this older version. 09.08.2013, 22:31, Philip Oakley philipoak...@iee.org: From: Dmitry Kuzminov dkuzmi...@yandex-team.ru Dmitry, The Git for Windows development list is at msys...@googlegroups.com. Is this git for Windows or one of the other git versions on windows, and their installers? There is a standard command prompt icon in taskbar for GIT Bash instead of GIT icon Steps to reproduce: Select Taskbar Properties, Taskbar buttons, set to Never combine Run GIT Bash Best regards, Dmitry Kuzminov -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Antoine Pelisse apeli...@gmail.com writes: The current code fixes the path to make it absolute when cloning, but doesn't consider tilde expansion, so that scenario fails throwing an exception because /home/myuser/~/my/repository doesn't exists: $ git clone hg::~/my/repository cd repository git fetch Expand the tilde when checking if the path is absolute, so that we don't fix a path that doesn't need to be. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Shouldn't that be the job of the shell? (s/~/$HOME/) I'm not sure what you mean here. Does it mean that I should stop cloning using ~ ? I think shells do not expand ~ when it appears in a string (e.g. hg::~/there); you could work it around with git clone hg::$(echo ~/there) and I suspect that is what Felipe is alluding to. A tool (like remote-hg bridge with this patch) that expands ~ in the middle of a string also may be surprising to some people, especially to those who know the shell does not. I also send this patch as I think it makes more sense to keep the ~ in the path, but just make sure we don't build invalid absolute path. By the way, I don't exactly understand why: abs_url = urlparse.urljoin(%s/ % os.getcwd(), orig_url) is done right after instead of: abs_url = os.path.abspath(orig_url) That looks like a good cleanup to me, too, but I may be missing some subtle points... By the way, you earlier sent an updated 1/2; is this supposed to be 2/2 to conclude the two-patch series? Cheers, Antoine contrib/remote-helpers/git-remote-hg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 1897327..861c498 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -1135,7 +1135,7 @@ def do_option(parser): def fix_path(alias, repo, orig_url): url = urlparse.urlparse(orig_url, 'file') -if url.scheme != 'file' or os.path.isabs(url.path): +if url.scheme != 'file' or os.path.isabs(os.path.expanduser(url.path)): return abs_url = urlparse.urljoin(%s/ % os.getcwd(), orig_url) cmd = ['git', 'config', 'remote.%s.url' % alias, hg::%s % abs_url] -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] submodule: fix confusing variable name
Ramsay Jones ram...@ramsay1.demon.co.uk writes: $path is part of the public API, so we can't just remove it. It would require a deprecation period, etc,. (Adding/documenting $sm_path as an alternative *may* be worth doing. dunno.) I think exporting sm_path (if not done already) and documenting the transition may be a good starting point, but deprecation of $path may be tricky. There is no good way for us to warn people who continue using $path and ask them to fix their fingers and scripts to use $sm_path instead. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase --interactive using short SHA-1's internally
Had some problems rebasing a large repository, fatal error because a short SHA-1 ref was ambiguous. After a quick inspection of git-rebase--interactive.sh, I found that it uses short refs in a few places (git rev-parse --short). Removing that option fixed my problem. See: https://github.com/git/git/blob/master/git-rebase--interactive.sh#L902 -- Diogo Campos -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase --interactive forgets strategies after --continue
I had some problems rebasing a repository that had empty commits, which caused the rebase to stop. After continuing it with git rebase --continue, it seems that the strategies I originally gave were forgotten. I quickly glanced at the code, and it seems that a lot of rebase options are stored in in a $state_dir, but $strategy_args is not one of them. Since git rebase --interactive not ignoring strategies (https://github.com/git/git/commit/db2b3b820e2b28da268cc88adff076b396392dfe) is a recent change to Git (only available in 1.8.4-rc+), I believe that this was overlooked. -- Diogo Campos -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git status resets permissions on index file -- Ubuntu 12.04 64b
I've looked into this a bit and I think this is a bug in Webstorm. Webstorm saves files a lot without you actually hitting save, so that's why I didn't put 2 and 2 together. It appears that any file change in Webstorm is screwing up the permissions on git's index -- but only in 64b Ubuntu, it wasn't happening in 32b. On Fri, Aug 9, 2013 at 10:00 AM, Justin Collum jcol...@gmail.com wrote: That doesn't make sense. If you are the owner of the file, why do you need sudo??? I've just never seen a chmod command without sudo. I assumed it was needed. Is this relevant to the bug that I'm seeing? On Fri, Aug 9, 2013 at 5:40 AM, Andreas Schwab sch...@linux-m68k.org wrote: Justin Collum jcol...@gmail.com writes: sudo chmod 644 ./.git/index That doesn't make sense. If you are the owner of the file, why do you need sudo??? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Hi Thorsten, Thorsten Glaser wrote[1]: git config user.email SHOULD NOT default to $(id -un)@$(hostname -f) because just too many cow-orkers seem to be unable to follow basic instructions Heh. Can you say a little more about your setup? In a university environment with sysadmin-managed email and /etc/mailname set up correctly it is handy that people can start working without doing anything special to configure git's [user] email setting. On the other hand it is obnoxious to receive patches with wrong authorship information. So I'm wondering if there's some detail that distinguishes between these cases. Incidentally, it's been a long time since I looked at the Please configure your email address; I've made something up, but you'll want to check it message: Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly: git config --global user.name Your Name git config --global user.email y...@example.com After doing this, you may fix the identity used for this commit with: git commit --amend --reset-author I wonder if it's too gentle and long to get the point across. Would something the following (including the guesses in the message for easier copy-pasting) help? No name and email address configured, so I had to guess. You can suppress this message by setting your identity explicitly: git config --global user.name Thorsten Glaser git config --global user.email t...@mirbsd.de After doing so, you may fix the identity used for this commit with git commit --amend --reset-author. It may also make sense to distinguish between cases where a mailname is set and not set. Git already notices the cases where the guessed email address ends with .(none) and errors out, and it could make sense to be more aggressive. Hope that helps, Jonathan [1] http://bugs.debian.org/719226 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] whatchanged: document its historical nature
After doing a bit of archaeology, I now know why whatchanged with an unwieldy long name persisted in the user's mindset for so long. My conclusions are: - It is better to encourage new users to use `log` very early in the document; - It is not sensible to remove the command at this point yet. After having used to `log` that does not take diff options for close to a year, it is understandable why there are many people who are used to type `whatchanged`. It could be argued that deprecation and retraining of fingers are doing favors to the long-time users. But the presense of the command is not hurting anybody, other than the new people who may stumble upon both and wonder what their differences are. By clearly indicating that these two are essentially the same, we would help the new people without harming anybody. -- 8 -- Subject: [PATCH] whatchanged: document its historical nature Encourage new users to use 'log' instead. These days, these commands are unified and just have different defaults. 'git log' only allowed you to view the log messages and no diffs when it was added in early June 2005. It was only in early April 2006 that the command learned to take diff options. Because of this, power users tended to use 'whatchanged' that already existed since mid May 2005 and supported diff options. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-whatchanged.txt | 41 --- 1 file changed, 8 insertions(+), 33 deletions(-) diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index c600b61..6faa200 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -13,43 +13,18 @@ SYNOPSIS DESCRIPTION --- -Shows commit logs and diff output each commit introduces. The -command internally invokes 'git rev-list' piped to -'git diff-tree', and takes command line options for both of -these commands. -This manual page describes only the most frequently used options. +Shows commit logs and diff output each commit introduces. +New users are encouraged to use linkgit:git-log[1] instead. The +`whatchanged` command is essentially the same as linkgit:git-log[1] +run with different defaults that shows a --raw diff outputat the +end. -OPTIONS --p:: - Show textual diffs, instead of the Git internal diff - output format that is useful only to tell the changed - paths and their nature of changes. +The command is kept primarily for historical reasons; fingers of +many people who learned Git long before `git log` was invented by +reading Linux kernel mailing list are trained to type it. --n:: - Limit output to n commits. - -since..until:: - Limit output to between the two named commits (bottom - exclusive, top inclusive). - --r:: - Show Git internal diff output, but for the whole tree, - not just the top level. - --m:: - By default, differences for merge commits are not shown. - With this flag, show differences to that commit from all - of its parents. -+ -However, it is not very useful in general, although it -*is* useful on a file-by-file basis. - -include::pretty-options.txt[] - -include::pretty-formats.txt[] Examples -- 1.8.4-rc2-195-gb76a8e9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
Hi, From a quick search for homepages: Stefan Beller wrote: [...] +# The 2 following authors are probably the same person, +# but both emails bounce. +Amos Waterland a...@rossby.metr.ou.edu +Amos Waterland a...@us.ibm.com From the history of http://people.seas.harvard.edu/~apw/sreplay/sreplay.git this looks like the same person as a...@debian.org. [...] +# The 2 following authors are probably the same person, +# but both emails bounce. +Daniel Trstenjak daniel.trsten...@online.de +Daniel Trstenjak trs...@science-computing.de daniel.trsten...@gmail.com [...] +# The 2 following authors are probably the same person, +# but both emails bounce. +Jason McMullan jason.mcmul...@timesys.com +Jason McMullan mcmul...@netapp.com A search at http://search.gmane.org/ by name sorted by Newest first finds a candidate email address. +# The 2 following authors are probably the same person, +# but both emails bounce. +Jens Axboe ax...@suse.de +Jens Axboe jens.ax...@oracle.com ax...@kernel.dk +# The 2 following authors are probably the same person, +# but both emails bounce. Nanako Shiraishi nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com I don't know how to contact Nanako these days. :( Maybe mailmap should learn a way to say there's no current public email address for this person. +# The 2 following authors are probably the same person, +# but both emails bounce. +Rutger Nijlunsing rut...@nospam.com +Rutger Nijlunsing g...@tux.tmfweb.nl Probably rutger.nijluns...@gmail.com. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] remote-hg: simplify shared repo setup
We don't need the initial clone, if the repository is shared, pulling
from the child updates the parent's storage; it's exactly the same as
cloning.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..cfd4f53 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -391,11 +391,12 @@ def get_repo(url, alias):
os.makedirs(dirname)
else:
shared_path = os.path.join(gitdir, 'hg')
-if not os.path.exists(shared_path):
-try:
-hg.clone(myui, {}, url, shared_path, update=False, pull=True)
-except:
-die('Repository error')
+
+# setup shared repo (if not there)
+try:
+hg.peer(myui, {}, shared_path, create=True)
+except error.RepoError:
+pass
if not os.path.exists(dirname):
os.makedirs(dirname)
--
1.8.3.267.gbb4989f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] remote-hg: add shared repo upgrade
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial to upgrade to the new organization by copying the Mercurial
repo from one of the remotes (e.g. 'origin'), so let's do so.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index cfd4f53..9ec13da 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -392,6 +392,17 @@ def get_repo(url, alias):
else:
shared_path = os.path.join(gitdir, 'hg')
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if os.path.exists(shared_path) and not os.path.exists(hg_path):
+repos = os.listdir(shared_path)
+for x in repos:
+local_hg = os.path.join(shared_path, x, 'clone', '.hg')
+if not os.path.exists(local_hg):
+continue
+shutil.copytree(local_hg, hg_path)
+break
+
# setup shared repo (if not there)
try:
hg.peer(myui, {}, shared_path, create=True)
--
1.8.3.267.gbb4989f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] remote-hg: shared repo upgrade fix
Hi, Here's my proposal split into two patches, as I suggested. With the fix for when there's more than one shared repo. Felipe Contreras (2): remote-hg: simplify share repo setup remote-hg: add shared repo upgrade contrib/remote-helpers/git-remote-hg | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) -- 1.8.3.267.gbb4989f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Shouldn't that be the job of the shell? (s/~/$HOME/) I'm not sure what you mean here. Does it mean that I should stop cloning using ~ ? I think shells do not expand ~ when it appears in a string (e.g. hg::~/there); you could work it around with git clone hg::$(echo ~/there) and I suspect that is what Felipe is alluding to. A tool (like remote-hg bridge with this patch) that expands ~ in the middle of a string also may be surprising to some people, especially to those who know the shell does not. It looks like mercurial will expand the tilde (it it starts with it): hg init \~ will create a $HOME/.hg. (while git init \~ will create ./~). So when we run: git clone hg::~/my/repo Git will remove the hg:: part, and Mercurial will expand tilde and clone $HOME/my/repo. So what should we do ? I think we should stick as close as possible to Hg behavior: That is consider that a path starting with tilde is absolute, and not try to fix it by building /home/user/~/repo/path. Of course if we could not depend on I think Hg works like that, it would be better if we could resolve that by asking Mercurial. I will dig into it. By the way, you earlier sent an updated 1/2; is this supposed to be 2/2 to conclude the two-patch series? Those two patches don't interact with each other, but you can of course join them if it makes it easier for you (and I don't think one is going to have to go faster than the other anyway). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] whatchanged: document its historical nature
On Fri, Aug 09, 2013 at 01:01:48PM -0700, Junio C Hamano wrote: After doing a bit of archaeology, I now know why whatchanged with an unwieldy long name persisted in the user's mindset for so long. My conclusions are: - It is better to encourage new users to use `log` very early in the document; - It is not sensible to remove the command at this point yet. After having used to `log` that does not take diff options for close to a year, it is understandable why there are many people who are used to type `whatchanged`. It could be argued that deprecation and retraining of fingers are doing favors to the long-time users. But the presense of the command is not hurting anybody, other than the new people who may stumble upon both and wonder what their differences are. By clearly indicating that these two are essentially the same, we would help the new people without harming anybody. -- 8 -- Subject: [PATCH] whatchanged: document its historical nature Encourage new users to use 'log' instead. These days, these commands are unified and just have different defaults. 'git log' only allowed you to view the log messages and no diffs when it was added in early June 2005. It was only in early April 2006 that the command learned to take diff options. Because of this, power users tended to use 'whatchanged' that already existed since mid May 2005 and supported diff options. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-whatchanged.txt | 41 --- 1 file changed, 8 insertions(+), 33 deletions(-) diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index c600b61..6faa200 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -13,43 +13,18 @@ SYNOPSIS DESCRIPTION --- -Shows commit logs and diff output each commit introduces. The -command internally invokes 'git rev-list' piped to -'git diff-tree', and takes command line options for both of -these commands. -This manual page describes only the most frequently used options. +Shows commit logs and diff output each commit introduces. +New users are encouraged to use linkgit:git-log[1] instead. The +`whatchanged` command is essentially the same as linkgit:git-log[1] +run with different defaults that shows a --raw diff outputat the s/outputat/output at/ Although I wonder if it would be better to say New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] with the `--raw` option specified. +end. -OPTIONS --p:: - Show textual diffs, instead of the Git internal diff - output format that is useful only to tell the changed - paths and their nature of changes. +The command is kept primarily for historical reasons; fingers of +many people who learned Git long before `git log` was invented by +reading Linux kernel mailing list are trained to type it. --n:: - Limit output to n commits. - -since..until:: - Limit output to between the two named commits (bottom - exclusive, top inclusive). - --r:: - Show Git internal diff output, but for the whole tree, - not just the top level. - --m:: - By default, differences for merge commits are not shown. - With this flag, show differences to that commit from all - of its parents. -+ -However, it is not very useful in general, although it -*is* useful on a file-by-file basis. - -include::pretty-options.txt[] - -include::pretty-formats.txt[] Examples -- 1.8.4-rc2-195-gb76a8e9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jonathan Nieder dixit: Can you say a little more about your setup? In a university environment with sysadmin-managed email and /etc/mailname set up correctly it is handy that people can start working without doing Ah okay. We don’t have /etc/mailname set up I think and, additionally, the Unix user name doesn’t match the eMail localpart, so that won’t work anyway. Though we’re having a very heterogenous desktop environment nowadays so I can’t really know all specifics. At least, I think, most devs seem to use the Unix git client now, whereas for svn they use the one that comes with Eclipse… I wonder if it's too gentle and long to get the point across. Would something the following (including the guesses in the message for easier copy-pasting) help? Definitely not. It needs to fail hard if user.email is not set, i.e. refuse to accept the commit. is set and not set. Git already notices the cases where the guessed email address ends with .(none) and errors out, and it could make sense to be more aggressive. The guessed addresses are like 'de...@pc-bn-041.lan.tarent.de' instead of 'd.e...@tarent.de' which is the correct Kolab address (this information can be publicly accessed since the project I noticed it in is on our public FusionForge instance, so I don’t think sharing specifics is bad here, but please don’t hammer our poor trainee with spam now). So they’re a “correct” unix username at a correct FQDN (which, thanks to split-horizon, even would work internally, except there’s of course no MTA set up) and won’t be caught by *.(none) matches. Hope this helps. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t/t7407: fix two typos in submodule tests
In t/t7407-submodule-foreach.sh there is a typo in one of the path names given for a test step. The correct path is nested1/nested2/.git, but nested1/nested1/nested2/.git is given instead. The typo is hidden because this line also accidentally omits the chain operator. The omitted chain also means the return values of all the previous commands in this test are also being ignored. Fix the path and add the chain operator so the entire test sequence can be properly validated. Signed-off-by: Phil Hord ho...@cisco.com --- t/t7407-submodule-foreach.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh index 91d4fd1..be93f10 100755 --- a/t/t7407-submodule-foreach.sh +++ b/t/t7407-submodule-foreach.sh @@ -145,7 +145,7 @@ test_expect_success 'use submodule foreach to checkout 2nd level submodule' ' git rev-parse --resolve-git-dir nested1/.git test_must_fail git rev-parse --resolve-git-dir nested1/nested2/.git git submodule foreach git submodule update --init - git rev-parse --resolve-git-dir nested1/nested1/nested2/.git + git rev-parse --resolve-git-dir nested1/nested2/.git test_must_fail git rev-parse --resolve-git-dir nested1/nested2/nested3/.git ) ' -- 1.8.4.rc1.433.g415b943 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remote-hg: add shared repo upgrade
On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse apeli...@gmail.com wrote: On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 6796d49 (remote-hg: use a shared repository store) introduced a bug by making the shared repository '.git/hg', which is already used before that patch, so clones that happened before that patch, fail after that patch, because there's no shared Mercurial repo. Does that still hold ? You are creating the shared_path repository just below, so it should work without the patch. The real reason for this patch is to avoid having to re-clone from a potential slow source, is it not ? Yeah, that's true. +# check and upgrade old organization +hg_path = os.path.join(shared_path, '.hg') +if os.path.exists(shared_path) and not os.path.exists(hg_path): +repos = os.listdir(shared_path) +for x in repos: +local_hg = os.path.join(shared_path, x, 'clone', '.hg') +if not os.path.exists(local_hg): +continue +shutil.copytree(local_hg, hg_path) +break + By the way, I liked my version better, that is: if os.path.exists(local_hg): shutil.copytree(local_hg, hg_path) break Simplifying the if not condition: continue else: break I prefer my version because if there's any need to add more lines, they don't have to be indented. That's why a lot of code ends up having unnecessary indentation. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser t...@mirbsd.de wrote:
Jonathan Nieder dixit:
I wonder if it's too gentle and long to get the point across. Would
something the following (including the guesses in the message for
easier copy-pasting) help?
Definitely not. It needs to fail hard if user.email is not set,
i.e. refuse to accept the commit.
Completely agree, and I argued this point some time ago.
is set and not set. Git already notices the cases where the guessed
email address ends with .(none) and errors out, and it could make
sense to be more aggressive.
The guessed addresses are like 'de...@pc-bn-041.lan.tarent.de'
instead of 'd.e...@tarent.de' which is the correct Kolab address
(this information can be publicly accessed since the project I
noticed it in is on our public FusionForge instance, so I don’t
think sharing specifics is bad here, but please don’t hammer our
poor trainee with spam now). So they’re a “correct” unix username
at a correct FQDN (which, thanks to split-horizon, even would
work internally, except there’s of course no MTA set up) and
won’t be caught by *.(none) matches.
This is how to implement that:
From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
From: Felipe Contreras 2nd felipe.contrera...@gmail.com
Date: Tue, 13 Nov 2012 07:33:12 +0100
Subject: [PATCH] ident: don't allow implicit email addresses
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
ident.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 1c123e6..85fc729 100644
--- a/ident.c
+++ b/ident.c
@@ -301,9 +301,9 @@ const char *fmt_ident(const char *name, const char *email,
}
if (strict email == git_default_email.buf
- strstr(email, (none))) {
+ !(user_ident_explicitly_given IDENT_MAIL_GIVEN)) {
fputs(env_hint, stderr);
- die(unable to auto-detect email address (got '%s'), email);
+ die(no explicit email address);
}
if (want_date) {
--
1.8.3.267.gbb4989f
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Huge possible memory leak while cherry-picking.
On Fri, Aug 9, 2013 at 7:13 AM, Лежанкин Иван abys...@gmail.com wrote: I have tried to cherry-pick a range of ~200 commits from one branch to another. And you can't imagine how I was surprised when the git process ate 8 Gb of RAM and died - before cherry-picking was complete. Try this: http://article.gmane.org/gmane.comp.version-control.git/226757 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Antoine Pelisse apeli...@gmail.com writes: So when we run: git clone hg::~/my/repo Git will remove the hg:: part, and Mercurial will expand tilde and clone $HOME/my/repo. Now you confused me. If the implementation were for us to remove the hg:: prefix and let Mercurial do whatever it wants to do with the rest, you are right that we will not have to do any expansion like your patch. But you sent a patch to do so, so apparently it is not what happens. So where does it go wrong? Puzzled... By the way, you earlier sent an updated 1/2; is this supposed to be 2/2 to conclude the two-patch series? Those two patches don't interact with each other, but you can of course join them if it makes it easier for you (and I don't think one is going to have to go faster than the other anyway). Hmph, so there is a different 2/2 that we haven't seen recently on the list (meaning you have three patches)? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] whatchanged: document its historical nature
John Keeping j...@keeping.me.uk writes: +New users are encouraged to use linkgit:git-log[1] instead. The +`whatchanged` command is essentially the same as linkgit:git-log[1] +run with different defaults that shows a --raw diff outputat the s/outputat/output at/ Thanks. Although I wonder if it would be better to say New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] with the `--raw` option specified. But that is different from the truth, no? git whatchanged -p will not behave as if git whatchanged -p with the --raw specified. The 'raw' kicks in only as a default. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] status: always show tracking branch even no change
Jiang Xin worldhello@gmail.com writes: If the current branch has an upstream branch, and there are changes between the current branch and its upstream, some commands (such as git status, git status -bs, and git checkout) will report their relationship. E.g. $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use git push to publish your local commits) # ... $ git status -bs ## master...origin/master [ahead 1] ... $ git checkout master Already on 'master' Your branch is ahead of 'origin/master' by 1 commit. (use git push to publish your local commits) But if there is no difference between the current branch and its upstream, the relationship will not be reported, and it's hard to tell whether the current branch has a tracking branch or not. And what's worse, when the 'push.default' config variable is set to `matching`, it's hard to tell whether the current branch has already been pushed out or not at all [1]. That description of the problem you are trying to solve makes (sort of) sense. So always show the remote tracking branch in the output of git status and other commands will help users to see where the current branch will push to and pull from. E.g. $ git status # On branch master # Your branch is identical to 'origin/master'. # ... $ git status -bs ## master...origin/master ... Hmmph. I do not know if this will help any case you described above, even though this might help some other cases. The added output is to always show the current branch and its upstream, but the thing is, the original issue in $gmane/198703 was *not* that the current branch was pushed and up to date. It was that there was no current branch to be pushed. The same thing would happen if you are on a local branch that is not set to be pushed to the other side (e.g. the configuration is set to matching and there is no such branch on the other end). Your branch is identical to will be given only if your branch is set to be pushed out, no? For the user to tell what is going on, the user has to notice the lack of this extra line in the output, and noticing the lack of anything is much unlikely. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Confusion everywhere :-) On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: So when we run: git clone hg::~/my/repo Git will remove the hg:: part, and Mercurial will expand tilde and clone $HOME/my/repo. Now you confused me. If the implementation were for us to remove the hg:: prefix and let Mercurial do whatever it wants to do with the rest, you are right that we will not have to do any expansion like your patch. But you sent a patch to do so, so apparently it is not what happens. So where does it go wrong? Puzzled... OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: If you run: git clone hg::./my_repo my_new_repo The remote path will be hg::./my_repo, so we have to fix this path (otherwise you won't be able to run git fetch from inside my_new_repo). It's currently done by checking if ./my_repo is an absolute path or not, and try to make it absolute if required. But my issue is when I do that: git clone hg::~/my_repo my_new_repo The clone works successfully by cloning $HOME/my_repo, but then, when we try to fix the repo path, we think that ~/my_repo is not an absolute path, so we make it absolute: /home/user/~/my_repo which is now off. So I'm not able to fetch that remote. What the current patch does, is to expand the tilde before checking if the path is absolute. So that fixes the bug, but that indeed can be confusing to another user that would expect hg::~/my_repo/ to *not be* hg::$HOME/my_repo (because he knows the expansion should not happen in that case). By the way, you earlier sent an updated 1/2; is this supposed to be 2/2 to conclude the two-patch series? Those two patches don't interact with each other, but you can of course join them if it makes it easier for you (and I don't think one is going to have to go faster than the other anyway). Hmph, so there is a different 2/2 that we haven't seen recently on the list (meaning you have three patches)? I have 2 patch (1 from me, 1 from Felipe): One with the tilde expansion, the other one with shared_path initialization (which now conflicts with the resend from Felipe) I will try to provide a better versioning of the patches next time. Sorry for the confusion, Thanks, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull l10n updates for 1.8.4 round 2
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] optimize git-contacts
This patch series aims to make contrib/git-contacts faster by reducing the number of expensive git-blame invocations it makes. It does so by taking advantage of git-blame's new ability to accept multiple -L ranges in a single invocation [1] (es/blame-L-twice in 'next'). Some numbers, given a randomly chosen range of commits: (before) % time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null real 0m6.142s user 0m5.429s sys 0m0.356s (after) % time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null real 0m2.285s user 0m2.093s sys 0m0.165s [1]: http://thread.gmane.org/gmane.comp.version-control.git/231739 Eric Sunshine (3): contacts: validate hunk length earlier contacts: gather all blame sources prior to invoking git-blame contacts: reduce git-blame invocations contrib/contacts/git-contacts | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- 1.8.4.rc2.460.ga591f4a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] contacts: validate hunk length earlier
Rather than calling get_blame() with a zero-length hunk only to have it
rejected immediately, perform hunk-length validation earlier in order to
avoid calling get_blame() unnecessarily.
This is a preparatory step to simplify later patches which reduce the
number of git-blame invocations by collecting together all lines to
blame within a single file at a particular revision. By validating the
blame range early, the subsequent patch can more easily avoid adding
empty ranges at collection time.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
contrib/contacts/git-contacts | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index d80f7d1..4fbb2ef 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -60,8 +60,6 @@ sub import_commits {
sub get_blame {
my ($commits, $source, $start, $len, $from) = @_;
- $len = 1 unless defined($len);
- return if $len == 0;
open my $f, '-|',
qw(git blame --porcelain -C), '-L', $start,+$len,
'--since', $since, $from^, '--', $source or die;
@@ -90,7 +88,8 @@ sub scan_patches {
} elsif (/^--- /) {
die Cannot parse hunk source: $_\n;
} elsif (/^@@ -(\d+)(?:,(\d+))?/ $source) {
- get_blame($commits, $source, $1, $2, $id);
+ my $len = defined($2) ? $2 : 1;
+ get_blame($commits, $source, $1, $len, $id) if $len;
}
}
}
--
1.8.4.rc2.460.ga591f4a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] contacts: reduce git-blame invocations
git-contacts invokes git-blame once for each patch hunk it encounters.
No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Reduce the number of git-blame invocations by taking advantage of the
ability to specify multiple -L ranges for a single invocation.
Without this patch, on a randomly chosen range of commits:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null
real 0m6.142s
user 0m5.429s
sys 0m0.356s
With this patch:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null
real 0m2.285s
user 0m2.093s
sys 0m0.165s
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
contrib/contacts/git-contacts | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index b4d3526..fb6429b 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -59,9 +59,11 @@ sub import_commits {
}
sub get_blame {
- my ($commits, $source, $start, $len, $from) = @_;
+ my ($commits, $source, $from, $ranges) = @_;
+ return unless @$ranges;
open my $f, '-|',
- qw(git blame --porcelain -C), '-L', $start,+$len,
+ qw(git blame --porcelain -C),
+ map({-L$_-[0],+$_-[1]} @$ranges),
'--since', $since, $from^, '--', $source or die;
while ($f) {
if (/^([0-9a-f]{40}) \d+ \d+ \d+$/) {
@@ -78,10 +80,7 @@ sub blame_sources {
my ($sources, $commits) = @_;
for my $s (keys %$sources) {
for my $id (keys %{$sources-{$s}}) {
- for my $range (@{$sources-{$s}{$id}}) {
- get_blame($commits, $s,
- $range-[0], $range-[1], $id);
- }
+ get_blame($commits, $s, $id, $sources-{$s}{$id});
}
}
}
--
1.8.4.rc2.460.ga591f4a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] contacts: gather all blame sources prior to invoking git-blame
git-contacts invokes git-blame immediately upon encountering a patch
hunk. No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Any effort to reduce the number of times git-blame is run will need to
to know in advance which line ranges to blame per file per revision.
Make this information available by collecting all sources as a distinct
step from invoking git-blame. A subsequent patch will utilize the
information to optimize git-blame invocations.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
contrib/contacts/git-contacts | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index 4fbb2ef..b4d3526 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -74,8 +74,20 @@ sub get_blame {
close $f;
}
+sub blame_sources {
+ my ($sources, $commits) = @_;
+ for my $s (keys %$sources) {
+ for my $id (keys %{$sources-{$s}}) {
+ for my $range (@{$sources-{$s}{$id}}) {
+ get_blame($commits, $s,
+ $range-[0], $range-[1], $id);
+ }
+ }
+ }
+}
+
sub scan_patches {
- my ($commits, $id, $f) = @_;
+ my ($sources, $id, $f) = @_;
my $source;
while ($f) {
if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
@@ -89,7 +101,7 @@ sub scan_patches {
die Cannot parse hunk source: $_\n;
} elsif (/^@@ -(\d+)(?:,(\d+))?/ $source) {
my $len = defined($2) ? $2 : 1;
- get_blame($commits, $source, $1, $len, $id) if $len;
+ push @{$sources-{$source}{$id}}, [$1, $len] if $len;
}
}
}
@@ -162,13 +174,16 @@ for (@ARGV) {
}
}
-my %commits;
+my %sources;
for (@files) {
- scan_patch_file(\%commits, $_);
+ scan_patch_file(\%sources, $_);
}
if (@rev_args) {
- scan_rev_args(\%commits, \@rev_args)
+ scan_rev_args(\%sources, \@rev_args)
}
+
+my %commits;
+blame_sources(\%sources, \%commits);
import_commits(\%commits);
my $contacts = {};
--
1.8.4.rc2.460.ga591f4a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Antoine Pelisse apeli...@gmail.com writes: OK, I think I see why you are puzzled. ... But my issue is when I do that: git clone hg::~/my_repo my_new_repo The clone works successfully by cloning $HOME/my_repo, but then, when we try to fix the repo path, we think that ~/my_repo is not an absolute path, so we make it absolute: /home/user/~/my_repo which is now off. So I'm not able to fetch that remote. OK, so clone works, but subsequent fetch from the cloned resoitory does not? git fetch hg::~/my_repo will still work but the call to git config done near the place your patch touches does not store hg::~/my_repo because it thinks ~/my_repo refers to ./~/my_repo and tries to come up with an absolute path. The patch tries to notice this case and return without rewriting, so that remote.*.url is kept as hg::~/my_repo. Assuming that I am following your reasoning so far, I think I can agree with the patch (not that my agreement matters that much, as you seem to be a lot more familiar with this codepath). Thanks for explaining. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remote-hg: add shared repo upgrade
Felipe Contreras felipe.contre...@gmail.com writes: On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse apeli...@gmail.com wrote: On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 6796d49 (remote-hg: use a shared repository store) introduced a bug by making the shared repository '.git/hg', which is already used before that patch, so clones that happened before that patch, fail after that patch, because there's no shared Mercurial repo. Does that still hold ? You are creating the shared_path repository just below, so it should work without the patch. The real reason for this patch is to avoid having to re-clone from a potential slow source, is it not ? Yeah, that's true. So both of you are happy if we apply 1/2 Message-ID: 1376078581-24766-2-git-send-email-felipe.contre...@gmail.com and this one with an updated log message? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Repo with only one file
On Fri, Aug 9, 2013 at 6:32 AM, Johannes Sixt j.s...@viscovery.net wrote: Am 8/9/2013 12:03, schrieb shawn wilson: The question still stands though - why is that unassociated commit left there? Because your command did not remove it. filter-branch does not know that it is unassociated when you ask it to follow all commits beginning at HEAD. But when you say 'HEAD -- webban.pl', you ask it to follow only commits that touch webban.pl, which automatically skips that commit. I can go with that. However, I don't think that's the end of the story either: % du -sh . 192M. Something has been left behind. What? Or how do I figure that out and remove it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano gits...@pobox.com wrote: OK, so clone works, but subsequent fetch from the cloned resoitory does not? git fetch hg::~/my_repo will still work but the call to git config done near the place your patch touches does not store hg::~/my_repo because it thinks ~/my_repo refers to ./~/my_repo and tries to come up with an absolute path. The patch tries to notice this case and return without rewriting, so that remote.*.url is kept as hg::~/my_repo. Assuming that I am following your reasoning so far, I think I can agree with the patch (not that my agreement matters that much, as you seem to be a lot more familiar with this codepath). Thanks for explaining. Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Fri, Aug 9, 2013 at 4:19 PM, Antoine Pelisse apeli...@gmail.com wrote: Confusion everywhere :-) On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: So when we run: git clone hg::~/my/repo Git will remove the hg:: part, and Mercurial will expand tilde and clone $HOME/my/repo. Now you confused me. If the implementation were for us to remove the hg:: prefix and let Mercurial do whatever it wants to do with the rest, you are right that we will not have to do any expansion like your patch. But you sent a patch to do so, so apparently it is not what happens. So where does it go wrong? Puzzled... OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: So if we didn't store a different path, it would work. So instead of expanding '~' ourselves, it would be better to don't expand anything, and leave it as it is, but how to detect that in fix_path()? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Fri, Aug 09, 2013 at 07:04:23PM +0530, Ramkumar Ramachandra wrote: I'll raise some (hopefully interesting) points. Let's take the example of a simple push: I start send-pack, which in turn starts receive_pack on the server and connects its stdin/stdout to it (using git_connect). Now, it reads the (sha1, ref) pairs it receives on stdin and spawns pack-objects --stdout with the right arguments as the response, right? Overall, nothing special: just pack-objects invoked with specific arguments. How does pack-objects work? ll_find_deltas() spawns some worker threads to find_deltas(). This is where this get fuzzy for me: it calls try_delta() in a nested loop, trying to find the smallest delta, right? I'm not sure whether the interfaces it uses to read objects differentiates between packed deltas versus packed undeltified objects versus loose objects at all. You are missing a step in the preparation of the delta list. If we already have a delta on-disk, we will check whether it is usable and keep a note in the list (see check_object). Then when we prepare the list of objects to delta, it is omitted from the list (see prepare_pack). That is why you may see a much smaller number objects in the progress eye candy for Compressing objects... than we are actually sending. Now, the main problem I see is that a pack has to be self-contained: I can't have an object bar which is a delta against an object that is not present in the pack, right? Therefore no matter what the server already has, I have to prepare deltas only against the data that I'm sending across. As Junio mentioned, that is what --thin is about; the sender omits the base and the receiver adds it back in (index-pack --fix-thin). And if you think about it, that is likely where most of Martin's 317 packs turned into 8MB space savings are coming from. Somebody pushes X, which deltas against Y. They send only the delta for X-Y, but the receiver stores that delta plus a full copy of Y, even though we already have Y in another pack. Repacking throws away the extra copy of Y. And that is why something like Junio's suggestion of do not traverse history; just concatenate the packs and throw away duplicate objects might be helpful. You would not find new deltas, but you would get rid of these duplicate objects, and doing so would be relatively cheap. Another solution could involve not writing the duplicate of Y in the first place. The reason we do not store thin-packs on disk is that you run into problems with cycles in the delta graph (e.g., A deltas against B, which deltas against C, which deltas against A; at one point you had a full copy of one object which let you create the cycle, but you later deleted it as redundant with the delta, and now you cannot reconstruct any of the objects). You could possibly solve this with cycle detection, though it would be complicated (you need to do it not just when getting rid of objects, but when sending a pack, to make sure you don't send a cycle of deltas that the other end cannot use). You _might_ be able to get by with a kind of two-level hack: consider your main pack as group A and newly pushed packs as group B. Allow storing thin deltas on disk from group B against group A, but never the reverse (nor within group B). That makes sure you don't have cycles, and it eliminates even more I/O than any repacking solution (because you never write the extra copy of Y to disk in the first place). But I can think of two problems: 1. You still want to repack more often than every 300 packs, because having many packs cost both in space, but also in object lookup time (we can do a log(N) search through each pack index, but have to search linearly through the set of indices). 2. As you accumulate group B packs with new objects, the deltas that people send will tend to be against objects in group B. They are closer to the tip of history, and therefore make better deltas for history built on top. That's all just off the top of my head. There are probably other flaws, too, as I haven't considered it too hard. But if you are really concerned about I/O on a busy repo (and I think for hosting sites, it is a real problem), the best-performing solution will probably not involve packs at all, but some kind of delta-capable storage that you can incrementally add to without rewriting the whole repository. The downside is that it would be significantly more complicated. Of course we may have to reconstruct deltas for trees in order to find the correct set of objects (i.e., the history traversal). But that is a separate phase from generating the pack's object content, and we do not reuse any of the traversal work in later phases. I see. Are we talking about tree-walk.c here? This is not unique to packing at all; we need to do this kind of traversal for any git operation that digs into older history, no? I recall a discussion about using generation numbers to speed
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Felipe Contreras felipe.contre...@gmail.com writes: OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: So if we didn't store a different path, it would work. So instead of expanding '~' ourselves, it would be better to don't expand anything, and leave it as it is, but how to detect that in fix_path()? I think that the patch relies on that os.path.expanduser(), if url.path is such a path that begins with ~ (or ~whom), returns an absolute path. When given an absolute path, or ~whom/path, fix_path returns without running 'git config' on remote.alias.url configuration. Presumably this git config is to fix what is already there, and in the case where the path is already absolute (e.g. /home/ap/hgrepo as opposed to ~ap/hgrepo) the resulting repository has a correct value for the variable set already without the need to fix it (that is why the original code just returns from the function), so doing the same for ~whom case with this patch should leave the setting, which presumably is hg::~ap/hgrepo? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: So if we didn't store a different path, it would work. So instead of expanding '~' ourselves, it would be better to don't expand anything, and leave it as it is, but how to detect that in fix_path()? I think that the patch relies on that os.path.expanduser(), if url.path is such a path that begins with ~ (or ~whom), returns an absolute path. When given an absolute path, or ~whom/path, fix_path returns without running 'git config' on remote.alias.url configuration. I think ~whom/path would run 'git config'. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature request: post-receive rss generation
Could you please add the following functionality: I want to be able pass a command line argument to git, which will generate an rss file with the latest changes. Several codes already exist: * git2rss (http://bent.latency.net/git2rss) * git-rss (https://github.com/iarna/git-rss) Thanks, Leon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Fri, Aug 09, 2013 at 12:42:14PM -0700, Jonathan Nieder wrote: I wonder if it's too gentle and long to get the point across. Would something the following (including the guesses in the message for easier copy-pasting) help? No name and email address configured, so I had to guess. You can suppress this message by setting your identity explicitly: git config --global user.name Thorsten Glaser git config --global user.email t...@mirbsd.de After doing so, you may fix the identity used for this commit with git commit --amend --reset-author. I don't know if including the name and email helps that much. It should already be printed along with that message, like: $ git commit --allow-empty -m foo [master ba77f94] foo Committer: Jeff King p...@sigill.intra.peff.net Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly: git config --global user.name Your Name git config --global user.email y...@example.com After doing this, you may fix the identity used for this commit with: git commit --amend --reset-author It may also make sense to distinguish between cases where a mailname is set and not set. Git already notices the cases where the guessed email address ends with .(none) and errors out, and it could make sense to be more aggressive. Yeah, there are basically three levels of ident: 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it. 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn but use it. 3. It looks obviously bogus (e.g., we do not have a domain name). Reject it. We can move some cases from (2) down to (3), like when we use gethostname rather than /etc/mailname. But we risk breaking people's existing setups. I don't think we know how many people rely on the implicit hostname selection and would be affected. I don't know if there is a good way to find out short of changing it and seeing who screams. We can put a deprecation warning in the release notes, but people tend to ignore those. Or perhaps now that we have had the long obnoxious implicit-ident warning for several versions, everybody has finally set user.email and the time is right to change. Another option could to add an option to control the strictness. We usually have a chicken-and-egg problem here with individual installs (i.e., any person who could set user.trustHostname = false could just as easily have set user.email). But in an institutional setting, the admin could set such a config in /etc/gitconfig for everybody. Or for a system like Debian, the packager could include the option, knowing that any reasonably configured system should have /etc/mailname set up (which is not something we can necessarily count on for other operating systems). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] remote-hg: add shared repo upgrade
If we have an old organization (v1.8.3), and want to upgrade to a newer
one (v1.8.4), the user would have to fetch the whole repository, instead
we can just move the repository, so the user would not notice any
difference.
Also, remove other clones, so in time they get set up as shared.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 12
1 file changed, 12 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index cfd4f53..6c82b8d 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -392,6 +392,18 @@ def get_repo(url, alias):
else:
shared_path = os.path.join(gitdir, 'hg')
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if os.path.exists(shared_path) and not os.path.exists(hg_path):
+repos = os.listdir(shared_path)
+for x in repos:
+local_hg = os.path.join(shared_path, x, 'clone', '.hg')
+if not os.path.exists(local_hg):
+continue
+if not os.path.exists(hg_path):
+shutil.move(local_hg, hg_path)
+shutil.rmtree(os.path.join(shared_path, x, 'clone'))
+
# setup shared repo (if not there)
try:
hg.peer(myui, {}, shared_path, create=True)
--
1.8.3.267.gbb4989f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] remote-hg: ensure shared repo is initialized
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
So, instead of simply checking if the directory exists, let's always try
to create an empty shared repository to ensure it's there. This works
because we don't need the initial clone, if the repository is shared,
pulling from the child updates the parent's storage; it's exactly the
same as cloning, so we can simplify the shared repo setup this way while
at the same time fixing the problem.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..cfd4f53 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -391,11 +391,12 @@ def get_repo(url, alias):
os.makedirs(dirname)
else:
shared_path = os.path.join(gitdir, 'hg')
-if not os.path.exists(shared_path):
-try:
-hg.clone(myui, {}, url, shared_path, update=False, pull=True)
-except:
-die('Repository error')
+
+# setup shared repo (if not there)
+try:
+hg.peer(myui, {}, shared_path, create=True)
+except error.RepoError:
+pass
if not os.path.exists(dirname):
os.makedirs(dirname)
--
1.8.3.267.gbb4989f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] remote-hg: shared repo upgrade fix
Hi, Same as before, except with commit messages updated, and improved the second patch: --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -400,8 +400,9 @@ def get_repo(url, alias): local_hg = os.path.join(shared_path, x, 'clone', '.hg') if not os.path.exists(local_hg): continue -shutil.copytree(local_hg, hg_path) -break +if not os.path.exists(hg_path): +shutil.move(local_hg, hg_path) +shutil.rmtree(os.path.join(shared_path, x, 'clone')) # setup shared repo (if not there) try: Felipe Contreras (2): remote-hg: ensure shared repo is initialized remote-hg: add shared repo upgrade contrib/remote-helpers/git-remote-hg | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) -- 1.8.3.267.gbb4989f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King p...@peff.net writes: Yeah, there are basically three levels of ident: 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it. 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn but use it. 3. It looks obviously bogus (e.g., we do not have a domain name). Reject it. We can move some cases from (2) down to (3), like ... Judging from Thorsten's earlier response, I am afraid no amount of autodetection would help the users of that site. If we were to do something, /etc/gitconfig as you outlined below would be the way to go, even though it makes me feel dirty. Another option could to add an option to control the strictness. We usually have a chicken-and-egg problem here with individual installs (i.e., any person who could set user.trustHostname = false could just as easily have set user.email). But in an institutional setting, the admin could set such a config in /etc/gitconfig for everybody. Or for a system like Debian, the packager could include the option, knowing that any reasonably configured system should have /etc/mailname set up (which is not something we can necessarily count on for other operating systems). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King wrote: Yeah, there are basically three levels of ident: 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it. 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn but use it. 3. It looks obviously bogus (e.g., we do not have a domain name). Reject it. We can move some cases from (2) down to (3), like when we use gethostname rather than /etc/mailname. But we risk breaking people's existing setups. I don't think we know how many people rely on the implicit hostname selection and would be affected. I don't know if there is a good way to find out short of changing it and seeing who screams. Yes. The result from a reverse DNS lookup is almost never the right mailname. * Small installations tend to use a smarthost. * Large installations tend to use more than one machine, and only one machine's name gets the MX record. So except for cases where someone doesn't actually care about the recorded author and just has a script making commits (such users already suffer from the .(none) heuristic), I don't think this would hurt anyone. We can put a deprecation warning in the release notes, but people tend to ignore those. Not so much a deprecation warning as an Here is one of the more noticeable changes in this release announcement. I'm pretty sure a deprecation warning would not help here. Either people are affected and we say WARNING: You were doing something perfectly reasonable, but now we discourage it, or, more likely, people are not affected. Announcing a change too loudly to users not affected by it has a very bad side effect of training them not to pay much attention to release notes. [...] Another option could to add an option to control the strictness. I suspect a new config item for this is a bad idea, given how simple it is to choose a good default for everyone. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] .mailmap: mark bouncing email addresses
Jonathan Nieder jrnie...@gmail.com writes: +# The 2 following authors are probably the same person, +# but both emails bounce. Nanako Shiraishi nana...@bluebottle.com Nanako Shiraishi nana...@lavabit.com I don't know how to contact Nanako these days. :( Maybe mailmap should learn a way to say there's no current public email address for this person. I don't, either, but these two entries describe the same person. One option that I didn't give other old-and-now-left-the-project contributors in my previous message (but I should have) is to let them say: I left the project, you can use my existing contributions, but I prefer you not to list my current address in your address book. The reason I didn't but I think I should have is because mailmap is not meant to record the current address to be used to contact the person. Its primary purpose is to make sure we group contributions by the same person under a single name. So in that sense, it is OK if they choose to give us the address they used the last time they contributed, even that address no longer works. I'd suggest using the lavabit address unless we hear the preferred address from her, as the lavabit address was used in 5bf46841 (git-gui: update Japanese translation, 2010-02-02), while the last use of the bluebottle address was in 6762079a (Cloning from a repo without current branch, 2007-06-16). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Felipe Contreras felipe.contre...@gmail.com writes: On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: So if we didn't store a different path, it would work. So instead of expanding '~' ourselves, it would be better to don't expand anything, and leave it as it is, but how to detect that in fix_path()? I think that the patch relies on that os.path.expanduser(), if url.path is such a path that begins with ~ (or ~whom), returns an absolute path. When given an absolute path, or ~whom/path, fix_path returns without running 'git config' on remote.alias.url configuration. I think ~whom/path would run 'git config'. Hmph, do you mean the third example of this? $ python import os os.path.expanduser(~/repo) '/home/junio/repo' os.path.expanduser(~junio/repo) '/home/junio/repo' os.path.expanduser(~felipe/repo) '~felipe/repo' which will give ~felipe/repo that is _not_ an absolute repository because no such user exists on this box? It is true that in that case fix_path() will not return early and will throw a bogus path at git config, but if the ~whom does not resolve to an existing home directory of a user, I am not sure what we can do better than what Antoine's patch does. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Fri, Aug 9, 2013 at 6:39 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: OK, I think I see why you are puzzled. Cloning works fine because we fix the path *after* the clone is done successfully, for the following reason: So if we didn't store a different path, it would work. So instead of expanding '~' ourselves, it would be better to don't expand anything, and leave it as it is, but how to detect that in fix_path()? I think that the patch relies on that os.path.expanduser(), if url.path is such a path that begins with ~ (or ~whom), returns an absolute path. When given an absolute path, or ~whom/path, fix_path returns without running 'git config' on remote.alias.url configuration. I think ~whom/path would run 'git config'. Hmph, do you mean the third example of this? $ python import os os.path.expanduser(~/repo) '/home/junio/repo' os.path.expanduser(~junio/repo) '/home/junio/repo' os.path.expanduser(~felipe/repo) '~felipe/repo' which will give ~felipe/repo that is _not_ an absolute repository because no such user exists on this box? It is true that in that case fix_path() will not return early and will throw a bogus path at git config, but if the ~whom does not resolve to an existing home directory of a user, I am not sure what we can do better than what Antoine's patch does. I was thinking something like this: if url.scheme != 'file' or os.path.isabs(url.path) or url.path[0] == '~': return -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 5:16 AM, Jeff King p...@peff.net wrote: Another solution could involve not writing the duplicate of Y in the first place. The reason we do not store thin-packs on disk is that you run into problems with cycles in the delta graph (e.g., A deltas against B, which deltas against C, which deltas against A; at one point you had a full copy of one object which let you create the cycle, but you later deleted it as redundant with the delta, and now you cannot reconstruct any of the objects). You could possibly solve this with cycle detection, though it would be complicated (you need to do it not just when getting rid of objects, but when sending a pack, to make sure you don't send a cycle of deltas that the other end cannot use). You _might_ be able to get by with a kind of two-level hack: consider your main pack as group A and newly pushed packs as group B. Allow storing thin deltas on disk from group B against group A, but never the reverse (nor within group B). That makes sure you don't have cycles, and it eliminates even more I/O than any repacking solution (because you never write the extra copy of Y to disk in the first place). But I can think of two problems: 1. You still want to repack more often than every 300 packs, because having many packs cost both in space, but also in object lookup time (we can do a log(N) search through each pack index, but have to search linearly through the set of indices). 2. As you accumulate group B packs with new objects, the deltas that people send will tend to be against objects in group B. They are closer to the tip of history, and therefore make better deltas for history built on top. That's all just off the top of my head. There are probably other flaws, too, as I haven't considered it too hard. Some refinements on this idea - We could keep packs in group B ordered as the packs come in. The new pack can depend on the previous ones. - A group index in addition to separate index for each pack would solve linear search object lookup problem. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [git-po] [fr] first commits for French localization (#62)
Hi, Another language support (French) is coming soon. I will send new pull request later after Avila corrects indent error and rewrites the commit logs. Folks who have interests on French l10n may help to review. -- Forwarded message -- From: Jean-Noël Avila notificati...@github.com Date: 2013/8/10 Subject: [git-po] [fr] first commits for French localization (#62) To: git-l10n/git-po git...@noreply.github.com This is the start of French localization. These translations have not been reviewed by a peer yet. You can merge this Pull Request by running git pull https://github.com/jnavila/git git-po-fr Or view, comment on, or merge it at: https://github.com/git-l10n/git-po/pull/62 Commit Summary [fr] 821/2112 messages translated [fr] Add reference for french translation team File Changes M po/TEAMS (4) A po/fr.po (9668) Patch Links: https://github.com/git-l10n/git-po/pull/62.patch https://github.com/git-l10n/git-po/pull/62.diff -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pull: Allow pull to preserve merges when rebasing.
If a user is working on master, and has merged in their feature branch, but now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because git pull currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.
Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.
Also add 'preserve' to the allowed values for the pull.rebase config setting.
Signed-off-by: Stephen Haberman step...@exigencecorp.com
---
Hey,
This is version 2 of my previous patch--I changed over to the --rebase=preserve
syntax as suggested by Johannes and Junio.
I also updated the documentation.
I believe it is ready for serious consideration. Please let me know if I'm
missing anything subtle or obvious.
Thanks,
Stephen
Documentation/config.txt | 8
Documentation/git-pull.txt | 18 --
git-pull.sh| 23 ++-
t/t5520-pull.sh| 28
4 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..4c22be2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -766,6 +766,10 @@ branch.name.rebase::
git pull is run. See pull.rebase for doing this in a non
branch-specific manner.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
@@ -1826,6 +1830,10 @@ pull.rebase::
pull is run. See branch.name.rebase for setting this on a
per-branch basis.
+
+ When preserve, also pass `--preserve-merges` along to 'git rebase'
+ so that locally committed merge commits will not be flattened
+ by running 'git pull'.
++
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 6ef8d59..87ff938 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -102,12 +102,18 @@ include::merge-options.txt[]
:git-pull: 1
-r::
---rebase::
- Rebase the current branch on top of the upstream branch after
- fetching. If there is a remote-tracking branch corresponding to
- the upstream branch and the upstream branch was rebased since last
- fetched, the rebase uses that information to avoid rebasing
- non-local changes.
+--rebase[=false|true|preserve]::
+ When true, rebase the current branch on top of the upstream
+ branch after fetching. If there is a remote-tracking branch
+ corresponding to the upstream branch and the upstream branch
+ was rebased since last fetched, the rebase uses that information
+ to avoid rebasing non-local changes.
++
+When preserve, also rebase the current branch on top of the upstream
+branch, but pass `--preserve-merges` along to `git rebase` so that
+locally created merge commits will not be flatten.
++
+When false, merge the current branch into the upstream branch.
+
See `pull.rebase`, `branch.name.rebase` and `branch.autosetuprebase` in
linkgit:git-config[1] if you want to make `git pull` always use
diff --git a/git-pull.sh b/git-pull.sh
index f0df41c..d142b38 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -40,13 +40,13 @@ test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
-merge_args= edit=
+merge_args= edit= rebase_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
-rebase=$(git config --bool branch.$curr_branch_short.rebase)
+rebase=$(git config branch.$curr_branch_short.rebase)
if test -z $rebase
then
- rebase=$(git config --bool pull.rebase)
+ rebase=$(git config pull.rebase)
fi
dry_run=
while :
@@ -111,7 +111,14 @@ do
merge_args=$merge_args$xx
;;
-r|--r|--re|--reb|--reba|--rebas|--rebase)
- rebase=true
+ # if the value is already non-false, like preserve, leave it
alone
+ if test -z $rebase -o false = $rebase
+ then
+ rebase=true
+ fi
+ ;;
+ --rebase=*)
+ rebase=${1#*=}
;;
--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
rebase=false
@@ -145,6 +152,12 @@ do
shift
done
+if test preserve = $rebase
+then
+
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Felipe Contreras felipe.contre...@gmail.com writes: Hmph, do you mean the third example of this? $ python import os os.path.expanduser(~/repo) '/home/junio/repo' os.path.expanduser(~junio/repo) '/home/junio/repo' os.path.expanduser(~felipe/repo) '~felipe/repo' which will give ~felipe/repo that is _not_ an absolute repository because no such user exists on this box? It is true that in that case fix_path() will not return early and will throw a bogus path at git config, but if the ~whom does not resolve to an existing home directory of a user, I am not sure what we can do better than what Antoine's patch does. I was thinking something like this: if url.scheme != 'file' or os.path.isabs(url.path) or url.path[0] == '~': return That did cross my mind. I know ~/ and ~who/ are expanded on UNIXy systems, and I read in Python documentation that Python on Windows treats ~/ and ~who/ the same way as on UNIXy systems, so the begins with ~ test would work on both systems. But it is probably a better design to outsource that knowledge to os.path.expanduser(), with the emphasis on os. part of that function. That way, we do not even have to care about such potential platform specifics, which is a big plus. The only possible difference that approach makes is the above example of naming a non-existent ~user, but that will not work anyway, so... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
Jeff King p...@peff.net writes: ... The reason we do not store thin-packs on disk is that you run into problems with cycles in the delta graph (e.g., A deltas against B, which deltas against C, which deltas against A; at one point you had a full copy of one object which let you create the cycle, but you later deleted it as redundant with the delta, and now you cannot reconstruct any of the objects). As an extension to that is that a thin-pack will make the validity of a single pack dependent on its surroundings, making verify-pack useless. It may say everything is fine, but corruption of another pack that holds a base object a delta in it depends on will render the pack unusable. With the current arrangement, if you grab a single pack and re-idx it, you know you can reconstruct all the objects in it. The original reason was not cycles; it was primarily because we did not want to have to map more than one packfile while reconstructing the delta chain for a single object (this was way before the open small mmap windows into a large packfile was invented). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
