* Re: git describe not matching git log
From: Michael J Gruber @ 2012-11-29 14:06 UTC (permalink / raw)
To: Steven Penny; +Cc: git, Jeff King
In-Reply-To: <CAAXzdLWNb7E1qincviX5y_uEsT71bbepuUtLR7Q_+Exm8Od6yw@mail.gmail.com>
Steven Penny venit, vidit, dixit 29.11.2012 10:04:
> It seems "git describe" is not matching "git log" as detailed in the help, in
> some cases. From git describe --help
>
> [torvalds@g5 git]$ git describe parent
> v1.0.4-14-g2414721
>
> The number of additional commits is the number of commits which would
> be displayed by "git log v1.0.4..parent".
>
> GOOD
>
> $ git clone git://github.com/antirez/redis.git
>
> $ cd redis
>
> $ git describe unstable
> with-deprecated-diskstore-1050-g7383c3b
>
> $ git log --oneline with-deprecated-diskstore..unstable | wc
> 1050 11779 78709
>
> BAD
>
> $ git clone git://github.com/git/git.git
>
> $ cd git
>
> $ git describe master
> v1.8.0.1-264-g226dcb5
>
> $ git log --oneline v1.8.0.1..master | wc
> 260 1650 14154
>
This is due to date skew: git-describe uses "insert_by_date" when it
traverses the dag, and this can go wrong.
Interestingling, this seems to get fixed by using Jeff's generation
numbers and "insert_by_generation" instead, so it does seem go wrong for
226dcb5~60 or so. git-describe's logic is a bit convoluted and may
depend on how we insert when generation numbers are the same... Have to
do more testing.
Michael
^ permalink raw reply
* Ubuntu: gitweb always looks for projects in /var/cache/git (“404 - no projects found”)
From: Alfonso Muñoz-Pomer Fuentes @ 2012-11-29 13:55 UTC (permalink / raw)
To: git
I’ve discovered this weird behaviour in gitweb and documented a workaround in
StackOverflow:
http://stackoverflow.com/questions/13609475/ubuntu-gitweb-always-looks-for-projects-in-var-cache-git-404-no-projects-f
Basically, the variable $projectroot in gitweb.cgi in the beginning is reset to
the system default value in git_get_projects_list, when it is declared again.
Is this a known bug? Or am I missing something?
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Eric S. Raymond @ 2012-11-29 13:55 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: dev, git
In-Reply-To: <20121129134203.GJ3424@lp-shahaf.local>
Daniel Shahaf <danielsh@elego.de>:
> I don't see the kludge here --- git has a "author" != "committer"
> distinction, svn doesn't, so if you want to grow that distinction the
> most natural way is a new property. Storing additional information in
> svn:author is a separate issue.
See my advocacy to Branko of going to Internet-scoped IDs. The kludge
would be maintaining the local and Internet-scoped identifications
as different properties and having to decide which one to key on
ad-hoc. Nothing to do with the author/committer distinction.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* AW: reposurgeon now writes Subversion repositories
From: Markus Schaber @ 2012-11-29 13:43 UTC (permalink / raw)
To: esr@thyrsus.com, Daniel Shahaf
Cc: dev@subversion.apache.org, git@vger.kernel.org
In-Reply-To: <20121129114637.GB9264@thyrsus.com>
Hi,
Von: Eric S. Raymond [mailto:esr@thyrsus.com]
> > How does reposurgeon handle empty directories with (node) properties?
>
> Currently by ignoring all of them except svn:ignore, which it turns
> into .gitignore content on the gitspace side. And now vice-versa, too.
>
> Not clear what else it *could* do. I'd take suggestions.
AFAIR, SvnBridge (which bridges SVN to Team Foundation Server for CodePlex) creates a hidden .svnproperties file where all the properties of the directory and files are stored.
I'm not really sure, but maybe this could be used as some standard to bridge svn properties to non-svn VCSes.
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com
CODESYS internet forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Daniel Shahaf @ 2012-11-29 13:42 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: dev, git
In-Reply-To: <20121129114637.GB9264@thyrsus.com>
(note, other half of the thread is on dev@svn only..)
Eric S. Raymond wrote on Thu, Nov 29, 2012 at 06:46:37 -0500:
> Daniel Shahaf <danielsh@elego.de>:
> > You might also seek community consensus to reserve an svn:foo name for
> > the "original author" property --- perhaps svn:original-author --- so
> > that reposurgeon and other git->svn tools can interoperate in the way
> > they transfer the "original author" information.
>
> OK. But I like the idea of letting the users set their own author
> content string better. Instead of another layer of kluges, why
I don't see the kludge here --- git has a "author" != "committer"
distinction, svn doesn't, so if you want to grow that distinction the
most natural way is a new property. Storing additional information in
svn:author is a separate issue.
> > > Subversion has a concept of "flows"; that is, named segments of
> > > history corresponding to files or directories that are created when
> > > the path is added, cloned when the path is copied, and deleted when
> > > the path is deleted. This information is not preserved in import
> > > streams or the internal representation that reposurgeon uses. Thus,
> > > after editing, the flow boundaries of a Subversion history may be
> > > arbitrarily changed.
> > >
> > > This is me being obsessive about documenting the details. I think it
> > > is doubtful that most Subversion users even know flows exist.
> >
> > I think you're saying that adds might turn into copies, and vice-versa.
> > That is something users would notice --- it is certainly exposed in the
> > UI --- even though node-id's are not exposed to clients.
>
> I'm saying nobody thinks of flows when they do branch copies. It's
> not just that users don't see node IDs, it's that no part of most users'
> mental model of how Subversion works resembles them.
I'm still not sure what you have in mind. I note that 'svn log' and
'svn blame' cross both file copies and branch creation --- that's one
effect of "'svn cp foo bar; svn ci' causes bar to be related to foo".
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
From: Matthieu Moy @ 2012-11-29 12:33 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream. While we're there,
also escape newlines, but I don't think we can get them from MediaWiki
pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..e7a0e7b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,13 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+ my $path = shift;
+ $path =~ s/"/\\"/g;
+ $path =~ s/\n/\\n/g;
+ return $path;
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +745,17 @@ sub import_file_revision {
print STDOUT "from refs/mediawiki/$remotename/master^0\n";
}
if ($content ne DELETED_CONTENT) {
- print STDOUT "M 644 inline $title.mw\n";
+ print STDOUT "M 644 inline " .
+ fe_escape_path($title . ".mw") . "\n";
literal_data($content);
if (%mediafile) {
- print STDOUT "M 644 inline $mediafile{title}\n";
+ print STDOUT "M 644 inline "
+ . fe_escape_path($mediafile{title}) . "\n";
literal_data_raw($mediafile{content});
}
print STDOUT "\n\n";
} else {
- print STDOUT "D $title.mw\n";
+ print STDOUT "D " . fe_escape_path($title . ".mw") . "\n";
}
# mediawiki revision number in the git note
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: reposurgeon now writes Subversion repositories
From: Eric S. Raymond @ 2012-11-29 11:46 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: dev, git
In-Reply-To: <20121129075829.GE3424@lp-shahaf.local>
Daniel Shahaf <danielsh@elego.de>:
> > Subversion's metadata doesn't have separate author and committer
> > properties, and doesn't store anything but a Unix user ID as
> > attribution. I don't see any way around this.
>
> You're not fully informed, then.
>
> 1) svn:author revprops can contain any UTF-8 string. They are not
> restricted to Unix user id's. (For example, they can contain full
> names, if the administrator so chooses.)
Right. At one point during the development of this feature I was
accidentally storing the full email field in this property. So I
already knew that this is allowed at some level.
And, I have no trouble believing that svn log will cheerfully echo
anything that I choose to stuff in that field.
But...
(1) How much work would it be it to set up a Subversion installation
so that when I svn commit, the tool does the right thing, e.g. puts
a DVCS-style fullname/email string in there?
(2) Have the tools been tested for bugs arising from having whitespace
in that data?
Really, if it's actually easy to set up DVCS-style globally unique IDs you
Subversion guys ought to be shouting it from the housetops. The absence
of this capability is a serious PITA in several situations, including
for example migrating projects between forges.
RFC: If I wrote a patch that let Subversion users set their own
content string for the author field in ~/.subversion/config, would
you merge it? Because I'd totally write that.
> 2) You can define custom revision properties. In your case, the easiest
> way would be to set an reposurgeon:author property, alongside the
> svn:author property.
Yeah, sure, I've assumed all along this wouldn't break if I tried it.
If I actually thought you guys were capable of designing a data model
with a perfectly general-looking store of key/value pairs and then
arbitrarily restricting the key set so I couldn't do that, I'd almost
have to find each and every one of you and kick your asses into next
Tuesday on account of blatant stupidity. I have no such plans :-).
But...what good does this capability do? OK, it would assist
round-tripping back to gitspace, but while that's kind of cool I don't
see any help for a normal Subversion workflow here.
> You might also seek community consensus to reserve an svn:foo name for
> the "original author" property --- perhaps svn:original-author --- so
> that reposurgeon and other git->svn tools can interoperate in the way
> they transfer the "original author" information.
OK. But I like the idea of letting the users set their own author
content string better. Instead of another layer of kluges, why
shouldn't Subversion join the DVCSes in the happy land of
Internet-scoped attributions?
> How does reposurgeon handle empty directories with (node) properties?
Currently by ignoring all of them except svn:ignore, which it turns
into .gitignore content on the gitspace side. And now vice-versa, too.
Not clear what else it *could* do. I'd take suggestions.
> > Subversion has a concept of "flows"; that is, named segments of
> > history corresponding to files or directories that are created when
> > the path is added, cloned when the path is copied, and deleted when
> > the path is deleted. This information is not preserved in import
> > streams or the internal representation that reposurgeon uses. Thus,
> > after editing, the flow boundaries of a Subversion history may be
> > arbitrarily changed.
> >
> > This is me being obsessive about documenting the details. I think it
> > is doubtful that most Subversion users even know flows exist.
>
> I think you're saying that adds might turn into copies, and vice-versa.
> That is something users would notice --- it is certainly exposed in the
> UI --- even though node-id's are not exposed to clients.
I'm saying nobody thinks of flows when they do branch copies. It's
not just that users don't see node IDs, it's that no part of most users'
mental model of how Subversion works resembles them.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Michael J Gruber @ 2012-11-29 11:40 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, git, jk, stimming
In-Reply-To: <1354126970-5356-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 28.11.2012 19:22:
>> Hi Ralf,
>>
>> This is the middle third of my review. Sorry for the long wait! I hope
>> it can still be useful.
>>
>
> Hi Thomas,
>
> no problem. Thanks for your review. Of course it's very useful.
> Some of the mistakes I made are so obvious that I can't say what
> I've had in mind when translation these messages :/ But some aren't,
> so thanks for the further explanations within your review.
>
>> I don't really share your apparent aversion to just using "<n>" :-)
> I don't really have one :) so I'm fine with using <n>.
>
>> This would be a good time to settle on a good translation for
>> "rewriting". Perhaps "neu schreiben". "Überschreiben" to me implies
> On some other places we actually use "neu schreiben".
How about "umschreiben"? "neu schreiben" is more like "write from
scratch", whereas "rewrite" is more often about taking a given base and
modifying it.
>>> -msgstr ""
>>> +msgstr "erzeugt kleinere Pakete"
>>
>> Smaller is not really the point: they are packs that do not have the
> [...]
>> You could call them "abgespeckt" ;-)
> I used "dünner"!?
>
> Furthermore I've unified the translation of "email" to "Email",
> not "eMail". You'll see the result below. I hope I haven't missed
> something.
>
> Thanks,
> Ralf
>
> ---
> po/de.po | 95 ++++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 47 insertions(+), 48 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index fe6e8cf..1a75ea2 100644
> --- a/po/de.po
> +++ b/po/de.po
...
> #: builtin/fsck.c:608
> msgid "git fsck [options] [<object>...]"
> @@ -4521,7 +4521,7 @@ msgstr "erzeugt Kopfknoten des Referenzprotokolls (Standard)"
>
> #: builtin/fsck.c:620
> msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""
"alternate objects" (hopefully) don't change much, so that "wechselnde"
is misleading.
Is there a set translation standard for the "alternative object store"
mechanism in git (alternates)? Otherwise "alternative Objekte" may be
choice which is close to the original and conveys the aspect that they
are objects from an alternative store.
> #: builtin/grep.c:817
> msgid "indicate hit with exit status without output"
> -msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
> +msgstr "zeigt Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
maybe "zeigt Übereinstimmungen nur durch Beendigungsstatus an"
"mit" sounds like "including", "additionally". Also, nothing is shown
("zeigt"), but something is indicated ("zeigt an").
> #: builtin/log.c:102
> msgid "decorate options"
> -msgstr "Ausgabeoptionen"
> +msgstr "decorate Optionen"
"decorate-Optionen" (unless we want to match the standard set by the bad
old K&R translation ;) )
> #: builtin/log.c:1098
> msgid "add To: header"
> -msgstr "fügt Kopfteil \"To:\" hinzu"
> +msgstr "fügt \"To:\" Header hinzu"
Here and in the following I'd a "-", e.g.
msgstr "fügt \"To:\"-Header hinzu"
> #: builtin/log.c:1100
> msgid "add Cc: header"
> -msgstr "fügt Kopteil \"Cc:\" hinzu"
> +msgstr "fügt \"Cc:\" Header hinzu"
...
> -"lädt Konfiguration für <Kommando> beim Überschreiben von Versionen "
> +"lädt Konfiguration für <Kommando> beim Neuschreiben von Versionen "
> "(impliziert --stdin)"
"Umschreiben" (if that becomes the agreed upon term for "rewrite").
Just my two Pfennig ;)
Michael
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-29 10:38 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Steven Michalske, Thomas Berg, Jeff King,
Shawn Pearce, git
In-Reply-To: <CAMP44s3ShoR7iR5QLYn_u+u_nNGnS1jumpt+iseWYKx0PX9UEA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Steven Michalske <smichalske@gmail.com> writes:
> >
> >> Would having arbitrary key value pairs be useful in the git data
> >> model?
> >
> > My answer to the question is that it is harmful to the data model,
> > but the benefit of going against the data model _may_ outweigh the
> > downside. It is all relative.
>
> If git doesn't provide the capability, people will keep using the
> commit message to store that extra information, which I would think is
> even more harmful. An standard 'commit-extra' note or something would
> help deal with that.
Agreed.
My use case for a capability like this is one of the more common ones.
I want to be able to store a fossil commit-ID inherited from another
VCS outside the commit comment. The absence of a key/value store forces
me into some annoying kludges.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Branko Čibej @ 2012-11-29 10:31 UTC (permalink / raw)
To: dev; +Cc: Eric S. Raymond, git
In-Reply-To: <20121129075829.GE3424@lp-shahaf.local>
On 29.11.2012 08:58, Daniel Shahaf wrote:
> I think you're saying that adds might turn into copies, and
> vice-versa. That is something users would notice --- it is certainly
> exposed in the UI --- even though node-id's are not exposed to clients.
... yet. But there are plans underway to expose them.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
^ permalink raw reply
* Re: Please pull l10n updates for 1.8.1 round 1
From: Jiang Xin @ 2012-11-29 9:40 UTC (permalink / raw)
To: Trần Ngọc Quân
Cc: Junio C Hamano, Git List, Peter Krefting,
Nguyễn Thái Ngọc Duy
In-Reply-To: <50b70eb8.46c5440a.38b1.3f66@mx.google.com>
Hi,
New pull request with updates on Vietnamese for git 1.8.1 from Tran:
The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to f93483ac94c21660422a19175f67cd3f8e87c531:
Merge git://github.com/vnwildman/git (2012-11-29 16:25:40 +0800)
----------------------------------------------------------------
Jiang Xin (2):
l10n: Update git.pot (14 new, 3 removed messages)
Merge git://github.com/vnwildman/git
Peter Krefting (1):
l10n: Update Swedish translation (1975t0f0u)
Tran Ngoc Quan (2):
l10n: vi.po: update to git-v1.7.12-437-g1084f
l10n: vi.po: Update follow git-v1.8.0-273-g2d242
po/git.pot | 1224 ++++++++++++++++++++------------------
po/sv.po | 1246 ++++++++++++++++++++------------------
po/vi.po | 1951 +++++++++++++++++++++++++++++++-----------------------------
3 files changed, 2305 insertions(+), 2116 deletions(-)
2012/11/29 Trần Ngọc Quân <vnwildman@gmail.com>:
> Hello JX,
> You missing pull from my repo (2 commits instead of one, v1.7 and v1.8): dcc52a0449c7ee10690e23152e63b9798f8a332f
>
> $ git log -n 2
> commit dcc52a0449c7ee10690e23152e63b9798f8a332f
> Author: Tran Ngoc Quan <vnwildman@gmail.com>
> Date: Sat Nov 24 07:37:35 2012 +0700
>
> l10n: vi.po: Update follow git-v1.8.0-273-g2d242
>
> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
>
> commit 131fa518f10521b4a534863331decbfef2875f24
> Author: Tran Ngoc Quan <vnwildman@gmail.com>
> Date: Wed Oct 31 08:19:59 2012 +0700
>
> l10n: vi.po: update to git-v1.7.12-437-g1084f
>
> * updated all new messages (1967t0f0u)
> * make quote become more good-looking
>
> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
>
> https://github.com/vnwildman/git.git master
> Thanks,
> Trần Ngọc Quân
>
> -----Original Message-----
> From: Jiang Xin [mailto:worldhello.net@gmail.com]
> Sent: Thursday, November 29, 2012 8:19 AM
> To: Junio C Hamano
> Cc: Git List; Peter Krefting; Trần Ngọc Quân; Nguyễn Thái Ngọc Duy
> Subject: Please pull l10n updates for 1.8.1 round 1
>
> Hi, Junio
>
> The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
>
> Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po.git master
>
> for you to fetch changes up to 647d5183b8dc36b38d19c7a3f388108f245b11d3:
>
> l10n: Update Swedish translation (1975t0f0u) (2012-11-23 08:59:11 +0100)
>
> ----------------------------------------------------------------
> Jiang Xin (1):
> l10n: Update git.pot (14 new, 3 removed messages)
>
> Peter Krefting (1):
> l10n: Update Swedish translation (1975t0f0u)
>
> Tran Ngoc Quan (1):
> l10n: vi.po: update to git-v1.7.12-437-g1084f
>
> po/git.pot | 1224 ++++++++++++++++++++++++----------------------
> po/sv.po | 1246 +++++++++++++++++++++++++----------------------
> po/vi.po | 1597 ++++++++++++++++++++++++++++++------------------------------
> 3 files changed, 2097 insertions(+), 1970 deletions(-)
>
> --
> Jiang Xin
>
^ permalink raw reply
* git describe not matching git log
From: Steven Penny @ 2012-11-29 9:04 UTC (permalink / raw)
To: git
It seems "git describe" is not matching "git log" as detailed in the help, in
some cases. From git describe --help
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
The number of additional commits is the number of commits which would
be displayed by "git log v1.0.4..parent".
GOOD
$ git clone git://github.com/antirez/redis.git
$ cd redis
$ git describe unstable
with-deprecated-diskstore-1050-g7383c3b
$ git log --oneline with-deprecated-diskstore..unstable | wc
1050 11779 78709
BAD
$ git clone git://github.com/git/git.git
$ cd git
$ git describe master
v1.8.0.1-264-g226dcb5
$ git log --oneline v1.8.0.1..master | wc
260 1650 14154
^ permalink raw reply
* [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Johannes Sixt @ 2012-11-29 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
From: Johannes Sixt <j6t@kdbg.org>
The earlier change 74faaa16 (Fix "git diff --stat" for interesting - but
empty - file changes) needed to change the count of differing files
because the executable-bit changes of two empty files are now counted.
On file systems that do not record the executable bit, however, the old
file count was actually correct (and the updated tests fail) because the
mode change cannot be diagnosed by looking at the file system alone.
Change the mode not only on the file system, but also in the index;
compare the new state against the commit, so that the tests do not depend
on the file system's ability to record the executable bit, when possible.
The exception is the test for unmerged entries, which does depend on the
file system; we have to skip it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 11/27/2012 22:21, schrieb Junio C Hamano:
> It turns out that there are at least two bugs in the diffstat
> counting code. This series comes on top of the earlier 74faaa1 (Fix
> "git diff --stat" for interesting - but empty - file changes,
> 2012-10-17) to fix them.
The tests still fail on Windows. I am not sure whether there is a
difference in comparing the file system against the index or a commit.
If there is, then the updated tests might not test the same thing.
-- Hannes
t/t4049-diff-stat-count.sh | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 37f50cd..9e29e71 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -15,7 +15,7 @@ test_expect_success 'setup' '
test_expect_success 'limit output to 2 (simple)' '
git reset --hard &&
- chmod +x c d &&
+ test_chmod +x c d &&
echo a >a &&
echo b >b &&
cat >expect <<-\EOF
@@ -24,13 +24,13 @@ test_expect_success 'limit output to 2 (simple)' '
...
4 files changed, 2 insertions(+)
EOF
- git diff --stat --stat-count=2 >actual &&
+ git diff --stat --stat-count=2 HEAD >actual &&
test_i18ncmp expect actual
'
test_expect_success 'binary changes do not count in lines' '
git reset --hard &&
- chmod +x c d &&
+ test_chmod +x c d &&
echo a >a &&
echo b >b &&
cat "$TEST_DIRECTORY"/test-binary-1.png >d &&
@@ -40,11 +40,11 @@ test_expect_success 'binary changes do not count in lines' '
...
4 files changed, 2 insertions(+)
EOF
- git diff --stat --stat-count=2 >actual &&
+ git diff --stat --stat-count=2 HEAD >actual &&
test_i18ncmp expect actual
'
-test_expect_success 'exclude unmerged entries from total file count' '
+test_expect_success FILEMODE 'exclude unmerged entries from total file count' '
git reset --hard &&
echo a >a &&
echo b >b &&
--
1.8.0.1.1524.gaf6675c
^ permalink raw reply related
* [PATCH] completion: fix warning for zsh
From: Felipe Contreras @ 2012-11-29 8:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
Otherwise the user might get something like:
git-completion.sh:2466: command not found: compdef
If this script is loaded before compinit. The script would work either
way, but let's not be more annoying to the user.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index af13fcc..0b77eb1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2404,6 +2404,8 @@ __gitk_main ()
if [[ -n ${ZSH_VERSION-} ]]; then
echo "WARNING: this script is deprecated, please see git-completion.zsh" 1>&2
+ autoload -U +X compinit && compinit
+
__gitcomp ()
{
emulate -L zsh
--
1.8.0.1
^ permalink raw reply related
* Re: reposurgeon now writes Subversion repositories
From: Daniel Shahaf @ 2012-11-29 7:58 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: dev, git
In-Reply-To: <20121129055946.2D7B84065F@snark.thyrsus.com>
Eric S. Raymond wrote on Thu, Nov 29, 2012 at 00:59:45 -0500:
> In summary, Subversion repository histories do not round-trip through
> reposurgeon editing. File content changes are preserved but some
> metadata is unavoidably lost. Furthermore, writing out a DVCS history
> in Subversion also loses significant portions of its metadata.
>
> Writing a Subversion repository or dump stream discards author
> information, the committer's name, and the hostname part of the commit
> address; only the commit timestamp and the local part of the
> committer's email address are preserved, the latter becoming the
> Subversion author field. However, reading a Subversion repository and
> writing it out again will preserve the author fields.
>
> Subversion's metadata doesn't have separate author and committer
> properties, and doesn't store anything but a Unix user ID as
> attribution. I don't see any way around this.
You're not fully informed, then.
1) svn:author revprops can contain any UTF-8 string. They are not
restricted to Unix user id's. (For example, they can contain full
names, if the administrator so chooses.)
2) You can define custom revision properties. In your case, the easiest
way would be to set an reposurgeon:author property, alongside the
svn:author property.
You might also seek community consensus to reserve an svn:foo name for
the "original author" property --- perhaps svn:original-author --- so
that reposurgeon and other git->svn tools can interoperate in the way
they transfer the "original author" information.
I note that one can set revision properties at commit time:
svn commit -m logmsg --with-revprop svn:original-author="Patch Submitter <foo@bar.example>"
> Empty directories aren't represented in import streams. Consequently,
> reading and writing Subversion repositories preserves file content,
> but not empty directories. It is also not guaranteed that after
> editing a Subverson repository that the sequence of directory
> creations and deletions relative to other operations will be
> identical; the only guarantee is that enclosing directories will be
> created before any files in them are.
How does reposurgeon handle empty directories with (node) properties?
% svnadmin create r
% svnmucc -mm -U file://$PWD/r mkdir foo propset k v foo
> Subversion has a concept of "flows"; that is, named segments of
> history corresponding to files or directories that are created when
> the path is added, cloned when the path is copied, and deleted when
> the path is deleted. This information is not preserved in import
> streams or the internal representation that reposurgeon uses. Thus,
> after editing, the flow boundaries of a Subversion history may be
> arbitrarily changed.
>
> This is me being obsessive about documenting the details. I think it
> is doubtful that most Subversion users even know flows exist.
>
I think you're saying that adds might turn into copies, and vice-versa.
That is something users would notice --- it is certainly exposed in the
UI --- even though node-id's are not exposed to clients.
>
Cheers
Daniel
^ permalink raw reply
* RE: Please pull l10n updates for 1.8.1 round 1
From: Trần Ngọc Quân @ 2012-11-29 7:28 UTC (permalink / raw)
To: 'Jiang Xin', 'Junio C Hamano'
Cc: 'Git List', 'Peter Krefting',
'Nguyễn Thái Ngọc Duy'
In-Reply-To: <CANYiYbHfhBXbLEEKdpJkhp+wY9-AJ1JkjfO62W3c+dm8qpk7_g@mail.gmail.com>
Hello JX,
You missing pull from my repo (2 commits instead of one, v1.7 and v1.8): dcc52a0449c7ee10690e23152e63b9798f8a332f
$ git log -n 2
commit dcc52a0449c7ee10690e23152e63b9798f8a332f
Author: Tran Ngoc Quan <vnwildman@gmail.com>
Date: Sat Nov 24 07:37:35 2012 +0700
l10n: vi.po: Update follow git-v1.8.0-273-g2d242
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
commit 131fa518f10521b4a534863331decbfef2875f24
Author: Tran Ngoc Quan <vnwildman@gmail.com>
Date: Wed Oct 31 08:19:59 2012 +0700
l10n: vi.po: update to git-v1.7.12-437-g1084f
* updated all new messages (1967t0f0u)
* make quote become more good-looking
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
https://github.com/vnwildman/git.git master
Thanks,
Trần Ngọc Quân
-----Original Message-----
From: Jiang Xin [mailto:worldhello.net@gmail.com]
Sent: Thursday, November 29, 2012 8:19 AM
To: Junio C Hamano
Cc: Git List; Peter Krefting; Trần Ngọc Quân; Nguyễn Thái Ngọc Duy
Subject: Please pull l10n updates for 1.8.1 round 1
Hi, Junio
The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po.git master
for you to fetch changes up to 647d5183b8dc36b38d19c7a3f388108f245b11d3:
l10n: Update Swedish translation (1975t0f0u) (2012-11-23 08:59:11 +0100)
----------------------------------------------------------------
Jiang Xin (1):
l10n: Update git.pot (14 new, 3 removed messages)
Peter Krefting (1):
l10n: Update Swedish translation (1975t0f0u)
Tran Ngoc Quan (1):
l10n: vi.po: update to git-v1.7.12-437-g1084f
po/git.pot | 1224 ++++++++++++++++++++++++----------------------
po/sv.po | 1246 +++++++++++++++++++++++++----------------------
po/vi.po | 1597 ++++++++++++++++++++++++++++++------------------------------
3 files changed, 2097 insertions(+), 1970 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-29 7:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steven Michalske, Thomas Berg, Jeff King, Shawn Pearce,
Eric Raymond, git
In-Reply-To: <7va9u0sx26.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Steven Michalske <smichalske@gmail.com> writes:
>
>> Would having arbitrary key value pairs be useful in the git data
>> model?
>
> My answer to the question is that it is harmful to the data model,
> but the benefit of going against the data model _may_ outweigh the
> downside. It is all relative.
If git doesn't provide the capability, people will keep using the
commit message to store that extra information, which I would think is
even more harmful. An standard 'commit-extra' note or something would
help deal with that.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-29 7:11 UTC (permalink / raw)
To: Steven Michalske
Cc: Thomas Berg, Felipe Contreras, Jeff King, Shawn Pearce,
Eric Raymond, git
In-Reply-To: <E4C993F4-B7A4-4CB6-A9EA-BFE98BE3A381@gmail.com>
Steven Michalske <smichalske@gmail.com> writes:
> Would having arbitrary key value pairs be useful in the git data
> model?
My answer to the question is that it is harmful to the data model,
but the benefit of going against the data model _may_ outweigh the
downside. It is all relative.
The first of very small number of principles of the git data model
is that the object name is derived solely from the contents, hence
we can tell two different things apart with object names without
looking at object contents.
This is actively broken by adding "junk" fields left and right.
Adding arbitrary pieces of data that are optional (and largely
ignored by core operations) means you can record objects with
essentially the same contents under different object names, so
object names no longer help us telling two moral-equivalent objects
apart.
But "if two objects have different names, they are not the same"
does not have to be the only and the absolute truth in all contexts;
the world is not so black and white. Depending on the application
and the context, you may want to treat two things that are not the
same as equivalents.
For example, at the blob level, two blob objects that store the same
text (say, one original and the other typed in double-space) would
be different objects and have different object names, but you may
want to treat them as "equivalents" (not same but interchangeable),
by applying textconv filter to normalize their contents when
comparing them. We still keep the "two objects with different names
are different" principle, but at the same time, allow users to treat
them as equivalent in specific contexts.
Introducing a hack to exclude selective "junk" fields from hashing
done for object name computation is not a solution and is out of the
question, but that does not necessarily mean that commit objects
should never be extended with new types of header fields. When a
commit object is made with a "junk" field, it will have a name that
is different from the one it would get without the "junk" field, but
the benefit of the ability to store extra data _may_ outweigh the
downside of having to always compare the contents of two objects
with different names to find out that they are different but
equivalent.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-29 6:16 UTC (permalink / raw)
To: Steven Michalske
Cc: Thomas Berg, Felipe Contreras, Junio C Hamano, Jeff King,
Shawn Pearce, git
In-Reply-To: <E4C993F4-B7A4-4CB6-A9EA-BFE98BE3A381@gmail.com>
Steven Michalske <smichalske@gmail.com>:
> Would having arbitrary key value pairs be useful in the git data
> model? We could have ones that affect the sha1 and others that are
> transparent.
My tools would have several uses for these.
bzr's implementation of import streams has a commit-propperties extension.
reposurgeon can read, display.. and manipulate these key/value pairs.
I do wish they were in core git.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* reposurgeon now writes Subversion repositories
From: Eric S. Raymond @ 2012-11-29 5:59 UTC (permalink / raw)
To: dev, git
This is something that probably doesn't happen very often -
cross-posting to the Subversion and git dev lists that is on-topic for
both :-).
The repo head version of reposurgeon can now write Subversion
repositories from its common git-import-stream-based representation of
repository histories, as well as reading them in. This joins full
support for git, hg, and bzr; it means that in theory reposurgeon
could now be used to move revision histories from these systems to
Subversion, as well as the other way around.
(For those of you who have been living under a rock, reposurgeon is a
multi-VCS surgery and conversion tool. Since 2.x it does a more
intelligent job of lifting from Subversion to anything else than any
other tool I know of. Much more at <http://www.catb.org/esr/reposurgeon/>.)
Presently, writing (as opposed to reading) Subversion repos is more of
a stunt than a real production technique, and may always remain so.
It has serious limitations. I am posting because I think the details
of those limitations will be of some technical interest to both
Subversion and git developers.
Indented paragraphs is the documentation from reposurgeon's manual
page. I have added some further notes.
In summary, Subversion repository histories do not round-trip through
reposurgeon editing. File content changes are preserved but some
metadata is unavoidably lost. Furthermore, writing out a DVCS history
in Subversion also loses significant portions of its metadata.
Writing a Subversion repository or dump stream discards author
information, the committer's name, and the hostname part of the commit
address; only the commit timestamp and the local part of the
committer's email address are preserved, the latter becoming the
Subversion author field. However, reading a Subversion repository and
writing it out again will preserve the author fields.
Subversion's metadata doesn't have separate author and committer
properties, and doesn't store anything but a Unix user ID as
attribution. I don't see any way around this.
Import-stream timestamps have 1-second granularity. The subsecond
parts of Subversion commit timestamps will be lost on their way through
reposurgeon.
Unavoidable in moving from Subversion to git import streams, and one
of two places where git's data model requires us to throw away
information.
However, I think I could preserve this information in a
Subversion-to-Subversion editing scenario by storing the incoming
timestamps as floats and only truncating them on import-stream output,
leaving the subseconds in place for Subversion output.
Empty directories aren't represented in import streams. Consequently,
reading and writing Subversion repositories preserves file content,
but not empty directories. It is also not guaranteed that after
editing a Subverson repository that the sequence of directory
creations and deletions relative to other operations will be
identical; the only guarantee is that enclosing directories will be
created before any files in them are.
When reading a Subversion repository, reposurgeon discards the special
directory-copy nodes associated with branch creations. These can't be
recreated if and when the repository is written back out to
Subversion; rather, each branch copy node from the original translates
into a branch creation plus the first set of file modifications on the
branch.
In theory, I could relax the rules of reposurgeon's internal
representation so that empty directory-creation and deletion nodes are
not discarded at read time but only when outputting a git event stream.
That would bring Subversion repositories closer to round-tripping, but
not get all the way there. One problem is botched branch copies -
directory copies with cp(1) followed by Subversion add operations.
This is not an uncommon malformation; reposurgeon takes it in stride,
treating these as though they had been real branch copies and
simplifying the backlinks appropriately.
When reading a Subversion repository, reposurgeon also automatically
breaks apart mixed-branch commits.
It has to. These just can't be represented in the import-stream model of
branching.
Because of the preceding two points, it is not guaranteed that
even revision numbers will be stable when a Subversion repository
is read in and then written out!
So not only can Subversion repos fail to round-trip exactly, in the
presence of lots of branch copies and mixed-branch commits the
relationship between the read-in and written out revision numbers
could get pretty unpredictable.
Subversion repositories are always written with a standard
(trunk/tags/branches) layout. Thus, a repository with a nonstandard
shape that has been analyzed by reposurgeon won't be written out with
the same shape.
In particular, this means linear Subversion repositories with no trunk
(an organization some smaller projects used to use and might still)
will turn into branchy repos with trunk on the way out.
Subversion has a concept of "flows"; that is, named segments of
history corresponding to files or directories that are created when
the path is added, cloned when the path is copied, and deleted when
the path is deleted. This information is not preserved in import
streams or the internal representation that reposurgeon uses. Thus,
after editing, the flow boundaries of a Subversion history may be
arbitrarily changed.
This is me being obsessive about documenting the details. I think it
is doubtful that most Subversion users even know flows exist.
Bugs: Presently, writing out a history to a Subversion repository does
not create mergeinfo properties representing branch merges. It also
loses all information about lightweight tags (though annotated tags
are turned into Subversion-style directory copies). These bugs will
probably be fixed in future reposurgeon releases.
I'm also not sure the present code handles branchiness exactly right.
My next task is to write a test suite for this new feature.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The Constitution is not neutral. It was designed to take the
government off the backs of the people.
-- Justice William O. Douglas
^ permalink raw reply
* Re: Please pull l10n updates for 1.8.1 round 1
From: Junio C Hamano @ 2012-11-29 5:59 UTC (permalink / raw)
To: Jiang Xin
Cc: Git List, Peter Krefting, Trần Ngọc Quân,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CANYiYbHfhBXbLEEKdpJkhp+wY9-AJ1JkjfO62W3c+dm8qpk7_g@mail.gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 00/11] alternative unify appending of sob
From: Junio C Hamano @ 2012-11-29 5:56 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Brandon Casey, git, Brandon Casey
In-Reply-To: <CACsJy8AfaETfikvB+zON4iiX2HBehJg-xX2GGmKYHueX8rv3qw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Mon, Nov 26, 2012 at 8:45 AM, Brandon Casey <drafnel@gmail.com> wrote:
>
>> I've integrated Duy's series with a few minor tweaks. I added a couple
>> of additional tests to t4014 and corrected one of the tests which had
>> incorrect behavior. I think his sign-off's should still be valid, so I
>> kept them in. Sorry that I've been slow, and now the two of us are stepping
>> on each other's toes, but Duy please take a look and let me know if there's
>> anything you dislike.
>
> I'm still not sure whether format-patch should follow cherry-pick's
> rule in appending sob. If it does, it probably makes more sense to fix
> the sequencer.c code then delete log-tree.c (not fixes on log-tree.c
> then delete it). I see that your changes pass all the new tests I
> added in format-patch so sequencer.c is probably good enough,
> log-tree.c changes are probably not needed. Feel free take over the
> series :-)
After reading the series over, I agree with the above.
Patch #9 that fixes the copy in log-tree.c only to discard it in
patch #11 does not seem to be the best organization of the series.
Instead, perhaps we can salvage the tests in patch #9 (but mark
failing ones as expecting failure) without updating the one in
log-tree.c, adjust prototype in patch #10 (still broken in
log-tree.c) to avoid having to make changes to the callers in patch
#11, and then conclude the series with #11?
Other than the code in patches #06 and #07 that I already commented
on, i.e. assignments in if () condition that make it harder to
follow the logic, I did not find anything majorly objectionable in
the series.
Thanks for a pleasant read.
^ permalink raw reply
* Re: [PATCH 04/11] sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
From: Brandon Casey @ 2012-11-29 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git@vger.kernel.org, pclouds@gmail.com
In-Reply-To: <7v8v9ltgxn.fsf@alter.siamese.dyndns.org>
On 11/28/2012 4:02 PM, Junio C Hamano wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> -static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
>> +static int is_rfc2822_line(const char *buf, int len)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < len; i++) {
>> + int ch = buf[i];
>> + if (ch == ':')
>> + break;
>> + if (isalnum(ch) || (ch == '-'))
>> + continue;
>> + return 0;
>> + }
>> +
>> + return 1;
>> +}
>> +
>> +static int is_cherry_pick_from_line(const char *buf, int len)
>> +{
>> + return (strlen(cherry_picked_prefix) + 41) <= len &&
>> + !prefixcmp(buf, cherry_picked_prefix);
>> +}
>> +
>> +static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
>> {
>> - int ch;
>> int hit = 0;
>> - int i, j, k;
>> + int i, k;
>> int len = sb->len - ignore_footer;
>> const char *buf = sb->buf;
>>
>> @@ -1039,15 +1061,9 @@ static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
>> ; /* do nothing */
>> k++;
>>
>> - for (j = 0; i + j < len; j++) {
>> - ch = buf[i + j];
>> - if (ch == ':')
>> - break;
>> - if (isalnum(ch) ||
>> - (ch == '-'))
>> - continue;
>> + if (!(is_rfc2822_line(buf+i, k-i) ||
>> + is_cherry_pick_from_line(buf+i, k-i)))
>> return 0;
>> - }
>> }
>> return 1;
>> }
>
> Refactored code looks vastly more readable, but I think the
> is_cherry_pick_from_line() function (by the way, shouldn't it be
> named is_cherry_picked_from_line()?
Yes.
> ) shows its ambivalence. It
> insists that the line has to be long enough to hold 40-hex object
> name plus a closing parenthesis, but it only makes sure that the
> prefix matches, without checking if the line has 40-hex object name,
> or the object name is immediately followed by a closing parenthesis.
> It also does not care if there are other garbage after it.
>
> If the code is trying to be strict to avoid misidentification, then
> the check should be tightened (i.e. require the known fixed length,
> make sure get_sha1_hex() is happy, 41st byte is a close parenthesis
> that is followed by the end of line). If the code is trying to be
> more lenient to allow people hand-editing the cherry-picked-from
> line that was generated, the check could be loosened (people may
> truncate the 40-hex down to 12-hex or something).
>
> I cannot read from this code which one was intended; the code must
> make up its mind, whichever way (I do not have a strong preference).
The intention was a stricter-type match, but implemented somewhat
lazily. Part of me doesn't think that anyone should need to modify
the string that 'cherry-pick -x' adds and that a strict match is
appropriate. The other part of me doesn't want to reject a line that
looks like "(cherry picked from ...)" line that has a trimmed sha1
inside.
I think I'll submit a somewhat loosened check.
>> +test_expect_success 'cherry-pick -x -s adds sob when last sob doesnt match committer' '
>
> Is the title of this test appropriate? It looks like it is making
> sure we do not add an extra blank line after the existing footer to
> me.
It's really just part of the series of tests that checks for correct
operation when "the last sob doesn't match committer". This test
has a few elements in it:
* existing sob footer contains the committer's sob, but not last.
ensure that we don't refrain from appending a sob just because
one already exists in the footer.
* ensure extra blank isn't inserted after existing footer and
"(cherry picked from..."
* ensure a blank isn't inserted between "(cherry picked from..."
and new sob
The title of the test is me trying to fit "correctly adds \"(cherry
picked from...\" and sob when footer contains committer's sob but
not last" within a single line.
>> + pristine_detach initial &&
>> + sha1=`git rev-parse mesg-with-footer^0` &&
>> + git cherry-pick -x -s mesg-with-footer &&
>> + cat <<-EOF >expect &&
>> + $mesg_with_footer
>> + (cherry picked from commit $sha1)
>> + Signed-off-by: $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>
>> + EOF
>> + git log -1 --pretty=format:%B >actual &&
>> + test_cmp expect actual
>> +'
>> +
>
>> +test_expect_success 'cherry-pick -x -s adds sob even when trailing sob exists for committer' '
>> + pristine_detach initial &&
>> + sha1=`git rev-parse mesg-with-footer-sob^0` &&
>> + git cherry-pick -x -s mesg-with-footer-sob &&
>> + cat <<-EOF >expect &&
>> + $mesg_with_footer_sob
>> + (cherry picked from commit $sha1)
>> + Signed-off-by: $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>
>> + EOF
>> + git log -1 --pretty=format:%B >actual &&
>> + test_cmp expect actual
>> +'
>
> For people on the sideline, $mesg_with_footer_sob ends with s-o-b by
> the same "$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>" we are adding
> here. This is probably a sensible thing to do.
>
> One thing I am not so happy about this whole "(cherry picked from"
> thing (and I am again agreeing with Linus who made me change the
> default long time ago not to add this line by default) is this. If
> you use "cherry-pick -s -x $commit" to transplant a commit from an
> unrelated part of the history, you will get the object name in the
> resulting commit. But you can do the same in at least two different
> ways. The easiest is:
>
> git format-patch -1 --stdout $commit | git am -s3
>
> and a bit closer to what "cherry-pick" does is:
>
> git checkout $commit^0 &&
> git rebase --onto @{-1} HEAD^ &&
> git checkout -B @{-1}
>
> i.e. rebase the single commit on top of the branch you were on.
>
> In either way, you don't get "cherry picked from", even though you
> just did the moral equivalent of it. Also we need to realize that
> the first one is essentially what happens all the time here; the "|"
> is implemented by the mailing list. And nobody misses "cherry
> picked from" to point at the original commit object, which is
> useless for the recipient of the resulting commit.
>
> But that is an orthogonal issue.
Are you suggesting that people shouldn't use 'cherry-pick -x' at all?
I agree that it is useless to use -x when the commit that will be
referenced will not be available as part of the permanent history
of the project.
I do however think it is useful to add a reference to the original
commit when back- or forward- porting a commit. I think it adds
a little visibility to the commit to say that it was not originally
implemented on top of the base it is built on. I find it helpful
to examine the original implementation (the referenced commit) when
verifying the correctness or attempting to understand the ported
commit.
-Brandon
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Please pull l10n updates for 1.8.1 round 1
From: Jiang Xin @ 2012-11-29 1:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git List, Peter Krefting, Trần Ngọc Quân,
Nguyễn Thái Ngọc Duy
Hi, Junio
The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po.git master
for you to fetch changes up to 647d5183b8dc36b38d19c7a3f388108f245b11d3:
l10n: Update Swedish translation (1975t0f0u) (2012-11-23 08:59:11 +0100)
----------------------------------------------------------------
Jiang Xin (1):
l10n: Update git.pot (14 new, 3 removed messages)
Peter Krefting (1):
l10n: Update Swedish translation (1975t0f0u)
Tran Ngoc Quan (1):
l10n: vi.po: update to git-v1.7.12-437-g1084f
po/git.pot | 1224 ++++++++++++++++++++++++----------------------
po/sv.po | 1246 +++++++++++++++++++++++++----------------------
po/vi.po | 1597 ++++++++++++++++++++++++++++++------------------------------
3 files changed, 2097 insertions(+), 1970 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH v7 p2 1/2] fast-export: don't handle uninteresting refs
From: Max Horn @ 2012-11-29 1:16 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1354141440-26534-2-git-send-email-felipe.contreras@gmail.com>
On 28.11.2012, at 23:23, Felipe Contreras wrote:
> They have been marked as UNINTERESTING for a reason, lets respect that.
>
> Currently the first ref is handled properly, but not the rest:
>
> % git fast-export master ^uninteresting ^foo ^bar
All these refs are assumed to point to the same object, right? I think it would be better if the commit message stated that explicitly. To make up for the lost space, you could then get rid of one of the four refs, I think three are sufficient to drive the message home ;-).
<snip>
> The reason this happens is that before traversing the commits,
> fast-export checks if any of the refs point to the same object, and any
> duplicated ref gets added to a list in order to issue 'reset' commands
> after the traversing. Unfortunately, it's not even checking if the
> commit is flagged as UNINTERESTING. The fix of course, is to do
> precisely that.
Hm... So this might be me being a stupid n00b (I am not yet that familiar with the internal rep of things in git and all...)... but I found the "precisely that" par very confusing, because right afterwards, you say:
>
> However, in order to do it properly we need to get the UNINTERESTING flag
> from the command line ref, not from the commit object.
So this sounds like you are saying "we do *precisely* that, except we don't, because it is more complicated, so we actually don't do this *precisely*, just manner of speaking..."
Some details here are beyond my knowledge, I am afraid, so I have to resort to guess: In particular it is not clear to me why the "however" part pops up: Reading it makes it sound as if the commit object also carries an UNINTERESTING flag, but we can't use it because of some reason (perhaps it doesn't have the semantics we need?), so we have to look at revs.pending instead. Right? Wrong? Or is it because the commit objects actually do *not* carry the UNINTERESTING bits, hence we need to look at revs.pending. Or is it due to yet another reason?
I would find it helpful if that could be clarified. E.g. like so:
"The fix is to add such a check. However, we cannot just use the UNINTERESTING flag of the commit object, because INSERT-REASON."
or
"The fix is to add such a check. However, the commit object does not contain the UNINTERESTING flag directly."
or something.
Anyway, other than these nitpicky questions, this whole thing looks very logical to me, description and code alike. I also played around with tons of "fast-export" invocations, with and without this patch, and it seems to do what the description says. Finally, I went to the various long threads discussion prior versions of this patch, in particular those starting at
http://thread.gmane.org/gmane.comp.version-control.git/208725
and
http://thread.gmane.org/gmane.comp.version-control.git/209355/focus=209370
These contained some concerns. Sadly, several of those discussions ultimately degenerated into not-so-pleasant exchanges :-(, and my impression is that as a result some people are not so inclined to comment on these patches anymore at all. Which is a pity :-(. But overall, it seems this patch makes nothing worse, but fixes some things; and it is simple enough that it shouldn't make future improvements harder.
So *I* at least am quite happy with this, it helps me! My impression is that Felipe's latest patch addresses most concerns people raised by means of an improved description. I couldn't find any in those threads that I feel still applies -- but of course those people should speak for themselves, I am simply afraid they don't want to be part of this anymore :-(.
Still, for what little it might be worth, I think this patch is good and a real improvement. I hope it can be merged soon.
Cheers,
Max
> Fortunately we
> can simply use revs.pending, which contains all the information we need
> for get_tags_and_duplicates(), plus the ref flag. This way the rest of
> the positive refs will remain untouched; it's only the negative ones
> that change in behavior.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> builtin/fast-export.c | 11 +++++++----
> t/t5801-remote-helpers.sh | 8 ++++++++
> t/t9350-fast-export.sh | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 191936c..2547e6c 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -474,18 +474,21 @@ static void handle_tag(const char *name, struct tag *tag)
> (int)message_size, (int)message_size, message ? message : "");
> }
>
> -static void get_tags_and_duplicates(struct object_array *pending,
> +static void get_tags_and_duplicates(struct rev_cmdline_info *info,
> struct string_list *extra_refs)
> {
> struct tag *tag;
> int i;
>
> - for (i = 0; i < pending->nr; i++) {
> - struct object_array_entry *e = pending->objects + i;
> + for (i = 0; i < info->nr; i++) {
> + struct rev_cmdline_entry *e = info->rev + i;
> unsigned char sha1[20];
> struct commit *commit;
> char *full_name;
>
> + if (e->flags & UNINTERESTING)
> + continue;
> +
> if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
> continue;
>
> @@ -681,7 +684,7 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)
> if (import_filename && revs.prune_data.nr)
> full_tree = 1;
>
> - get_tags_and_duplicates(&revs.pending, &extra_refs);
> + get_tags_and_duplicates(&revs.cmdline, &extra_refs);
>
> if (prepare_revision_walk(&revs))
> die("revision walk setup failed");
> diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
> index 12ae256..ece8fd5 100755
> --- a/t/t5801-remote-helpers.sh
> +++ b/t/t5801-remote-helpers.sh
> @@ -162,4 +162,12 @@ test_expect_failure 'pushing without marks' '
> compare_refs local2 HEAD server HEAD
> '
>
> +test_expect_success 'push all with existing object' '
> + (cd local &&
> + git branch dup2 master &&
> + git push origin --all
> + ) &&
> + compare_refs local dup2 server dup2
> +'
> +
> test_done
> diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
> index 1f59862..c8e41c1 100755
> --- a/t/t9350-fast-export.sh
> +++ b/t/t9350-fast-export.sh
> @@ -454,4 +454,34 @@ test_expect_success 'test bidirectionality' '
> git fast-import --export-marks=marks-cur --import-marks=marks-cur
> '
>
> +cat > expected << EOF
> +blob
> +mark :13
> +data 5
> +bump
> +
> +commit refs/heads/master
> +mark :14
> +author A U Thor <author@example.com> 1112912773 -0700
> +committer C O Mitter <committer@example.com> 1112912773 -0700
> +data 5
> +bump
> +from :12
> +M 100644 :13 file
> +
> +EOF
> +
> +test_expect_success 'avoid uninteresting refs' '
> + > tmp-marks &&
> + git fast-export --import-marks=tmp-marks \
> + --export-marks=tmp-marks master > /dev/null &&
> + git tag v1.0 &&
> + git branch uninteresting &&
> + echo bump > file &&
> + git commit -a -m bump &&
> + git fast-export --import-marks=tmp-marks \
> + --export-marks=tmp-marks ^uninteresting ^v1.0 master > actual &&
> + test_cmp expected actual
> +'
> +
> test_done
> --
> 1.8.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox