Please pull l10n updates for 1.8.4 round 2

[Jiang Xin]

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: { }"

[Thomas Rast]

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

Re: Remove old forgotten command: whatchanged

[Matthieu Moy]

Junio C Hamano  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:

diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3bdd56e..486a58b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -818,7 +818,7 @@ for further details.
 'GIT_FLUSH'::
If this environment variable is set to "1", then commands such
as 'git blame' (in incremental mode), 'git rev-list', 'git log',
-   'git check-attr', 'git check-ignore', and 'git whatchanged' will
+   'git check-attr', and 'git check-ignore' will
force a flush of the output stream after each record have been
flushed. If this
variable is set to "0", the output of these commands will be done
diff --git a/Documentation/gitcore-tutorial.txt 
b/Documentation/gitcore-tutorial.txt
index f538a87..8e53560 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -534,9 +534,8 @@ 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.
+changes. The porcelain command 'git log' can also be used to display
+changes introduced by some commits.
 
 To see the whole history of our pitiful little git-tutorial project, you
 can do
@@ -546,11 +545,10 @@ $ 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)
+with the associated patches, use the `--patch` option:
 
 
-$ git whatchanged -p
+$ git log -p
 
 
 and you will see exactly what has changed in the repository over its

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

nike air max 2013 women

[kkiwnue]

nike air max 2013 women
  
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
  
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

[Eric Sunshine]

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

[kkiwnue]

Beats by Dre Solo    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    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

[shawn wilson]

On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt  wrote:
> Am 8/9/2013 8:33, schrieb shawn wilson:
>> On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt  wrote:
>>> Am 8/8/2013 23:11, schrieb Phil Hord:
 On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson  wrote:
> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt  
> 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

[Johannes Sixt]

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

[Jeff King]

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

[Jeff King]

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

[Jeff King]

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

[Ben Tebulin]

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

[Zheng Liu]

From: Zheng Liu 

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 
---
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  
+touch_date()
+{
+   touch -t `date -r $1 +%Y%m%d%H%M.%S` "$2"
+}
+
+# usage: last_modified 
+last_modified()
+{
+   stat -f "%m" "$1"
+}
+
+# usage: format_last_modified 
+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  
+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

[Andreas Schwab]

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

[Duy Nguyen]

On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano  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

[Stefan Beller]

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

[Matthieu Moy]

Andreas Schwab  writes:

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

[Thomas Gummerer]

Duy Nguyen  writes:

> On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer  wrote:
>> Duy Nguyen  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 " as soon as I
>>> resolve  (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 

Re: [RFC PATCH] During a shallow fetch, prevent sending over unneeded objects

[Duy Nguyen]

On Fri, Aug 9, 2013 at 12:10 AM, Junio C Hamano  wrote:
> Duy Nguyen  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/RFC v2] read-cache: save index entry updates in ILOG index extension

[Duy Nguyen]

On Fri, Aug 9, 2013 at 1:46 AM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> Old operation's updates are removed as new ones are added to keep the
>> size under 1 MB. ILOG keeps minimum 10 operations regardless of its
>> size. These contansts should be configurable later one. ILOG content
>> will be compressed later on so that it leaves minimum
>> footprint.
>
> List of  tuples would not compress well, I suspect.

I was hoping that it still compresses well the discrete segments of
pathname. In the worst case we can group sha-1 together, separate from
pathnames.

>> Because it's only needed at index writing time, read-only
>> operations won't pay the cost for decompressing and compressing ILOG.
>
> Another idea is to lazily read existing ILOG by (1) keeping just an
> offset in the originating index file at read_index() time and (2)
> reading it on demand when ":-4:Makefile" was asked for.

We need to go through ILOG extension anyway for index sha-1
verification, so it's already read in kernel buffer. What we save is a
just malloc. But I'll try.

>
>> diff --git a/cache.h b/cache.h
>> index 85b544f..a2156bf 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -168,6 +168,7 @@ struct cache_entry {
>>
>>  /* used to temporarily mark paths matched by pathspecs */
>>  #define CE_MATCHED   (1 << 26)
>> +#define CE_BASE  (1 << 27)
>
> As this is not about pathspec match, please have its own comment
> line (or a blank line, if this goes without comment) above this new
> line.

This patch is more about the idea, whether it makes sense. You would
(and did) find the patch somewhat disgusting later on.

>> @@ -277,6 +278,7 @@ struct index_state {
>>initialized : 1;
>>   struct hash_table name_hash;
>>   struct hash_table dir_hash;
>> + struct strbuf *index_log;
>>  };
>
> Sane to have this as a per-index_state variable.
>
>> +extern void log_index_changes(const char *prefix, const char **argv);
>
> Not sane to name this function _index_anything and not to have index_state
> as its first parameter, breaking the naming convention.

The reason I can't put index_state there is because this function is
called early, often before read_cache is is called. And I can't caller
it later because argv would be ruined by parse_options(). An option is
to convert argv to a string unconditionally in git.c, then
log_index_changes can be called much later, and with index_state
pointer.

>> +static void get_updated_entries(struct index_state *istate,
>> + struct cache_entry ***cache_out,
>> + unsigned int *cache_nr_out)
>> +{
>> + struct cache_entry **cache;
>> + unsigned int i, nr, cache_nr = 0;
>> +
>> + *cache_nr_out = 0;
>> + *cache_out = NULL;
>> + for (i = 0; i < istate->cache_nr; i++) {
>> + if (istate->cache[i]->ce_flags & CE_BASE)
>> + continue;
>> + cache_nr++;
>> + }
>> + if (!cache_nr)
>> + return;
>> + cache = xmalloc(cache_nr * sizeof(*istate->cache));
>> + for (i = nr = 0; i < istate->cache_nr; i++) {
>> + struct cache_entry *ce = istate->cache[i];
>> + if (ce->ce_flags & CE_BASE)
>> + continue;
>> + cache[nr++] = ce;
>> + }
>> + *cache_out = cache;
>> + *cache_nr_out = cache_nr;
>> +}
>
> I can read what the function does, but I do not understand the
> assumption this code makes.
>
> Is this assuming that any newly created cache_entry that goes to
> the_index via add_index_entry() will not have CE_BASE bit set?  Some
> codepaths try to preserve the flags bit they do not care and/or
> understand (e.g. rename_index_entry_at() creates a new ce with a new
> name, and keeps most of the flags bit except for the name-hash state
> bits), so CE_BASE will be propagated from the original to the new
> one, I think.
>
> You seem to be recording the state _after_ the change---that can be
> read without the extension, can't it?  I thought we care more about
> the state that was _lost_ by the change.
>
> Recording the state after the change misses deleted entries, doesn't
> it?

Right. At the end of the commit message I mentioned about "git add
--undo". After I wrote it, I became more convinced it's the way to go.
That should be the UI, instead of letting the user hunt the right
entry through the index log. And then caller has the responsibility to
track changes and feed it to read-cache (CE_BASE trick is gone). And
it would record something like raw diff: a pair of old/new sha-1 and a
path name. This helps differentiate modified, deleted and added
entries that "git add --undo" may need to undo.

>> +static void write_index_log(struct strbuf *sb,
>> + const struct strbuf *old_log,
>> + const struct strbuf *msg,
>> + struct cache_entry **cache,
>> + unsigned int cache_nr)
>> +

Re: [PATCH] git exproll: steps to tackle gc aggression

[Ramkumar Ramachandra]

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

Re: [PATCH] pull: Allow pull to preserve merges when rebasing.

[Johannes Schindelin]

Hi,

On Thu, 8 Aug 2013, Junio C Hamano wrote:

> Stephen Haberman  writes:
> 
> > Hi Johannes,
> >
> >> This should probably be added to config.txt and
> >> Documentation/git-pull.txt, too, right?
> >
> > Yep, I meant to note that I'd do that after getting an initial
> > confirmation that the pull.preserve-merges was the preferred approach.
> 
> If you were to go that route, no dashes in the last component of
> configuration variable names, please.
> 
> > (I was being lazy and didn't want to write up docs only to switch to
> > overloading pull.rebase or what not.)
> 
> I think we have a recent update that allows you to say
> 
>   [pull]
>   rebase = false
> 
> to mean "I want 'git pull' to use merge".  Currently the other
> choice is:
> 
>   [pull]
>   rebase = true
> 
> to say "I want to run 'git pull --rebase'".  I do not think it is
> unreasonable to extend it further so that
> 
>   [pull]
>   rebase = preserve
> 
> is understood.

We have a patch in Git for Windows allowing rebase = interactive which I
did not have time to send upstream.

Ciao,
Johannes
--
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

[Elia Pinto]

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

Re: [GUILT] add FreeBSD support

[Josef 'Jeff' Sipek]

On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
> From: Zheng Liu 
> 
> 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 
> ---
> 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  
> +touch_date()
> +{
> + touch -t `date -r $1 +%Y%m%d%H%M.%S` "$2"
> +}
> +
> +# usage: last_modified 
> +last_modified()
> +{
> + stat -f "%m" "$1"
> +}
> +
> +# usage: format_last_modified 
> +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  
> +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

[Phil Hord]

On Fri, Aug 9, 2013 at 6:03 AM, shawn wilson  wrote:
> On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt  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

[gnehzuil.liu]

在 2013-8-9，下午10:46，Josef 'Jeff' Sipek  写道：

> On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
>> From: Zheng Liu 
>> 
>> 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 
>> ---
>> 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  
>> +touch_date()
>> +{
>> +touch -t `date -r $1 +%Y%m%d%H%M.%S` "$2"
>> +}
>> +
>> +# usage: last_modified 
>> +last_modified()
>> +{
>> +stat -f "%m" "$1"
>> +}
>> +
>> +# usage: format_last_modified 
>> +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  
>> +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

[Josef 'Jeff' Sipek]

On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote:
> �� 2013-8-9��10:46��Josef 'Jeff' Sipek  д
> 
> > On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
> >> From: Zheng Liu 
> >> 
> >> 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

Re: [PATCH] pull: Allow pull to preserve merges when rebasing.

[Stephen Haberman]

> We have a patch in Git for Windows allowing rebase = interactive
> which I did not have time to send upstream.

Cool, so, would rebase=preserve and rebase=interactive be completely
orthogonal?

E.g. do we have to worry about the user wanting to do both, like with
something ugly like rebase=preserve-interactive?

Assuming not, rebase=preserve sounds good to me. I have a patch
that does that about ready to submit.

- Stephen

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

[Kevin Layer]

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

[Junio C Hamano]

Duy Nguyen  writes:

> On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano  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

[Andres Perera]

On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy  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 
> ---
>  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= | --no-prune]
> +'git gc' [--aggressive] [--auto] [--quiet] [--prune= | --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 
> *pre

[PATCH 1/2] remote-hg: add shared repo upgrade

[Antoine Pelisse]

From: Felipe Contreras 

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 
Signed-off-by: Felipe Contreras 
Signed-off-by: Antoine Pelisse 
---
 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

[Junio C Hamano]

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

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

[Justin Collum]

> 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  wrote:
> Justin Collum  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

[Dmitry Kuzminov]

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

[Ramsay Jones]

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

[Antoine Pelisse]

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 
---
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras  
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: [PATCH 1/2] submodule: fix confusing variable name

[Fredrik Gustafsson]

On Thu, Aug 08, 2013 at 06:44:22PM +0100, Ramsay Jones wrote:
> $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.)

