[PATCH 1/2] Documentation: remove --prune from pack-refs examples
The option has been the default for a while, and doesn't otherwise appear in the page. --- Documentation/git-pack-refs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index f131677..154081f 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -33,8 +33,8 @@ Subsequent updates to branches always create new files under `$GIT_DIR/refs` directory hierarchy. A recommended practice to deal with a repository with too many -refs is to pack its refs with `--all --prune` once, and -occasionally run `git pack-refs --prune`. Tags are by +refs is to pack its refs with `--all` once, and +occasionally run `git pack-refs`. Tags are by definition stationary and are not expected to change. Branch heads will be packed with the initial `pack-refs --all`, but only the currently active branch heads will become unpacked, -- 1.8.3.3.754.g9c3c367 Jonathon Mah m...@jonathonmah.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 2/2] Documentation: fix git-prune example usage
--- Documentation/git-prune.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 80d01b0..bf82410 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -59,7 +59,7 @@ borrows from your repository via its `.git/objects/info/alternates`: -$ git prune $(cd ../another $(git rev-parse --all)) +$ git prune $(cd ../another git rev-parse --all) Notes -- 1.8.3.3.754.g9c3c367 Jonathon Mah m...@jonathonmah.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
Thomas Sabo Charms Armband
Thomas Sabo Charms Armband http://www.schmuckskaufen.com/ ist in der Regel für den großen mythischen neben eleganten Schmuck Thema Materialien Inhalt zusammen mit Blogs alle den Weg durch jeden, der betroffenen ist. Dies ist wirklich eine ausgezeichnete zuverlässige und folgenden wirklich berühmt entdecken gefunden in der gesamten komplette Umgebung von Schmuck-Design danach bietet die Quintessenz schwierig Widerstand gegen die Fähigkeit seiner Konkurrenz haben. Thomas Sabo Armbänder ist normalerweise in unzähligen Menge in Bezug auf Quellen. Versteckt, 14k verwendet verschiedene Uhren, deshalb Haus könnte am ehesten vielleicht die wichtigsten Elemente, die Sie werden die Fähigkeit aus, die zu wählen, vielleicht erleben werden. Natürliche Schnüre mit Material beendet wird sofort zur Verfügung gestellt werden, aber vielleicht nicht immer beliebt vor allem, weil Material und zusätzlich Wildleder gewachsen zu sein. Die Investition in eine zweifarbige Armband ist auch eine andere. Es ist für manche Menschen eine besondere ideal beste tatsächlichen wahrer Segen über Thomas Sabo teuren Schmuck Aufdeckung zu wenig Stellen, an denen gute Rabatte Abschluss Kopf die Entscheidung für pop out, einzigartig zu sein Armbänder Menschen am Ende gleichzeitig ansprechend. Absolut müssen Wahrhaftigkeit die Show Thomas Sabo gute Rabatte erreichen bis kommenden Standard Bauart, die konsequent zu einem und zusätzlich so ziemlich jeder individuelle Positionierung ändern. Verbessern Sie einen guten begehrten Potential innerhalb der Art von generatethomas Thomas Sabo teuren Schmuck Land Fußabdrücke über Entschlüsselung nie schlagen in Richtung machen ein paar Siegel aus aus der Vereinbarung über die Küsse von Damen zu entwickeln. Was bedeutet, dass der Einkauf Designer inspiriert metallischen Schmuck ist nie immer bedeuten, könnten Sie mit der Gleichheit der physischen Erscheinung dieses Produkts einschränken. Seine aaa kostengünstiger Ansatz zur Verabschiedung der neuesten Mode wesentlicher Bedeutung und zusätzlich einzigartige Design-Argument. So, nach Zeit, sobald Sie sehen ziemlich jeder in Bezug auf die Internet-Schmuckgeschäfte Umgang in Designer inspiriert Schmuck metallic Produkt dann nie zögern bei der Sie Ihre bevorzugte Gruppe Silber, metallic Ohrring, oder vielleicht Reize auf Merkmale der Thomas Sabo Charms Kollektion formuliert, von Backlinks von London Sweetie Sammlung. In der besonderen Situation in der Einführung der neuen Spring / Summer 2013 TV-Serie in der es london, führte die tatsächlichen internationalen Lifestyle schnelle Thomas Sabo Australien ihre harte Arbeit zusammen mit Superstar Brian Geiger Garrett. Rock 'n' Roll, auffällig sind zusätzlich expressive: Merkmale, die für Sie unterschreiben. In deutscher Violinist und auch die starke Digital Rebel in der Mitte Fernsehserie innerhalb derselben zu bestimmen. Zusammen mit seinem attraktiven erscheinen mit seiner fantastischen charismatischen Nervenkitzel bietet Brian Garrett den Cool Dude in deinem Geist Venture ein wirklich spezifische Ausdruckskraft. Das brandneue mens Mischung glänzt zusammen mit Behauptung Schmuck und zusätzlich spannende Themen, die in der Regel Jesse sofort angekündigt gewesen ihre wichtigsten Stücke hatte. Thomas Sabo Charms 2013 http://www.schmuckskaufen.com/ Köstliche Couture, die sicherlich in Ca liegt, ist eine Geschwindigkeit, die Kleidung sein, die jeweils eine anspruchsvolle und wird wie Thomas Sabo erwerben unkonventionell. Es ist nur ein Favorit tag Ebenen über andere Kleidungsstücke neben Spielereien obwohl Erwerb wirksam. Obwohl eine große Zahl von Thomas Sabo im Internet-Shop dieses Satzes, um Mädchen Thomas Sabo Armbänder Verzeichnis Mar del Plata nach cxf haben zeigen, ist köstlich Couture auf der Oberseite, die entworfen, um Männern zu helfen. Sie können mit einem leistungsstarken eklektische Mischung aus Material Innenseiten infolge Köstliche Preisgünstige Thomas Sabo Nähen teuer Reize in sich so ziemlich alle verschiedenen Arten zusammen mit anderen Add-ons oder Geldbörsen, Schuhe zusammen mit Boot-Designs auch als Kleid Hände sich zusammenziehen in. Thru Kinder sind in der Regel Make-up für die Epidermis mit viel der Schmuck Produzent Sukkulenten Couture verbunden. Es ist Aufgabe, ein Beispiel ist Sengende Couture hochpreisigen Schmuck ist in der Regel ein mit Einzigartigkeit verbunden kombinieren, wird auch eine Information. - nike air max günstig nike air max sale Nike Air Max kaufen -- View this message in context: http://git.661346.n2.nabble.com/Thomas-Sabo-Charms-Armband-tp7592203.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
nike air max 1 Damen
NIKE FREE three.0 V2 HERREN Im Jahr 2005 wurde Messi angewiesen, seinen Vertrag mit Nike zu verbessern, aber er berichtet Nr. Möglicherweise erhält Messi einige Vorteile oder vielleicht Versuchung von Adidas, und nike air max 1 Damen http://www.airmaxschuhekaufen.de/ dann hat er zusätzlich modifiziert. Mit dem einzigartigen Art, wird Messi von Adidas wie eine geeignete Mitarbeiter mit seiner einzigartigen Sequenz von Fußball Turnschuhe abgeholt. Nike Schuhe Unternehmen verleiht dieser besonderen neuen Art mit nur einer Idee, vor allem, Zeitplan. Nike Geschäft angenommen hat synthetischem Gewebe die Schaft des Schuhs ab 2002 Welt Tasse wird bis 2010 Weltbechers bekam, und auch diese ausgezeichnete muss die primäre streben von Nike Geschäft sein, Turnschuhe nur zum Zeitplan herablassen. Nike Free 5.0 V4 Die neuen Wissenschaften verwendet ähnlich einem Fiber-Composite-Sohle und zusätzlich patentierte Vapor Traction System machen diese Turnschuhe präsentieren hervorragende Traktion und zusätzlich deluxe ob diese Agentur oder auf komfortablen Boden Sohle plates.NIKE FREE 2012 DAMEN Nike Stiefel verwendet haben verschiedene Arten und auch Farbe. Das Paar wird von den Anbietern und zusätzlich jeden Tag, Wanderer, die einen Stil Aussage machen wollen genutzt werden. Um Nike Shops in den Lagerraum zu entdecken. Der Nike Swoosh-Logo wurde zum Nachdenken über die meisten wahrscheinlich die Quintessenz lobte Business-Logos mit der Weltkugel jetzt. Der Titel Nike wurde von der griechischen Göttin des Sieges inspiriert. Wie ein Ding der Wirklichkeit, wie eine Vielzahl von namhaften Unternehmen, Nike hatte auch einen bescheidenen Zustand zunächst NIKE FREE Jahr 2012. Die einzigartigen Eigentümer werden verwendet, um Sportler sowie benutze es, um mehr zu bekommen, wenn bis 40 Jahren bis heute verglichen werden. img src=http://git.661346.n2.nabble.com/file/n7592204/nikeairmax1damen031_8.jpg; border=0/ http://www.airmaxschuhekaufen.de Grundsätzlich definiert ist, ist das ganze Leben Versicherungsschutz Richtlinien wirklich ein starkes Geldanlage beslut det umfasst Sie einmal mehr, da später auf, wie Sie nike befreit this harten Hyper TR retire.The Raten Interesse skabes akkumulieren eine Rente, das ist ein Aufwand att entwickelt auf einem zusätzlichen Preis ein paar Helfer bringen Sie in dad viel viel mehr Geld. In dem Fall, dass ähnlich wie dieser sehr gut, eine starke Rente verfügt zusätzlich über 2 geben Ihnen mit täglichen Lebens Versicherung Nike free run Dänemark profitiert von der Partei des unvorhergesehenen verringerter Lebenserwartung Projekt. Die ausgezeichnete Art des Versicherungsschutzes Plan kan eine fantastische Geldanlage indenfor Feier att du einfach nicht über einen Ruhestand program.It Schützling die Familie in 2 zahlreiche techniques.Nike kostenlos Angebote immer man aber nicht eine, sondern zwei mit anzufangen, wenn sie Ihre verlieren Umsatz auf der Oberseite Konto Ihrer Untergangs erlaubt die Ausschüttung an die udgifter die Einnahmen möglicherweise ReGel könnte shield.double gefärbt Arbeitsalltag erleben Versicherungsschutz tatsächlich kan eine deiner Pensionierung steuerliche Vorteile Plan zu adressieren. Nike Air Max 1 Herren http://www.airmaxschuhekaufen.de/ Nur weil Athleten eigentlich wirklich populär sind die Auslösezeit der Anzeige Nike Schuhe, macht das Unternehmen große Fortschritte bei der Bereitstellung der Standard-Kunde ein gutes Ergebnis für den Kauf ihrer Schuhe: Der Nike Sinn für Mode wird als sehr modisch angesehen. Verschiedene Marken sind tatsächlich mehrere Veranstaltungen, wie das Schwarze Schatten Nike Schuhe günstig Turnschuhe und ist wirklich für traditionelle Spiele konzipiert. Offensichtlich sind die Verbraucher wirklich glücklich, weil da Leichtathletik Athleten. - nike air max günstig nike air max sale Nike Air Max kaufen -- View this message in context: http://git.661346.n2.nabble.com/nike-air-max-1-Damen-tp7592204.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
git svn fetch segfault on exit
Hi,
I'm using archlinux with git version 1.8.3.3, svn version 1.8.0
(r1490375) and perl v5.18.0 (built for x86_64-linux-thread-multi)
Every git svn call that involves a fetch produces a segmentation fault
on exit (but the operation succeeds).
*** Error in `/usr/bin/perl': double free or corruption (!prev):
0x02ce1ac0 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x788ae)[0x7fd4d83798ae]
/usr/lib/libc.so.6(+0x79587)[0x7fd4d837a587]
/usr/lib/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fd4d568e9ad]
/usr/lib/libapr-1.so.0(apr_pool_terminate+0x30)[0x7fd4d568f590]
/usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.so(_wrap_apr_terminate+0x50)[0x7fd4d6886920]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_entersub+0x571)[0x7fd4d876f821]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_runops_standard+0x16)[0x7fd4d8767e26]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_sv+0x3b0)[0x7fd4d86f93b0]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_list+0x2c7)[0x7fd4d86fb477]
/usr/lib/perl5/core_perl/CORE/libperl.so(perl_destruct+0x1321)[0x7fd4d86fca91]
/usr/bin/perl(main+0x111)[0x400e01]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fd4d8322a15]
/usr/bin/perl[0x400e71]
This bug has already been reported by others on subversion mailing list
and and archlinux bbs:
https://bugs.archlinux.org/task/36070
http://permalink.gmane.org/gmane.comp.version-control.subversion.user/114019
I tried to fix it but the problem is that I know absolutely nothing of
perl. Anyway, I noticed that with the modifications bellow (in
Git::SVN::Ra::new) the crash does not occur (I do not think it's a real
fix though).
--- /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm.orig2013-07-18
11:15:23.584625508 +0200
+++ /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm2013-07-18
11:16:14.624622422 +0200
@@ -79,7 +79,6 @@
SVN::_Core::svn_config_ensure($config_dir, undef);
my ($baton, $callbacks) =
SVN::Core::auth_open_helper(_auth_providers);
my $config = SVN::Core::config_get_config($config_dir);
-$RA = undef;
my $dont_store_passwords = 1;
my $conf_t = ${$config}{'config'};
{
@@ -108,7 +107,7 @@
config = $config,
pool = SVN::Pool-new,
auth_provider_callbacks = $callbacks);
-$RA = bless $self, $class;
+$self = bless $self, $class;
# Make sure its canonicalized
$self-url($url);
@@ -118,7 +117,7 @@
$self-{cache} = { check_path = { r = 0, data = {} },
get_dir = { r = 0, data = {} } };
-return $RA;
+return $self;
}
sub url {
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 0/6] fix blame -L regression; add tests
Eric Sunshine sunsh...@sunshineco.com writes:
This series fixes a regression in blame -L X,-N, adds blame -L tests,
and makes minor documentation adjustments. The tests, in particular,
were motivated by the desire to revisit and continue working on [1]
which extends git-blame to accept multiple -L's. That topic will need to
extend blame -L tests, of which there were essentially none.
Patches [2/6] (modernize style) and [3/6] (add blame -L tests) are
intentionally independent of the git log -L topic (from earlier this
year) to which the other patches are related. This independence should
allow these two patches to graduate at their own pace without being tied
to git log -L.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/229755/
Eric Sunshine (6):
line-range: fix blame -L X,-N regression
t8001/t8002 (blame): modernize style
t8001/t8002 (blame): add blame -L tests
t8001/t8002 (blame): add blame -L :funcname tests
blame-options.txt: place each -L option variation on its own line
blame-options.txt: explain that -L start and end are optional
Thanks, and except for the comment I just sent out,
Acked-by: Thomas Rast tr...@inf.ethz.ch
In case it wasn't obvious to anyone else: the tests do actually verify
that the right lines were picked, by counting how often each author is
blamed.
--
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: [PATCH 5/6] blame-options.txt: place each -L option variation on its own line
Eric Sunshine sunsh...@sunshineco.com writes:
Standard practice in Git documentation is for each variation of an
option (such as: -p / --porcelain) to be placed on its own line in the
OPTIONS table. The -L option does not follow suit. It cuddles
-L start,end and -L :regex, separated by a comma. This is
inconsistent and potentially confusing since the comma separating them
is typeset the same as the comma in start,end. Fix this by placing
each variation on its own line.
Ok, but why not fix them all in one go?
Edited to remove the false positives:
$ git grep -n '^.*,.*::$' Documentation/*.txt
Documentation/blame-options.txt:12:-L start,end, -L :regex::
Documentation/config.txt:1252:gitcvs.dbuser, gitcvs.dbpass::
Documentation/config.txt:1513:http.lowSpeedLimit, http.lowSpeedTime::
Documentation/git-add.txt:90:-e, \--edit::
Documentation/git-check-attr.txt:22:-a, --all::
Documentation/git-check-ignore.txt:26:-q, --quiet::
Documentation/git-check-ignore.txt:30:-v, --verbose::
Documentation/git-check-ignore.txt:42:-n, --non-matching::
Documentation/git-log.txt:65:-L start,end:file, -L :regex:file::
Documentation/git-log.txt:156:git log -L '/int main/',/^}/:main.c::
Documentation/git-p4.txt:171:--verbose, -v::
Documentation/git-p4.txt:282:--dry-run, -n::
--
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: [PATCH v3 0/3] Switch German translation to G+E
Ralf Thielow ralf.thie...@gmail.com writes:
This is a resend of v3 because at least one patch was
damaged last time for whatever reason.
Ralf Thielow (3):
l10n: de.po: switch from pure German to German+English (part 1)
l10n: de.po: switch from pure German to German+English (part 2)
l10n: de.po: switch from pure German to German+English (part 3)
Thanks, this one applied cleanly.
Acked-by: Thomas Rast tr...@inf.ethz.ch
--
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: git svn fetch segfault on exit
Jonathan Lambrechts jonathanlambrec...@gmail.com writes:
Every git svn call that involves a fetch produces a segmentation fault
on exit (but the operation succeeds).
*** Error in `/usr/bin/perl': double free or corruption (!prev):
0x02ce1ac0 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x788ae)[0x7fd4d83798ae]
/usr/lib/libc.so.6(+0x79587)[0x7fd4d837a587]
/usr/lib/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fd4d568e9ad]
/usr/lib/libapr-1.so.0(apr_pool_terminate+0x30)[0x7fd4d568f590]
/usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.so(_wrap_apr_terminate+0x50)[0x7fd4d6886920]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_entersub+0x571)[0x7fd4d876f821]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_runops_standard+0x16)[0x7fd4d8767e26]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_sv+0x3b0)[0x7fd4d86f93b0]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_list+0x2c7)[0x7fd4d86fb477]
/usr/lib/perl5/core_perl/CORE/libperl.so(perl_destruct+0x1321)[0x7fd4d86fca91]
/usr/bin/perl(main+0x111)[0x400e01]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fd4d8322a15]
/usr/bin/perl[0x400e71]
Can you check if your version of the perl subversion bindings were
compiled against the perl and subversion versions that you have
installed?
Perl -- as an interpreted language -- is mostly supposed to be safe from
such segfaults, and since git-svn is pure perl, the likely culprit is in
the bindings or the svn libraries. And the easiest way to get that to
break is a version mismatch.
--
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
[PATCH v2 1/2] apply, entry: speak of submodules instead of subprojects
There are only four (with some generous rounding) instances in the
current source code where we speak of subproject instead of
submodule. They are as follows:
* one error message in git-apply and two in entry.c
* the patch format for submodule changes
The latter was introduced in 0478675 (Expose subprojects as special
files to git diff machinery, 2007-04-15), apparently before the
terminology was settled. We can of course not change the patch
format.
Let's at least change the error messages to consistently call them
submodule.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/apply.c | 2 +-
entry.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 0e9b631..f1d4cc9 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3847,7 +3847,7 @@ static void add_index_file(const char *path, unsigned
mode, void *buf, unsigned
const char *s = buf;
if (get_sha1_hex(s + strlen(Subproject commit ), ce-sha1))
- die(_(corrupt patch for subproject %s), path);
+ die(_(corrupt patch for submodule %s), path);
} else {
if (!cached) {
if (lstat(path, st) 0)
diff --git a/entry.c b/entry.c
index d7c131d..6af4b6a 100644
--- a/entry.c
+++ b/entry.c
@@ -199,9 +199,9 @@ static int write_entry(struct cache_entry *ce, char *path,
const struct checkout
break;
case S_IFGITLINK:
if (to_tempfile)
- return error(cannot create temporary subproject %s,
path);
+ return error(cannot create temporary submodule %s,
path);
if (mkdir(path, 0777) 0)
- return error(cannot create subproject directory %s,
path);
+ return error(cannot create submodule directory %s,
path);
break;
default:
return error(unknown file mode for %s in index, path);
--
1.8.3.3.1053.g4beaad1
--
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] show-branch: fix description of --date-order
The existing description reads as if it somehow applies a filter.
Change it to explain that it is merely about the ordering.
Message-proposed-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
builtin/show-branch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 99ec4af..9788eb1 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -673,8 +673,8 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
OPT_SET_INT(0, sparse, dense,
N_(show merges reachable from only one tip), 0),
OPT_SET_INT(0, date-order, sort_order,
- N_(show commits where no parent comes before its
- children),
+ N_(topologically sort, maintaining date order
+ where possible),
REV_SORT_BY_COMMIT_DATE),
{ OPTION_CALLBACK, 'g', reflog, reflog_base,
N_(n[,base]),
N_(show n most recent ref-log entries starting
at
--
1.8.3.3.1053.g4beaad1
--
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] git_mkstemps: correctly test return value of open()
I presume that I should apply this change to my porting of git_mkstemps_mode() to tig. If there are no complaints about this for a couple of days I will do so. REF: $gmane/229961 On 07/17/2013 03:29 PM, Junio C Hamano wrote: Thomas Rasttr...@inf.ethz.ch writes: Thomas Rasttr...@inf.ethz.ch writes: From: Dale R. Worleywor...@alum.mit.edu open() returns -1 on failure, and indeed 0 is a possible success value if the user closed stdin in our process. Fix the test. Signed-off-by: Thomas Rasttr...@inf.ethz.ch wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wrapper.c b/wrapper.c index dd7ecbb..6a015de 100644 --- a/wrapper.c +++ b/wrapper.c @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode) template[5] = letters[v % num_letters]; v /= num_letters; fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd 0) + if (fd= 0) return fd; /* * Fatal error (EPERM, ENOSPC etc). -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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 svn exits with error error closing pipe: Bad file descriptor
After upgrade to subversion 1.8.0 on some repositories
git svn clone shows two warnings:
error closing pipe: Bad file descriptor at
/home/users/kornet/giti/libexec/git-core/git-svn line 0.
at exit. They appear because process git cat-file --batch exits before
command_close_bidi_pipe is called by destructor during perl exit. The
solution is to call the destructor explicitly, e.q.:
index ff1ce3d..6811738 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2068,6 +2068,10 @@ sub gc_directory {
}
}
+END {
+undef $_repository;
+}
+
__END__
Data structures:
However I'm not sure whether it is not a symptom of some other error.
What's confuses me more is that the warnings don't appear for all
repositories. For example they appear for http://svn.pld-linux.org/svn/cdpl/
while cloning http://svn.pld-linux.org/svn/atob ends normally.
On the other hand it is consistent between two different machines with
different Linux distributions and perl versions.
--
Kacper Kornet
--
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] TIG: Fix to reinstate proper operation with no arguments
Somehow this patch breaks the main view to not open the correct commit
in diff view when enter is pressed. Back to the debugger...
On 07/18/2013 12:51 AM, Drew Northup wrote:
Since c7d67ab running tig with no options has failed with the
error tig: No revisions match the given arguments. This was due
to a change in how the arguments for the back-end git call was
being constructed. This change caused the blank field left in
place of (encoding_arg) when it is empty to not overwrite
buf which then caused the value in buf to be copied into
dst_argv twice. The resulting git command failed if there was no
available revision named log as shown in the trace.
From the TIG_TRACE log:
git log log --no-color --pretty=raw --parents --parents --
fatal: bad revision 'log'
This fix works by teaching tig that when it is supplied with a
blank field in the source argument buffer that it should skip
over that field and continue instead of copying the previous
field value into the destination buffer a second time.
github issue # 167
Signed-off-by: Drew Northupn1xim.em...@gmail.com
---
This should apply cleanly to the tig public master whether the
mkstemps() patch I wrote has been applied or not.
tig.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tig.c b/tig.c
index ba9ba98..1016cfe 100644
--- a/tig.c
+++ b/tig.c
@@ -3105,10 +3105,11 @@ static bool
format_append_arg(struct format_context *format, const char ***dst_argv,
const char *arg)
{
format-bufpos = 0;
+ int len = 0;
while (arg) {
char *next = strstr(arg, %();
- int len = next ? next - arg : strlen(arg);
+ len = next ? next - arg : strlen(arg);
if (len !string_format_from(format-buf,format-bufpos,
%.*s, len, arg))
return FALSE;
@@ -3119,7 +3120,11 @@ format_append_arg(struct format_context *format, const
char ***dst_argv, const c
arg = next ? strchr(next, ')') + 1 : NULL;
}
- return argv_append(dst_argv, format-buf);
+ if(len){
+ return argv_append(dst_argv, format-buf);
+ } else {
+ return TRUE;
+ }
}
static bool
--
--
-Drew Northup
--
As opposed to vegetable or mineral error?
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
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 counterpart to SVN bugtraq properties?
On 17.07.2013 15:33, John Keeping wrote: On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL or how to parse the bug ID from a commit message. AFAIU, there is nothing comparable for Git [2]? If that's actually the case, is someone interested in working out a similar specification for Git? [1] http://code.google.com/p/tortoisesvn/source/browse/tags/version_1.2.0/doc/issuetrackers.txt [2] http://stackoverflow.com/questions/17545548 The Git way to record the issue ID as a footer in the commit message. See for example [1]. Although I'm not aware of any standard for naming this footer. I wasn't aware of that and probably I'm not the only one. For instance, we are using JIRA and typical commit messages look like SG-1234: fix something More details on what has been fixed ... So the issues ID is present in the first line. This has the advantage that every GUI client will display it, as usually the short version of the commit message (which is used everywhere) reaches up to the first dot or LF. Hence it's pretty easy to display a hyperlink for the SG-1234 part. bugtraq properties allow to define whether the issue ID should be appended to the top or bottom of the commit message. So looks like such an option makes sense for Git as well. In terms of recording the URL and other data, I think you'd want a dotfile in the repository (perhaps .bugzilla). This shoudld probably be in the gitconfig format, like .gitmodules. Having such a file sounds reasonable for storing the defaults, though let's call it .bugtraq or have some other more general name. Similar to .gitmodules, it makes sense to have the actual properties stored in $GIT_DIR/config which can be initialized from this .bugtraq file. The arguments are the same as for submodules: URLs stored in .bugtraq might need to be changed, depending on the client location (firewall/proxy...). Or we could just have $GIT_DIR/config properties *optionally*, overriding the .bugtraq properties, as for most users the default configuration will work fine anyway. I think all it needs is to draw up a spec for the names of keys and format of their values, along with the format of footer(s) identifying issues associated with a commit and to persuade UI developers to support it... ;-) I'll try to compose something here. But I'm wondering how we could attract a couple of developers or users to join in this discussion? -Marc -- 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: require choice between rebase/merge on non-fast-forward pull
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
;;
+*)
+ # integrating with a single other history
+ merge_head=${merge_head% }
+ if test -z $rebase$no_ff$ff_only${squash#--no-squash}
+ test -n $orig_head
+ ! $(git merge-base --is-ancestor $orig_head $merge_head)
I think this needs to be:
! $(git merge-base --is-ancestor $orig_head $merge_head ||
git merge-base --is-ancestor $merge_head $orig_head)
in order to avoid printing the message when git pull does not fetch
any new changes and the user has some new commits.
--
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 tag output order is incorrect (IMHO)
I am posting here first time, so please excuse me if this is not right place to send something like this. Please check - http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order And also - https://github.com/gitlabhq/gitlabhq/issues/4565 IMHO git tag is expected to show tag-list ordered by versions. It may be case, that people do not follow same version numbering convention. Most people after x.9.x increment major version (that is why they may not be affected because of this) Another option like git tag --date-asc can be added which will print tags by creation date. (As long as people do not create backdated tag, this will work). Thanks, -Rahul-- 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 tag output order is incorrect (IMHO)
On Thu, Jul 18, 2013 at 10:27 PM, Rahul Bansal rahul.ban...@rtcamp.com wrote: I am posting here first time, so please excuse me if this is not right place to send something like this. Please check - http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order And also - https://github.com/gitlabhq/gitlabhq/issues/4565 IMHO git tag is expected to show tag-list ordered by versions. It may be case, that people do not follow same version numbering convention. Most people after x.9.x increment major version (that is why they may not be affected because of this) Another option like git tag --date-asc can be added which will print tags by creation date. (As long as people do not create backdated tag, this will work). Try git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags -- 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 tag output order is incorrect (IMHO)
On Thu, Jul 18, 2013 at 10:51 PM, Duy Nguyen pclo...@gmail.com wrote: Try git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags And I wondered why it did not seem right. Use this one instead git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags make it --sort=-taggerdate to reverse sort order. -- 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 tag output order is incorrect (IMHO)
Hi Day, I am aware of that command as well. I think `git tag` current default order is string-based sorting. I felt version-number based sorting and/or create-date based sorting will be more appropriate. -- Rahul Bansal | Founder CEO | rtCamp Solutions Pvt. Ltd. Skype: rahul286 | Twitter: @rahul286 | Web: http://rtcamp.com/ On Thu, Jul 18, 2013 at 9:21 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jul 18, 2013 at 10:27 PM, Rahul Bansal rahul.ban...@rtcamp.com wrote: I am posting here first time, so please excuse me if this is not right place to send something like this. Please check - http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order And also - https://github.com/gitlabhq/gitlabhq/issues/4565 IMHO git tag is expected to show tag-list ordered by versions. It may be case, that people do not follow same version numbering convention. Most people after x.9.x increment major version (that is why they may not be affected because of this) Another option like git tag --date-asc can be added which will print tags by creation date. (As long as people do not create backdated tag, this will work). Try git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags -- 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 tag output order is incorrect (IMHO)
Thanks again Duy. :-) Sorry for misspelling your name in earlier email. -- Rahul Bansal | Founder CEO | rtCamp Solutions Pvt. Ltd. Skype: rahul286 | Twitter: @rahul286 | Web: http://rtcamp.com/ On Thu, Jul 18, 2013 at 9:26 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jul 18, 2013 at 10:51 PM, Duy Nguyen pclo...@gmail.com wrote: Try git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags And I wondered why it did not seem right. Use this one instead git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags make it --sort=-taggerdate to reverse sort order. -- 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 tag output order is incorrect (IMHO)
On Thu, Jul 18, 2013 at 10:57 PM, Rahul Bansal rahul.ban...@rtcamp.com wrote: Hi Day, I am aware of that command as well. I think `git tag` current default order is string-based sorting. I felt version-number based sorting and/or create-date based sorting will be more appropriate. ok you mean the _default_ order? What about other non-version tags (even temporary ones just to mark something then removed)? -- 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] send-email: improve SSL certificate verification
Torsten Bögershausen tbo...@web.de writes:
I wasn't sure where to apply the patch, so I manually copy/paste it
on top of pu:
commit 6b1ca0f4d443ee8716857b871b0513ae85c9f112
Merge: bce90ab f351fcf
Thanks, t9001 passes on Mac OS X 10.6.
To be sure I didn't messed it up, please see the diff below.
When it shows up on pu, I can re-test of course.
As the history of rr/send-email-ssl-verify needs rewriting to squash
this change in, here is a single patch with which I would propose to
replace all the commits accumulated on that branch.
Ramkumar, as you will still be the primary author of the resulting
commit, I tentatively added a line for your sign-off even though you
haven't signed off _this_ version yet, so that I would not forget.
If this version looks good, please tell us you would.
Torsten, I have Tested-by with your name, again so that I would not
forget, but obviously this one hasn't been tested by you yet. If
this tests OK, please tell us so.
Thanks.
-- 8 --
From: Ramkumar Ramachandra artag...@gmail.com
Subject: send-email: be explicit with SSL certificate verification
When initiating an SSL connection without explicitly specifying the
SSL certificate verification mode, Net::SMTP::SSL defaults to no
verification, but recent versions of the module gives a warning
against this use of the default.
Enable certificate verification by default, using /etc/ssl/certs as
the default path for certificates of certificate authorities. This
path can be overriden by the --smtp-ssl-cert-path command line
option and the sendemail.smtpSSLCertPath configuration variable.
Passing an empty string as the path for CA certificates path disables
the SSL certificate verification explicitly, which does not trigger
the warning from recent versions of Net::SMTP::SSL.
(PROVISO) Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Helped-by: Brian M. Carlson sand...@crustytoothpaste.net
(PROVISO) Tested-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 4
Documentation/git-send-email.txt | 6 ++
git-send-email.perl | 41 +---
3 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53fc5..4de154c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2022,6 +2022,10 @@ sendemail.smtpencryption::
sendemail.smtpssl::
Deprecated alias for 'sendemail.smtpencryption = ssl'.
+sendemail.smtpsslcertpath::
+ Path to ca-certificates (either a directory or a single file).
+ Set it to an empty string to disable certificate verification.
+
sendemail.identity.*::
Identity-specific versions of the 'sendemail.*' parameters
found below, taking precedence over those when the this
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 40a9a9a..f0e57a5 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -198,6 +198,12 @@ must be used for each option.
--smtp-ssl::
Legacy alias for '--smtp-encryption ssl'.
+--smtp-ssl-cert-path::
+ Path to ca-certificates (either a directory or a single file).
+ Set it to an empty string to disable certificate verification.
+ Defaults to the value set to the 'sendemail.smtpsslcertpath'
+ configuration variable, if set, or `/etc/ssl/certs` otherwise.
+
--smtp-user=user::
Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser';
if a username is not specified (with '--smtp-user' or
'sendemail.smtpuser'),
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..60eaed3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -69,6 +69,9 @@ sub usage {
--smtp-pass str * Password for SMTP-AUTH; not necessary.
--smtp-encryption str * tls or ssl; anything else disables.
--smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
+--smtp-ssl-cert-pathstr * Path to ca-certificates (either directory
or file).
+ Pass an empty string to disable
certificate
+ verification.
--smtp-domain str * The domain name sent to HELO/EHLO
handshake
--smtp-debug0|1 * Disable, enable Net::SMTP debug.
@@ -194,7 +197,7 @@ sub do_edit {
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
my ($to_cmd, $cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
-my ($smtp_authuser, $smtp_encryption);
+my ($smtp_authuser, $smtp_encryption, $smtp_ssl_cert_path);
my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
my ($validate, $confirm);
my (@suppress_cc);
@@ -222,6 +225,7 @@ sub do_edit {
smtpserveroption = \@smtp_server_options,
smtpuser = \$smtp_authuser,
smtppass = \$smtp_authpass,
+smtpsslcertpath =
[PATCH v2 1/2] Documentation: remove --prune from pack-refs examples
The option has been the default for a while, and doesn't otherwise appear in the page. Signed-off-by: Jonathon Mah m...@jonathonmah.com --- Forgot sign-off in v1. Also, I was unsure whether to rewrap the lines (and if so, to how many columns); erred on the side of minimal changes. Documentation/git-pack-refs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index f131677..154081f 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -33,8 +33,8 @@ Subsequent updates to branches always create new files under `$GIT_DIR/refs` directory hierarchy. A recommended practice to deal with a repository with too many -refs is to pack its refs with `--all --prune` once, and -occasionally run `git pack-refs --prune`. Tags are by +refs is to pack its refs with `--all` once, and +occasionally run `git pack-refs`. Tags are by definition stationary and are not expected to change. Branch heads will be packed with the initial `pack-refs --all`, but only the currently active branch heads will become unpacked, -- 1.8.3.3.754.g9c3c367 Jonathon Mah m...@jonathonmah.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 v2 2/2] Documentation: fix git-prune example usage
Signed-off-by: Jonathon Mah m...@jonathonmah.com --- Documentation/git-prune.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 80d01b0..bf82410 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -59,7 +59,7 @@ borrows from your repository via its `.git/objects/info/alternates`: -$ git prune $(cd ../another $(git rev-parse --all)) +$ git prune $(cd ../another git rev-parse --all) Notes -- 1.8.3.3.754.g9c3c367 Jonathon Mah m...@jonathonmah.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 0/4] git-gui translation update
git-gui/lib/option.tcl |2 +- git-gui/po/git-gui.pot | 1057 git-gui/po/ja.po | 1147 ++-- 3 files changed, 1200 insertions(+), 1006 deletions(-) -- 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/4] Add Git-gui Translate (yes, no, ask)
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com
---
git-gui/lib/option.tcl | 2 +-
git-gui/po/git-gui.pot | 14 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/git-gui/lib/option.tcl b/git-gui/lib/option.tcl
index 0cf1da1..7af858c 100644
--- a/git-gui/lib/option.tcl
+++ b/git-gui/lib/option.tcl
@@ -158,7 +158,7 @@ proc do_options {} {
{t gui.newbranchtemplate {mc New Branch Name Template}}
{c gui.encoding {mc Default File Contents Encoding}}
{b gui.warndetachedcommit {mc Warn before committing to a
detached head}}
-{s gui.stageuntracked {mc Staging of untracked files} {list
yes no ask}}
+{s gui.stageuntracked {mc Staging of untracked files} {list
[mc yes] [mc no] [mc ask]}}
} {
set type [lindex $option 0]
set name [lindex $option 1]
diff --git a/git-gui/po/git-gui.pot b/git-gui/po/git-gui.pot
index 6ebfc94..35783ca 100644
--- a/git-gui/po/git-gui.pot
+++ b/git-gui/po/git-gui.pot
@@ -8,7 +8,7 @@ msgid
msgstr
Project-Id-Version: PACKAGE VERSION\n
Report-Msgid-Bugs-To: \n
-POT-Creation-Date: 2013-07-10 02:45+0900\n
+POT-Creation-Date: 2013-07-10 03:27+0900\n
PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n
Last-Translator: FULL NAME EMAIL@ADDRESS\n
Language-Team: LANGUAGE l...@li.org\n
@@ -1982,6 +1982,18 @@ msgstr
msgid Staging of untracked files
msgstr
+#: lib/option.tcl:161
+msgid yes
+msgstr
+
+#: lib/option.tcl:161
+msgid no
+msgstr
+
+#: lib/option.tcl:161
+msgid ask
+msgstr
+
#: lib/option.tcl:207
msgid Change
msgstr
--
1.8.1.msysgit.1
--
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 4/4] Update Japanese translation (Git-gui)
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com --- git-gui/po/ja.po | 153 ++- 1 file changed, 73 insertions(+), 80 deletions(-) diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po index 0bbe504..05215b9 100644 --- a/git-gui/po/ja.po +++ b/git-gui/po/ja.po @@ -7,14 +7,17 @@ msgid msgstr Project-Id-Version: git-gui\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2013-07-10 02:45+0900\n +POT-Creation-Date: 2013-07-10 03:38+0900\n PO-Revision-Date: 2010-02-02 19:03+0900\n -Last-Translator: しらいし ななこ nana...@lavabit.com\n +Last-Translator: しらいし ななこ nana...@lavabit.com, Yamada Saburo devil.tamac...@gmail.com\n Language-Team: Japanese\n Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n +Plural-Forms: nplurals=1; plural=0;\n +X-Language: ja_JP\n +X-Source-Language: C\n #: git-gui.sh:859 #, tcl-format @@ -29,8 +32,8 @@ msgstr 主フォント msgid Diff/Console Font msgstr diff/コンソール・フォント -#: git-gui.sh:926 git-gui.sh:940 git-gui.sh:953 git-gui.sh:1043 -#: git-gui.sh:1062 git-gui.sh:3094 +#: git-gui.sh:926 git-gui.sh:940 git-gui.sh:953 git-gui.sh:1043 git-gui.sh:1062 +#: git-gui.sh:3094 msgid git-gui: fatal error msgstr git-gui: 致命的なエラー @@ -124,26 +127,23 @@ msgstr コミット予定済、ファイル無し #: git-gui.sh:2087 msgid File type changed, not staged -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット未予定 #: git-gui.sh:2088 git-gui.sh:2089 -#, fuzzy msgid File type changed, old type staged for commit -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット予定の形式が古い #: git-gui.sh:2090 msgid File type changed, staged -msgstr ファイル型変更、コミット予定済 +msgstr ファイルタイプ変更、コミット予定済 #: git-gui.sh:2091 -#, fuzzy msgid File type change staged, modification not staged -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプの変更はコミット予定済、内容の変更はコミット未予定 #: git-gui.sh:2092 -#, fuzzy msgid File type change staged, file missing -msgstr ファイル型変更、コミット予定済 +msgstr ファイルタイプの変更はコミット予定済、ファイルが見つからない #: git-gui.sh:2094 msgid Untracked, not staged @@ -403,19 +403,16 @@ msgstr SSH キーを表示 #: git-gui.sh:2983 git-gui.sh:3115 msgid Usage -msgstr +msgstr 使用状況 #: git-gui.sh:3064 lib/blame.tcl:573 -#, fuzzy msgid Error msgstr エラー #: git-gui.sh:3095 #, tcl-format msgid fatal: cannot stat path %s: No such file or directory -msgstr -致命的: パス %s が stat できません。そのようなファイルやディレクトリはありま -せん +msgstr 致命的: パス %s が stat できません。そのようなファイルやディレクトリはありません #: git-gui.sh:3128 msgid Current Branch: @@ -614,9 +611,8 @@ msgid Find Text... msgstr テキストを検索 #: lib/blame.tcl:288 -#, fuzzy msgid Goto Line... -msgstr 複製… +msgstr 指定行へ移動 #: lib/blame.tcl:297 msgid Do Full Copy Detection @@ -715,12 +711,11 @@ msgstr ブランチをチェックアウト msgid Checkout msgstr チェックアウト -#: lib/branch_checkout.tcl:30 lib/branch_create.tcl:37 -#: lib/branch_delete.tcl:34 lib/branch_rename.tcl:32 lib/browser.tcl:292 -#: lib/checkout_op.tcl:579 lib/choose_font.tcl:45 lib/merge.tcl:174 -#: lib/option.tcl:127 lib/remote_add.tcl:34 lib/remote_branch_delete.tcl:43 -#: lib/tools_dlg.tcl:41 lib/tools_dlg.tcl:202 lib/tools_dlg.tcl:345 -#: lib/transport.tcl:141 +#: lib/branch_checkout.tcl:30 lib/branch_create.tcl:37 lib/branch_delete.tcl:34 +#: lib/branch_rename.tcl:32 lib/browser.tcl:292 lib/checkout_op.tcl:579 +#: lib/choose_font.tcl:45 lib/merge.tcl:174 lib/option.tcl:127 +#: lib/remote_add.tcl:34 lib/remote_branch_delete.tcl:43 lib/tools_dlg.tcl:41 +#: lib/tools_dlg.tcl:202 lib/tools_dlg.tcl:345 lib/transport.tcl:141 msgid Cancel msgstr 中止 @@ -970,8 +965,7 @@ msgid msgstr 最後にスキャンした状態はリポジトリの状態と合致しません。\n \n -最後にスキャンして以後、別の Git プログラムがリポジトリを変更しています。現在 -のブランチを変更する前に、再スキャンが必要です。\n +最後にスキャンして以後、別の Git プログラムがリポジトリを変更しています。現在のブランチを変更する前に、再スキャンが必要です。\n \n 自動的に再スキャンを開始します。\n @@ -1007,8 +1001,7 @@ msgid msgstr ローカル・ブランチから離れます。\n \n -ブランチ上に滞まりたいときは、この「分離されたチェックアウト」から新規ブラン -チを開始してください。 +ブランチ上に滞まりたいときは、この「分離されたチェックアウト」から新規ブランチを開始してください。 #: lib/checkout_op.tcl:503 lib/checkout_op.tcl:507 #, tcl-format @@ -1045,8 +1038,7 @@ msgid msgstr 現在のブランチを設定できません。\n \n -作業ディレクトリは部分的にしか切り替わっていません。ファイルの更新には成功し -ましたが、 Git の内部データを更新できませんでした。\n +作業ディレクトリは部分的にしか切り替わっていません。ファイルの更新には成功しましたが、 Git の内部データを更新できませんでした。\n 起こるはずのないエラーです。あきらめて %s を終了します。 #: lib/choose_font.tcl:41 @@ -1350,8 +1342,7 @@ msgid msgstr 訂正するコミットがそもそもありません。\n \n -これから作るのは最初のコミットです。その前にはまだ訂正するようなコミットはあ -りません。\n +これから作るのは最初のコミットです。その前にはまだ訂正するようなコミットはありません。\n #: lib/commit.tcl:18 msgid @@ -1363,8 +1354,7 @@ msgid msgstr マージ中にコミットの訂正はできません。\n \n -現在はまだマージの途中です。先にこのマージを中止しないと、前のコミットの訂正 -はできません\n +現在はまだマージの途中です。先にこのマージを中止しないと、前のコミットの訂正はできません\n #: lib/commit.tcl:48 msgid Error loading commit data for amend: @@ -1394,8 +1384,7 @@ msgid msgstr 最後にスキャンした状態はリポジトリの状態と合致しません。\n \n -最後にスキャンして以後、別の Git プログラムがリポジトリを変更しています。新し -くコミットする前に、再スキャンが必要です。\n +最後にスキャンして以後、別の Git プログラムがリポジトリを変更しています。新しくコミットする前に、再スキャンが必要です。\n \n 自動的に再スキャンを開始します。\n @@ -1409,8 +1398,7 @@ msgid msgstr マージしていないファイルはコミットできません。\n \n -ファイル %s にはマージ衝突が残っています。まず解決してコミット予定に加える必
[PATCH 1/4] Update git-gui/po/git-gui.pot
Signed-off-by: Yamada Saburo devil.tamac...@gmail.com --- git-gui/po/git-gui.pot | 1045 ++-- 1 file changed, 567 insertions(+), 478 deletions(-) diff --git a/git-gui/po/git-gui.pot b/git-gui/po/git-gui.pot index 0c94f9c..6ebfc94 100644 --- a/git-gui/po/git-gui.pot +++ b/git-gui/po/git-gui.pot @@ -8,41 +8,42 @@ msgid msgstr Project-Id-Version: PACKAGE VERSION\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2010-01-26 15:47-0800\n +POT-Creation-Date: 2013-07-10 02:45+0900\n PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n Last-Translator: FULL NAME EMAIL@ADDRESS\n Language-Team: LANGUAGE l...@li.org\n +Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=CHARSET\n Content-Transfer-Encoding: 8bit\n -#: git-gui.sh:41 git-gui.sh:793 git-gui.sh:807 git-gui.sh:820 git-gui.sh:903 -#: git-gui.sh:922 -msgid git-gui: fatal error -msgstr - -#: git-gui.sh:743 +#: git-gui.sh:859 #, tcl-format msgid Invalid font specified in %s: msgstr -#: git-gui.sh:779 +#: git-gui.sh:911 msgid Main Font msgstr -#: git-gui.sh:780 +#: git-gui.sh:912 msgid Diff/Console Font msgstr -#: git-gui.sh:794 +#: git-gui.sh:926 git-gui.sh:940 git-gui.sh:953 git-gui.sh:1043 +#: git-gui.sh:1062 git-gui.sh:3094 +msgid git-gui: fatal error +msgstr + +#: git-gui.sh:927 msgid Cannot find git in PATH. msgstr -#: git-gui.sh:821 +#: git-gui.sh:954 msgid Cannot parse Git version string: msgstr -#: git-gui.sh:839 +#: git-gui.sh:979 #, tcl-format msgid Git version cannot be determined.\n @@ -54,473 +55,493 @@ msgid Assume '%s' is version 1.5.0?\n msgstr -#: git-gui.sh:1128 +#: git-gui.sh:1276 msgid Git directory not found: msgstr -#: git-gui.sh:1146 +#: git-gui.sh:1306 msgid Cannot move to top of working directory: msgstr -#: git-gui.sh:1154 +#: git-gui.sh:1314 msgid Cannot use bare repository: msgstr -#: git-gui.sh:1162 +#: git-gui.sh:1322 msgid No working directory msgstr -#: git-gui.sh:1334 lib/checkout_op.tcl:306 +#: git-gui.sh:1494 lib/checkout_op.tcl:306 msgid Refreshing file status... msgstr -#: git-gui.sh:1390 +#: git-gui.sh:1554 msgid Scanning for modified files ... msgstr -#: git-gui.sh:1454 +#: git-gui.sh:1621 msgid Calling prepare-commit-msg hook... msgstr -#: git-gui.sh:1471 +#: git-gui.sh:1638 msgid Commit declined by prepare-commit-msg hook. msgstr -#: git-gui.sh:1629 lib/browser.tcl:246 +#: git-gui.sh:1796 lib/browser.tcl:252 msgid Ready. msgstr -#: git-gui.sh:1787 +#: git-gui.sh:1954 #, tcl-format msgid Displaying only %s of %s files. msgstr -#: git-gui.sh:1913 +#: git-gui.sh:2080 msgid Unmodified msgstr -#: git-gui.sh:1915 +#: git-gui.sh:2082 msgid Modified, not staged msgstr -#: git-gui.sh:1916 git-gui.sh:1924 +#: git-gui.sh:2083 git-gui.sh:2095 msgid Staged for commit msgstr -#: git-gui.sh:1917 git-gui.sh:1925 +#: git-gui.sh:2084 git-gui.sh:2096 msgid Portions staged for commit msgstr -#: git-gui.sh:1918 git-gui.sh:1926 +#: git-gui.sh:2085 git-gui.sh:2097 msgid Staged for commit, missing msgstr -#: git-gui.sh:1920 +#: git-gui.sh:2087 msgid File type changed, not staged msgstr -#: git-gui.sh:1921 +#: git-gui.sh:2088 git-gui.sh:2089 +msgid File type changed, old type staged for commit +msgstr + +#: git-gui.sh:2090 msgid File type changed, staged msgstr -#: git-gui.sh:1923 +#: git-gui.sh:2091 +msgid File type change staged, modification not staged +msgstr + +#: git-gui.sh:2092 +msgid File type change staged, file missing +msgstr + +#: git-gui.sh:2094 msgid Untracked, not staged msgstr -#: git-gui.sh:1928 +#: git-gui.sh:2099 msgid Missing msgstr -#: git-gui.sh:1929 +#: git-gui.sh:2100 msgid Staged for removal msgstr -#: git-gui.sh:1930 +#: git-gui.sh:2101 msgid Staged for removal, still present msgstr -#: git-gui.sh:1932 git-gui.sh:1933 git-gui.sh:1934 git-gui.sh:1935 -#: git-gui.sh:1936 git-gui.sh:1937 +#: git-gui.sh:2103 git-gui.sh:2104 git-gui.sh:2105 git-gui.sh:2106 +#: git-gui.sh:2107 git-gui.sh:2108 msgid Requires merge resolution msgstr -#: git-gui.sh:1972 +#: git-gui.sh:2143 msgid Starting gitk... please wait... msgstr -#: git-gui.sh:1984 +#: git-gui.sh:2155 msgid Couldn't find gitk in PATH msgstr -#: git-gui.sh:2043 +#: git-gui.sh:2214 msgid Couldn't find git gui in PATH msgstr -#: git-gui.sh:2455 lib/choose_repository.tcl:36 +#: git-gui.sh:2633 lib/choose_repository.tcl:36 msgid Repository msgstr -#: git-gui.sh:2456 +#: git-gui.sh:2634 msgid Edit msgstr -#: git-gui.sh:2458 lib/choose_rev.tcl:561 +#: git-gui.sh:2636 lib/choose_rev.tcl:567 msgid Branch msgstr -#: git-gui.sh:2461 lib/choose_rev.tcl:548 +#: git-gui.sh:2639 lib/choose_rev.tcl:554 msgid Commit@@noun msgstr -#: git-gui.sh:2464 lib/merge.tcl:121 lib/merge.tcl:150 lib/merge.tcl:168 +#: git-gui.sh:2642 lib/merge.tcl:123 lib/merge.tcl:152 lib/merge.tcl:170 msgid Merge msgstr -#: git-gui.sh:2465 lib/choose_rev.tcl:557 +#: git-gui.sh:2643 lib/choose_rev.tcl:563
Re: Re* [PATCH] send-email: improve SSL certificate verification
Junio C Hamano wrote: Ramkumar, as you will still be the primary author of the resulting commit, I tentatively added a line for your sign-off even though you haven't signed off _this_ version yet, so that I would not forget. If this version looks good, please tell us you would. Yeah, it seems to work fine for me. Sign-off is fine. Thanks for putting it together. -- 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: require choice between rebase/merge on non-fast-forward pull
John Keeping j...@keeping.me.uk writes:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
;;
+*)
+# integrating with a single other history
+merge_head=${merge_head% }
+if test -z $rebase$no_ff$ff_only${squash#--no-squash}
+test -n $orig_head
+! $(git merge-base --is-ancestor $orig_head $merge_head)
I think this needs to be:
! $(git merge-base --is-ancestor $orig_head $merge_head ||
git merge-base --is-ancestor $merge_head $orig_head)
Neither makes sense. You want to check the exit status of git
merge-base --is-ancestor, not execute its (empty) output as a command.
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 tag output order is incorrect (IMHO)
Rahul Bansal rahul.ban...@rtcamp.com writes: IMHO git tag is expected to show tag-list ordered by versions. A git tag can be anything, not related to versions at all. 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: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
Mark Levedahl mleved...@gmail.com writes: Cygwin 1.7 is very different than the earlier, no longer supported, and no longer available Cygwin variants in many ways, but stat is one of them. Cygwin 1.7 uses Windows ACLs to represent file permissions, and therefore gets the file permissions directly from the underlying OS calls. Earlier Cygwin versions (attempted to) overlay POSIX permissions on Windows systems using extended attributes and other means, and in many cases had to resort to opening the file and examining it to determine executability. This is not true in 1.7. Therefore, your later patch would be expected to have much less benefit for 1.7 than for 1.5 (I don't detect *any* benefit on 1.7 when I set core.filemode=false). There are many choices, three are: a) Remove the win32 stat funcs, eliminating all of the troublesome code paths and maintenance burden (your original patch). b) Add your latest patch, with attendant complexity and maintenance burden, to support a version of Cygwin that is no longer available and was last updated over four years ago. c) Like b, except make this triggered only by a CYGWIN_15 macro, limiting this to use by the legacy cygwin platform. Let's do (a) in a single patch, then. People who do want to keep running older Cygwin installation they already have can revert the removal and rebuild Git, but the number of people who have to do so will become only smaller over time if older Cygwin versions are no longer available. I presume that we _could_ add a CYGWIN_15 macro that conditionally keeps the win32 lstat implementation and get_st_mode_bits() part, and that might make it easier for folks with older Cygwin installations, but I am not sure if it is worth it. I strongly vote for a, could support c, but fear b is just going to keep us chasing down bugs. Especially so when we consider that this patch can only speed things up when core.filemode=false, which mode: a) causes git to fail its test suite. b) breaks compatibility with Linux c) violates the primary goal of the Cygwin project, which is to provide a Linux environment on Windows. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk: Show origin of this line triggered programatically
The Show origin of this line context menu command on a line in a patch
in gitk is by far my most frequently used way of navigating back in
history. It's so much faster than git gui blame.
Now, I wish it were available right from my text editor, showing me the
origin of the line under the cursor when working with code.
In fact, it is; I have been using this feature in a roughly hacked way
for a couple of months now, and I don't want to miss it any more. Most
of my co-workers are jealous when they see it.
I'd like to get it into gitk for real now, and I need some guidance on
the best way to implement it.
I can see two ways:
1) Add an option like '--show-origin=foo.cpp:25'. This would run
git blame on the given line in the working copy, and highlight the
result.
2) Add an option like '--select-file=foo.cpp:25'. This would be used in
combination with the existing --select-commit option to simply
highlight a given line in the patch (so the caller needs to do the
initial git blame himself).
There are pros and cons to both. 1) is certainly easier to use from a
text editor scripter's point of view (a simple one-liner in most cases),
whereas 2) probably needs a glue script to run the initial git blame. On
the other hand, that glue script could also take care of restricting the
history to a week or so forward from the target commit, which makes gitk
load much faster. Also, 2) could be used from git gui blame's Show
history context command, which currently only selects the commit but
can't highlight the line.
So I think I'd lean towards option 2). Below is the prototype that I
have been using; not sure how buggy it is. If we go this route, one
question would be whether we want to ship the glue script too, and how.
Any opinions?
-Stefan
From 80acb168ef13a55521e9b821450800450660769d Mon Sep 17 00:00:00 2001
From: Stefan Haller ste...@haller-berlin.de
Date: Thu, 18 Jul 2013 18:55:11 +0200
Subject: [PATCH] gitk: Add options --select-file and --select-line
These can be used in combination with --select-commit to jump to a given
line in a patch. This can be useful for scripting your text editor to bring
up gitk showing you the place in the history that last modified the line
you are on.
For example, given this little glue script, saved as show_line_in_gitk.rb
somewhere in your path:
#!/usr/bin/env ruby
if ARGV.length != 2
puts Usage: #{$0} file line
exit 1
end
file, line = ARGV
blame_output = `git blame -p -L#{line},+1 #{file}`
exit 1 if $?.exitstatus != 0
blame_output_lines = blame_output.split(\n)
commit, line = blame_output_lines[0].split
file = blame_output_lines.grep(/^filename /)[0][9..-1]
date = blame_output_lines.grep(/^committer-time /)[0][15..-1]
datestr = Time.at(date.to_i + 60 * 60 * 24 * 7).to_s
system gitk --before='#{datestr}' \
--select-commit=#{commit} \
--select-file='#{file}' \
--select-line=#{line}
you could add this function to your .vimrc:
function! ShowLineInGitk()
execute !show_line_in_gitk.rb . expand(%p) . . line(.)
endfunction
and map it to a key.
---
gitk | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 5cd00d8..318a484 100755
--- a/gitk
+++ b/gitk
@@ -464,12 +464,17 @@ proc stop_rev_list {view} {
}
proc reset_pending_select {selid} {
-global pending_select mainheadid selectheadid
+global pending_select pending_select_file pending_select_line
+global mainheadid selectheadid selectfile select_line
if {$selid ne {}} {
set pending_select $selid
} elseif {$selectheadid ne {}} {
set pending_select $selectheadid
+ if {$selectfile ne {}} {
+ set pending_select_file $selectfile
+ set pending_select_line $select_line
+ }
} else {
set pending_select $mainheadid
}
@@ -1597,6 +1602,17 @@ proc getcommitlines {fd inst view updating} {
return 2
}
+proc select_pending_line {} {
+global pending_select pending_select_file pending_select_line
+
+if {[info exists pending_select_file]} {
+ selectline [rowofcommit $pending_select] 1 \
+ [list $pending_select_file $pending_select_line]
+} else {
+ selectline [rowofcommit $pending_select] 1
+}
+}
+
proc chewcommits {} {
global curview hlview viewcomplete
global pending_select
@@ -1611,7 +1627,7 @@ proc chewcommits {} {
reset_pending_select {}
if {[commitinview $pending_select $curview]} {
- selectline [rowofcommit $pending_select] 1
+ select_pending_line
} else {
set row [first_real_row]
selectline $row 1
@@ -5083,7 +5099,7 @@ proc layoutmore {} {
if {[info exists pending_select]
[commitinview $pending_select
Re: [PATCH 5/6] blame-options.txt: place each -L option variation on its own line
Thomas Rast t...@thomasrast.ch writes: Eric Sunshine sunsh...@sunshineco.com writes: Standard practice in Git documentation is for each variation of an option (such as: -p / --porcelain) to be placed on its own line in the OPTIONS table. The -L option does not follow suit. It cuddles -L start,end and -L :regex, separated by a comma. This is inconsistent and potentially confusing since the comma separating them is typeset the same as the comma in start,end. Fix this by placing each variation on its own line. Ok, but why not fix them all in one go? Edited to remove the false positives: $ git grep -n '^.*,.*::$' Documentation/*.txt Documentation/blame-options.txt:12:-L start,end, -L :regex:: Documentation/config.txt:1252:gitcvs.dbuser, gitcvs.dbpass:: Documentation/config.txt:1513:http.lowSpeedLimit, http.lowSpeedTime:: Documentation/git-add.txt:90:-e, \--edit:: Documentation/git-check-attr.txt:22:-a, --all:: Documentation/git-check-ignore.txt:26:-q, --quiet:: Documentation/git-check-ignore.txt:30:-v, --verbose:: Documentation/git-check-ignore.txt:42:-n, --non-matching:: Documentation/git-log.txt:65:-L start,end:file, -L :regex:file:: Documentation/git-log.txt:156:git log -L '/int main/',/^}/:main.c:: Documentation/git-p4.txt:171:--verbose, -v:: Documentation/git-p4.txt:282:--dry-run, -n:: Thanks, but I think it is cleaner to fix the others in a separate treewide clean-up patch. Also I wonder if this one Documentation/git-log.txt:156 git log -L '/int main/',/^}/:main.c should be more like one of these: git log -L '/int main/,/^}/':main.c git log -L '/int main/,/^}/:main.c' I find it somewhat hard to spot the closing sq in the middle of a string. -- 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] git_mkstemps: correctly test return value of open()
Drew Northup n1xim.em...@gmail.com writes: I presume that I should apply this change to my porting of git_mkstemps_mode() to tig. If there are no complaints about this for a couple of days I will do so. Hmph, Thomas and I were actually asking you to give us Signed-off-by: Drew Northup n1xim.em...@gmail.com for the patch in question. If tig has the same issue, applying that same patch there may make sense, but that is an independent issue. Thanks. REF: $gmane/229961 On 07/17/2013 03:29 PM, Junio C Hamano wrote: Thomas Rasttr...@inf.ethz.ch writes: Thomas Rasttr...@inf.ethz.ch writes: From: Dale R. Worleywor...@alum.mit.edu open() returns -1 on failure, and indeed 0 is a possible success value if the user closed stdin in our process. Fix the test. Signed-off-by: Thomas Rasttr...@inf.ethz.ch wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wrapper.c b/wrapper.c index dd7ecbb..6a015de 100644 --- a/wrapper.c +++ b/wrapper.c @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode) template[5] = letters[v % num_letters]; v /= num_letters; fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd 0) + if (fd= 0) return fd; /* * Fatal error (EPERM, ENOSPC etc). -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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] git_mkstemps: correctly test return value of open()
Junio C Hamano gits...@pobox.com writes: Drew Northup n1xim.em...@gmail.com writes: I presume that I should apply this change to my porting of git_mkstemps_mode() to tig. If there are no complaints about this for a couple of days I will do so. Hmph, Thomas and I were actually asking you to give us Signed-off-by: Drew Northup n1xim.em...@gmail.com Gaahhh, I need a bit more caffeine. Somehow I mixed up Dale and Drew. Sorry for the noise. Please ignore. for the patch in question. If tig has the same issue, applying that same patch there may make sense, but that is an independent issue. Thanks. REF: $gmane/229961 On 07/17/2013 03:29 PM, Junio C Hamano wrote: Thomas Rasttr...@inf.ethz.ch writes: Thomas Rasttr...@inf.ethz.ch writes: From: Dale R. Worleywor...@alum.mit.edu open() returns -1 on failure, and indeed 0 is a possible success value if the user closed stdin in our process. Fix the test. Signed-off-by: Thomas Rasttr...@inf.ethz.ch wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wrapper.c b/wrapper.c index dd7ecbb..6a015de 100644 --- a/wrapper.c +++ b/wrapper.c @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode) template[5] = letters[v % num_letters]; v /= num_letters; fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd 0) + if (fd= 0) return fd; /* * Fatal error (EPERM, ENOSPC etc). -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: require choice between rebase/merge on non-fast-forward pull
Andreas Schwab sch...@linux-m68k.org writes:
John Keeping j...@keeping.me.uk writes:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
;;
+*)
+ # integrating with a single other history
+ merge_head=${merge_head% }
+ if test -z $rebase$no_ff$ff_only${squash#--no-squash}
+ test -n $orig_head
+ ! $(git merge-base --is-ancestor $orig_head $merge_head)
I think this needs to be:
! $(git merge-base --is-ancestor $orig_head $merge_head ||
git merge-base --is-ancestor $merge_head $orig_head)
Neither makes sense. You want to check the exit status of git
merge-base --is-ancestor, not execute its (empty) output as a command.
Gaah. You are right.
Thanks for spotting.
--
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 1/2] Documentation: remove --prune from pack-refs examples
Jonathon Mah m...@jonathonmah.com writes: The option has been the default for a while, and doesn't otherwise appear in the page. Signed-off-by: Jonathon Mah m...@jonathonmah.com --- Forgot sign-off in v1. Also, I was unsure whether to rewrap the lines (and if so, to how many columns); erred on the side of minimal changes. Thanks. Documentation/git-pack-refs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index f131677..154081f 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -33,8 +33,8 @@ Subsequent updates to branches always create new files under `$GIT_DIR/refs` directory hierarchy. A recommended practice to deal with a repository with too many -refs is to pack its refs with `--all --prune` once, and -occasionally run `git pack-refs --prune`. Tags are by +refs is to pack its refs with `--all` once, and +occasionally run `git pack-refs`. Tags are by definition stationary and are not expected to change. Branch heads will be packed with the initial `pack-refs --all`, but only the currently active branch heads will become unpacked, -- 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/4] Update git-gui/po/ja.po (Git-gui Japanese)
悪魔野玉茶無 devil.tamac...@gmail.com writes: I suspect that is not a name (and I somehow have suspicion that the S-o-b is not real, either), but if you send patches as somebody that does not match your sign-off, please add From: Yamada Saburo devil.tamac...@gmail.com followed by a blank line at the very beginning of the e-mail body. That will override the e-mail From: line your MUA puts in your message and record the commit as authored by Yamada Saburo. Signed-off-by: Yamada Saburo devil.tamac...@gmail.com --- Thanks. git-gui/po/ja.po | 1066 +- 1 file changed, 583 insertions(+), 483 deletions(-) diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po index 9aff249..0bbe504 100644 --- a/git-gui/po/ja.po +++ b/git-gui/po/ja.po @@ -7,41 +7,42 @@ msgid msgstr Project-Id-Version: git-gui\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2010-01-26 15:47-0800\n +POT-Creation-Date: 2013-07-10 02:45+0900\n PO-Revision-Date: 2010-02-02 19:03+0900\n Last-Translator: しらいし ななこ nana...@lavabit.com\n 山田三郎 would be the last translater, no? Language-Team: Japanese\n +Language: \n What is this about MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n -#: git-gui.sh:1921 +#: git-gui.sh:2088 git-gui.sh:2089 +#, fuzzy +msgid File type changed, old type staged for commit +msgstr ファイル型変更、コミット未予定 If this is no longer fuzzy, please resolve it by removing #, fuzzy marker. Also, this translation seems to be incomplete. It may be OK for some strings (e.g. RegExp that seems to be a label of a checkbox or something) to be the same as the original, but some others may need a bit more work. I wonder if there is a mechanism in *.po files to differentiate between I looked at this entry and using the original string as the template is fine and I didn't translate this string, but it should be. I think the following entries seem to fall into the latter category. -#: lib/commit.tcl:272 +#: lib/commit.tcl:269 +msgid +You are about to commit on a detached head. This is a potentially dangerous +thing to do because if you switch to another branch you will lose your +changes and it can be difficult to retrieve them later from the reflog. You +should probably cancel this commit and create a new branch to continue.\n + \n + Do you really want to proceed with your Commit? +msgstr No translation??? -#: lib/index.tcl:398 +#: lib/index.tcl:380 +#, tcl-format +msgid Stage %d untracked files? +msgstr No translation??? -#: lib/option.tcl:149 +#: lib/option.tcl:151 +msgid Use Textconv For Diffs and Blames +msgstr No translation??? -#: lib/option.tcl:153 +#: lib/option.tcl:156 +msgid Additional Diff Parameters +msgstr No translation??? +#: lib/option.tcl:160 +msgid Warn before committing to a detached head +msgstr No translation??? +#: lib/option.tcl:161 +msgid Staging of untracked files +msgstr No translation??? +#: lib/transport.tcl:25 +msgid fetch all remotes +msgstr No translation??? -- 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 1/2] Git.pm: add new temp_is_locked function
Kyle J. McKay mackyle at gmail.com writes:
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self( at _);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+
+ defined $$temp_fd $$temp_fd-opened
$TEMP_FILES{$$temp_fd}{locked};
+}
+
=item temp_release ( NAME )
=item temp_release ( FILEHANDLE )
at at -1248,7 +1277,7 at at sub _temp_cache {
my $temp_fd = \$TEMP_FILEMAP{$name};
if (defined $$temp_fd and $$temp_fd-opened) {
- if ($TEMP_FILES{$$temp_fd}{locked}) {
+ if (temp_is_locked($name)) {
throw Error::Simple(Temp file with moniker ' .
$name . ' already in use);
}
There's a problem with this use of temp_is_locked. There is an else
clause right after this:
} else {
if (defined $$temp_fd) {
# then we're here because of a closed handle.
Prior to the patch, the comment is correct, but after the patch, the
if block may also be entered if the file is open but locked. This is
because temp_is_locked checks that the temp file is defined, open,
and locked.
This issue leads to lots of
Temp file 'svn_delta_3360_0' was closed. Opening replacement.
messages for me.
Reverting the change in _temp_cache solves the problem for me.
Adding an !$$temp_fd-opened clause to the if statement also
works, but this is less efficient.
--
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 4/4] Update Japanese translation (Git-gui)
悪魔野玉茶無 devil.tamac...@gmail.com writes: @@ -124,26 +127,23 @@ msgstr コミット予定済、ファイル無し #: git-gui.sh:2087 msgid File type changed, not staged -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット未予定 There are good changes like this in this patch, and ... #: git-gui.sh:3095 #, tcl-format msgid fatal: cannot stat path %s: No such file or directory -msgstr -致命的: パス %s が stat できません。そのようなファイルやディレクトリはありま -せん +msgstr 致命的: パス %s が stat できません。そのようなファイルやディレクトリはありません dubious ones like this (there is no change to the string, just the way msgstr is formatted to make them all overlong single strings). #: git-gui.sh:2088 git-gui.sh:2089 -#, fuzzy msgid File type changed, old type staged for commit -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット予定の形式が古い Is this correct? I do not personally use git-gui, but I _think_ this message is given when you did something like this: edit file ;# file is a regular file git add file rm file ln -s something file ;# file is now a symbolic link at this point, git status would say MT file. The latter half of the translated Japanese reads format planned to commit is ancient. Perhaps 元のファイルタイプでの変更をコミット予定済, or something? In any case, I think the organization of the series should be [PATCH 1/3] git-gui: mark yes/no/ask for translation which is your 3/4, and then [PATCH 2/3] git-gui: update git-gui/po/git-gui.pot which is your 1/4, and then [PATCH 3/3] git-gui: update Japanese translation which is all the changes to git-gui/po/ja.po in your 2/4 and 4/4. Also I forgot to notice when I was reading the earlier patches, but git-gui has a separate root commit, so please base your work on Pat Thoyts's tree at: git://repo.or.cz/git-gui 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
[RFC/PATCH] rev-parse(1): logically group options
The options section of the git-rev-parse manual page has grown
organically so that there now does not seem to be much logic behind the
ordering of the options. It also does not make it clear that certain
options must appear first on the command line.
Address this by reorganising the options into groups with subheadings.
The text of option descriptions does not change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-rev-parse.txt | 104 +++-
1 file changed, 61 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 993903c..fa284b0 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -24,9 +24,35 @@ distinguish between them.
OPTIONS
---
+
+Operation Modes
+~~~
+
+Each of these options must appear first on the command line.
+
+--local-env-vars::
+ List the GIT_* environment variables that are local to the
+ repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR).
+ Only the names of the variables are listed, not their value,
+ even if they are set.
+
--parseopt::
Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
+--resolve-git-dir path::
+ Check if path is a valid repository or a gitfile that
+ points at a valid repository, and print the location of the
+ repository. If path is a gitfile then the resolved path
+ to the real repository is printed.
+
+--sq-quote::
+ Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
+ section below). In contrast to the `--sq` option below, this
+ mode does only quoting. Nothing else is done to command input.
+
+Options for --parseopt
+~~
+
--keep-dashdash::
Only meaningful in `--parseopt` mode. Tells the option parser to echo
out the first `--` met instead of skipping it.
@@ -36,10 +62,8 @@ OPTIONS
the first non-option argument. This can be used to parse sub-commands
that take options themselves.
---sq-quote::
- Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
- section below). In contrast to the `--sq` option below, this
- mode does only quoting. Nothing else is done to command input.
+Options for Filtering
+~
--revs-only::
Do not output flags and parameters not meant for
@@ -55,6 +79,9 @@ OPTIONS
--no-flags::
Do not output flag parameters.
+Options for Output
+~~
+
--default arg::
If there is no parameter given by the user, use `arg`
instead.
@@ -110,6 +137,17 @@ can be used.
strip '{caret}' prefix from the object names that already have
one.
+--abbrev-ref[=(strict|loose)]::
+ A non-ambiguous short name of the objects name.
+ The option core.warnAmbiguousRefs is used to select the strict
+ abbreviation mode.
+
+--short::
+--short=number::
+ Instead of outputting the full SHA-1 values of object names try to
+ abbreviate them to a shorter unique name. When no length is specified
+ 7 is used. The minimum length is 4.
+
--symbolic::
Usually the object names are output in SHA-1 form (with
possible '{caret}' prefix); this option makes them output in a
@@ -123,16 +161,8 @@ can be used.
unfortunately named tag master), and show them as full
refnames (e.g. refs/heads/master).
---abbrev-ref[=(strict|loose)]::
- A non-ambiguous short name of the objects name.
- The option core.warnAmbiguousRefs is used to select the strict
- abbreviation mode.
-
---disambiguate=prefix::
- Show every object whose name begins with the given prefix.
- The prefix must be at least 4 hexadecimal digits long to
- avoid listing each and every object in the repository by
- mistake.
+Options for Input
+~
--all::
Show all refs found in `refs/`.
@@ -155,18 +185,11 @@ shown. If the pattern does not contain a globbing
character (`?`,
character (`?`, `*`, or `[`), it is turned into a prefix
match by appending `/*`.
---show-toplevel::
- Show the absolute path of the top-level directory.
-
---show-prefix::
- When the command is invoked from a subdirectory, show the
- path of the current directory relative to the top-level
- directory.
-
---show-cdup::
- When the command is invoked from a subdirectory, show the
- path of the top-level directory relative to the current
- directory (typically a sequence of ../, or an empty string).
+--disambiguate=prefix::
+ Show every object whose name begins with the given prefix.
+ The prefix must be at least 4 hexadecimal digits long to
+ avoid listing each and every object in the repository by
+ mistake.
--git-dir::
Show `$GIT_DIR` if defined. Otherwise show the path to
@@ -177,6 +200,14 @@ If
Re: [PATCH v3 1/2] Git.pm: add new temp_is_locked function
On Jul 18, 2013, at 11:34, David Rothenberger wrote:
Kyle J. McKay mackyle at gmail.com writes:
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self( at _);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+
+ defined $$temp_fd $$temp_fd-opened $TEMP_FILES{$$temp_fd}
{locked};
+}
+
=item temp_release ( NAME )
=item temp_release ( FILEHANDLE )
at at -1248,7 +1277,7 at at sub _temp_cache {
my $temp_fd = \$TEMP_FILEMAP{$name};
if (defined $$temp_fd and $$temp_fd-opened) {
- if ($TEMP_FILES{$$temp_fd}{locked}) {
+ if (temp_is_locked($name)) {
throw Error::Simple(Temp file with moniker ' .
$name . ' already in use);
}
There's a problem with this use of temp_is_locked. There is an else
clause right after this:
} else {
if (defined $$temp_fd) {
# then we're here because of a closed handle.
Prior to the patch, the comment is correct, but after the patch, the
if block may also be entered if the file is open but locked. This is
because temp_is_locked checks that the temp file is defined, open,
and locked.
This issue leads to lots of
Temp file 'svn_delta_3360_0' was closed. Opening replacement.
messages for me.
Reverting the change in _temp_cache solves the problem for me.
Adding an !$$temp_fd-opened clause to the if statement also
works, but this is less efficient.
That change was made as a result of this feedback:
On Jul 6, 2013, at 17:11, Jonathan Nieder wrote:
Hi,
Kyle McKay wrote:
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
[...]
+=item temp_is_locked ( NAME )
+
+Returns true if the file mapped to CNAME is currently locked.
+
+If true is returned, an attempt to Ctemp_acquire() the same
[snip]
Looking more closely, it looks like this is factoring out the idiom
for checking if a name is already in use from the _temp_cache
function. Would it make sense for _temp_cache to call this helper?
So I think the answer is it does not make sense for _temp_cache to
call this helper.
Will release a v4 in just a moment with that single change reverted.
--
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 v4 1/2] Git.pm: add new temp_is_locked function
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
perl/Git.pm | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 7a252ef..204fdc6 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -61,7 +61,7 @@ require Exporter;
remote_refs prompt
get_tz_offset
credential credential_read credential_write
-temp_acquire temp_release temp_reset temp_path);
+temp_acquire temp_is_locked temp_release temp_reset temp_path);
=head1 DESCRIPTION
@@ -1206,6 +1206,35 @@ sub temp_acquire {
$temp_fd;
}
+=item temp_is_locked ( NAME )
+
+Returns true if the internal lock created by a previous Ctemp_acquire()
+call with CNAME is still in effect.
+
+When temp_acquire is called on a CNAME, it internally locks the temporary
+file mapped to CNAME. That lock will not be released until Ctemp_release()
+is called with either the original CNAME or the LFile::Handle that was
+returned from the original call to temp_acquire.
+
+Subsequent attempts to call Ctemp_acquire() with the same CNAME will fail
+unless there has been an intervening Ctemp_release() call for that CNAME
+(or its corresponding LFile::Handle that was returned by the original
+Ctemp_acquire() call).
+
+If true is returned by Ctemp_is_locked() for a CNAME, an attempt to
+Ctemp_acquire() the same CNAME will cause an error unless
+Ctemp_release is first called on that CNAME (or its corresponding
+LFile::Handle that was returned by the original Ctemp_acquire() call).
+
+=cut
+
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self(@_);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+
+ defined $$temp_fd $$temp_fd-opened
$TEMP_FILES{$$temp_fd}{locked};
+}
+
=item temp_release ( NAME )
=item temp_release ( FILEHANDLE )
--
1.8.3
--
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 v4 2/2] git-svn: allow git-svn fetching to work using serf
When attempting to git-svn fetch files from an svn https?: url using
the serf library (the only choice starting with svn 1.8) the following
errors can occur:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
David Rothenberger daver...@acm.org has determined the cause to
be that ra_serf does not drive the delta editor in a depth-first
manner [...]. Instead, the calls come in this order:
1. open_root
2. open_directory
3. add_file
4. apply_textdelta
5. add_file
6. apply_textdelta
When using the ra_serf access method, git-svn can end up needing
to create several temp files before the first one is closed.
This change causes a new temp file moniker to be generated if the
one that would otherwise have been used is currently locked.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
perl/Git/SVN/Fetcher.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index bd17418..10edb27 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -315,11 +315,13 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
return undef if $self-is_path_ignored($fb-{path});
- my $fh = $::_repository-temp_acquire('svn_delta');
+ my $suffix = 0;
+ ++$suffix while
$::_repository-temp_is_locked(svn_delta_${$}_$suffix);
+ my $fh = $::_repository-temp_acquire(svn_delta_${$}_$suffix);
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '', $fh or croak $!;
- my $base = $::_repository-temp_acquire('git_blob');
+ my $base = $::_repository-temp_acquire(git_blob_${$}_$suffix);
if ($fb-{blob}) {
my ($base_is_link, $size);
--
1.8.3
--
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 2/2] git-svn: allow git-svn fetching to work using serf
(cc-ing Eric Wong, who maintains git-svn and knows both it and the libsvn perl bindings much better than I do) Kyle J. McKay wrote: David Rothenberger daver...@acm.org has determined the cause to be that ra_serf does not drive the delta editor in a depth-first manner [...]. Instead, the calls come in this order: Thanks. Sorry to nitpick, but the problem is not depth-first versus breadth-first versus random. Blaming the traversal order makes this completely confusing. The actual problem is that the driver asks us to keep multiple files open at a time. The approach taken in this patch would be racy if the driver calls us multiple times concurrently (since temp_acquire can fail). I believe it doesn't but haven't checked. The approach is generally good. I wanted to propose some clearer documentation for temp_is_locked() but didn't end up finding a moment for it, so... meh. I'll be happy to help get the details right if someone else finds time for that (hint, hint). 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 v2] pull: require choice between rebase/merge on non-fast-forward pull
Because it is so easy to let Git handle automatically a trivial
merge with git pull, a person who is new to Git may not realize
that the project s/he is interacting with may prefer a rebase
workflow.
Add a safety valve to fail git pull that does not explicitly
specify what branch from which repository to integrate your history
with, when it is neither a fast-forward or already up-to-date,
until/unless the user expressed her preference between the two ways
of integration.
This can be an irritating backward incompatible change for old
timers, but it can be a one time irritation by doing:
git config --global pull.rebase false
once to say I will always --merge, and they'd not even notice.
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326
for a full discussion.
Helped-by: John Keeping j...@keeping.me.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This time with updates to the documentation and the test suite.
Documentation/git-pull.txt | 9
git-pull.sh| 40 +++-
t/t5520-pull.sh| 51 ++
t/t5524-pull-msg.sh| 2 +-
4 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 24ab07a..86f5170 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -97,6 +97,14 @@ must be given before the options meant for 'git fetch'.
Options related to merging
~~
+When `git pull` that does not explicitly specify what branch from
+which repository is to be integrated with your history on the
+command line, recent Git will refuse to work until you specify how
+that integration should happen, either with a command line option
+(`--merge` or `--rebase`) or a configuration variable (`pull.rebase`
+or `branch.name.rebase`, which is the same as `--merge`
+(`--rebase`) when set to `false` (`true`) respectively.
+
include::merge-options.txt[]
:git-pull: 1
@@ -119,6 +127,7 @@ It rewrites history, which does not bode well when you
published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
+--merge::
--no-rebase::
Override earlier --rebase.
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..88c198f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -41,13 +41,21 @@ test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
merge_args= edit=
+
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
+
+# See if we are configured to rebase by default.
+# The value $rebase is, throughout the main part of the code:
+#(empty) - the user did not have any preference
+#true- the user told us to integrate by rebasing
+#false - the user told us to integrate by merging
rebase=$(git config --bool branch.$curr_branch_short.rebase)
if test -z $rebase
then
rebase=$(git config --bool pull.rebase)
fi
+
dry_run=
while :
do
@@ -113,7 +121,8 @@ do
-r|--r|--re|--reb|--reba|--rebas|--rebase)
rebase=true
;;
- --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+ --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\
+ -m|--m|--me|--mer|--merg|--merge)
rebase=false
;;
--recurse-submodules)
@@ -219,6 +228,7 @@ test true = $rebase {
fi
done
}
+
orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
$@ || exit 1
test -z $dry_run || exit 0
@@ -264,6 +274,34 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
;;
+*)
+ # integrating with a single other history; be careful not to
+ # trigger this check when we will say fast-forward or already
+ # up-to-date.
+ merge_head=${merge_head% }
+ if test -z $rebase$no_ff$ff_only${squash#--no-squash}
+ test -n $orig_head
+ test $# = 0
+ ! git merge-base --is-ancestor $orig_head $merge_head
+ ! git merge-base --is-ancestor $merge_head $orig_head
+ then
+echo 2 orig-head was $orig_head
+echo 2 merge-head is $merge_head
+git show 2 --oneline -s $orig_head $merge_head
+
+ die The pull does not fast-forward; please specify
+if you want to merge or rebase.
+
+Use either
+
+git pull --rebase
+git pull --merge
+
+You can also use 'git config pull.rebase true' (if you want --rebase) or
+'git config pull.rebase false' (if you want --merge) to set this once for
+this project and forget about it.
+ fi
+ ;;
esac
if test -z $orig_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 6af6c63..1e91eca 100755
---
Re: [PATCH v3 1/2] Git.pm: add new temp_is_locked function
Kyle J. McKay wrote: That change was made as a result of this feedback: On Jul 6, 2013, at 17:11, Jonathan Nieder wrote: Kyle McKay wrote: The temp_is_locked function can be used to determine whether or not a given name previously passed to temp_acquire is currently locked. [...] +=item temp_is_locked ( NAME ) + +Returns true if the file mapped to CNAME is currently locked. + +If true is returned, an attempt to Ctemp_acquire() the same [snip] Looking more closely, it looks like this is factoring out the idiom for checking if a name is already in use from the _temp_cache function. Would it make sense for _temp_cache to call this helper? So I think the answer is it does not make sense for _temp_cache to call this helper. Thanks for looking into it. Sorry for the confusion. The point of my question was an example of a way to make sure the internal API stays easy to understand. But it seems to have backfired, and this is a small enough isolated change that I think it's okay to say let's clean it up later. Will release a v4 in just a moment with that single change reverted. 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 v3 0/3] Switch German translation to G+E
Thomas Rast t...@thomasrast.ch writes: Ralf Thielow ralf.thie...@gmail.com writes: This is a resend of v3 because at least one patch was damaged last time for whatever reason. Ralf Thielow (3): l10n: de.po: switch from pure German to German+English (part 1) l10n: de.po: switch from pure German to German+English (part 2) l10n: de.po: switch from pure German to German+English (part 3) Thanks, this one applied cleanly. Acked-by: Thomas Rast tr...@inf.ethz.ch Let's make sure our i18n coordinator is aware of this effort. 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: [RFC/PATCH] Add the NO_SENTINEL build variable
Jonathan Nieder wrote: Ramsay Jones wrote: One of the three gcc compilers that I use does not understand the sentinel function attribute. (so, it spews 108 warning messages) Do you know what version of gcc introduced the sentinel attribute? Would it make sense for the ifdef in git-compat-util.h to be keyed on __GNUC__ and __GNUC_MINOR__ instead of a new makefile flag? I have on old (v4.2.1) gcc repo on Linux and looking at ~/gcc-4.2.1/gcc/ChangeLog-2004 I can see that the sentinel attribute was added on 2004-09-04 by Kaveh R. Ghazi. Also, I find bump version string to version 4.0.0 was on 2004-09-09 and bump version string to version 3.5.0 was on 2004-01-16. Several of my system header files (on Linux) imply that the sentinel attribute is supported by __GNUC__ = 4. (One of them, ansidecl.h, states that gcc 3.5 supports it but ...) 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] Add the GIT_SENTINEL macro
The sentinel function attribute is not understood by versions of
the gcc compiler prior to v4.0. At present, for earlier versions
of gcc, the build issues 108 warnings related to the unknown
attribute. In order to suppress the warnings, we conditionally
define the GIT_SENTINEL macro to provide the sentinel attribute
for gcc v4.0 and newer.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
This was built on the next branch
ATB,
Ramsay Jones
argv-array.h | 2 +-
builtin/revert.c | 4 ++--
exec_cmd.h| 2 +-
git-compat-util.h | 7 +++
run-command.h | 2 +-
5 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/argv-array.h b/argv-array.h
index e805748..9a4c053 100644
--- a/argv-array.h
+++ b/argv-array.h
@@ -15,7 +15,7 @@ void argv_array_init(struct argv_array *);
void argv_array_push(struct argv_array *, const char *);
__attribute__((format (printf,2,3)))
void argv_array_pushf(struct argv_array *, const char *fmt, ...);
-__attribute__((sentinel))
+GIT_SENTINEL(0)
void argv_array_pushl(struct argv_array *, ...);
void argv_array_pop(struct argv_array *);
void argv_array_clear(struct argv_array *);
diff --git a/builtin/revert.c b/builtin/revert.c
index b8b5174..219f354 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -54,7 +54,7 @@ static int option_parse_x(const struct option *opt,
return 0;
}
-__attribute__((sentinel))
+GIT_SENTINEL(0)
static void verify_opt_compatible(const char *me, const char *base_opt, ...)
{
const char *this_opt;
@@ -71,7 +71,7 @@ static void verify_opt_compatible(const char *me, const char
*base_opt, ...)
die(_(%s: %s cannot be used with %s), me, this_opt, base_opt);
}
-__attribute__((sentinel))
+GIT_SENTINEL(0)
static void verify_opt_mutually_compatible(const char *me, ...)
{
const char *opt1, *opt2 = NULL;
diff --git a/exec_cmd.h b/exec_cmd.h
index 307b55c..fbbb44d 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -7,7 +7,7 @@ extern const char *git_exec_path(void);
extern void setup_path(void);
extern const char **prepare_git_cmd(const char **argv);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
-__attribute__((sentinel))
+GIT_SENTINEL(0)
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
diff --git a/git-compat-util.h b/git-compat-util.h
index ff193f4..cac8157 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -303,6 +303,13 @@ extern char *gitbasename(char *);
#endif
#endif
+/* The sentinel attribute is valid from gcc version 4.0 */
+#if defined(__GNUC__) (__GNUC__ = 4)
+#define GIT_SENTINEL(n) __attribute__((sentinel(n)))
+#else
+#define GIT_SENTINEL(n)
+#endif
+
#include compat/bswap.h
#ifdef USE_WILDMATCH
diff --git a/run-command.h b/run-command.h
index 0a47679..2f2b453 100644
--- a/run-command.h
+++ b/run-command.h
@@ -46,7 +46,7 @@ int finish_command(struct child_process *);
int run_command(struct child_process *);
extern char *find_hook(const char *name);
-__attribute__((sentinel))
+GIT_SENTINEL(0)
extern int run_hook(const char *index_file, const char *name, ...);
#define RUN_COMMAND_NO_STDIN 1
--
1.8.3
--
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] t3032 - make compatible with systems using \r\n as a line ending
Jonathan Nieder wrote: Mark Levedahl wrote: Subtests 6, 7, and 9 rely test that merge-recursive correctly ignores whitespace when so directed. Change the particular whitespace sequences to be ones that are not known line endings so the whitespace is not changed when being extracted by line oriented grep. merge-recursive needs to be able to deal with \r at EOL, too, so if at all possible I would prefer to see the test fixed to pass on Cygwin some other way. Maybe use -U/--binary option to grep? Indeed, if you look at the top of that test file, you will see: test_have_prereq SED_STRIPS_CR SED_OPTIONS=-b test_have_prereq MINGW export GREP_OPTIONS=-U which may explain why it works for me on MinGW, but not why it works on cygwin 1.5. 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
Re: [PATCH] Fix some sparse warnings
Jeff King wrote:
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three Using plain integer as NULL pointer warnings.
Each warning relates to the use of an '{0}' initialiser expression
in the declaration of an 'struct object_info'.
I question the value of this warning. Initialization with '= {0}' is a
well-established idiom, and sparse should know about it. Also, plain 0
*is* a null pointer constant.
I agree with you. It's not a bug, and I think sparse is being overly
picky here; it is missing the forest for the trees in interpreting the
idiom.
Yes, last time this came up, I looked at writing a patch to sparse to
allow this without complaint. It's still on my sparse TODO list, but
even if I finished it tonight, it would take a while to get into a
released version of sparse. ;-)
Still, it may be worth tweaking in the name of eliminating compiler
noise, since it does not cost us very much to do so (and I believe we
have done so in the past, too).
We could also ask people with sparse to turn off the use NULL instead
of 0 warning, but I think it _is_ a useful warning elsewhere (even
though it is never a bug, it violates our style guidelines and may be an
indication of a bug).
Indeed, if it wasn't for this, I would be happy to turn this warning off.
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
Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
Mark Levedahl wrote:
On 07/15/2013 10:06 PM, Torsten Bögershausen wrote:
On 2013-07-15 21.49, Junio C Hamano wrote:
Mark Levedahl mleved...@gmail.com writes:
In order to limit the adverse effects caused by this implementation,
we provide a new fast stat interface, which allows us to use this
only for interactions with the index (i.e. the cached stat data).
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
I've tested this on Cygwin 1.7 on WIndows 7 , comparing to the results
using your prior patch (removing the Cygwin specific lstat entirely)
and get the same results with both, so this seems ok from me.
My comparison point was created by reverting your current patch from
pu, then reapplying your earlier patch on top, so the only difference
was which approach was used to address the stat functions.
Caveats:
1) I don't find any speed improvement of the current patch over the
previous one (the tests actually ran faster with the earlier patch,
though the difference was less than 1%).
Hm, measuring the time for the test suite is one thing,
did you measure the time of git status with and without the patch?
(I don't have my test system at hand, so I can test in a few days/weeks)
Timing for 5 rounds of git status in the git project. First, with the
current fast_lstat patches:
/usr/local/src/gitfor i in {1..5} ; do time git status /dev/null ; done
real0m0.218s
user0m0.000s
sys 0m0.218s
real0m0.187s
user0m0.077s
sys 0m0.109s
real0m0.187s
user0m0.030s
sys 0m0.156s
real0m0.203s
user0m0.031s
sys 0m0.171s
real0m0.187s
user0m0.062s
sys 0m0.124s
Now, with Ramsay's original patch just removing the non-Posix stat
functions:
/usr/local/src/gitfor i in {1..5} ; do time git status /dev/null ; done
real0m0.218s
user0m0.046s
sys 0m0.171s
real0m0.187s
user0m0.015s
sys 0m0.171s
real0m0.187s
user0m0.015s
sys 0m0.171s
real0m0.187s
user0m0.047s
sys 0m0.140s
real0m0.187s
user0m0.031s
sys 0m0.156s
I see no difference in the above. (Yes, I checked multiple times that I
was using different executables).
Hmm, that looks good. :-D
Torsten reported a performance boost using the win32 stat() implementation
on a linux git repo (2s - 1s, if I recall correctly) on cygwin 1.7.
Do you have a larger repo available to test?
If performance isn't an issue (it isn't for _me_), then I will happily
re-submit my original patch (removing the win32 stat implementation).
[Hmm, I may do anyway!]
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
Re: t3032 incompatible with Cygwin/Windows
Mark Levedahl wrote: Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail on msysgit for similar reasons. Looking at test 6, the expected result is a line ending with \r\n in text.txt. This line is extracted with grep (grep 'justice and holiness' text.txt actual), with unavoidable result that on Cygwin the line ending is \n. This happens because on Cygwin, the text utils are compiled to open files in text mode meaning than \n and \r\n are both recognized as EOL markers. Thus, even though text.txt is an exact match for what is created on Linux, the test fails because \r\n cannot be distinguished by the available tools. I'm not sure the right way forward. I did confirm that by substituting q_to_tab for q_to_cr in t3032, the test pass on Cygwin and on Linux. Perhaps t3032 should be so amended to avoid use of a non-portable line ending construct? This passes for me, on both cygwin and MinGW. After adding a test_pause to test #6: $ ./t3032-merge-recursive-options.sh -v ... expecting success: q_to_cr -\EOF expected justice and holiness and is the nurse of his age and theQ EOF git read-tree --reset -u HEAD git merge-recursive --ignore-space-change HEAD^ -- HEAD remote grep justice and holiness text.txt actual test_cmp expected actual test_pause Merging HEAD with remote Merging: 0ab7224 Clarify be82dcf Remove cruft found 1 common ancestor: c1e95d9 Initial revision Auto-merging text.txt $ xxd expected 000: 2020 2020 6a75 7374 6963 6520 616e 6420 justice and 010: 686f 6c69 6e65 7373 2061 6e64 2069 7320 holiness and is 020: 7468 6520 6e75 7273 6520 6f66 2068 6973 the nurse of his 030: 2061 6765 2061 6e64 2074 6865 0d0aage and the.. $ xxd actual 000: 2020 2020 6a75 7374 6963 6520 616e 6420 justice and 010: 686f 6c69 6e65 7373 2061 6e64 2069 7320 holiness and is 020: 7468 6520 6e75 7273 6520 6f66 2068 6973 the nurse of his 030: 2061 6765 2061 6e64 2074 6865 0d0aage and the.. $ grep justice and holiness text.txt | xxd 000: 2020 2020 6a75 7374 6963 6520 616e 6420 justice and 010: 686f 6c69 6e65 7373 2061 6e64 2069 7320 holiness and is 020: 7468 6520 6e75 7273 6520 6f66 2068 6973 the nurse of his 030: 2061 6765 2061 6e64 2074 6865 0d0aage and the.. $ exit ... # passed all 11 test(s) 1..11 $ 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
Re: [PATCH] Add the GIT_SENTINEL macro
On Thu, Jul 18, 2013 at 09:02:12PM +0100, Ramsay Jones wrote: The sentinel function attribute is not understood by versions of the gcc compiler prior to v4.0. At present, for earlier versions of gcc, the build issues 108 warnings related to the unknown attribute. In order to suppress the warnings, we conditionally define the GIT_SENTINEL macro to provide the sentinel attribute for gcc v4.0 and newer. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Acked-by: Jeff King p...@peff.net -__attribute__((sentinel)) +GIT_SENTINEL(0) void argv_array_pushl(struct argv_array *, ...); We could also add GIT_SENTINEL to handle the default-zero case, but I do not think it is worth the trouble. -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 1/2] git_mkstemps: correctly test return value of open()
I've been looking into writing a proper test for this patch. My first
attempt tests the symptom that was seen initially, that git commit
fails if fd 0 is closed.
One problem is how to arrange for fd 0 to be closed. I could use the
bash redirection -, but I think you want to be more portable than
that. This version uses execvp() inside a small C program, and
execvp() is a Posix function.
I've tested that this test does what it should: If you remove the
fix, fd = 0, the test fails. If you then remove test-close-fd-0
from before git init in the test, the test is nullified and succeeds
again.
Here is the diff. What do people think of it?
diff --git a/Makefile b/Makefile
index 0600eb4..6b410f5 100644
--- a/Makefile
+++ b/Makefile
@@ -557,6 +557,7 @@ X =
PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
TEST_PROGRAMS_NEED_X += test-chmtime
+TEST_PROGRAMS_NEED_X += test-close-fd-0
TEST_PROGRAMS_NEED_X += test-ctype
TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
index 986b2a8..6a31103 100755
--- a/t/t0070-fundamental.sh
+++ b/t/t0070-fundamental.sh
@@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable
directory prints file
grep cannotwrite/test err
'
+test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
+ git init
+ echo Test. test-file
+ git add test-file
+ test-close-fd-0 git commit -m Message.
+'
+
test_expect_success 'check for a bug in the regex routines' '
# if this test fails, re-build git with NO_REGEX=1
test-regex
diff --git a/test-close-fd-0.c b/test-close-fd-0.c
new file mode 100644
index 000..3745c34
--- /dev/null
+++ b/test-close-fd-0.c
@@ -0,0 +1,14 @@
+#include unistd.h
+
+/* Close file descriptor 0 (which is standard-input), then execute the
+ * remainder of the command line as a command. */
+
+int main(int argc, char **argv)
+{
+ /* Close fd 0. */
+ close(0);
+ /* Execute the requested command. */
+ execvp(argv[1], argv[1]);
+ /* If execve() failed, return an error. */
+ return 1;
+}
diff --git a/wrapper.c b/wrapper.c
index dd7ecbb..6a015de 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int
mode)
template[5] = letters[v % num_letters]; v /= num_letters;
fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
- if (fd 0)
+ if (fd = 0)
return fd;
/*
* Fatal error (EPERM, ENOSPC etc).
Dale
--
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: [PATCH 4/4] Update Japanese translation (Git-gui)
-- Forwarded message -- From: Yamada Saburo devil.tamac...@gmail.com Date: 2013/7/19 Subject: Re: [PATCH 4/4] Update Japanese translation (Git-gui) To: Junio C Hamano gits...@pobox.com Hi Hamano, dubious ones like this (there is no change to the string, just the way msgstr is formatted to make them all overlong single strings). changed by QT Linguist for Win. Perhaps 元のファイルタイプでの変更をコミット予定済, or something? Your translation looks right. New mail is due to be thrown later here. Thanks 2013/7/19 Junio C Hamano gits...@pobox.com: 悪魔野玉茶無 devil.tamac...@gmail.com writes: @@ -124,26 +127,23 @@ msgstr コミット予定済、ファイル無し #: git-gui.sh:2087 msgid File type changed, not staged -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット未予定 There are good changes like this in this patch, and ... #: git-gui.sh:3095 #, tcl-format msgid fatal: cannot stat path %s: No such file or directory -msgstr -致命的: パス %s が stat できません。そのようなファイルやディレクトリはありま -せん +msgstr 致命的: パス %s が stat できません。そのようなファイルやディレクトリはありません dubious ones like this (there is no change to the string, just the way msgstr is formatted to make them all overlong single strings). #: git-gui.sh:2088 git-gui.sh:2089 -#, fuzzy msgid File type changed, old type staged for commit -msgstr ファイル型変更、コミット未予定 +msgstr ファイルタイプ変更、コミット予定の形式が古い Is this correct? I do not personally use git-gui, but I _think_ this message is given when you did something like this: edit file ;# file is a regular file git add file rm file ln -s something file ;# file is now a symbolic link at this point, git status would say MT file. The latter half of the translated Japanese reads format planned to commit is ancient. Perhaps 元のファイルタイプでの変更をコミット予定済, or something? In any case, I think the organization of the series should be [PATCH 1/3] git-gui: mark yes/no/ask for translation which is your 3/4, and then [PATCH 2/3] git-gui: update git-gui/po/git-gui.pot which is your 1/4, and then [PATCH 3/3] git-gui: update Japanese translation which is all the changes to git-gui/po/ja.po in your 2/4 and 4/4. Also I forgot to notice when I was reading the earlier patches, but git-gui has a separate root commit, so please base your work on Pat Thoyts's tree at: git://repo.or.cz/git-gui 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
Fwd: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese)
-- Forwarded message -- From: Yamada Saburo devil.tamac...@gmail.com Date: 2013/7/19 Subject: Re: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese) To: Junio C Hamano gits...@pobox.com Hi Hamano, I suspect that is not a name Real name. +Language: \n What is this about I used QT Linguist for Win. This line append by QT Linguist. fuzzy No translation??? x7 translated in Patch4/4. Thanks 2013/7/19 Junio C Hamano gits...@pobox.com: 悪魔野玉茶無 devil.tamac...@gmail.com writes: I suspect that is not a name (and I somehow have suspicion that the S-o-b is not real, either), but if you send patches as somebody that does not match your sign-off, please add From: Yamada Saburo devil.tamac...@gmail.com followed by a blank line at the very beginning of the e-mail body. That will override the e-mail From: line your MUA puts in your message and record the commit as authored by Yamada Saburo. Signed-off-by: Yamada Saburo devil.tamac...@gmail.com --- Thanks. git-gui/po/ja.po | 1066 +- 1 file changed, 583 insertions(+), 483 deletions(-) diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po index 9aff249..0bbe504 100644 --- a/git-gui/po/ja.po +++ b/git-gui/po/ja.po @@ -7,41 +7,42 @@ msgid msgstr Project-Id-Version: git-gui\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2010-01-26 15:47-0800\n +POT-Creation-Date: 2013-07-10 02:45+0900\n PO-Revision-Date: 2010-02-02 19:03+0900\n Last-Translator: しらいし ななこ nana...@lavabit.com\n 山田三郎 would be the last translater, no? Language-Team: Japanese\n +Language: \n What is this about MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n -#: git-gui.sh:1921 +#: git-gui.sh:2088 git-gui.sh:2089 +#, fuzzy +msgid File type changed, old type staged for commit +msgstr ファイル型変更、コミット未予定 If this is no longer fuzzy, please resolve it by removing #, fuzzy marker. Also, this translation seems to be incomplete. It may be OK for some strings (e.g. RegExp that seems to be a label of a checkbox or something) to be the same as the original, but some others may need a bit more work. I wonder if there is a mechanism in *.po files to differentiate between I looked at this entry and using the original string as the template is fine and I didn't translate this string, but it should be. I think the following entries seem to fall into the latter category. -#: lib/commit.tcl:272 +#: lib/commit.tcl:269 +msgid +You are about to commit on a detached head. This is a potentially dangerous +thing to do because if you switch to another branch you will lose your +changes and it can be difficult to retrieve them later from the reflog. You +should probably cancel this commit and create a new branch to continue.\n + \n + Do you really want to proceed with your Commit? +msgstr No translation??? -#: lib/index.tcl:398 +#: lib/index.tcl:380 +#, tcl-format +msgid Stage %d untracked files? +msgstr No translation??? -#: lib/option.tcl:149 +#: lib/option.tcl:151 +msgid Use Textconv For Diffs and Blames +msgstr No translation??? -#: lib/option.tcl:153 +#: lib/option.tcl:156 +msgid Additional Diff Parameters +msgstr No translation??? +#: lib/option.tcl:160 +msgid Warn before committing to a detached head +msgstr No translation??? +#: lib/option.tcl:161 +msgid Staging of untracked files +msgstr No translation??? +#: lib/transport.tcl:25 +msgid fetch all remotes +msgstr No translation??? -- 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] git_mkstemps: correctly test return value of open()
On Thu, Jul 18, 2013 at 1:32 PM, Dale R. Worley wor...@alum.mit.edu wrote: I've been looking into writing a proper test for this patch. My first attempt tests the symptom that was seen initially, that git commit fails if fd 0 is closed. One problem is how to arrange for fd 0 to be closed. I could use the bash redirection -, but I think you want to be more portable than that. That's just a plain-vanilla part of POSIX shell behaviour, no? http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05 -- 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] Add the GIT_SENTINEL macro
Ramsay Jones wrote: This was built on the next branch All the uses of the sentinel attribute seem to come from eccb6149 (use sentinel function attribute for variadic lists, 2013-07-09), so this should be okay to go on top of the jk/gcc-function-attributes branch. --- a/git-compat-util.h +++ b/git-compat-util.h @@ -303,6 +303,13 @@ extern char *gitbasename(char *); #endif #endif +/* The sentinel attribute is valid from gcc version 4.0 */ +#if defined(__GNUC__) (__GNUC__ = 4) +#define GIT_SENTINEL(n) __attribute__((sentinel(n))) +#else +#define GIT_SENTINEL(n) +#endif I'd mildly prefer #if ... #define GIT_SENTINEL __attribute__((sentinel)) #else ... (without the numeric parameter). I don't know any function in git (or any other project for that matter) that takes extra parameters after the NULL sentinel. But I don't care much, so Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks for a pleasant patch. 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: [RFC/PATCH] Add the NO_SENTINEL build variable
Ramsay Jones ram...@ramsay1.demon.co.uk writes: Jonathan Nieder wrote: Ramsay Jones wrote: One of the three gcc compilers that I use does not understand the sentinel function attribute. (so, it spews 108 warning messages) Do you know what version of gcc introduced the sentinel attribute? Would it make sense for the ifdef in git-compat-util.h to be keyed on __GNUC__ and __GNUC_MINOR__ instead of a new makefile flag? I have on old (v4.2.1) gcc repo on Linux and looking at ~/gcc-4.2.1/gcc/ChangeLog-2004 I can see that the sentinel attribute was added on 2004-09-04 by Kaveh R. Ghazi. Also, I find bump version string to version 4.0.0 was on 2004-09-09 and bump version string to version 3.5.0 was on 2004-01-16. Several of my system header files (on Linux) imply that the sentinel attribute is supported by __GNUC__ = 4. (One of them, ansidecl.h, states that gcc 3.5 supports it but ...) Perhaps a message from yesterday would have helped? http://article.gmane.org/gmane.comp.version-control.git/230633 seems to indicate that checking for version 4 is sufficient. Also I asked you to split the __attribute__((sentinel(n)) support into a separate patch. We currently do not pass anything but 0 (meaning, the sentinel is always at the end), and SENTINEL in all capital is easy enough to grep for when somebody _does_ want to have such a support, so I'd prefer not to see __attribute__((sentinel(n)) until it becomes necessary. 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 3/3] apply, find_name_traditional: Do not initialize len to the lines length.
The variable len is set to
len = strchrnul(line, '\n') - line;
unconditionally 9 lines later, hence we can remove the call to strlen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 1218688..681a40b 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -722,7 +722,7 @@ static char *find_name(const char *line, char *def, int
p_value, int terminate)
static char *find_name_traditional(const char *line, char *def, int p_value)
{
- size_t len = strlen(line);
+ size_t len;
size_t date_len;
if (*line == '') {
--
1.8.3.3.754.g9c3c367.dirty
--
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] http-push.c, add_send_request: Do not initialize transfer_request.
That pointer will be assigned to new memory via
request = xmalloc(sizeof(*request));
20 lines later unconditionally anyway, so it's safe to not assign it to an
arbitrary variable.
As this patch is a micro-optimization (for readability?) it would be nice
to have as little work with this patch, so maybe I need a feature to send
a patch without a symmetric number of lines around change-diff. For this
patch I'd be only interested in showing the next 20 lines, but nothing
really before the function declaration.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
http-push.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/http-push.c b/http-push.c
index 395a8cf..6dad188 100644
--- a/http-push.c
+++ b/http-push.c
@@ -663,7 +663,7 @@ static void add_fetch_request(struct object *obj)
static int add_send_request(struct object *obj, struct remote_lock *lock)
{
- struct transfer_request *request = request_queue_head;
+ struct transfer_request *request;
struct packed_git *target;
/* Keep locks active */
--
1.8.3.3.754.g9c3c367.dirty
--
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] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
The variable name ret sounds like the variable to be returned, but
since e6c111b4 we return error. Hence the variable name is miss leading.
As this variable is used only to extract the bits from the callback of
a tree object, I named it cb_bits for callback bits.
Also the assignment to 0 was removed at the start of the function as well
after the if(interesting) block. Those were unneeded as that variable
is set to the callback return value any time we enter the if(interesting)
block, so we'd overwrite old values anyway.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
tree-walk.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index c366852..3c323d1 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -324,7 +324,6 @@ static inline int prune_traversal(struct name_entry *e,
int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
{
- int ret = 0;
int error = 0;
struct name_entry *entry = xmalloc(n*sizeof(*entry));
int i;
@@ -342,6 +341,7 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
strbuf_setlen(base, info-pathlen);
}
for (;;) {
+ int cb_bits;
unsigned long mask, dirmask;
const char *first = NULL;
int first_len = 0;
@@ -405,15 +405,14 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
if (interesting 0)
break;
if (interesting) {
- ret = info-fn(n, mask, dirmask, entry, info);
- if (ret 0) {
- error = ret;
+ cb_bits = info-fn(n, mask, dirmask, entry, info);
+ if (cb_bits 0) {
+ error = cb_bits;
if (!info-show_all_errors)
break;
}
- mask = ret;
+ mask = cb_bits;
}
- ret = 0;
for (i = 0; i n; i++)
if (mask (1ul i))
update_extended_entry(tx + i, entry + i);
--
1.8.3.3.754.g9c3c367.dirty
--
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 subtree push mangles commit message newlines
Hi all, I recently started using git-subtree and ran into a small issue when pushing to the subtree repository: newlines in the commit message seem not to be preserved. I was using git-subtree from [1], but can also reproduce this with the version from the main git source-tree commit 634392b26275fe, and I don't see any changes that could affect this behaviour since then. Best, Jaap [1] https://github.com/helmo/git/tree/subtree-updates/contrib/subtree -- 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] t3032 - make compatible with systems using \r\n as a line ending
On 07/18/2013 03:19 PM, Ramsay Jones wrote: Jonathan Nieder wrote: Mark Levedahl wrote: Subtests 6, 7, and 9 rely test that merge-recursive correctly ignores whitespace when so directed. Change the particular whitespace sequences to be ones that are not known line endings so the whitespace is not changed when being extracted by line oriented grep. merge-recursive needs to be able to deal with \r at EOL, too, so if at all possible I would prefer to see the test fixed to pass on Cygwin some other way. Maybe use -U/--binary option to grep? Indeed, if you look at the top of that test file, you will see: test_have_prereq SED_STRIPS_CR SED_OPTIONS=-b test_have_prereq MINGW export GREP_OPTIONS=-U which may explain why it works for me on MinGW, but not why it works on cygwin 1.5. ATB, Ramsay Jones Thanks, hadn't noticed that, it leads to a much better patch. Mark -- 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] test-lib.sh - define and use GREP_STRIPS_CR
Define a common macro for grep needing -U to allow tests to not need
to inquire of specific platforms needing this option. Change
t3032 and t5560 to use this rather than testing explicitly for mingw.
This fixes these two tests on Cygwin.
Signed-off-by: Mark Levedahl mleved...@gmail.com
---
This replaces my earlier patch against t3032 (8896b287 on pu)
t/t3032-merge-recursive-options.sh | 2 +-
t/t5560-http-backend-noserver.sh | 2 +-
t/test-lib.sh | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t3032-merge-recursive-options.sh
b/t/t3032-merge-recursive-options.sh
index 2b17311..5fd7bbb 100755
--- a/t/t3032-merge-recursive-options.sh
+++ b/t/t3032-merge-recursive-options.sh
@@ -14,7 +14,7 @@ test_description='merge-recursive options
. ./test-lib.sh
test_have_prereq SED_STRIPS_CR SED_OPTIONS=-b
-test_have_prereq MINGW export GREP_OPTIONS=-U
+test_have_prereq GREP_STRIPS_CR export GREP_OPTIONS=-U
test_expect_success 'setup' '
conflict_hunks () {
diff --git a/t/t5560-http-backend-noserver.sh b/t/t5560-http-backend-noserver.sh
index ef98d95..9be9ae3 100755
--- a/t/t5560-http-backend-noserver.sh
+++ b/t/t5560-http-backend-noserver.sh
@@ -5,7 +5,7 @@ test_description='test git-http-backend-noserver'
HTTPD_DOCUMENT_ROOT_PATH=$TRASH_DIRECTORY
-test_have_prereq MINGW export GREP_OPTIONS=-U
+test_have_prereq GREP_STRIPS_CR export GREP_OPTIONS=-U
run_backend() {
echo $2 |
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2d63307..1abea40 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -824,6 +824,7 @@ case $(uname -s) in
test_set_prereq MINGW
test_set_prereq NOT_CYGWIN
test_set_prereq SED_STRIPS_CR
+ test_set_prereq GREP_STRIPS_CR
;;
*CYGWIN*)
test_set_prereq POSIXPERM
@@ -831,6 +832,7 @@ case $(uname -s) in
test_set_prereq NOT_MINGW
test_set_prereq CYGWIN
test_set_prereq SED_STRIPS_CR
+ test_set_prereq GREP_STRIPS_CR
;;
*)
test_set_prereq POSIXPERM
--
1.8.3.2.0.13
--
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: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
On 2013-07-18 19.50, Ramsay Jones wrote:
Mark Levedahl wrote:
On 07/15/2013 10:06 PM, Torsten Bögershausen wrote:
On 2013-07-15 21.49, Junio C Hamano wrote:
Mark Levedahl mleved...@gmail.com writes:
In order to limit the adverse effects caused by this implementation,
we provide a new fast stat interface, which allows us to use this
only for interactions with the index (i.e. the cached stat data).
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
I've tested this on Cygwin 1.7 on WIndows 7 , comparing to the results
using your prior patch (removing the Cygwin specific lstat entirely)
and get the same results with both, so this seems ok from me.
My comparison point was created by reverting your current patch from
pu, then reapplying your earlier patch on top, so the only difference
was which approach was used to address the stat functions.
Caveats:
1) I don't find any speed improvement of the current patch over the
previous one (the tests actually ran faster with the earlier patch,
though the difference was less than 1%).
Hm, measuring the time for the test suite is one thing,
did you measure the time of git status with and without the patch?
(I don't have my test system at hand, so I can test in a few days/weeks)
Timing for 5 rounds of git status in the git project. First, with the
current fast_lstat patches:
/usr/local/src/gitfor i in {1..5} ; do time git status /dev/null ; done
real0m0.218s
user0m0.000s
sys 0m0.218s
real0m0.187s
user0m0.077s
sys 0m0.109s
real0m0.187s
user0m0.030s
sys 0m0.156s
real0m0.203s
user0m0.031s
sys 0m0.171s
real0m0.187s
user0m0.062s
sys 0m0.124s
Now, with Ramsay's original patch just removing the non-Posix stat
functions:
/usr/local/src/gitfor i in {1..5} ; do time git status /dev/null ; done
real0m0.218s
user0m0.046s
sys 0m0.171s
real0m0.187s
user0m0.015s
sys 0m0.171s
real0m0.187s
user0m0.015s
sys 0m0.171s
real0m0.187s
user0m0.047s
sys 0m0.140s
real0m0.187s
user0m0.031s
sys 0m0.156s
I see no difference in the above. (Yes, I checked multiple times that I
was using different executables).
Hmm, that looks good. :-D
Torsten reported a performance boost using the win32 stat() implementation
on a linux git repo (2s - 1s, if I recall correctly) on cygwin 1.7.
Do you have a larger repo available to test?
(I have a 5 years old Dual Core, 2.5 Ghz, 1 TB hard disk, Win XP, cygwin 1.7)
On that machine I can see the performance boost.
Which kind of computers are you guys using?
SSD/hard disk ?
How much RAM ?
Which OS ?
Is there a difference between Win XP, Win7, Win8?
[snip]
--
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 subtree push mangles commit message newlines
Never mind, this is already fixed in a5b8e28e4eb. Sorry for the noise. Jaap On Thu, Jul 18, 2013 at 11:22:33PM +0200, Jaap Eldering wrote: Hi all, I recently started using git-subtree and ran into a small issue when pushing to the subtree repository: newlines in the commit message seem not to be preserved. I was using git-subtree from [1], but can also reproduce this with the version from the main git source-tree commit 634392b26275fe, and I don't see any changes that could affect this behaviour since then. Best, Jaap [1] https://github.com/helmo/git/tree/subtree-updates/contrib/subtree -- 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 -- 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] Finishing touches to name-rev fix
This is an update to finish the jc/name-rev-exact-ref topic, which fixed the command to convert an object name that points at a tag to a refname of the tag (earlier, it did not show anything). The codepath to handle its command line arguments, however, fed the commit that the tag points at to the underlying naming machinery. The first patch in this follow-up series corrects it for the command line codepath. The second patch is a related fix for git describe. The command is about naming the given commit in relation to a tag in its neighbourhood, and while it does allow the input to be a commit-ish (e.g. a tag that points at a commit), it did not unwrap it down to commit, which is a bug (it is like git commit-tree -p $tag that would mistakenly record a tag object as one of the parents of the resulting commit). Junio C Hamano (2): name-rev: differentiate between tags and commits they point at describe: fix --contains when a tag is given as input builtin/describe.c | 3 ++- builtin/name-rev.c | 41 - t/t6120-describe.sh | 24 3 files changed, 58 insertions(+), 10 deletions(-) -- 1.8.3.3-992-gf0e5e44 -- 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] name-rev: differentiate between tags and commits they point at
git name-rev --stdin has been fixed to convert an object name that
points at a tag to a refname of the tag. The codepath to handle its
command line arguments, however, fed the commit that the tag points
at to the underlying naming machinery.
With this fix, you will get this:
$ git name-rev --refs=tags/\* --name-only $(git rev-parse v1.8.3 v1.8.3^0)
v1.8.3
v1.8.3^0
which is the same as what you would get from the fixed --stdin variant:
$ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --refs=tags/\* --name-only
v1.8.3
v1.8.3^0
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/name-rev.c | 24
t/t6120-describe.sh | 12
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 29a6f56..4c7cc62 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -334,7 +334,7 @@ int cmd_name_rev(int argc, const char **argv, const char
*prefix)
for (; argc; argc--, argv++) {
unsigned char sha1[20];
- struct object *o;
+ struct object *object;
struct commit *commit;
if (get_sha1(*argv, sha1)) {
@@ -343,17 +343,25 @@ int cmd_name_rev(int argc, const char **argv, const char
*prefix)
continue;
}
- o = deref_tag(parse_object(sha1), *argv, 0);
- if (!o || o-type != OBJ_COMMIT) {
- fprintf(stderr, Could not get commit for %s.
Skipping.\n,
+ commit = NULL;
+ object = parse_object(sha1);
+ if (object) {
+ struct object *peeled = deref_tag(object, *argv, 0);
+ if (peeled peeled-type == OBJ_COMMIT)
+ commit = (struct commit *)peeled;
+ }
+
+ if (!object) {
+ fprintf(stderr, Could not get object for %s.
Skipping.\n,
*argv);
continue;
}
- commit = (struct commit *)o;
- if (cutoff commit-date)
- cutoff = commit-date;
- add_object_array((struct object *)commit, *argv, revs);
+ if (commit) {
+ if (cutoff commit-date)
+ cutoff = commit-date;
+ }
+ add_object_array(object, *argv, revs);
}
if (cutoff)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index a25729f..1d20854 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -174,4 +174,16 @@ check_describe test2-lightweight-* --tags
--match=test2-*
check_describe test2-lightweight-* --long --tags --match=test2-* HEAD^
+test_expect_success 'name-rev with exact tags' '
+ echo A expect
+ tag_object=$(git rev-parse refs/tags/A)
+ git name-rev --tags --name-only $tag_object actual
+ test_cmp expect actual
+
+ echo A^0 expect
+ tagged_commit=$(git rev-parse refs/tags/A^0)
+ git name-rev --tags --name-only $tagged_commit actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.3.3-992-gf0e5e44
--
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] describe: fix --contains when a tag is given as input
git describe takes a commit and gives it a name based on tags in
its neighbourhood. The command does take a commit-ish but when
given a tag that points at a commit, it should dereference the tag
before computing the name for the commit.
As the whole processing is internally delegated to name-rev, if we
unwrap tags down to the underlying commit when invoking name-rev, it
will make the name-rev issue an error message based on the unwrapped
object name (i.e. either 40-hex object name, or $tag^0) that is
different from what the end-user gave to the command when the commit
cannot be described. Introduce an internal option --peel-tag to the
name-rev to tell it to unwrap a tag in its input from the command
line.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/describe.c | 3 ++-
builtin/name-rev.c | 17 -
t/t6120-describe.sh | 12
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index db41cd7..7d73722 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -446,7 +446,8 @@ int cmd_describe(int argc, const char **argv, const char
*prefix)
struct argv_array args;
argv_array_init(args);
- argv_array_pushl(args, name-rev, --name-only,
--no-undefined,
+ argv_array_pushl(args, name-rev,
+--peel-tag, --name-only, --no-undefined,
NULL);
if (always)
argv_array_push(args, --always);
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 4c7cc62..0aaa19e 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -307,7 +307,7 @@ static void name_rev_line(char *p, struct name_ref_data
*data)
int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = OBJECT_ARRAY_INIT;
- int all = 0, transform_stdin = 0, allow_undefined = 1, always = 0;
+ int all = 0, transform_stdin = 0, allow_undefined = 1, always = 0,
peel_tag = 0;
struct name_ref_data data = { 0, 0, NULL };
struct option opts[] = {
OPT_BOOLEAN(0, name-only, data.name_only, N_(print only
names (no SHA-1))),
@@ -320,6 +320,12 @@ int cmd_name_rev(int argc, const char **argv, const char
*prefix)
OPT_BOOLEAN(0, undefined, allow_undefined, N_(allow to
print `undefined` names)),
OPT_BOOLEAN(0, always, always,
N_(show abbreviated commit object as fallback)),
+ {
+ /* A Hidden OPT_BOOL */
+ OPTION_SET_INT, 0, peel-tag, peel_tag, NULL,
+ N_(dereference tags in the input (internal use)),
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1,
+ },
OPT_END(),
};
@@ -361,6 +367,15 @@ int cmd_name_rev(int argc, const char **argv, const char
*prefix)
if (cutoff commit-date)
cutoff = commit-date;
}
+
+ if (peel_tag) {
+ if (!commit) {
+ fprintf(stderr, Could not get commit for %s.
Skipping.\n,
+ *argv);
+ continue;
+ }
+ object = (struct object *)commit;
+ }
add_object_array(object, *argv, revs);
}
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 1d20854..c0e5b2a 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -186,4 +186,16 @@ test_expect_success 'name-rev with exact tags' '
test_cmp expect actual
'
+test_expect_success 'describe --contains with the exact tags' '
+ echo A^0 expect
+ tag_object=$(git rev-parse refs/tags/A)
+ git describe --contains $tag_object actual
+ test_cmp expect actual
+
+ echo A^0 expect
+ tagged_commit=$(git rev-parse refs/tags/A^0)
+ git describe --contains $tagged_commit actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.3.3-992-gf0e5e44
--
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: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
On 07/18/2013 05:49 PM, Torsten Bögershausen wrote: On 2013-07-18 19.50, Ramsay Jones wrote: Hmm, that looks good. :-D Torsten reported a performance boost using the win32 stat() implementation on a linux git repo (2s - 1s, if I recall correctly) on cygwin 1.7. Do you have a larger repo available to test? (I have a 5 years old Dual Core, 2.5 Ghz, 1 TB hard disk, Win XP, cygwin 1.7) On that machine I can see the performance boost. Which kind of computers are you guys using? SSD/hard disk ? How much RAM ? Which OS ? Is there a difference between Win XP, Win7, Win8? [snip] My previous results were from a Win 7 laptop, 2.7 GHz 2nd generation I7, 8 Gig Ram, 250 GByte spinning rust drive, all formatted NTFS. Here's some more results, running WinXP in VirtualBox on my older Linux laptop (2.5 GHz Penryn dual core, 500 GByte spinning rust, virtual file system is NTFS). First, results using Ramsay's last patch on pu adding the fast_lstat: Timing results are after first doing 5 'git status runs' to assure the cache is hot: % using the fast_lstat and friends... /usr/local/src/gittime git -c core.filemode=false status /dev/null real0m0.469s user0m0.062s sys 0m0.436s /usr/local/src/git /usr/local/src/gittime git -c core.filemode=true status /dev/null real0m0.719s user0m0.030s sys 0m0.686s /usr/local/src/git And now the same. but using Ramsay's first patch that removes all win32 stat stuff and forces everything to go through Cygwin's normal stat/fstat: % stat - with / without core.filemode, no win32 stats /usr/local/src/gittime git -c core.filemode=false status /dev/null real0m0.328s user0m0.093s sys 0m0.264s /usr/local/src/git /usr/local/src/gittime git -c core.filemode=true status /dev/null real0m0.625s user0m0.124s sys 0m0.500s /usr/local/src/git Unlike the results on the fast Win7 laptop, the above show statistically significant slow down from the fast_lstat approach. I'm just not seeing a case for the special case handling, and of course Junio has already voted with his preference of removing the special case stuff as well. Mark -- 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] git_mkstemps: correctly test return value of open()
From: Junio C Hamano gits...@pobox.com That's just a plain-vanilla part of POSIX shell behaviour, no? http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05 Close standard input is so weird I never thought it was Posix. In that case, we can eliminate the C helper program: diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh index 986b2a8..d427f3a 100755 --- a/t/t0070-fundamental.sh +++ b/t/t0070-fundamental.sh @@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file grep cannotwrite/test err ' +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' ' + git init + echo Test. test-file + git add test-file + git commit -m Message. - +' + test_expect_success 'check for a bug in the regex routines' ' # if this test fails, re-build git with NO_REGEX=1 test-regex diff --git a/wrapper.c b/wrapper.c index dd7ecbb..6a015de 100644 --- a/wrapper.c +++ b/wrapper.c @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode) template[5] = letters[v % num_letters]; v /= num_letters; fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd 0) + if (fd = 0) return fd; /* * Fatal error (EPERM, ENOSPC etc). Is this a sensible place to put this test? Dale -- 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] git add -e: Explicitly specify that patch should have no color
After this commit: 4c7f1819b3c142ace98269a556bc929c80e7c9fd make color.ui default to 'auto' the patch file for 'git add -e' receives all the color codes. This is because diffopt.use_color defaults to -1, which causes want_color to now return 'auto'. By explicitly setting use_color to 0, we can ensure the diff output has no color codes in it. Signed-off-by: Andrew Wong andrew.k...@gmail.com --- builtin/add.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/add.c b/builtin/add.c index f45d9d4..8266a9c 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -343,6 +343,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix) argc = setup_revisions(argc, argv, rev, NULL); rev.diffopt.output_format = DIFF_FORMAT_PATCH; + rev.diffopt.use_color = 0; DIFF_OPT_SET(rev.diffopt, IGNORE_DIRTY_SUBMODULES); out = open(file, O_CREAT | O_WRONLY, 0666); if (out 0) -- 1.8.3.3.755.gbf91598 -- 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] git p4 test: Check ignore files with client spec
This test confirms that a file can be ignored during git p4 sync if if is excluded in P4 client specification. Signed-off-by: Vitor Antunes vitor@gmail.com --- t/t9801-git-p4-branch.sh | 23 --- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh index 9730821..2bf142d 100755 --- a/t/t9801-git-p4-branch.sh +++ b/t/t9801-git-p4-branch.sh @@ -469,9 +469,11 @@ test_expect_success 'use-client-spec detect-branches skips branches setup' ' View: //depot/usecs/b1/... //depot/usecs/b3/... EOF - echo b3/b3-file3 b3/b3-file3 - p4 add b3/b3-file3 - p4 submit -d b3/b3-file3 + echo b3/b3-file3_1 b3/b3-file3_1 + echo b3/b3-file3_2 b3/b3-file3_2 + p4 add b3/b3-file3_1 + p4 add b3/b3-file3_2 + p4 submit -d b3/b3-file3_1 b3/b3-file3_2 ) ' @@ -487,6 +489,21 @@ test_expect_success 'use-client-spec detect-branches skips branches' ' ) ' +test_expect_success 'use-client-spec detect-branches skips files in branches' ' + client_view //depot/usecs/... //client/... \ + -//depot/usecs/b3/b3-file3_1 //client/b3/b3-file3_1 + test_when_finished cleanup_git + test_create_repo $git + ( + cd $git + git p4 sync --detect-branches --use-client-spec //depot/usecs@all + git checkout -b master p4/usecs/b3 + test_path_is_file b1-file1 + test_path_is_file b3-file3_2 + test_path_is_missing b3-file3_1 + ) +' + test_expect_success 'kill p4d' ' kill_p4d ' -- 1.8.3.2 -- 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] git_mkstemps: correctly test return value of open()
wor...@alum.mit.edu (Dale R. Worley) writes: From: Junio C Hamano gits...@pobox.com That's just a plain-vanilla part of POSIX shell behaviour, no? http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05 Close standard input is so weird I never thought it was Posix. In that case, we can eliminate the C helper program: diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh index 986b2a8..d427f3a 100755 --- a/t/t0070-fundamental.sh +++ b/t/t0070-fundamental.sh @@ -25,6 +25,13 @@ test_expect_success POSIXPERM,SANITY 'mktemp to unwritable directory prints file grep cannotwrite/test err ' +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' ' + git init + echo Test. test-file + git add test-file + git commit -m Message. - +' + Yup. I wonder how it would fail without the fix, though ;-) test_expect_success 'check for a bug in the regex routines' ' # if this test fails, re-build git with NO_REGEX=1 test-regex diff --git a/wrapper.c b/wrapper.c index dd7ecbb..6a015de 100644 --- a/wrapper.c +++ b/wrapper.c @@ -322,7 +322,7 @@ int git_mkstemps_mode(char *pattern, int suffix_len, int mode) template[5] = letters[v % num_letters]; v /= num_letters; fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd 0) + if (fd = 0) return fd; /* * Fatal error (EPERM, ENOSPC etc). Is this a sensible place to put this test? Dale -- 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] git_mkstemps: correctly test return value of open()
From: Junio C Hamano gits...@pobox.com +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' ' + git init + echo Test. test-file + git add test-file + git commit -m Message. - +' + Yup. I wonder how it would fail without the fix, though ;-) Eh, what? You could run it and see. The test script system will just say not ok for this test. If you execute those commands from a shell, you see: $ git init Initialized empty Git repository in /common/not-replicated/worley/temp/1/.git/ $ echo Test. test-file $ git add test-file $ git commit -m Message. - error: unable to create temporary sha1 filename : No such file or directory error: Error building trees $ Dale -- 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 2/2] git-svn: allow git-svn fetching to work using serf
On Jul 18, 2013, at 12:29, Jonathan Nieder wrote: (cc-ing Eric Wong, who maintains git-svn and knows both it and the libsvn perl bindings much better than I do) Kyle J. McKay wrote: David Rothenberger daver...@acm.org has determined the cause to be that ra_serf does not drive the delta editor in a depth-first manner [...]. Instead, the calls come in this order: Thanks. Sorry to nitpick, but the problem is not depth-first versus breadth-first versus random. Blaming the traversal order makes this completely confusing. The actual problem is that the driver asks us to keep multiple files open at a time. On Sun, 07 Jul 2013 18:00:40 GMT, Branko Čibej wrote: On 07.07.2013 19:40, Jonathan Nieder wrote: (cc-ing subversion's users@ list for advice) Kyle McKay wrote: On Jul 6, 2013, at 18:37, Jonathan Nieder wrote: Kyle McKay wrote: Begin forwarded message: [2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932 Ah, thanks for the context. It's still not clear to me how we know that ra_serf driving the editor in a non depth-first manner is the problem here. Has that explanation been confirmed somehow? [...] Since ra_serf makes multiple connections to the server (hard-coded to 4 prior to svn 1.8, defaults to 4 in svn 1.8 but can be set to between 1 and 8) it makes sense there would be multiple active calls to apply_textdelta if processing is done as results are received on the multiple connections. Ah, that's worrisome. Do I understand you correctly that to work with ra_serf in skelta mode, callers need to make their apply_textdelta callback thread-safe? No; the editor drive is single-threaded, but the order of the operations isn't strictly depth-first. Brane also describes this as a non-depth-first traversal order which is the root of the problem. If the order of operations were strictly depth-first, the previous file would end up being closed before the next one's opened. The approach taken in this patch would be racy if the driver calls us multiple times concurrently (since temp_acquire can fail). I believe it doesn't but haven't checked. Brane says the editor drive is single-threaded so that doesn't seem like a problem. -- 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: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
Mark Levedahl mleved...@gmail.com writes: Unlike the results on the fast Win7 laptop, the above show statistically significant slow down from the fast_lstat approach. I'm just not seeing a case for the special case handling, and of course Junio has already voted with his preference of removing the special case stuff as well. Please don't take what I said as any vote in this thread. I do not have a first-hand data to back anything up. I was primarily trying to see my understanding of the consensus of the thread was correct. If we can do without s/lstat/fast_lstat/ almost everywhere in the codebase, of course, I would be happier, as it would give us one less thing to worry about. If the assumptions like they were declining minority and only lose population over time, it is easy for them to revert the removal and keep going, and removal will not hurt them too much in the first place, only a few hundred milliseconds, that might trump the longer-term maintainability issue, and we may end up having to carry that win32 stat implementation a bit longer until these users all switch to Cygwin 1.7, but judging from the cvs binary seems to be built incorrectly incident the other day, it might be the case some users still hesitate to update, fearing that 1.7 series may not be solid enough, perhaps? -- 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 0/2] allow git-svn fetching to work using serf
Kyle J. McKay mack...@gmail.com writes: This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. ... Versions v2-v3 of the patch introduced a bug when attempting to change the _temp_cache function to use the new temp_is_locked function at the suggestion of a reviewer. Err, excuse me, is this meant to _replace_ what is already in 'next' for the past 6 days? Could you feed an incremental update, highlighting where the update improves compared to the previous attempt in the 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: [PATCH v4 2/2] git-svn: allow git-svn fetching to work using serf
Jonathan Nieder jrnie...@gmail.com wrote: (cc-ing Eric Wong, who maintains git-svn and knows both it and the libsvn perl bindings much better than I do) I doubt that's the case anymore. I've hardly looked at SVN in many years, now. Anyways, if the patches: 1) do not introduce regressions 2) fixes real problems I'm inclined to think they're OK... I'm sorry I can't help more, I had access to better drugs back then. -- 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/1] incremental update against 'next' branch
NOTE: This patch requires: 4e63dcc Git.pm: add new temp_is_locked function which is currently in next. Versions v2-v3 of the allow git-svn fetching to work using serf patch introduced a bug when attempting to change the Git.pm _temp_cache function to use the new temp_is_locked function at the suggestion of a reviewer. This patch reverts that change as the logic in _temp_cache isn't really conducive to using temp_is_locked because its tests are not exactly the same as the ones in temp_is_locked. Kyle J. McKay (1): Git.pm: revert _temp_cache use of temp_is_locked perl/Git.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.3 -- 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/1] Git.pm: revert _temp_cache use of temp_is_locked
When the temp_is_locked function was introduced, there was
a desire to make _temp_cache use it. Unfortunately due to the
various tests and logic flow involved changing the _temp_cache
function to use the new temp_is_locked function is problematic
as _temp_cache needs a slightly different test than is provided
by the temp_is_locked function.
This change reverts use of temp_is_locked in the _temp_cache
function and restores the original code that existed there
before the temp_is_locked function was added.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 0ba15b9..204fdc6 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1277,7 +1277,7 @@ sub _temp_cache {
my $temp_fd = \$TEMP_FILEMAP{$name};
if (defined $$temp_fd and $$temp_fd-opened) {
- if (temp_is_locked($name)) {
+ if ($TEMP_FILES{$$temp_fd}{locked}) {
throw Error::Simple(Temp file with moniker ' .
$name . ' already in use);
}
--
1.8.3
--
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 0/2] allow git-svn fetching to work using serf
On Jul 18, 2013, at 16:34, Junio C Hamano wrote: Kyle J. McKay mack...@gmail.com writes: This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. ... Versions v2-v3 of the patch introduced a bug when attempting to change the _temp_cache function to use the new temp_is_locked function at the suggestion of a reviewer. Err, excuse me, is this meant to _replace_ what is already in 'next' for the past 6 days? Could you feed an incremental update, highlighting where the update improves compared to the previous attempt in the log message? OK. I have sent out an incremental update against 'next' branch' patch based on how a set of recent incremental updates to 'next' was sent to the list on 2013-07-04. If that is not what you had in mind, I apologize in advance. -- 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
What's cooking in git.git (Jul 2013, #06; Thu, 18)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Quite a many topics are now in 'master', and 'next' has been shrinking in a reasonable pace, but there are some biggies remaining (including the ones that have not been even queued yet). Some may have to cook until the next cycle. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * bc/commit-invalid-utf8 (2013-07-09) 3 commits (merged to 'next' on 2013-07-11 at a2ee572) + commit: reject non-characters + commit: reject overlong UTF-8 sequences + commit: reject invalid UTF-8 codepoints Tighten up autodetection of UTF-8 encoded strings. * bc/push-match-many-refs (2013-07-08) 1 commit (merged to 'next' on 2013-07-11 at df4d56d) + remote.c: avoid O(m*n) behavior in match_push_refs Pushing to repositories with many refs employed O(m*n) algorithm where n is the number of refs on the receiving end. * bc/send-email-use-port-as-separate-param (2013-07-04) 1 commit (merged to 'next' on 2013-07-09 at a569eb5) + send-email: provide port separately from hostname Pass port number as a separate argument when send-email initializes Net::SMTP, instead of as a part of the hostname, i.e. host:port. This allows GSSAPI codepath to match with the hostname given. * bp/mediawiki-preview (2013-07-08) 7 commits (merged to 'next' on 2013-07-12 at 870890a) + git-remote-mediawiki: add preview subcommand into git mw + git-remote-mediawiki: add git-mw command + git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki + git-remote-mediawiki: update tests to run with the new bin-wrapper + git-remote-mediawiki: add a git bin-wrapper for developement + wrap-for-bin: make bin-wrappers chainable + git-remote-mediawiki: introduction of Git::Mediawiki.pm Add a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. I personally do not think this belongs to Git. If you are working on a set of AsciiDoc source files, you sure do want to locally format to preview what you will be pushing out, and if you are working on a set of C or Java source files, you do want to test it before pushing it out, too. That kind of thing belongs to your build script, not to your SCM. But I'll let it pass, as this is only a contrib/ thing. * cp/submodule-custom-update (2013-07-03) 1 commit (merged to 'next' on 2013-07-09 at 3d27516) + submodule update: allow custom command to update submodule working tree In addition to the choice from rebase, merge, or checkout-detach, allow a custom command to be used in submodule update to update the working tree of submodules. * es/overlapping-range-set (2013-07-09) 2 commits (merged to 'next' on 2013-07-11 at 3df5a94) + range_set: fix coalescing bug when range is a subset of another + t4211: fix broken test when one -L range is subset of another * fg/submodule-clone-depth (2013-07-03) 1 commit (merged to 'next' on 2013-07-09 at ab156f3) + Add --depth to submodule update/add Allow shallow-cloning of submodules with git submodule update. * jc/revert-clone-doc-update-for-push-from-shallow (2013-07-15) 1 commit + Revert git-clone.txt: remove the restriction on pushing from a shallow clone * jk/fetch-pack-many-refs (2013-07-02) 3 commits (merged to 'next' on 2013-07-09 at a53b7c7) + fetch-pack: avoid quadratic behavior in rev_list_push + commit.c: make compare_commits_by_commit_date global + fetch-pack: avoid quadratic list insertion in mark_complete Fetching between repositories with many refs employed O(n^2) algorithm to match up the common objects, which has been corrected. * jk/format-patch-from (2013-07-03) 2 commits (merged to 'next' on 2013-07-09 at 6ed86d5) + teach format-patch to place other authors into in-body From + pretty.c: drop const-ness from pretty_print_context git format-patch learned --from[=whom] option, which sets the From: header to the specified person (or the person who runs the command, if =whom part is missing) and move the original author information to an in-body From: header as necessary. * jk/in-pack-size-measurement (2013-07-12) 10 commits (merged to 'next' on 2013-07-12 at 5ba720f) + pack-revindex: radix-sort the revindex + pack-revindex: use unsigned to store number of objects + cat-file: split --batch input lines on whitespace + cat-file: add %(objectsize:disk) format atom + cat-file: add --batch-check=format + cat-file: refactor --batch option parsing + cat-file: teach --batch to stream blob objects + t1006: modernize output comparisons + teach sha1_object_info_extended a disk_size query + zero-initialize object_info structs (this branch is used by
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jul 18, 2013 at 3:35 PM, Junio C Hamano gits...@pobox.com wrote: Add a safety valve to fail git pull that does not explicitly specify what branch from which repository to integrate your history with, when it is neither a fast-forward or already up-to-date, until/unless the user expressed her preference between the two ways of integration. --- diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 24ab07a..86f5170 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -97,6 +97,14 @@ must be given before the options meant for 'git fetch'. Options related to merging ~~ +When `git pull` that does not explicitly specify what branch from +which repository is to be integrated with your history on the +command line, recent Git will refuse to work until you specify how +that integration should happen, either with a command line option +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` +or `branch.name.rebase`, which is the same as `--merge` +(`--rebase`) when set to `false` (`true`) respectively. This paragraph-long single sentence may be intimidating. Perhaps some simplification is possible: As a safety measure, bare `git pull` (without repository or branch) needs to be told how to integrate pulled changes with your history; either via `--merge` or `--rebase`. Also see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]. I intentionally omitted the true/false explanation of the configuration variables since the user can follow the link and read about them. It also may make sense to drop mention of those variables altogether since they are already described (including link) in the description of --rebase. I also intentionally omitted recent Git since it's rather nebulous. -- 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 7/6] diff: remove diff-files -q at Git 2.0 version boundary
This was inherited from show-diff -q that was invented to tell
comparison between the index and the working tree to ignore only
removals in 2005.
These days, it is spelled as --diff-filter=d.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* And this is the endgame.
diff-lib.c | 3 ---
diff-no-index.c | 8
diff.c | 8
diff.h | 2 --
4 files changed, 21 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 4634b29..872643f 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -89,9 +89,6 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
unsigned ce_option = ((option DIFF_RACY_IS_MODIFIED)
? CE_MATCH_RACY_IS_DIRTY : 0);
- if (option DIFF_SILENT_ON_REMOVED)
- handle_deprecated_show_diff_q(revs-diffopt);
-
diff_set_mnemonic_prefix(revs-diffopt, i/, w/);
if (diff_unmerged_stage 0)
diff --git a/diff-no-index.c b/diff-no-index.c
index a788a5f..98a9cf1 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -187,7 +187,6 @@ void diff_no_index(struct rev_info *revs,
{
int i, prefixlen;
int no_index = 0;
- unsigned deprecated_show_diff_q_option_used = 0;
const char *paths[2];
/* Were we asked to do --no-index explicitly? */
@@ -224,10 +223,6 @@ void diff_no_index(struct rev_info *revs,
int j;
if (!strcmp(argv[i], --no-index))
i++;
- else if (!strcmp(argv[i], -q)) {
- deprecated_show_diff_q_option_used = 1;
- i++;
- }
else if (!strcmp(argv[i], --))
i++;
else {
@@ -260,9 +255,6 @@ void diff_no_index(struct rev_info *revs,
revs-max_count = -2;
diff_setup_done(revs-diffopt);
- if (deprecated_show_diff_q_option_used)
- handle_deprecated_show_diff_q(revs-diffopt);
-
setup_diff_pager(revs-diffopt);
DIFF_OPT_SET(revs-diffopt, EXIT_WITH_STATUS);
diff --git a/diff.c b/diff.c
index 78819ba..2d0b5e3 100644
--- a/diff.c
+++ b/diff.c
@@ -3570,14 +3570,6 @@ static int parse_diff_filter_opt(const char *optarg,
struct diff_options *opt)
return 0;
}
-/* Used only by diff-files and diff --no-index */
-void handle_deprecated_show_diff_q(struct diff_options *opt)
-{
- warning('diff -q' and 'diff-files -q' are deprecated.);
- warning(Use 'diff --diff-filter=d' instead to ignore deleted
filepairs.);
- parse_diff_filter_opt(d, opt);
-}
-
int diff_opt_parse(struct diff_options *options, const char **av, int ac)
{
const char *arg = av[0];
diff --git a/diff.h b/diff.h
index 5237d63..a367207 100644
--- a/diff.h
+++ b/diff.h
@@ -341,8 +341,6 @@ extern int parse_rename_score(const char **cp_p);
extern long parse_algorithm_value(const char *value);
-extern void handle_deprecated_show_diff_q(struct diff_options *);
-
extern int print_stat_summary(FILE *fp, int files,
int insertions, int deletions);
extern void setup_diff_pager(struct diff_options *);
--
1.8.3.3-1001-gcfc78f3
--
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] Add the GIT_SENTINEL macro
Ramsay Jones ram...@ramsay1.demon.co.uk writes: The sentinel function attribute is not understood by versions of the gcc compiler prior to v4.0. At present, for earlier versions of gcc, the build issues 108 warnings related to the unknown attribute. In order to suppress the warnings, we conditionally define the GIT_SENTINEL macro to provide the sentinel attribute for gcc v4.0 and newer. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- This was built on the next branch It seems to apply well on the tip of jk/gcc-function-attributes. - This macro is not about git at all, so I'll edit the patch to call it GCC_ATTR_SENTINEL before applying. - Also I'll drop the (0) at the end. 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 6/6] diff: deprecate -q option to diff-files
Junio C Hamano wrote: We should remove the support for -q in Git 2.0. No. I hope you are teasing. I don't mind seeing support for -q dropped, but I really don't think it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some future release/ be ok? The patch text itself looks good. 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] Add the GIT_SENTINEL macro
Junio C Hamano wrote: It seems to apply well on the tip of jk/gcc-function-attributes. - This macro is not about git at all, so I'll edit the patch to call it GCC_ATTR_SENTINEL before applying. Would naming it something like LAST_ARG_MUST_BE_NULL instead make sense? That way, if some other compiler gains a different syntax for the same annotation, it would be possible to do #if defined(__GNUC__) __GNUC__ = 4 # define LAST_ARG_MUST_BE_NULL __attribute__((sentinel)) #elif defined(_MSC_VER) _MSC_VER 27 # define LAST_ARG_MUST_BE_NULL __declspec(lastargnull) #else # define LAST_ARG_MUST_BE_NULL #endif -- 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] TIG: Fix to reinstate proper operation with no arguments
On Thu, Jul 18, 2013 at 9:30 AM, Drew Northup n1xim.em...@gmail.com wrote:
Somehow this patch breaks the main view to not open the correct commit in
diff view when enter is pressed. Back to the debugger...
Does this (possibly white-space damaged) patch work for you?
diff --git a/tig.c b/tig.c
index ba9ba98..74a2928 100644
--- a/tig.c
+++ b/tig.c
@@ -3104,7 +3104,7 @@ format_expand_arg(struct format_context *format,
const char *name)
static bool
format_append_arg(struct format_context *format, const char
***dst_argv, const char *arg)
{
- format-bufpos = 0;
+ format-buf[0] = format-bufpos = 0;
while (arg) {
char *next = strstr(arg, %();
--
Jonas Fonseca
--
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
RESPOND URGENTLY!!
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels...@yahoo.com.hk. Have a pleasant day. George Daniels -- 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