Maybe something for git 2.0? Well, Jens and Junio is the ones who can
make sane decissions about this. I trust they make a good decision. The
state as now is that this is a bug for case insesitive systems.

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.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: Remove old forgotten command: whatchanged

[Junio C Hamano]

Matthieu Moy  writes:

> Junio C Hamano  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 
---
 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=] [..] [--pretty=] [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
+++ b/contrib/examples/git-whatchanged.sh
@@ -0,0 

Re: [PATCH] git exproll: steps to tackle gc aggression

[Junio C Hamano]

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

[Junio C Hamano]

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

[Elia Pinto]

2013/8/9 Junio C Hamano :
> Elia Pinto  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 
>
> 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"

[Ralf Thielow]

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 
---
 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  [-L  [-L ]]]
[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=]
- 
+   [--[no-]diff3]   
 
 
 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

[Stefan Beller]

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

[Stefan Beller]

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 
---
 .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  
 Alex Vandiver  
 Alexander Gavrilov 
 Alexey Shumkin  
+Alexey Shumkin  
 Anders Kaseorg  
 Anders Kaseorg  
 Aneesh Kumar K.V 
@@ -31,6 +32,7 @@ Christian Stimming  
 Csaba Henk  
 Dan Johnson 
 Dana L. How  
+Dana L. How  Dana How
 Daniel Barkalow 
 David Brown  
 David D. Kilzer 
@@ -65,6 +67,7 @@ J. Bruce Fields  

 J. Bruce Fields  
 J. Bruce Fields  
 Jakub Narębski 
+James Y Knight  
 Jason Riedy  
 Jason Riedy  
 Jay Soffian  
@@ -92,8 +95,8 @@ Junio C Hamano  
 Junio C Hamano  
 Junio C Hamano  
 Junio C Hamano  
-Karl Wiberg  Karl Hasselström 
-Karl Wiberg  Karl Hasselström 

+Karl Wiberg  Karl  Hasselström
+Karl Wiberg  
 Karsten Blees  
 Karsten Blees  
 Kay Sievers  
@@ -177,6 +180,7 @@ Robin Rosenberg  

 Ryan Anderson  
 Salikh Zakirov  
 Sam Vilain  
+Sam Vilain  s...@vilain.net
 Santi Béjar  
 Sean Estabrooks 
 Sebastian Schuberth  
@@ -191,6 +195,7 @@ Stefan Sperling  
 Stephen Boyd  
 Steven Drake  
 Steven Grimm  
+Steven Grimm  kor...@midwinter.com
 Steven Walter  
 Steven Walter  
 Sven Verdoolaege  
-- 
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

[Stefan Beller]

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

 Anders Kaseorg  
 Anders Kaseorg  
 Aneesh Kumar K.V 
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Amos Waterland 
+Amos Waterland 
 Ben Walton  
 Bernt Hansen  
 Brandon Casey  
@@ -34,6 +38,10 @@ Dan Johnson 
 Dana L. How  
 Dana L. How  Dana How
 Daniel Barkalow 
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Daniel Trstenjak 
+Daniel Trstenjak 
 David Brown  
 David D. Kilzer 
 David Kågedal 
@@ -68,11 +76,19 @@ J. Bruce Fields  

 J. Bruce Fields  
 Jakub Narębski 
 James Y Knight  
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Jason McMullan 
+Jason McMullan 
 Jason Riedy  
 Jason Riedy  
 Jay Soffian  
 Jeff King  
 Jeff Muizelaar  
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Jens Axboe 
+Jens Axboe 
 Jim Meyering  
 Joachim Berdal Haga 
 Johannes Schindelin  
@@ -144,6 +160,8 @@ Michele Ballabio 
 Miklos Vajna  
 Namhyung Kim  
 Namhyung Kim  
+# The 2 following authors are probably the same person,
+# but both emails bounce.
 Nanako Shiraishi 
 Nanako Shiraishi 
 Nelson Elhage  
@@ -177,6 +195,10 @@ Robert Fitzsimons 
 Robert Shearman  
 Robert Zeh 
 Robin Rosenberg  
+# The 2 following authors are probably the same person,
+# but both emails bounce.
+Rutger Nijlunsing 
+Rutger Nijlunsing 
 Ryan Anderson  
 Salikh Zakirov  
 Sam Vilain  
-- 
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

[Philip Oakley]

From: "Dmitry Kuzminov" 

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

[Dmitry Kuzminov]

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" :
> From: "Dmitry Kuzminov" 
>
> 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

[Junio C Hamano]

Antoine Pelisse  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 
> ---
> On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras 
>  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

[Junio C Hamano]

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

[Diogo de Campos]

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

[Diogo de Campos]

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

[Justin Collum]

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  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  wrote:
>> Justin Collum  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

[Jonathan Nieder]

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

[Junio C Hamano]

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

 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.
 
--::
-   Limit output to  commits.
-
-..::
-   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

[Jonathan Nieder]

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 
> +Amos Waterland 

>From the history of http://people.seas.harvard.edu/~apw/sreplay/sreplay.git
this looks like the same person as .

[...]
> +# The 2 following authors are probably the same person,
> +# but both emails bounce.
> +Daniel Trstenjak 
> +Daniel Trstenjak 



[...]
> +# The 2 following authors are probably the same person,
> +# but both emails bounce.
> +Jason McMullan 
> +Jason McMullan 

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 
> +Jens Axboe 



> +# The 2 following authors are probably the same person,
> +# but both emails bounce.
>  Nanako Shiraishi 
>  Nanako Shiraishi 

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 
> +Rutger Nijlunsing 

Probably .

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

[Felipe Contreras]

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

[Felipe Contreras]

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

[Felipe Contreras]

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

[Antoine Pelisse]

On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano  wrote:
> Antoine Pelisse  writes:
>> On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras 
>>  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

[John Keeping]

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 
> ---
> 
>  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.
>  
> --::
> - Limit output to  commits.
> -
> -..::
> - 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

[Thorsten Glaser]

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

Re: [PATCH 2/2] remote-hg: add shared repo upgrade

[Antoine Pelisse]

On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
 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 ?

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

>  # setup shared repo (if not there)
>  try:
>  hg.peer(myui, {}, shared_path, create=True)
--
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

[Phil Hord]

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

[Felipe Contreras]

On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse  wrote:
> On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
>  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

[Felipe Contreras]

On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser  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 
Date: Tue, 13 Nov 2012 07:33:12 +0100
Subject: [PATCH] ident: don't allow implicit email addresses

Signed-off-by: Felipe Contreras 
---
 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.

[Felipe Contreras]

On Fri, Aug 9, 2013 at 7:13 AM, Лежанкин Иван  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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Antoine Pelisse]

Confusion everywhere :-)

On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano  wrote:
> Antoine Pelisse  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

[Junio C Hamano]

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

[Eric Sunshine]

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

[Eric Sunshine]

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

[Eric Sunshine]

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

[Eric Sunshine]

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

[Junio C Hamano]

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

[Junio C Hamano]

Felipe Contreras  writes:

> On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse  wrote:
>> On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
>>  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

[shawn wilson]

On Fri, Aug 9, 2013 at 6:32 AM, Johannes Sixt  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

[Antoine Pelisse]

On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano  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

[Felipe Contreras]

On Fri, Aug 9, 2013 at 4:19 PM, Antoine Pelisse  wrote:
> Confusion everywhere :-)
>
> On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano  wrote:
>> Antoine Pelisse  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

[Jeff King]

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 disc

Re: [PATCH] remote-hg: fix path when cloning with tilde expansion

[Junio C Hamano]

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

[Felipe Contreras]

On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano  wrote:
> Felipe Contreras  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..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

[Leon Mintz]

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

[Jeff King]

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

[Felipe Contreras]

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

[Felipe Contreras]

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

[Felipe Contreras]

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

[Junio C Hamano]

Jeff King  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: [PATCH 2/2] .mailmap: mark bouncing email addresses

[Junio C Hamano]

Jonathan Nieder  writes:

> From a quick search for homepages:

Thanks for digging.

So I'll discard this patch for now, and instead send this message
CC'ed to these guessed addresses.

-- >8 --

Dear Amos, Daniel, Jason, Jens, and Rutger:

our record indicates that you contributed to our project (Git --
distributed source control system) in the past under more than
two e-mail addresses, all of which now seem to be defunct.

We would want to keep our .mailmap up-to-date, primarily in
order to consolidate these multiple entries for each of you into
one.  Could you tell us your preferred e-mail address your
contributions are listed as?  This message is sent to our best
current guess of your address.

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: git should not use a default user.email config value

[Jonathan Nieder]

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

[Junio C Hamano]

Jonathan Nieder  writes:

>> +# The 2 following authors are probably the same person,
>> +# but both emails bounce.
>>  Nanako Shiraishi 
>>  Nanako Shiraishi 
>
> 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

[Junio C Hamano]

Felipe Contreras  writes:

> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano  wrote:
>> Felipe Contreras  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..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

[Felipe Contreras]

On Fri, Aug 9, 2013 at 6:39 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano  wrote:
>>> Felipe Contreras  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..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 v4] gc: reject if another gc is running, unless --force is given

[Duy Nguyen]

On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera  wrote:
> On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy  
> wrote:
>> +   uintmax_t pid;
>
> pid_t is always an signed type, therefore unintmax_t does not make
> sense as a catch all value

I only catch real process id. In practice we don't have processes with
negative pid_t, do we? I can't find any document about this, but at
least waitpid seems to treat negative pid (except -1) just as an
indicator while the true pid is the positive counterpart.

> 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
-- 
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: git rebase --interactive using short SHA-1's internally

[David]

On 10 August 2013 05:22, Diogo de Campos  wrote:
> Had some problems rebasing a large repository, fatal error because a
> short SHA-1 ref was ambiguous.

This recent disussion might also interest you:
http://thread.gmane.org/gmane.comp.version-control.git/229091
--
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

[Duy Nguyen]

On Sat, Aug 10, 2013 at 5:16 AM, Jeff King  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)

[Jiang Xin]

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 
Date: 2013/8/10
Subject: [git-po] [fr] first commits for French localization (#62)
To: git-l10n/git-po 


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