tiffany uk - The Engagement ring Women Dream about
The name connected with [url=http://www.tiffanyandcoringsoutlet.co.uk/]tiffany uk[/url] truly would mean status and comfort. And, that is exactly what provides them web site demand such high prices for their rings. Keep in the mind that when buying a Tiffany call, that the Tiffany look and brand tend to be of what you\'re buying compared to the product itself. Diamonds aided by the same clarity and quality of them in rings from Tiffany\'s are obtainable elsewhere, in a large number of cases, up to forty to 70 % less than just what exactly Tiffany charges for his or her fantastic rings. Certainly, there's no denying that Tiffany rings are elegant. However, in all honesty, one can obtain diamonds with extremely comparable quality for fewer. http://www.tiffanyandcoringsoutlet.co.uk -- View this message in context: http://git.661346.n2.nabble.com/tiffany-uk-The-Engagement-ring-Women-Dream-about-tp7572341.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reposurgeon now writes Subversion repositories
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 -- To unsubscribe from this list: send the line 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] completion: fix warning for zsh
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.contre...@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 12
+ autoload -U +X compinit compinit
+
__gitcomp ()
{
emulate -L zsh
--
1.8.0.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] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Johannes Sixt j...@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 j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull l10n updates for 1.8.1 round 1
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 vnwild...@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 vnwild...@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 vnwild...@gmail.com commit 131fa518f10521b4a534863331decbfef2875f24 Author: Tran Ngoc Quan vnwild...@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 vnwild...@gmail.com https://github.com/vnwildman/git.git master Thanks, Trần Ngọc Quân -Original Message- From: Jiang Xin [mailto:worldhello@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 -- To unsubscribe from this list: send the line 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: reposurgeon now writes Subversion repositories
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 -- To unsubscribe from this list: send the line 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: Millisecond precision in timestamps?
Felipe Contreras felipe.contre...@gmail.com: On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano gits...@pobox.com wrote: Steven Michalske smichal...@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 -- To unsubscribe from this list: send the line 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] l10n: de.po: translate 825 new messages
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 KR 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 -- To unsubscribe from this list: send the line 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: reposurgeon now writes Subversion repositories
Daniel Shahaf danie...@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 -- To unsubscribe from this list: send the line 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-remote-mediawiki: escape double quotes and LF in file names
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@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
--
To unsubscribe from this list: send the line 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: reposurgeon now writes Subversion repositories
(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 danie...@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 -- To unsubscribe from this list: send the line 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: reposurgeon now writes Subversion repositories
Daniel Shahaf danie...@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 -- To unsubscribe from this list: send the line 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 describe not matching git log
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 2601650 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: reposurgeon now writes Subversion repositories
Hi, Von: Eric S. Raymond [mailto:e...@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.scha...@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 -- To unsubscribe from this list: send the line 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: highlighting commits touching path with globs doesn't work for files list
Hi GIT Gurus, Highlighting files (in patch view) and commits which modified those files is a really nice feature to have. Often it is needed to highlight based on a glob expression for files, e.g. '*Makefile*' -- that seems to highlight the commits but files in the patch view are no longer highlighted, which significantly reduces usefulness of such a feature. Also, those choices (Exact/IgnCase/Regexp) seems to have no relation with the edit box when looking for touching path files, so shouldn't it be somehow disabled/emptied to avoid users trying to create the ultimate filepattern regexp for no good reason? (the same for next field on where to search through -- All Fields/... ) ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To unsubscribe from this list: send the line 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] If `egrep` is aliased, temporary disable it in bash.completion
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac at...@redhat.com
Signed-off-by: Holger Arnold holge...@gmail.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0960acc..79073c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS= $'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
--
Adam Tkac, Red Hat, Inc.
--
To unsubscribe from this list: send the line 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] DESTDIR support in contrib/subtree/Makefile
Signed-off-by: Adam Tkac at...@redhat.com --- It is a good habit in Makefiles to honor DESTDIR variable to support `make DESTDIR=/instalroot install` syntax. Comments are welcomed. Regards, Adam contrib/subtree/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 05cdd5c..36ae3e4 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH) doc: $(GIT_SUBTREE_DOC) install: $(GIT_SUBTREE) - $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir) + $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir) install-doc: install-man install-man: $(GIT_SUBTREE_DOC) - $(INSTALL) -m 644 $^ $(man1dir) + $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) xmlto -m $(MANPAGE_NORMAL_XSL) man $^ -- 1.8.0 -- Adam Tkac, Red Hat, Inc. -- To unsubscribe from this list: send the line 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] git-submodule update: Add --commit option
This option triggers automatic commits when `submodule update` changes
any gitlinked submodule SHA-1s. The commit message contains a
`shortlog` summary of the changes for each changed submodule.
---
On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:
BTW, I am more and more convinced that an automatically manufactured
commit on update with --branch should be the default. What do other
think? Sascha raised a concern that he would not want this, but as far as
I understood he let the CI-server do that so I see no downside to
natively adding that to git. People who want to manually craft those
commits can still amend the generated commit. Since this is all about
helping people keeping their submodules updated why not go the full way?
Here's a first pass (without documentation) for automatic commits on
submodule updates. There have been a number of requests for
automatically-committed submodule updates due to submodule upstreams.
This patch shows how you can do that (if applied with my `submodule
update --remote` series), and reuse the same logic to automatically
commit changes due to local submodule changes (as shown here in the
new test).
I think the logic is pretty good, but the implementation is pretty
ugly due to POSIX shell variable limitations. I'm basically trying to
pass an array of [(name, sm_path, sha1, subsha1), ...] into
commit_changes(). I though about perling-out in commit_changes(), but
I lack sufficient perl-fu to know how to tie clear_local_git_env, cd,
and shortlog up in a single open2 call. If anyone can give me some
implementation pointers, that would be very helpful.
This is against v1.8.0 (without my --remote series). To apply on top
of the --remote series, you'd have to save the original gitlinked
$sha1 and use that original value when constructing changed_modules.
I can attach this to the end of the --remote series if desired, but I
think this patch could also stand on its own.
Obviously this still needs documentation, etc., but I wanted feedback
on the implementation before I started digging into that.
Cheers,
Trevor
---
git-submodule.sh| 67 -
t/t7406-submodule-update.sh | 19 +
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..d9a59af 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename $0 | sed -e 's/-/ /')
USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--]
repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference repository] [--merge] [--recursive] [--] [path...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--commit] [--rebase] [--reference repository] [--merge] [--recursive] [--]
[path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n]
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--] [path...]
@@ -21,6 +21,7 @@ require_work_tree
command=
branch=
force=
+commit=
reference=
cached=
recursive=
@@ -240,6 +241,52 @@ module_clone()
}
#
+# Commit changed submodule gitlinks
+#
+# $1 = name-a;sha1-a;subsha1-a\n[name-b;sha1-b;subsha1-b\n...]
+#
+commit_changes()
+{
+ echo commiting $1
+ OIFS=$IFS
+ IFS=;
+ paths=$(echo $1 |
+ while read name sm_path sha1 subsha1
+ do
+ echo $sm_path
+ done
+ )
+ names=$(echo $1 |
+ while read name sm_path sha1 subsha1
+ do
+ printf ' %s' $name
+ done
+ )
+ summary=$(eval_gettext Updated submodules:)$names
+ body=$(echo $1 |
+ while read name sm_path sha1 subsha1
+ do
+ if test $name = $sm_path
+ then
+ printf 'Changes to %s:\n\n' $name
+ else
+ printf 'Changes to %s (%s):\n\n' $name
$sm_path
+ fi
+ (
+ clear_local_git_env
+ cd $sm_path
+ git shortlog ${sha1}..${subsha1} ||
+ die $(eval_gettext Unable to generate
shortlog in submodule path '\$sm_path')
+ )
+ done
+ )
+ IFS=$OIFS
+ message=$(printf '%s\n\n%s\n' $summary $body)
+ echo message: [$message]
+ git commit -m $message $paths
+}
+
+#
# Add a new submodule to the working tree, .gitmodules and the index
#
# $@ = repo path
@@ -515,6 +562,9 @@ cmd_update()
-f|--force)
Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
Johannes Sixt j.s...@viscovery.net writes: 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. The hunks in the patch look fine. The last one that tests unmerged entries do not have to have chmod if it gives you trouble (you would need to reduce number of files from 4 to 3 if you go that route, I think). -- To unsubscribe from this list: send the line 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] git-submodule update: Add --commit option
On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote: + test a = b This kills the test (with --immediate) so you can look at the generated commit. If you actually want the test to pass (e.g. if this becomes a PATCH and not an RFC), this line should be removed. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
Matthieu Moy matthieu@imag.fr writes:
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@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;
+}
Is this sufficient?
My reading of the big comment at the beginning of fast-import.c is
that you would also want to quote each backslash; otherwise a
character (or an octal) after it will be taken as a C-style quoted
special letter, no?
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
--
To unsubscribe from this list: send the line 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] git-submodule update: Add --commit option
On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote: + test $(git log -1 --oneline) = bbdbe2d Updated submodules: submodule s/bbdbe2d/cd69713/ I forgot to update the SHA-1 here after tweaking the commit message format. I'd like to rewrite this test so it won't use the SHA-1, but this was the quickest way to check that the commit message and gitlink were both changed appropriately. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Millisecond precision in timestamps?
Eric S. Raymond e...@thyrsus.com writes: Felipe Contreras felipe.contre...@gmail.com: On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano gits...@pobox.com wrote: Steven Michalske smichal...@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. 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. That is exactly why I said it is all relative. If it helps your application, you can weigh the pros-and-cons yourself and choose to throw junk extended header fields in the commit objects you create, using hash-object (or commit-tree). You can read it out using cat-file and do whatever you want to do with it, and modern Git (v1.5.0 was from early 2007) and tools that are designed to work with Git know to ignore such junk field. The absence of a key/value store forces me into some annoying kludges. Do not do annoying kludge, then. Come up with a method to encode your list of (key,value) tuples into a single string, throw a custom extra header after all the standard header fields in, perhaps like this: tree 0664b9c82d87269b335ff78f32d0e4a504f58cfc author A U Thor aut...@example.xz 135599 +0900 committer C O Mitter commit...@example.xz 135599 +0900 encoding iso-2022-jp reposurgeon-metadata your-serialized-list-of-key-value-tuples second-line-of-such-serialization third-line-of-such-serialization My first commit Signed-off-by: A U Thor aut...@example.xz Signed-off-by: C O Mitter commit...@example.xz -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
Junio C Hamano gits...@pobox.com writes:
+sub fe_escape_path {
+my $path = shift;
+$path =~ s//\\/g;
+$path =~ s/\n/\\n/g;
+return $path;
+}
Is this sufficient?
My reading of the big comment at the beginning of fast-import.c is
that you would also want to quote each backslash;
Nice catch, thanks.
Also, I was lacking the double-quotes around $path. In my defense, I had
only read the doc, not the code, and git-fast-import.txt was less
complete than fast-import.c. New patch follows, fixing the doc too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v2] git-remote-mediawiki: escape , \, and LF in file names
A mediawiki page can contain, and even start with a character, we have
to escape it when generating the fast-export stream, as well as \
character. 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@imag.fr
---
contrib/mw-to-git/git-remote-mediawiki | 16 +---
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh | 26 ++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..094129d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,14 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+my $path = shift;
+$path =~ s/\\//g;
+$path =~ s//\\/g;
+$path =~ s/\n/\\n/g;
+return '' . $path . '';
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +746,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
diff --git a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
index 246d47d..b6405ce 100755
--- a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
+++ b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
@@ -318,4 +318,30 @@ test_expect_success 'git push with \ in format control' '
'
+test_expect_success 'fast-import meta-characters in page name (mw - git)' '
+ wiki_reset
+ wiki_editpage \file\_\\_foo expect to be called \file\_\\_foo
false
+ git clone mediawiki::'$WIKI_URL' mw_dir_21
+ test_path_is_file mw_dir_21/\file\_\\_foo.mw
+ wiki_getallpage ref_page_21
+ test_diff_directories mw_dir_21 ref_page_21
+'
+
+
+test_expect_success 'fast-import meta-characters in page name (git - mw) ' '
+ wiki_reset
+ git clone mediawiki::'$WIKI_URL' mw_dir_22
+ (
+ cd mw_dir_22
+ echo this file is called \file\_\\_foo.mw \file\_\\_foo
+ git add .
+ git commit -am file \file\_\\_foo
+ git pull
+ git push
+ )
+ wiki_getallpage ref_page_22
+ test_diff_directories mw_dir_22 ref_page_22
+'
+
+
test_done
--
1.8.0.319.g8abfee4
--
To unsubscribe from this list: send the line 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] git-fast-import.txt: improve documentation for quoted paths
The documentation mentionned only newlines and double quotes as characters needing escaping, but the backslash also needs it. Also, the documentation was not clearly saying that double quotes around the file name were required (double quotes in the examples could be interpreted as part of the sentence, not part of the actual string). Signed-off-by: Matthieu Moy matthieu@imag.fr --- Documentation/git-fast-import.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 6603a7a..35b909c 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -558,8 +558,9 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +If an `LF`, backslash or double quote must be encoded into `path` +shell-style quoting should be used, and the complete name should be +surrounded with double quotes e.g. `path/with\n, \\ and \ in it`. The value of `path` must be in canonical form. That is it must not: -- 1.8.0.319.g8abfee4 -- To unsubscribe from this list: send the line 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] If `egrep` is aliased, temporary disable it in bash.completion
Adam Tkac at...@redhat.com writes:
Subject: Re: [PATCH v2] If `egrep` is aliased, temporary disable it in
bash.completion
The code does not seem to do anything special if it is not aliased,
though, so If ... part does not sound correct; perhaps you meant
just in case egrep is aliased to something totally wacky or
something?
The script seems to use commands other than 'egrep' that too can be
aliased to do whatever unexpected things. How does this patch get
away without backslashing them all, like
\echo ...
\sed ...
\test ...
\: comment ...
\git args ...
and still fix problems for users? Can't the same solution you would
give to users who alias one of the above to do something undesirable
be applied to those who alias egrep?
Puzzled...
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac at...@redhat.com
Signed-off-by: Holger Arnold holge...@gmail.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0960acc..79073c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS= $'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[StGit PATCH] Include emacs and vim contribs in source tarball
This will enable downstream distros to package them. Signed-off-by: Zane Bitter zbit...@redhat.com --- MANIFEST.in |3 +++ 1 file changed, 3 insertions(+) diff --git a/MANIFEST.in b/MANIFEST.in index c94eef6..a80f013 100644 --- a/MANIFEST.in +++ b/MANIFEST.in @@ -9,6 +9,9 @@ include examples/gitconfig include contrib/*.sh include contrib/*.bash include contrib/stg-* +include contrib/Makefile +include contrib/stgit.el +recursive-include contrib/vim *.vim include t/t*.sh t/t*/* t/Makefile t/README include Documentation/*.txt Documentation/Makefile Documentation/*.conf include Documentation/build-docdep.perl Documentation/callouts.xsl -- To unsubscribe from this list: send the line 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] If `egrep` is aliased, temporary disable it in bash.completion
Junio C Hamano gits...@pobox.com writes: Adam Tkac at...@redhat.com writes: Subject: Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion The code does not seem to do anything special if it is not aliased, though, so If ... part does not sound correct; perhaps you meant just in case egrep is aliased to something totally wacky or something? The script seems to use commands other than 'egrep' that too can be aliased to do whatever unexpected things. How does this patch get away without backslashing them all, like \echo ... \sed ... \test ... \: comment ... \git args ... and still fix problems for users? Can't the same solution you would give to users who alias one of the above to do something undesirable be applied to those who alias egrep? Puzzled... Sorry for having been more snarky than necessary (blame it to lack of caffeine). What I was trying to get at were: * I have this suspicion that this patch exists only because you saw somebody who aliases egrep to something unexpected by the use of it in this script, and egrep *happened* to be the only such unreasonable alias. The reporter may not have aliased echo or sed away, or the aliases to these command *happened* to produce acceptable output (even though it might have been slightly different from unaliased one, the difference *happened* not to matter for the purpose of this script). * To the person who observes the same aliasing breakage due to his aliasing sed to something else, you would solve his problem by telling him don't do that, then. If that is the solution, why wouldn't it work for egrep? * The next person who aliased other commands this script uses in such a way that the behaviour of the alias differs sufficiently from the unaliased version, you will have to patch the file again, with the same backslashing. This patch is not a solution, but a band-aid that only works for a particular case you *happened* to have seen. * A complete solution that follows the direction this patch suggests would involve backslashing *all* commands that can potentially aliased away. Is that really the direction we would want to go in (answer: I doubt it)? Is that the only approach to solve this aliasing issue (answer: I don't know, but we should try to pursue it before applying a band-aid that is not a solution)? Is there a way to tell bash do not alias-expand from here up to there? Perhaps shopt -u expand_aliases upon entry and restore its original value when we exit, or something? IOW, something along this line? contrib/completion/git-completion.bash | 13 + 1 file changed, 13 insertions(+) diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash index 0b77eb1..193f53c 100644 --- i/contrib/completion/git-completion.bash +++ w/contrib/completion/git-completion.bash @@ -23,6 +23,14 @@ #3) Consider changing your PS1 to also show the current branch, # see git-prompt.sh for details. +if shopt -q expand_aliases +then + _git__aliases_were_enabled=yes +else + _git__aliases_were_enabled= +fi +shopt -u expand_aliases + case $COMP_WORDBREAKS in *:*) : great ;; *) COMP_WORDBREAKS=$COMP_WORDBREAKS: @@ -2504,3 +2512,8 @@ __git_complete gitk __gitk_main if [ Cygwin = $(uname -o 2/dev/null) ]; then __git_complete git.exe __git_main fi + +if test -n $_git__aliases_were_enabled +then + shopt -s expand_aliases +fi -- To unsubscribe from this list: send the line 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] t4049: avoid test failures on filemode challenged file systems (Windows)
Junio C Hamano gits...@pobox.com writes: Johannes Sixt j.s...@viscovery.net writes: 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. The hunks in the patch look fine. The last one that tests unmerged entries do not have to have chmod if it gives you trouble (you would need to reduce number of files from 4 to 3 if you go that route, I think). That is, something like this. -- 8 -- Subject: [PATCH] t4049: refocus tests The primary thing Linus's patch wanted to change was to make sure that 0-line change appears for a mode-only change. Update the first test to chmod a file that we can see in the output (limited by --stat-count) to demonstrate it. Also make sure to use test_chmod and compare the index and the tree, so that we can run this test even on a filesystem without permission bits. Later two tests are about fixes to separate issues that were introduced and/or uncovered by Linus's patch as a side effect, but the issues are not related to mode-only changes. Remove chmod from the tests. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t4049-diff-stat-count.sh | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh index 37f50cd..5b594e8 100755 --- a/t/t4049-diff-stat-count.sh +++ b/t/t4049-diff-stat-count.sh @@ -13,32 +13,31 @@ test_expect_success 'setup' ' git commit -m initial ' -test_expect_success 'limit output to 2 (simple)' ' +test_expect_success 'mode-only change show as a 0-line change' ' git reset --hard - chmod +x c d + test_chmod +x b d echo a a - echo b b + echo c c cat expect -\EOF a | 1 + -b | 1 + +b | 0 ... 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 echo a a - echo b b + echo c c cat $TEST_DIRECTORY/test-binary-1.png d cat expect -\EOF a | 1 + -b | 1 + +c | 1 + ... -4 files changed, 2 insertions(+) +3 files changed, 2 insertions(+) EOF git diff --stat --stat-count=2 actual test_i18ncmp expect actual @@ -56,12 +55,11 @@ test_expect_success 'exclude unmerged entries from total file count' ' done | git update-index --index-info echo d d - chmod +x c d cat expect -\EOF a | 1 + b | 1 + ... -4 files changed, 3 insertions(+) +3 files changed, 3 insertions(+) EOF git diff --stat --stat-count=2 actual test_i18ncmp expect actual -- 1.8.0.1.407.g3c58eb7 -- To unsubscribe from this list: send the line 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] completion: fix warning for zsh
Will apply directly on 'master'; 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 1/2] git-fast-import.txt: improve documentation for quoted paths
On Thu, Nov 29, 2012 at 06:00:54PM +0100, Matthieu Moy wrote: The documentation mentionned only newlines and double quotes as s/nn/n/ diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 6603a7a..35b909c 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -558,8 +558,9 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +If an `LF`, backslash or double quote must be encoded into `path` +shell-style quoting should be used, and the complete name should be +surrounded with double quotes e.g. `path/with\n, \\ and \ in it`. I think the point of the original is that you do not _need_ to quote unless you have those two characters. IOW, you can do: M 100644 :1 file \with \backslashes and it will stay in the literal to the end of line code path because the path does not begin with a double-quote. It is only when you trigger the shell-style quoting code path is in effect that you must then follow the rules of that quoting (which includes escaping backslashes). So technically, your modification to the beginning of the sentence is not correct. That being said, I think what you have written is more helpful to an end user. There is no harm in quoting when we do not have to, as fast-import implementations must know how to unquote anyway (and we over-quote in fast-export in this case). And while the example above does work (and was always designed to), it is sort of an unintuitive area that I would not be surprised to see other fast-import implementations get wrong. As a writer of a stream, it probably pays to be defensive and err on the side of quoting more. As for the text itself, a few minor punctuation suggestions: If an `LF`, backslash or double quote must be encoded ^ missing comma as list delimiter into `path` shell-style quoting should be used, and the complete ^ missing comma in if/then clause This one was in the original as well, but it makes it harder to read and is worth fixing. surrounded with double quotes e.g. `path/with\n, \\ and \ in it`. Should the parenthetical be in parentheses (or a separate sentence)? -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: Ubuntu: gitweb always looks for projects in /var/cache/git (“404 - no projects found”)
On Thu, Nov 29, 2012 at 01:55:57PM +, Alfonso Muñoz-Pomer Fuentes wrote: 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? I think the analysis in that stack overflow post is wrong. The use of our in git_get_projects_list is not the culprit. The problem is that one should not edit gitweb.cgi directly; its built-in defaults (which you are tweaking) are overridden by /etc/gitweb.conf, which is shipped by the Ubuntu package. You should be making your changes in the config file, not the CGI script. -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
[RFC/PATCH 2/2] reset: learn to reset on unborn branch
When run on an unborn branch, git reset currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Fix this by interpreting it as a reset to the empty tree.
If --patch is given, we currently pass the revision specifier, as
given on the command line, to interactive_reset(). On an unborn
branch, HEAD can of course not be resolved, so we need to pass the
sha1 of the empty tree to interactive_reset() as well. This is fine
since interactive_reset only needs the parameter to be a treeish and
doesn't use it for display purposes.
---
Is it correct that interactive_reset does not use the revision
specifier for display purposes? Or, worse, that it requires it to be a
commit in some cases? I tried it and didn't see any problem.
builtin/reset.c| 10 +---
t/t7106-reset-unborn-branch.sh | 52 ++
2 files changed, 59 insertions(+), 3 deletions(-)
create mode 100755 t/t7106-reset-unborn-branch.sh
diff --git a/builtin/reset.c b/builtin/reset.c
index cec9874..3845225 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -229,7 +229,10 @@ static struct object *lookup_commit_or_tree(const char
*rev) {
unsigned char sha1[20];
struct commit *commit;
struct tree *tree;
- if (get_sha1_treeish(rev, sha1))
+ if (!strcmp(rev, HEAD) get_sha1(HEAD, sha1)) {
+ // unborn branch: reset to empty tree
+ hashcpy(sha1, EMPTY_TREE_SHA1_BIN);
+ } else if (get_sha1_treeish(rev, sha1))
die(_(Failed to resolve '%s' as a valid ref.), rev);
commit = lookup_commit_reference_gently(sha1, 1);
if (commit)
@@ -292,7 +295,8 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
* Otherwise, argv[i] could be either rev or paths and
* has to be unambiguous.
*/
- else if (!get_sha1_treeish(argv[i], sha1)) {
+ else if (!strcmp(argv[i], HEAD) ||
+!get_sha1_treeish(argv[i], sha1)) {
/*
* Ok, argv[i] looks like a rev; it should not
* be a filename.
@@ -315,7 +319,7 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
if (patch_mode) {
if (reset_type != NONE)
die(_(--patch is incompatible with
--{hard,mixed,soft}));
- return interactive_reset(rev, argv + i, prefix);
+ return interactive_reset(sha1_to_hex(sha1), argv + i, prefix);
}
/* git reset tree [--] paths... can be used to
diff --git a/t/t7106-reset-unborn-branch.sh b/t/t7106-reset-unborn-branch.sh
new file mode 100755
index 000..67d45be
--- /dev/null
+++ b/t/t7106-reset-unborn-branch.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='git reset should work on unborn branch'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo a a
+ echo b b
+'
+
+test_expect_success 'reset' '
+ git add a b
+ git reset
+ test $(git ls-files) ==
+'
+
+test_expect_success 'reset HEAD' '
+ rm .git/index
+ git add a b
+ git reset HEAD
+ test $(git ls-files) ==
+'
+
+test_expect_success 'reset $file' '
+ rm .git/index
+ git add a b
+ git reset a
+ test $(git ls-files) == b
+'
+
+test_expect_success 'reset -p' '
+ rm .git/index
+ git add a
+ echo y | git reset -p
+ test $(git ls-files) ==
+'
+
+test_expect_success 'reset --soft not allowed' '
+ rm .git/index
+ git add a
+ test_must_fail git reset --soft
+'
+
+test_expect_success 'reset --hard' '
+ rm .git/index
+ git add a
+ git reset --hard
+ test $(git ls-files) ==
+ test_path_is_missing a
+'
+
+test_done
--
1.8.0.1.240.ge8a1f5a
--
To unsubscribe from this list: send the line 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 0/2] Fix git reset on unborn branch
I decided to address this before cherry-pick on unborn branch. RFC mostly because I'm not sure about the user interface. When we have agreed on that, I will add documentation. Martin von Zweigbergk (2): reset: learn to reset to tree reset: learn to reset on unborn branch builtin/reset.c | 73 ++--- t/t1512-rev-parse-disambiguation.sh | 4 -- t/t7102-reset.sh| 26 + t/t7106-reset-unborn-branch.sh | 52 ++ 4 files changed, 122 insertions(+), 33 deletions(-) create mode 100755 t/t7106-reset-unborn-branch.sh -- 1.8.0.1.240.ge8a1f5a -- To unsubscribe from this list: send the line 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 1/2] reset: learn to reset to tree
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree} work just like git reset $rev, except
that the former will not update HEAD (since there is no commit to
point it to).
Disallow --soft with trees, since that is about updating only HEAD.
By not updating HEAD, git reset $rev^{tree} behaves quite like git
reset $rev .. One might therefore consider requiring a path when
using reset with a tree to make that similarity more obvious. However,
a future commit will make git reset work on an unborn branch by
interpreting it as git reset $empty_tree and it would seem
unintuitive to the user to say git reset . on an unborn
branch. Requiring a path would also make git reset --hard $tree
disallowed.
This commit effectively undoes some of commit 13243c2 (reset: the
command takes committish, 2012-07-03). The command line argument is
now required to be an unambiguous treeish.
---
My implementation of lookup_commit_or_tree looks a little clunky. I'm
not very familiar with the API. Suggestions welcome.
Why is the HEAD is now at ... message printed only for --hard reset?
After all, HEAD is updated for all types of reset not involving paths.
builtin/reset.c | 67 +
t/t1512-rev-parse-disambiguation.sh | 4 ---
t/t7102-reset.sh| 26 ++
3 files changed, 65 insertions(+), 32 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 915cc9f..cec9874 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -225,6 +225,21 @@ static void die_if_unmerged_cache(int reset_type)
}
+static struct object *lookup_commit_or_tree(const char *rev) {
+ unsigned char sha1[20];
+ struct commit *commit;
+ struct tree *tree;
+ if (get_sha1_treeish(rev, sha1))
+ die(_(Failed to resolve '%s' as a valid ref.), rev);
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (commit)
+ return (struct object *) commit;
+ tree = parse_tree_indirect(sha1);
+ if (tree)
+ return (struct object *) tree;
+ die(_(Could not parse object '%s'.), rev);
+}
+
int cmd_reset(int argc, const char **argv, const char *prefix)
{
int i = 0, reset_type = NONE, update_ref_status = 0, quiet = 0;
@@ -232,7 +247,8 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
const char *rev = HEAD;
unsigned char sha1[20], *orig = NULL, sha1_orig[20],
*old_orig = NULL, sha1_old_orig[20];
- struct commit *commit;
+ struct object *object;
+ struct commit *commit = NULL;
struct strbuf msg = STRBUF_INIT;
const struct option options[] = {
OPT__QUIET(quiet, N_(be quiet, only report errors)),
@@ -276,7 +292,7 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
* Otherwise, argv[i] could be either rev or paths and
* has to be unambiguous.
*/
- else if (!get_sha1_committish(argv[i], sha1)) {
+ else if (!get_sha1_treeish(argv[i], sha1)) {
/*
* Ok, argv[i] looks like a rev; it should not
* be a filename.
@@ -289,19 +305,12 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
}
}
- if (get_sha1_committish(rev, sha1))
- die(_(Failed to resolve '%s' as a valid ref.), rev);
-
- /*
-* NOTE: As git reset $treeish -- $path should be usable on
-* any tree-ish, this is not strictly correct. We are not
-* moving the HEAD to any commit; we are merely resetting the
-* entries in the index to that of a treeish.
-*/
- commit = lookup_commit_reference(sha1);
- if (!commit)
- die(_(Could not parse object '%s'.), rev);
- hashcpy(sha1, commit-object.sha1);
+ object = lookup_commit_or_tree(rev);
+ if (object-type == OBJ_COMMIT)
+ commit = (struct commit*) object;
+ else if (reset_type == SOFT)
+ die(_(--soft requires a commit, which '%s' is not), rev);
+ hashcpy(sha1, object-sha1);
if (patch_mode) {
if (reset_type != NONE)
@@ -347,23 +356,25 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
die(_(Could not reset index file to revision '%s'.),
rev);
}
- /* Any resets update HEAD to the head being switched to,
-* saving the previous head in ORIG_HEAD before. */
- if (!get_sha1(ORIG_HEAD, sha1_old_orig))
- old_orig = sha1_old_orig;
- if (!get_sha1(HEAD, sha1_orig)) {
- orig = sha1_orig;
- set_reflog_message(msg, updating ORIG_HEAD, NULL);
- update_ref(msg.buf, ORIG_HEAD, orig,
Re: [RFC/PATCH 1/2] reset: learn to reset to tree
Martin von Zweigbergk martinv...@gmail.com writes:
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree} work just like git reset $rev, except
that the former will not update HEAD (since there is no commit to
point it to).
That is a horrible design I have to nack, unless you require
pathspec. You cannot tell what git reset $sha1 would do without
checking the type of the object $sha1 refers to. If you do this
only when pathspec is present, then the design is very reasonable.
Disallow --soft with trees, since that is about updating only HEAD.
Likewise.
--
To unsubscribe from this list: send the line 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-fast-import.txt: improve documentation for quoted paths
Jeff King p...@peff.net writes: So technically, your modification to the beginning of the sentence is not correct. I'd say the resulting sentence is somehow incorrect, but not more than the previous one (both say if ... without really telling what the condition was). If an `LF`, backslash or double quote must be encoded ^ missing comma as list delimiter Google tells me that my version was UK-correct but not US-correct. As french, I have no opinion on the subject, I take yours ;-). How about this: A path can use the C-style string quoting (this is accepted in all cases and mandatory if the filename starts with double quote or contains `LF`). In C-style quoting, `LF`, backslash, and double quote characters must be escaped by preceding them with a backslash. Also, the complete name should be surrounded with double quotes (e.g. `path/with\n, \\ and \ in it`). This should be technically correct, and this is accepted in all cases should encourrage people to use it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
On Tue, Nov 27, 2012 at 6:28 PM, Heiko Voigt hvo...@hvoigt.net wrote: Hi, On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote: On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: The v4 series leaves the remote branch amigious, but it helps you point the local branch at the right hash so that future calls to $ git submodule foreach 'git pull' can use the branch's .git/modules/name/config settings. But IMO thats the functionality which should be implemented in submodule update and not left to the user. I would think more of some convention like: $ git checkout -t origin/$branch when first initialising the submodule with e.g. $ git submodule update --init --branch Then later calls of $ git submodule update --branch would have a branch configured to pull from. I imagine that results in a similar behavior gerrit is doing on the server side? That sounds like it's doing pretty much the same thing. Can you think of a test that would distinguish it from my current v4 implementation? Well the main difference is that gerrit is automatically updating the superproject AFAIK. I would like it if we could implement the same workflow support in the submodule script. It seems to me that this is already proven to be useful workflow. It is proven in Gerrit, but Gerrit implements a central-server workflow. That is, only Gerrit ever floats the submodules, and he pushes the result for everyone else to share. I fear the consequences of everyone pulling submodules and then later trying to merge superprojects with someone else's breadcrumbs. Do you have some idea how this would be handled? Phil ps. Apologies for my lateness on this topic. I'm trying to catch up now. pps. Re-sent since Gmail has hidden the plain text option in a different place, now. On Tue, Nov 27, 2012 at 9:42 PM, W. Trevor King wk...@tremily.us wrote: On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote: On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote: On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: The v4 series leaves the remote branch amigious, but it helps you point the local branch at the right hash so that future calls to $ git submodule foreach 'git pull' can use the branch's .git/modules/name/config settings. But IMO thats the functionality which should be implemented in submodule update and not left to the user. Then you might need submodule.name.local-branch, submodule.name.remote-repository, and submodule.name.remote-branch to configure $ git checkout submodule.name.local-branch $ git pull submodule.name.remote-repository submodule.name.remote-branch and this would ignore the $sha1 stored in the gitlink (which all of the other update commands use). This ignoring-the-$sha1 bit made me think that a built-in pull wasn't a good fit for 'submodule update'. Maybe if it went into a new 'submodule pull'? Then users have a clear distinction: * 'update' to push superproject $sha1 changes into the submodules * 'pull' to push upstream-branch changes into the submodules I would think more of some convention like: $ git checkout -t origin/$branch when first initialising the submodule with e.g. $ git submodule update --init --branch Then later calls of $ git submodule update --branch would have a branch configured to pull from. I imagine that results in a similar behavior gerrit is doing on the server side? That sounds like it's doing pretty much the same thing. Can you think of a test that would distinguish it from my current v4 implementation? Well the main difference is that gerrit is automatically updating the superproject AFAIK. I would like it if we could implement the same workflow support in the submodule script. It seems to me that this is already proven to be useful workflow. Ah, sorry, I meant the configuring which remote branch you were pulling from happens at submodule initialization (via .git/modules/…) for both your workflow and my v4. You're right that having a builtin pull is different from my v4. https://github.com/hvoigt/git/commits/hv/floating_submodules_draft I looked over this before, but maybe not thoroughly enough ;). How about reusing the -b|--branch option for add? Since we only change the behavior when submodule.$name.update is set to branch it seems reasonable to me. Opinions? That was the approach I used in v1, but people were concerned that we would be stomping on previously unclaimed config space. Since noone has pointed out other uses besides Gerrit's very similar case, I'm not sure if that is still an issue. Could you point me to that mail? I cannot seem to find it in my archive. Hmm. It seems like Phil's initial response was (accidentally?) off list. The relevant portion was: On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote: Some
Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
On Thu, Nov 29, 2012 at 07:47:32PM +0100, Matthieu Moy wrote: Jeff King p...@peff.net writes: So technically, your modification to the beginning of the sentence is not correct. I'd say the resulting sentence is somehow incorrect, but not more than the previous one (both say if ... without really telling what the condition was). That's fair. There is a lot left unsaid in the original. :) If an `LF`, backslash or double quote must be encoded ^ missing comma as list delimiter Google tells me that my version was UK-correct but not US-correct. As french, I have no opinion on the subject, I take yours ;-). Thanks, I had a vague recollection that it might be regional. I probably should have looked it up myself. How about this: A path can use the C-style string quoting (this is accepted in all cases and mandatory if the filename starts with double quote or contains `LF`). In C-style quoting, `LF`, backslash, and double quote characters must be escaped by preceding them with a backslash. Also, the complete name should be surrounded with double quotes (e.g. `path/with\n, \\ and \ in it`). This should be technically correct, and this is accepted in all cases should encourrage people to use it. I think that is much better, but it reads a little more easily to me if we rearrange the second sentence. To complete my English bikeshedding, here is how I would have written the whole paragraph: A path can use C-style string quoting; this is accepted in all cases and mandatory if the filename starts with double quote or contains `LF`. In C-style quoting, the complete name should be surrounded with double quotes, and any `LF`, backslash, or double quote characters must be escaped by preceding them with a backslash (e.g., `path/with\n, \\ and \ in it`). Feel free to incorporate or ignore any of my tweaks from that version. -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: Millisecond precision in timestamps?
Junio C Hamano gits...@pobox.com: That is exactly why I said it is all relative. If it helps your application, you can weigh the pros-and-cons yourself and choose to throw junk extended header fields in the commit objects you create, using hash-object (or commit-tree). You can read it out using cat-file and do whatever you want to do with it, and modern Git (v1.5.0 was from early 2007) and tools that are designed to work with Git know to ignore such junk field. A good start. But remember that reposurgeon's entire interface to the git object level is through fast-export/fast-import. I need import- stream syntax for these. bzr's syntax would do: --- mark :1 committer Eric S. Raymond e...@thyrsus.com 1289147634 -0500 data 14 First commit. property branch-nick 12 bzr-testrepo M 644 inline README data 41 This is a test file in a dummy bzr repo. --- If we actually care about keys being full utf-8 with embedded whitespace it should look more like this: --- mark :1 committer Eric S. Raymond e...@thyrsus.com 1289147634 -0500 data 14 First commit. property 11 branch-nick propval 12 bzr-testrepo M 644 inline README data 41 This is a test file in a dummy bzr repo. --- -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line 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 1/2] reset: learn to reset to tree
On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree} work just like git reset $rev, except
that the former will not update HEAD (since there is no commit to
point it to).
That is a horrible design I have to nack, unless you require
pathspec. You cannot tell what git reset $sha1 would do without
checking the type of the object $sha1 refers to. If you do this
only when pathspec is present, then the design is very reasonable.
Very good point. Thanks! I now see that git checkout also requires a
path when given a tree.
So then git reset on an unborn branch would imply git reset
$empty_tree -- . instead. And git reset --hard $tree would not be
allowed. And the intersection of these -- git reset --hard on and
unborn branch -- would also not work. Would the correct fix be to
first make git reset --hard -- $path work (*sigh*)? I have never
understood why that doesn't (shouldn't) work.
--
To unsubscribe from this list: send the line 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 v3] git-fast-import.txt: improve documentation for quoted paths
The documentation mentionned only newlines and double quotes as characters needing escaping, but the backslash also needs it. Also, the documentation was not clearly saying that double quotes around the file name were required (double quotes in the examples could be interpreted as part of the sentence, not part of the actual string). Signed-off-by: Matthieu Moy matthieu@imag.fr --- cut-and-paste of Peff's version, adapted from mine. Documentation/git-fast-import.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 959e4d3..d1844ea 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -562,8 +562,12 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +A path can use C-style string quoting; this is accepted in all cases +and mandatory if the filename starts with double quote or contains +`LF`. In C-style quoting, the complete name should be surrounded with +double quotes, and any `LF`, backslash, or double quote characters +must be escaped by preceding them with a backslash (e.g., +`path/with\n, \\ and \ in it`). The value of `path` must be in canonical form. That is it must not: -- 1.8.0.319.g8abfee4 -- To unsubscribe from this list: send the line 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 v3] git-remote-mediawiki: escape , \, and LF in file names
A mediawiki page can contain, and even start with a character, we have
to escape it when generating the fast-export stream, as well as \
character. 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@imag.fr
---
contrib/mw-to-git/git-remote-mediawiki | 16 +---
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh | 26 ++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..094129d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,14 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+my $path = shift;
+$path =~ s/\\//g;
+$path =~ s//\\/g;
+$path =~ s/\n/\\n/g;
+return '' . $path . '';
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +746,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
diff --git a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
index 246d47d..b6405ce 100755
--- a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
+++ b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
@@ -318,4 +318,30 @@ test_expect_success 'git push with \ in format control' '
'
+test_expect_success 'fast-import meta-characters in page name (mw - git)' '
+ wiki_reset
+ wiki_editpage \file\_\\_foo expect to be called \file\_\\_foo
false
+ git clone mediawiki::'$WIKI_URL' mw_dir_21
+ test_path_is_file mw_dir_21/\file\_\\_foo.mw
+ wiki_getallpage ref_page_21
+ test_diff_directories mw_dir_21 ref_page_21
+'
+
+
+test_expect_success 'fast-import meta-characters in page name (git - mw) ' '
+ wiki_reset
+ git clone mediawiki::'$WIKI_URL' mw_dir_22
+ (
+ cd mw_dir_22
+ echo this file is called \file\_\\_foo.mw \file\_\\_foo
+ git add .
+ git commit -am file \file\_\\_foo
+ git pull
+ git push
+ )
+ wiki_getallpage ref_page_22
+ test_diff_directories mw_dir_22 ref_page_22
+'
+
+
test_done
--
1.8.0.319.g8abfee4
--
To unsubscribe from this list: send the line 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 1/2] reset: learn to reset to tree
Junio C Hamano gits...@pobox.com writes:
Martin von Zweigbergk martinv...@gmail.com writes:
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree} work just like git reset $rev, except
that the former will not update HEAD (since there is no commit to
point it to).
That is a horrible design I have to nack, unless you require
pathspec. You cannot tell what git reset $sha1 would do without
checking the type of the object $sha1 refers to. If you do this
only when pathspec is present, then the design is very reasonable.
The above applies to an _arbitrary_ $sha1.
Allowing reset $tree -- $pathspec is a very good addition in the
same sense that git checkout $tree -- $pathspec is useful. These
two commands, reset and checkout, share that the source we grab
the blobs out of only need to be a tree and does not have to be a
commit, and the only difference between them is where the blobs we
grabbed out of that tree go, either only to the index or to both the
index and the working tree.
But I do not think it is connected, at least at the level the end
users perceive, to the issue of reset issued while on an unborn
branch.
If you limit the scope of the behaviour change exposed to the end
users so that you would make
$ git reset [HEAD]
act as a short-hand for
$ rm -f $GIT_DIR/index
when HEAD points at an unborn branch, and similarly make
$ git reset --hard [HEAD]
act as a short-hand for
$ rm -f $GIT_DIR/index
$ git clean -f -d
in such a case, I do not think it is unreasonable at all.
In such a case,
$ git reset --soft [HEAD]
would become just a no-op. Earlier you were on an unborn branch,
and after reset --soft, nothing changes.
Hmm?
--
To unsubscribe from this list: send the line 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wk...@tremily.us wrote: [snip initial thoughts leading to the update --remote v5] I was thinking the same thing, but reading this whole thread a couple of weeks late. Thanks for noticing. Moreover, I think that 'git submodule update --pull' is also the wrong way to spell this action. Maybe you are misled from the outset by your current workflow: Did you see my v5 (add --remote) series? For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Millisecond precision in timestamps?
On Wed, Nov 28, 2012 at 2:29 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: There is room for new headers, and older versions of git will ignore them. You could add a new committer-timestamp field that elaborates on the timestamp included on the committer line. Newer versions of git would respect it, and older versions would fall back to using the committer timestamp. But I really wonder if anybody actually cares about adding sub-second timestamp support, or if it is merely because SVN has it. Roundtrip conversions may benefit from sub-second timestamps, but personally I think negative timestamps are more interesting and of practical use. Prehistoric projects need them even if they intend to switch to Git, never to go back to their original tarballs and collection of RCS ,v files. And if we were to add committer-timestamp and friends to support negative timestamps anyway (because older tools will not support them), supporting sub-second part might be something we want to think about at the same time. Posix-time is signed, but I suppose the git tools do not expect/allow a '-' character in the stream. Has git considered the year-2038 problem? No hurry... Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
Jeff King p...@peff.net writes: On Thu, Nov 29, 2012 at 06:00:54PM +0100, Matthieu Moy wrote: The documentation mentionned only newlines and double quotes as s/nn/n/ diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 6603a7a..35b909c 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -558,8 +558,9 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +If an `LF`, backslash or double quote must be encoded into `path` +shell-style quoting should be used, and the complete name should be +surrounded with double quotes e.g. `path/with\n, \\ and \ in it`. That shell-style contradicts with what fast-import.c says, though. It claims to grok \octal and described as C-style. -- To unsubscribe from this list: send the line 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-fast-import.txt: improve documentation for quoted paths
On Thu, Nov 29, 2012 at 11:15:56AM -0800, Junio C Hamano wrote: -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +If an `LF`, backslash or double quote must be encoded into `path` +shell-style quoting should be used, and the complete name should be +surrounded with double quotes e.g. `path/with\n, \\ and \ in it`. That shell-style contradicts with what fast-import.c says, though. It claims to grok \octal and described as C-style. Yeah, I think it was just laziness by the original author to use shell-style to mean quotes and backslash escaping without thinking too hard about which escape sequences are available. Saying C-style is more accurate (and Matthieu's more recent update does that). -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 v3] git-fast-import.txt: improve documentation for quoted paths
Matthieu Moy matthieu@imag.fr writes: The documentation mentionned only newlines and double quotes as characters needing escaping, but the backslash also needs it. Also, the documentation was not clearly saying that double quotes around the file name were required (double quotes in the examples could be interpreted as part of the sentence, not part of the actual string). Signed-off-by: Matthieu Moy matthieu@imag.fr --- cut-and-paste of Peff's version, adapted from mine. Documentation/git-fast-import.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 959e4d3..d1844ea 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -562,8 +562,12 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +A path can use C-style string quoting; this is accepted in all cases +and mandatory if the filename starts with double quote or contains +`LF`. ... or backslash? +In C-style quoting, the complete name should be surrounded with +double quotes, and any `LF`, backslash, or double quote characters +must be escaped by preceding them with a backslash (e.g., +`path/with\n, \\ and \ in it`). The value of `path` must be in canonical form. That is it must not: -- To unsubscribe from this list: send the line 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 1/2] reset: learn to reset to tree
Martin von Zweigbergk martinv...@gmail.com writes: Would the correct fix be to first make git reset --hard -- $path work (*sigh*)? I have never understood why that doesn't (shouldn't) work. What does it even mean, even when you are on an existing commit, to hard reset partially? Perhaps you looking for git checkout $tree -- $path? -- To unsubscribe from this list: send the line 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 v3] git-fast-import.txt: improve documentation for quoted paths
On Thu, Nov 29, 2012 at 11:33:19AM -0800, Junio C Hamano wrote: diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 959e4d3..d1844ea 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -562,8 +562,12 @@ A `path` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (``). -If an `LF` or double quote must be encoded into `path` shell-style -quoting should be used, e.g. `path/with\n and \ in it`. +A path can use C-style string quoting; this is accepted in all cases +and mandatory if the filename starts with double quote or contains +`LF`. ... or backslash? No, that was what we discussed elsewhere in the thread. It is OK to say: M 100644 :1 file \with \backslashes as de-quoting is triggered by the first character being double-quote. -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: Millisecond precision in timestamps?
On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote: And if we were to add committer-timestamp and friends to support negative timestamps anyway (because older tools will not support them), supporting sub-second part might be something we want to think about at the same time. Posix-time is signed, but I suppose the git tools do not expect/allow a '-' character in the stream. Has git considered the year-2038 problem? Yes. The timestamp is in base-10 ASCII, so there is no Y2038 problem in the data format (it is up to the implementation to read it into a sufficiently large time_t internally, of course[1]). But negative timestamps are a different story. We use unsigned long internally for timestamps, and fsck will complain about it. -Peff [1] We use unsigned long, which means we are Y2038-fine on I32/LP64 systems, but not on 32-bit or IL32/LLP64 systems. I do not use Windows, but my understanding is that LLP64 is the norm there, so it would eventually be a problem. But since we are unsigned, it is actually a Y2106 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: [PATCH] gitweb: git_summary - show $project in title
Thank you for your comments. In the appended version of the patch
the project title is escaped:
Subject: [PATCH] gitweb: git_summary - show $project in title
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconsistent user experience.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..be94b0b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6450,7 +6450,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print div class=\title\nbsp;/div\n;
+ print div class=\title\ . esc_html($project) . /div\n;
print table class=\projects_list\\n .
tr id=\metadata_desc\tddescription/tdtd .
esc_html($descr) . /td/tr\n;
unless ($omit_owner) {
--
1.7.10.4
On 13.11.2012 01:46, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Sun, Nov 11, 2012 at 06:20:58AM +0100, Henrich Schuchardt wrote:
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconstent user experience.
This patch adds the missing project title.
Signed-off-by: Henrich Schuchardt xypron.g...@gmx.de
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..3e1c452 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6451,7 +6451,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print div class=\title\nbsp;/div\n;
+ print div class=\title\$project/div\n;
I do not have any opinion on whether the intent of the change is good or
not, but shouldn't $project be run through esc_html() here?
I think the answer is yes. And if $project needs to be escaped, the
git_feed function you fixed today has another codepath that needs to
be fixed. When git_get_project_description($project) returns undef,
the description is taken from $project without any escaping.
--
To unsubscribe from this list: send the line 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/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
Michael Haggerty mhag...@alum.mit.edu writes: struct msg_data stored (char *, len) of the data to be included in a That (type, varname) is a bit funny notation, even though it is understandable. message, kept the character data NUL-terminated, etc., much like a strbuf would do. So change it to use a struct strbuf. This makes the code clearer and reduces copying a little bit. A side effect of this change is that the memory for each message is freed after it is used rather than leaked, though that detail is unimportant given that imap-send is a top-level command. -- ? For some reason, there is a bunch of infrastructure in this file for dealing with IMAP flags, although there is nothing in the code that actually allows any flags to be set. If there is no plan to add support for flags in the future, a bunch of code could be ripped out and struct msg_data could be completely replaced with strbuf. Yeah, after all these years we have kept the unused flags field there and nobody needed anything out of it. I am OK with a removal if it is done at the very end of the series. 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 0/8] Add function strbuf_addstr_xml_quoted() and more
Michael Haggerty mhag...@alum.mit.edu writes: There were two functions doing almost the same XML quoting of character entities, so implement a library function strbuf_addstr_xml_quoted() and use that in both places. Along the way, do a lot of simplification within imap-send.c, which was doing a lot of its own string management instead of using strbuf. Overall the series looked good to me. Thanks; will queue. -- To unsubscribe from this list: send the line 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 1/2] reset: learn to reset to tree
On Thu, Nov 29, 2012 at 11:13 AM, Junio C Hamano gits...@pobox.com wrote: [...]These two commands, reset and checkout, share that the source we grab the blobs out of only need to be a tree and does not have to be a commit, and the only difference between them is where the blobs we grabbed out of that tree go, either only to the index or to both the index and the working tree. Slightly off topic, but another difference (or somehow another aspect of the same difference?) that has tripped me up a few times is that git checkout $rev . only affects added and modified files (in $rev compared to HEAD), but git reset $rev . would also delete deleted files from the index. I suppose this is also a partial answer to your question in another message: What does it even mean, even when you are on an existing commit, to hard reset partially? Perhaps you looking for git checkout $tree -- $path? A more direct answer would be that I would expect git reset --hard $rev -- . to behave like git reset --hard $rev, except that it wouldn't update HEAD. It seems to me that that would be similar to how git reset $rev -- . behaves like git reset $rev, except that it doesn't update HEAD. But reset and checkout with and without paths still confuse me after years of using git, so I wouldn't be surprised if I'm not making any sense. -- To unsubscribe from this list: send the line 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] gitweb: add readme to overview page
Hello Junio,
thank you for your comment in message
7vip9ak971@alter.siamese.dyndns.org
that message 1352652039-31453-1-git-send-email-xypron.g...@gmx.de
lost the thread context.
As already described I would be happy if a README.html could be added to
the overview page of gitweb.
Please, find below an updated patch. Compared to the first version of my
patch it avoids a warning concerning doubled slashes in filenames and adds
a subtitle projects between the README and the project list.
Best regards
Heinrich Schuchardt
Subject: [PATCH] gitweb: add readme to overview page
For repositories it is possible to maintain a README.html which will
be shown on the summary page. This is not possible for the server
root.
German law requires to provide contact data on the web server. This
data could easily be entered in the overview page using a README.html.
Furthermore it is possible to put the repositories not directly into
the root directory but into a subdirectory. Here also a README.html
would be helpful to indicate what the subdirectory is about.
The patch introduces README.html functionality for the root directory
and all subdirectories.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
gitweb/gitweb.perl | 13 +
1 file changed, 13 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..618b0d8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6368,6 +6368,19 @@ sub git_project_list {
}
git_project_search_form($searchtext, $search_use_regexp);
+ # If XSS prevention is on, we don't include README.html.
+ # TODO: Allow a readme in some safe format.
+ my $path = ;
+ if (defined $project_filter) {
+ $path = /$project_filter;
+ }
+ if (!$prevent_xss -s $projectroot$path/README.html) {
+ print div class=\title\readme/div\n .
+ div class=\readme\\n;
+ insert_file($projectroot$path/README.html);
+ print \n/div\n; # class=readme
+ }
+ print div class=\title\projects/div\n;
git_project_list_body(\@list, $order);
git_footer_html();
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
Hi Ralf
Here is the final third of my review.
#: builtin/prune-packed.c:7
msgid git prune-packed [-n|--dry-run] [-q|--quiet]
-msgstr
+msgstr git prune-packed [-n|--dry-run] [-q|--quite]
^
typo at the far end
#: builtin/prune.c:133
-#, fuzzy
msgid report pruned objects
-msgstr kann Objekt %s nicht lesen
+msgstr meldet entfernte Objekte
If you translate pruned as gelöscht or some such, that avoids the
ambiguity with remote.
#: builtin/prune.c:136
msgid expire objects older than time
-msgstr
+msgstr lässt Objekte älter als Zeit verfallen
verfallen is nice!
#: builtin/push.c:391
msgid check
-msgstr
+msgstr Überprüfung
I think the original string should not be translatable to begin with.
The manpage says
--recurse-submodules=check|on-demand
Make sure all submodule commits used by the revisions to be pushed
are available on a remote tracking branch. If *check* is used git
will verify that all submodule commits that changed in the
revisions to be pushed are available on at least one remote of the
submodule. If any commits are missing the push will be aborted and
exit with non-zero status. If *on-demand* is used all submodules
that changed in the revisions to be pushed will be pushed. If
on-demand was not able to push all necessary revisions it will
also be aborted and exit with non-zero status.
So 'check' is not translatable.
#: builtin/push.c:395 builtin/push.c:396
msgid receive pack program
-msgstr
+msgstr Programm zum Empfangen von Paketen
Or perhaps 'receive-pack' Programm.
#: builtin/read-tree.c:111
-#, fuzzy
msgid only empty the index
-msgstr Konnte die Bereitstellung nicht lesen
+msgstr leert nur die Bereitstellung
Only here means it doesn't read-a-tree, but empty the index. So
dropping the nur would probably be better.
#: builtin/remote.c:11
msgid git remote [-v | --verbose]
-msgstr
+msgstr git remove [-v | --verbose]
^^^
typo
#: builtin/remote.c:173
msgid set up remote as a mirror to push to or fetch from
msgstr
+Aufsetzen der Fernarchivs als Spiegelarchiv zum Versenden und Anfordern
^^^
des?
Run \git rev-parse --parseopt -h\ for more information on the first
usage.
msgstr
+git rev-parse --parseopt [Optionen] -- [Argumente...]\n
+ or: git rev-parse --sq-quote [Argumente...]\n
+ or: git rev-parse [Optionen] [Argumente...]\n
+\n
+Führe \git rev-parse --parseopt -h\ für weitere Informationen bei erster
+Verwendung aus.
Should use 'oder:' in the case split, shouldn't it?
#: builtin/rm.c:134
-#, fuzzy
msgid do not list removed files
-msgstr Kann geänderte Dateien nicht aus der Bereitstellung herausnehmen
+msgstr listet keine entfernten Dateien auf
Again removed-gelöscht or some such avoids an ambiguity.
#: builtin/show-branch.c:651
-#, fuzzy
msgid show remote-tracking and local branches
-msgstr Kein externer Übernahmezweig für %s von %s
+msgstr zeigt externer Übernahmezweige und lokale Zweige an
^^^
[...]
#: builtin/show-branch.c:653
-#, fuzzy
msgid show remote-tracking branches
-msgstr Kein externer Übernahmezweig für %s von %s
+msgstr zeigt externer Übernahmezweige an
^^^
extern*e*
#: builtin/tag.c:464
-#, fuzzy
msgid use another key to sign the tag
-msgstr konnte Markierung nicht signieren
+msgstr benutzt einen Schlüssel um die Markierung zu signieren
The original says *another* -- maybe
benutzt einen anderen Schlüssel um die Markierung zu signieren
#: builtin/update-index.c:750
msgid mark files as \not changing\
-msgstr
+msgstr markiert Dateien als \not changing\
Neither original nor translation are very helpful. Maybe
Always assume this file to be unchanged
Betrachte diese Datei immer als unverändert
#: builtin/update-index.c:756
msgid mark files as \index-only\
-msgstr
+msgstr markiert Dateien als \index-only\
Likewise, but here I don't even understand what the manpage is trying to
tell me, in particular I don't see how it would be different from
assume-unchanged. Maybe see manpage would be the best documentation.
#: builtin/update-index.c:776
msgid repopulate stages #2 and #3 for the listed paths
msgstr
+wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade
ISTR we settled on something for 'stage', but it's not in the glossary.
Either way I don't think this is it. Ausführung der Phasen would mean
that it's some part of a process, whereas the stages are a state.
Yay, that's it. Even in three parts it was tedious, and I cannot begin
to imagine what *writing* 825 new translations must have felt like.
Thanks for your work!
- Thomas
--
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
What's cooking in git.git (Nov 2012, #10; Thu, 29)
What's cooking in git.git (Nov 2012, #10; Thu, 29) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Hopefully 1.8.1-rc0 preview will be tagged this weekend. Many topics are marked to be cooked in 'next' during the feature freeze, but some topics in flight should be in 'master' before -rc1 happens. 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 -- [New Topics] * wk/submodule-update-remote (2012-11-28) 2 commits - submodule add: If --branch is given, record it in .gitmodules - submodule update: add --remote for submodule's upstream changes Still under active discussion. -- [Graduated to master] * er/doc-add-new-commands (2012-11-26) 1 commit (merged to 'next' on 2012-11-28 at 2daf755) + Documentation: how to add a new command * fc/completion-test-simplification (2012-11-16) 6 commits (merged to 'next' on 2012-11-28 at b7b2f67) + completion: simplify __gitcomp() test helper + completion: refactor __gitcomp related tests + completion: consolidate test_completion*() tests + completion: simplify tests using test_completion_long() + completion: standardize final space marker in tests + completion: add comment for test_completion() Clean up completion tests. Use of conslidated helper may make instrumenting one particular test during debugging of the test itself, but I think that issue should be addressed in some other way (e.g. making sure individual tests in 9902 can be skipped). * fc/remote-hg (2012-11-27) 22 commits (merged to 'next' on 2012-11-28 at f805784) + remote-hg: fix for older versions of python + remote-hg: fix for files with spaces (merged to 'next' on 2012-11-18 at 4a4f2e4) + remote-hg: avoid bad refs + remote-hg: try the 'tip' if no checkout present + remote-hg: fix compatibility with older versions of hg + remote-hg: add missing config for basic tests + remote-hg: the author email can be null + remote-hg: add option to not track branches + remote-hg: add extra author test + remote-hg: add tests to compare with hg-git + remote-hg: add bidirectional tests + test-lib: avoid full path to store test results + remote-hg: add basic tests + remote-hg: fake bookmark when there's none + remote-hg: add compat for hg-git author fixes + remote-hg: add support for hg-git compat mode + remote-hg: match hg merge behavior + remote-hg: make sure the encoding is correct + remote-hg: add support to push URLs + remote-hg: add support for remote pushing + remote-hg: add support for pushing + Add new remote-hg transport helper New remote helper for hg. * fc/send-email-no-sender-prompt (2012-11-26) 1 commit (merged to 'next' on 2012-11-28 at 690d525) + send-email: avoid questions when user has an ident (this branch is used by jk/send-email-sender-prompt.) In cases the sender ident is sufficiently specified, there is no need to prompt the user before sending the series out. * fc/zsh-completion (2012-11-19) 2 commits (merged to 'next' on 2012-11-26 at 48ebdc9) + completion: start moving to the new zsh completion + completion: add new zsh completion Completion script revamped for zsh users. * jc/doc-push-satellite (2012-11-27) 1 commit (merged to 'next' on 2012-11-28 at 7114637) + Documentation/git-push.txt: clarify the push from satellite workflow Clarify what the example that pushes branches into remote-tracking branches of another repository is trying to achieve (i.e. emulating a fetch in reverse). * jk/pickaxe-textconv (2012-10-28) 2 commits (merged to 'next' on 2012-11-26 at 2c5b5c9) + pickaxe: use textconv for -S counting + pickaxe: hoist empty needle check Use textconv filters when searching with log -S. * jk/send-email-sender-prompt (2012-11-28) 7 commits (merged to 'next' on 2012-11-28 at a808921) + t9001: check send-email behavior with implicit sender + Merge branch 'fc/send-email-no-sender-prompt' into jk/send-email-sender-prompt + t: add tests for git var + ident: keep separate explicit flags for author and committer + ident: make user_ident_explicitly_given static + t7502: factor out autoident prerequisite + test-lib: allow negation of prerequisites (this branch uses fc/send-email-no-sender-prompt.) General clean-ups in various areas, originally written to support a patch that later turned out to be unneeded. * jl/submodule-rm (2012-11-23) 1 commit (merged to 'next' on 2012-11-28 at 0e4115f) + Teach rm to remove submodules when given with a trailing '/' Finishing touches to git rm $submodule that removes the working tree of a submodule. * km/send-email-remove-cruft-in-address (2012-11-26) 5 commits (merged to 'next' on
Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
On Thu, Nov 29, 2012 at 01:30:54PM -0800, Junio C Hamano wrote: For some reason, there is a bunch of infrastructure in this file for dealing with IMAP flags, although there is nothing in the code that actually allows any flags to be set. If there is no plan to add support for flags in the future, a bunch of code could be ripped out and struct msg_data could be completely replaced with strbuf. Yeah, after all these years we have kept the unused flags field there and nobody needed anything out of it. I am OK with a removal if it is done at the very end of the series. There's a bunch of unused junk in imap-send. The original implementation copied a bunch of code from isync, a much more full-featured imap client, and the result ended up way more complex than it needed to be. I have ripped a few things out over the years when they cause a problem (e.g., portability of /dev/urandom, conflict over the name struct string_list), but have mostly let it be out of a vague sense that we might one day want to pull bugfixes from isync upstream. That has not happened once in the last six years, though, and I would doubt that a straightforward merge would work after so many years. So ripping out and refactoring the code in the name of maintainability is probably a good thing at this point. -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] cache-tree: invalidate i-t-a paths after writing trees
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: An alternative might be to add a phoney bit next to used in the cache_tree structure, mark the cache tree as phoney when we skip an entry marked as CE_REMOVE or CE_ITA, and make the postprocessing loop this patch adds aware of that bit, instead of iterating over the index entries; instead, it would recurse the resulting cache tree and invalidate parts of the tree that have subtrees with the phoney bit set, or something. Yeah, that sounds better. Did anything happen to this topic after this? -- To unsubscribe from this list: send the line 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wk...@tremily.us wrote: [snip initial thoughts leading to the update --remote v5] I was thinking the same thing, but reading this whole thread a couple of weeks late. Thanks for noticing. Moreover, I think that 'git submodule update --pull' is also the wrong way to spell this action. Maybe you are misled from the outset by your current workflow: Did you see my v5 (add --remote) series? Eventually, I did. Sorry for the out-of-order replies. For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. This seems precisely backwards to me. Why not use $ git submodule update --remote --fetch to do your default behavior instead? I suppose I am arguing against the tide of the dominant workflow, but the fetch-by-default idea needlessly conflates two primitive operations: float and fetch. I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I've always felt that the origin defaults are broken and are simply being ignored because most users do not trip over them. But ISTR that submodule commands use the remote indicated by the superproject's current remote-tracking configuration, with a fallback to 'origin' if there is none. Sort of a best effort algorithm, I think. Am I remembering that wrong? I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: add readme to overview page
The following setting provides the same feature
# html text to include at home page
$home_text = indextext.html;
Sorry for the noise.
Best regards
Heinrich Schuchardt
On 29.11.2012 23:30, Xypron wrote:
Hello Junio,
thank you for your comment in message
7vip9ak971@alter.siamese.dyndns.org
that message 1352652039-31453-1-git-send-email-xypron.g...@gmx.de
lost the thread context.
As already described I would be happy if a README.html could be added to
the overview page of gitweb.
Please, find below an updated patch. Compared to the first version of my
patch it avoids a warning concerning doubled slashes in filenames and adds
a subtitle projects between the README and the project list.
Best regards
Heinrich Schuchardt
Subject: [PATCH] gitweb: add readme to overview page
For repositories it is possible to maintain a README.html which will
be shown on the summary page. This is not possible for the server
root.
German law requires to provide contact data on the web server. This
data could easily be entered in the overview page using a README.html.
Furthermore it is possible to put the repositories not directly into
the root directory but into a subdirectory. Here also a README.html
would be helpful to indicate what the subdirectory is about.
The patch introduces README.html functionality for the root directory
and all subdirectories.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
gitweb/gitweb.perl | 13 +
1 file changed, 13 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..618b0d8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6368,6 +6368,19 @@ sub git_project_list {
}
git_project_search_form($searchtext, $search_use_regexp);
+ # If XSS prevention is on, we don't include README.html.
+ # TODO: Allow a readme in some safe format.
+ my $path = ;
+ if (defined $project_filter) {
+ $path = /$project_filter;
+ }
+ if (!$prevent_xss -s $projectroot$path/README.html) {
+ print div class=\title\readme/div\n .
+ div class=\readme\\n;
+ insert_file($projectroot$path/README.html);
+ print \n/div\n; # class=readme
+ }
+ print div class=\title\projects/div\n;
git_project_list_body(\@list, $order);
git_footer_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
Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
On Fri, Nov 30, 2012 at 7:06 AM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: An alternative might be to add a phoney bit next to used in the cache_tree structure, mark the cache tree as phoney when we skip an entry marked as CE_REMOVE or CE_ITA, and make the postprocessing loop this patch adds aware of that bit, instead of iterating over the index entries; instead, it would recurse the resulting cache tree and invalidate parts of the tree that have subtrees with the phoney bit set, or something. Yeah, that sounds better. Did anything happen to this topic after this? Not from my side because I forgot to mark this thread as a todo item and unsurprisingly forgot about it. -- 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
[PATCH v6 0/8] push: update remote tags only with force
This patch series originated in response to the following thread: http://thread.gmane.org/gmane.comp.version-control.git/208354 I made some adjustments based on Junio's last round of feedback including a new patch reworking the push rules comment in remote.c. Also refined some of the log messages--nothing major. Finally, took a stab at putting something together for the release notes, see below. Chris Release notes: git push no longer updates tags (lightweight or annotated) by default. Specifically, if the destination reference already exists and is under refs/tags/ or it points to a tag object, it is not allowed to fast- forward (unless forced using +A:B notation or by passing --force.) This is consistent with how a tag is normally thought of: a reference that does not move once defined. It also ensures a push will not inadvertently clobber an already existing tag--something that can go unnoticed if fast-forwarding is allowed. Chris Rorvick (8): push: return reject reasons as a bitset push: add advice for rejected tag reference push: flag updates push: flag updates that require force push: require force for refs under refs/tags/ push: require force for annotated tags push: clarify rejection of update to non-commit-ish push: cleanup push rules comment Documentation/git-push.txt | 9 ++--- builtin/push.c | 24 +- builtin/send-pack.c| 9 +++-- cache.h| 7 +++- remote.c | 83 +++--- send-pack.c| 1 + t/t5516-fetch-push.sh | 44 +++- transport-helper.c | 6 transport.c| 25 -- transport.h| 10 +++--- 10 files changed, 167 insertions(+), 51 deletions(-) -- 1.8.0.158.g0c4328c -- To unsubscribe from this list: send the line 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 v6 1/8] push: return reject reasons as a bitset
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 13 -
builtin/send-pack.c | 4 ++--
transport.c | 17 -
transport.h | 9 +
4 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..9d17fc7 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -244,7 +244,7 @@ static void advise_checkout_pull_push(void)
static int push_with_options(struct transport *transport, int flags)
{
int err;
- int nonfastforward;
+ unsigned int reject_reasons;
transport_set_verbosity(transport, verbosity, progress);
@@ -257,7 +257,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
err = transport_push(transport, refspec_nr, refspec, flags,
-nonfastforward);
+reject_reasons);
if (err != 0)
error(_(failed to push some refs to '%s'), transport-url);
@@ -265,18 +265,13 @@ static int push_with_options(struct transport *transport,
int flags)
if (!err)
return 0;
- switch (nonfastforward) {
- default:
- break;
- case NON_FF_HEAD:
+ if (reject_reasons REJECT_NON_FF_HEAD) {
advise_pull_before_push();
- break;
- case NON_FF_OTHER:
+ } else if (reject_reasons REJECT_NON_FF_OTHER) {
if (default_matching_used)
advise_use_upstream();
else
advise_checkout_pull_push();
- break;
}
return 1;
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index d342013..9f98607 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -85,7 +85,7 @@ int cmd_send_pack(int argc, const char **argv, const char
*prefix)
int send_all = 0;
const char *receivepack = git-receive-pack;
int flags;
- int nonfastforward = 0;
+ unsigned int reject_reasons;
int progress = -1;
argv++;
@@ -223,7 +223,7 @@ int cmd_send_pack(int argc, const char **argv, const char
*prefix)
ret |= finish_connect(conn);
if (!helper_status)
- transport_print_push_status(dest, remote_refs, args.verbose, 0,
nonfastforward);
+ transport_print_push_status(dest, remote_refs, args.verbose, 0,
reject_reasons);
if (!args.dry_run remote) {
struct ref *ref;
diff --git a/transport.c b/transport.c
index 9932f40..d4568e7 100644
--- a/transport.c
+++ b/transport.c
@@ -714,7 +714,7 @@ static int print_one_push_status(struct ref *ref, const
char *dest, int count, i
}
void transport_print_push_status(const char *dest, struct ref *refs,
- int verbose, int porcelain, int
*nonfastforward)
+ int verbose, int porcelain, unsigned int
*reject_reasons)
{
struct ref *ref;
int n = 0;
@@ -733,18 +733,17 @@ void transport_print_push_status(const char *dest, struct
ref *refs,
if (ref-status == REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
- *nonfastforward = 0;
+ *reject_reasons = 0;
for (ref = refs; ref; ref = ref-next) {
if (ref-status != REF_STATUS_NONE
ref-status != REF_STATUS_UPTODATE
ref-status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
- if (ref-status == REF_STATUS_REJECT_NONFASTFORWARD
- *nonfastforward != NON_FF_HEAD) {
+ if (ref-status == REF_STATUS_REJECT_NONFASTFORWARD) {
if (!strcmp(head, ref-name))
- *nonfastforward = NON_FF_HEAD;
+ *reject_reasons |= REJECT_NON_FF_HEAD;
else
- *nonfastforward = NON_FF_OTHER;
+ *reject_reasons |= REJECT_NON_FF_OTHER;
}
}
}
@@ -1031,9 +1030,9 @@ static void die_with_unpushed_submodules(struct
string_list *needs_pushing)
int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
- int *nonfastforward)
+ unsigned int *reject_reasons)
{
- *nonfastforward = 0;
+ *reject_reasons = 0;
transport_verify_remote_names(refspec_nr, refspec);
if (transport-push) {
@@ -1099,7 +1098,7 @@ int transport_push(struct transport *transport,
if (!quiet || err)
[PATCH v6 2/8] push: add advice for rejected tag reference
Advising the user to fetch and merge only makes sense if the rejected
reference is a branch. If none of the rejections are for branches, just
tell the user the reference already exists.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
builtin/push.c | 11 +++
cache.h| 1 +
remote.c | 10 ++
transport.c| 2 ++
transport.h| 1 +
5 files changed, 25 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index 9d17fc7..e08485d 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -220,6 +220,10 @@ static const char message_advice_checkout_pull_push[] =
(e.g. 'git pull') before pushing again.\n
See the 'Note about fast-forwards' in 'git push --help' for
details.);
+static const char message_advice_ref_already_exists[] =
+ N_(Updates were rejected because the destination reference already
exists\n
+ in the remote and the update is not a fast-forward.);
+
static void advise_pull_before_push(void)
{
if (!advice_push_non_ff_current || !advice_push_nonfastforward)
@@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
advise(_(message_advice_checkout_pull_push));
}
+static void advise_ref_already_exists(void)
+{
+ advise(_(message_advice_ref_already_exists));
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport,
int flags)
advise_use_upstream();
else
advise_checkout_pull_push();
+ } else if (reject_reasons REJECT_ALREADY_EXISTS) {
+ advise_ref_already_exists();
}
return 1;
diff --git a/cache.h b/cache.h
index dbd8018..d72b64d 100644
--- a/cache.h
+++ b/cache.h
@@ -1002,6 +1002,7 @@ struct ref {
unsigned int force:1,
merge:1,
nonfastforward:1,
+ not_forwardable:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 04fd9ea..5101683 100644
--- a/remote.c
+++ b/remote.c
@@ -1279,6 +1279,14 @@ int match_push_refs(struct ref *src, struct ref **dst,
return 0;
}
+static inline int is_forwardable(struct ref* ref)
+{
+ if (!prefixcmp(ref-name, refs/tags/))
+ return 0;
+
+ return 1;
+}
+
void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
int force_update)
{
@@ -1316,6 +1324,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int
send_mirror,
* always allowed.
*/
+ ref-not_forwardable = !is_forwardable(ref);
+
ref-nonfastforward =
!ref-deletion
!is_null_sha1(ref-old_sha1)
diff --git a/transport.c b/transport.c
index d4568e7..bc31e8e 100644
--- a/transport.c
+++ b/transport.c
@@ -740,6 +740,8 @@ void transport_print_push_status(const char *dest, struct
ref *refs,
ref-status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
if (ref-status == REF_STATUS_REJECT_NONFASTFORWARD) {
+ if (ref-not_forwardable)
+ *reject_reasons |= REJECT_ALREADY_EXISTS;
if (!strcmp(head, ref-name))
*reject_reasons |= REJECT_NON_FF_HEAD;
else
diff --git a/transport.h b/transport.h
index 404b113..bfd2df5 100644
--- a/transport.h
+++ b/transport.h
@@ -142,6 +142,7 @@ void transport_set_verbosity(struct transport *transport,
int verbosity,
#define REJECT_NON_FF_HEAD 0x01
#define REJECT_NON_FF_OTHER0x02
+#define REJECT_ALREADY_EXISTS 0x04
int transport_push(struct transport *connection,
int refspec_nr, const char **refspec, int flags,
--
1.8.0.158.g0c4328c
--
To unsubscribe from this list: send the line 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 v6 3/8] push: flag updates
If the reference exists on the remote and it is not being removed, then
mark as an update. This is in preparation for handling tags (lightweight
and annotated) exceptionally.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 1 +
remote.c | 18 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index d72b64d..722321c 100644
--- a/cache.h
+++ b/cache.h
@@ -1003,6 +1003,7 @@ struct ref {
merge:1,
nonfastforward:1,
not_forwardable:1,
+ update:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 5101683..07040b8 100644
--- a/remote.c
+++ b/remote.c
@@ -1326,15 +1326,19 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
ref-not_forwardable = !is_forwardable(ref);
- ref-nonfastforward =
+ ref-update =
!ref-deletion
- !is_null_sha1(ref-old_sha1)
- (!has_sha1_file(ref-old_sha1)
- || !ref_newer(ref-new_sha1, ref-old_sha1));
+ !is_null_sha1(ref-old_sha1);
- if (ref-nonfastforward !ref-force !force_update) {
- ref-status = REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
+ if (ref-update) {
+ ref-nonfastforward =
+ !has_sha1_file(ref-old_sha1)
+ || !ref_newer(ref-new_sha1, ref-old_sha1);
+
+ if (ref-nonfastforward !ref-force
!force_update) {
+ ref-status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
}
}
}
--
1.8.0.158.g0c4328c
--
To unsubscribe from this list: send the line 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 v6 5/8] push: require force for refs under refs/tags/
References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter. This behavior is oriented to
branches which are expected to move with commits. Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 11 ++-
builtin/push.c | 2 +-
builtin/send-pack.c| 5 +
cache.h| 1 +
remote.c | 18 ++
send-pack.c| 1 +
t/t5516-fetch-push.sh | 23 ++-
transport-helper.c | 6 ++
transport.c| 8 ++--
9 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..09bdec7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -51,11 +51,12 @@ be named. If `:`dst is omitted, the same ref as src
will be
updated.
+
The object referenced by src is used to update the dst reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward dst. By having the optional leading `+`,
-you can tell git to update the dst ref even when the update is not a
-fast-forward. This does *not* attempt to merge src into dst. See
-EXAMPLES below for details.
+on the remote side. By default this is only allowed if dst is not
+under refs/tags/, and then only if it can fast-forward dst. By having
+the optional leading `+`, you can tell git to update the dst ref even
+if it is not allowed by default (e.g., it is not a fast-forward.) This
+does *not* attempt to merge src into dst. See EXAMPLES below for
+details.
+
`tag tag` means the same as `refs/tags/tag:refs/tags/tag`.
+
diff --git a/builtin/push.c b/builtin/push.c
index e08485d..83a3cc8 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -222,7 +222,7 @@ static const char message_advice_checkout_pull_push[] =
static const char message_advice_ref_already_exists[] =
N_(Updates were rejected because the destination reference already
exists\n
- in the remote and the update is not a fast-forward.);
+ in the remote.);
static void advise_pull_before_push(void)
{
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 9f98607..f849e0a 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -44,6 +44,11 @@ static void print_helper_status(struct ref *ref)
msg = non-fast forward;
break;
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ res = error;
+ msg = already exists;
+ break;
+
case REF_STATUS_REJECT_NODELETE:
case REF_STATUS_REMOTE_REJECT:
res = error;
diff --git a/cache.h b/cache.h
index b7ab4ac..a32a0ea 100644
--- a/cache.h
+++ b/cache.h
@@ -1011,6 +1011,7 @@ struct ref {
REF_STATUS_NONE = 0,
REF_STATUS_OK,
REF_STATUS_REJECT_NONFASTFORWARD,
+ REF_STATUS_REJECT_ALREADY_EXISTS,
REF_STATUS_REJECT_NODELETE,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
*
* (1) if the old thing does not exist, it is OK.
*
-* (2) if you do not have the old thing, you are not allowed
+* (2) if the destination is under refs/tags/ you are
+* not allowed to overwrite it; tags are expected
+* to be static once created
+*
+* (3) if you do not have the old thing, you are not allowed
* to overwrite it; you would not know what you are losing
* otherwise.
*
-* (3) if both new and old are commit-ish, and new is a
+* (4) if both new and old are commit-ish, and new is a
* descendant of old, it is OK.
*
-* (4) regardless of all of the above, removing :B is
+* (5) regardless of all of the above, removing :B is
* always allowed.
*/
@@ -1337,7 +1341,13 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
!has_sha1_file(ref-old_sha1)
|| !ref_newer(ref-new_sha1, ref-old_sha1);
- if (ref-nonfastforward) {
+ if (ref-not_forwardable) {
+ ref-requires_force = 1;
+ if
[PATCH v6 4/8] push: flag updates that require force
Add a flag for indicating an update to a reference requires force.
Currently the `nonfastforward` flag is used for this when generating the
status message. A separate flag insulates dependent logic from the
details of set_ref_status_for_push().
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
cache.h | 4 +++-
remote.c| 11 ---
transport.c | 2 +-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 722321c..b7ab4ac 100644
--- a/cache.h
+++ b/cache.h
@@ -999,7 +999,9 @@ struct ref {
unsigned char old_sha1[20];
unsigned char new_sha1[20];
char *symref;
- unsigned int force:1,
+ unsigned int
+ force:1,
+ requires_force:1,
merge:1,
nonfastforward:1,
not_forwardable:1,
diff --git a/remote.c b/remote.c
index 07040b8..4a6f822 100644
--- a/remote.c
+++ b/remote.c
@@ -1293,6 +1293,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int
send_mirror,
struct ref *ref;
for (ref = remote_refs; ref; ref = ref-next) {
+ int force_ref_update = ref-force || force_update;
+
if (ref-peer_ref)
hashcpy(ref-new_sha1, ref-peer_ref-new_sha1);
else if (!send_mirror)
@@ -1335,9 +1337,12 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
!has_sha1_file(ref-old_sha1)
|| !ref_newer(ref-new_sha1, ref-old_sha1);
- if (ref-nonfastforward !ref-force
!force_update) {
- ref-status = REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
+ if (ref-nonfastforward) {
+ ref-requires_force = 1;
+ if (!force_ref_update) {
+ ref-status =
REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
}
}
}
diff --git a/transport.c b/transport.c
index bc31e8e..f3160b1 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
const char *msg;
strcpy(quickref, status_abbrev(ref-old_sha1));
- if (ref-nonfastforward) {
+ if (ref-requires_force) {
strcat(quickref, ...);
type = '+';
msg = forced update;
--
1.8.0.158.g0c4328c
--
To unsubscribe from this list: send the line 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 v6 7/8] push: clarify rejection of update to non-commit-ish
Pushes must already (by default) update to a commit-ish due to the fast- forward check in set_ref_status_for_push(). But rejecting for not being a fast-forward suggests the situation can be resolved with a merge. Flag these updates (i.e., to a blob or a tree) as not forwardable so the user is presented with more appropriate advice. While updating *from* a tag object is potentially destructive, updating *to* a tag is not. Additionally, a push to the refs/tags/ hierarchy is already excluded from fast-forwarding, and refs/heads/ is protected from anything but commit objects by a check in write_ref_sha1(). Thus someone fast-forwarding to a tag is probably not doing so by accident. Since updating to a tag is benign and unlikely to cause confusion, allow it in case someone finds the behavior useful. Signed-off-by: Chris Rorvick ch...@rorvick.com --- remote.c | 5 + 1 file changed, 5 insertions(+) diff --git a/remote.c b/remote.c index f5bc4e7..ee0c1e5 100644 --- a/remote.c +++ b/remote.c @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref) if (!o || o-type != OBJ_COMMIT) return 0; + /* new object must be commit-ish */ + o = deref_tag(parse_object(ref-new_sha1), NULL, 0); + if (!o || o-type != OBJ_COMMIT) + return 0; + return 1; } -- 1.8.0.158.g0c4328c -- To unsubscribe from this list: send the line 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 v6 8/8] push: cleanup push rules comment
Rewrite to remove inter-dependencies amongst the rules. Signed-off-by: Chris Rorvick ch...@rorvick.com --- remote.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/remote.c b/remote.c index ee0c1e5..6309a87 100644 --- a/remote.c +++ b/remote.c @@ -1319,27 +1319,29 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, continue; } - /* This part determines what can overwrite what. -* The rules are: + /* +* The below logic determines whether an individual +* refspec A:B can be pushed. The push will succeed +* if any of the following are true: * -* (0) you can always use --force or +A:B notation to -* selectively force individual ref pairs. +* (1) the remote reference B does not exist * -* (1) if the old thing does not exist, it is OK. +* (2) the remote reference B is being removed (i.e., +* pushing :B where no source is specified) * -* (2) if the destination is under refs/tags/ you are -* not allowed to overwrite it; tags are expected -* to be static once created +* (3) the update meets all fast-forwarding criteria: * -* (3) if you do not have the old thing, you are not allowed -* to overwrite it; you would not know what you are losing -* otherwise. +* (a) the destination is not under refs/tags/ +* (b) the old is a commit +* (c) the new is a descendant of the old * -* (4) if old is a commit and new is a descendant of old -* (implying new is commit-ish), it is OK. +* NOTE: We must actually have the old object in +* order to overwrite it in the remote reference, +* and that the new object must be commit-ish. +* These are implied by (b) and (c) respectively. * -* (5) regardless of all of the above, removing :B is -* always allowed. +* (4) it is forced using the +A:B notation, or by +* passing the --force argument */ ref-not_forwardable = !is_forwardable(ref); -- 1.8.0.158.g0c4328c -- To unsubscribe from this list: send the line 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 v6 6/8] push: require force for annotated tags
Do not allow fast-forwarding of references that point to a tag object.
Updating from a tag is potentially destructive since it would likely
leave the tag dangling. Disallowing updates to a tag also makes sense
semantically and is consistent with the behavior of lightweight tags.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-push.txt | 10 +-
remote.c | 11 +--
t/t5516-fetch-push.sh | 21 +
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 09bdec7..7a04ce5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -52,11 +52,11 @@ updated.
+
The object referenced by src is used to update the dst reference
on the remote side. By default this is only allowed if dst is not
-under refs/tags/, and then only if it can fast-forward dst. By having
-the optional leading `+`, you can tell git to update the dst ref even
-if it is not allowed by default (e.g., it is not a fast-forward.) This
-does *not* attempt to merge src into dst. See EXAMPLES below for
-details.
+a tag (annotated or lightweight), and then only if it can fast-forward
+dst. By having the optional leading `+`, you can tell git to update
+the dst ref even if it is not allowed by default (e.g., it is not a
+fast-forward.) This does *not* attempt to merge src into dst. See
+EXAMPLES below for details.
+
`tag tag` means the same as `refs/tags/tag:refs/tags/tag`.
+
diff --git a/remote.c b/remote.c
index 012b52f..f5bc4e7 100644
--- a/remote.c
+++ b/remote.c
@@ -1281,9 +1281,16 @@ int match_push_refs(struct ref *src, struct ref **dst,
static inline int is_forwardable(struct ref* ref)
{
+ struct object *o;
+
if (!prefixcmp(ref-name, refs/tags/))
return 0;
+ /* old object must be a commit */
+ o = parse_object(ref-old_sha1);
+ if (!o || o-type != OBJ_COMMIT)
+ return 0;
+
return 1;
}
@@ -1323,8 +1330,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int
send_mirror,
* to overwrite it; you would not know what you are losing
* otherwise.
*
-* (4) if both new and old are commit-ish, and new is a
-* descendant of old, it is OK.
+* (4) if old is a commit and new is a descendant of old
+* (implying new is commit-ish), it is OK.
*
* (5) regardless of all of the above, removing :B is
* always allowed.
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 8f024a0..6009372 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -950,6 +950,27 @@ test_expect_success 'push requires --force to update
lightweight tag' '
)
'
+test_expect_success 'push requires --force to update annotated tag' '
+ mk_test heads/master
+ mk_child child1
+ mk_child child2
+ (
+ cd child1
+ git tag -a -m message 1 Tag
+ git push ../child2 Tag:refs/tmp/Tag
+ git push ../child2 Tag:refs/tmp/Tag
+ file1
+ git add file1
+ git commit -m file1
+ git tag -f -a -m message 2 Tag
+ test_must_fail git push ../child2 Tag:refs/tmp/Tag
+ git push --force ../child2 Tag:refs/tmp/Tag
+ git tag -f -a -m message 3 Tag HEAD~
+ test_must_fail git push ../child2 Tag:refs/tmp/Tag
+ git push --force ../child2 Tag:refs/tmp/Tag
+ )
+'
+
test_expect_success 'push --porcelain' '
mk_empty
echo .git/foo To testrepo
--
1.8.0.158.g0c4328c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Query] Can we ignore case for commiters name in shortlog?
Hi Junio and others, I have a query. git shortlog lists the patches submitted per commiter, like: Viresh Kumar (7): cpufreq: Improve debug prints cpufreq: return early from __cpufreq_driver_getavg() cpufreq: governors: remove redundant code cpufreq: Fix sparse warnings by updating cputime64_t to u64 cpufreq: Fix sparse warning by making local function static cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy-cur cpufreq: Make sure target freq is within limits viresh kumar (3): cpufreq / core: Fix typo in comment describing show_bios_limit() cpufreq / core: Fix printing of governor and driver name cpufreq: Move common part from governors to separate file, v2 I know, there was something wrong at my end and i have commited stuff with different cases. I was just thinking if we can ignore case for commiter name while listing stuff here? So, that we get over any manual mistakes from commiter. -- viresh -- To unsubscribe from this list: send the line 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote: On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. This seems precisely backwards to me. Why not use $ git submodule update --remote --fetch to do your default behavior instead? I suppose I am arguing against the tide of the dominant workflow, but the fetch-by-default idea needlessly conflates two primitive operations: float and fetch. Because --no-fetch is the existing option, and if it ain't broke… ;). I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I've always felt that the origin defaults are broken and are simply being ignored because most users do not trip over them. But ISTR that submodule commands use the remote indicated by the superproject's current remote-tracking configuration, with a fallback to 'origin' if there is none. Sort of a best effort algorithm, I think. Am I remembering that wrong? The current code uses a bare git-fetch. I'm not sure what that defaults to if you're on a detached head. If it bothers you, I'm fine adding the submodule.name.remote option in v6. I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. I haven't dealt with any gitlink merges, but I think that supporting easy gitlink merges is orthogonal to this --remote option. For simple cases like autocommitted submodule floats, one of the conflicting gitlinks will be an ancestor of the other, so it should be easy to automate that merge. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [Query] Can we ignore case for commiters name in shortlog?
On Thu, Nov 29, 2012 at 6:09 PM, viresh kumar viresh.ku...@linaro.org wrote: Hi Junio and others, I have a query. git shortlog lists the patches submitted per commiter, like: Viresh Kumar (7): cpufreq: Improve debug prints cpufreq: return early from __cpufreq_driver_getavg() cpufreq: governors: remove redundant code cpufreq: Fix sparse warnings by updating cputime64_t to u64 cpufreq: Fix sparse warning by making local function static cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy-cur cpufreq: Make sure target freq is within limits viresh kumar (3): cpufreq / core: Fix typo in comment describing show_bios_limit() cpufreq / core: Fix printing of governor and driver name cpufreq: Move common part from governors to separate file, v2 I know, there was something wrong at my end and i have commited stuff with different cases. I was just thinking if we can ignore case for commiter name while listing stuff here? So, that we get over any manual mistakes from commiter. There's a feature that does exactly this. http://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html See the section called Mapping Authors. It discusses the .mailmap file. -- David -- To unsubscribe from this list: send the line 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: [Query] Can we ignore case for commiters name in shortlog?
On 30 November 2012 08:54, David Aguilar dav...@gmail.com wrote: There's a feature that does exactly this. http://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html See the section called Mapping Authors. It discusses the .mailmap file. I have my name there :) I thought using names with different case is actually different then misspelling it. And so, everybody must not be required to update their names in mailmap with different case. So, with same email id and same name (that may be in different case), we can show commits together in shortlog. -- viresh -- To unsubscribe from this list: send the line 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: [Query] Can we ignore case for commiters name in shortlog?
On Fri, 30 Nov 2012, viresh kumar wrote: Hi Junio and others, I have a query. git shortlog lists the patches submitted per commiter, like: Viresh Kumar (7): cpufreq: Improve debug prints cpufreq: return early from __cpufreq_driver_getavg() cpufreq: governors: remove redundant code cpufreq: Fix sparse warnings by updating cputime64_t to u64 cpufreq: Fix sparse warning by making local function static cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy-cur cpufreq: Make sure target freq is within limits viresh kumar (3): cpufreq / core: Fix typo in comment describing show_bios_limit() cpufreq / core: Fix printing of governor and driver name cpufreq: Move common part from governors to separate file, v2 I know, there was something wrong at my end and i have commited stuff with different cases. I was just thinking if we can ignore case for commiter name while listing stuff here? So, that we get over any manual mistakes from commiter. Have a look at the .mailmap file in the top directory of your repo. Nicolas -- To unsubscribe from this list: send the line 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: [Query] Can we ignore case for commiters name in shortlog?
On 30 November 2012 09:03, Nicolas Pitre nicolas.pi...@linaro.org wrote: Have a look at the .mailmap file in the top directory of your repo. Repeating what i said to David in other mail: I have my name there :) I thought using names with different case is actually different then misspelling it. And so, everybody must not be required to update their names in mailmap with different case. So, with same email id and same name (that may be in different case), we can show commits together in shortlog. -- viresh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New git.pot is generated for git 1.8.1 l10n round 2
Hi, New git.pot is generated from v1.8.0.1-347-gf94c3 in the master branch. l10n: Update git.pot (5 new, 1 removed messages) L10n for git 1.8.1 round 2: Generate po/git.pot from v1.8.0.1-347-gf94c3. Signed-off-by: Jiang Xin worldhello@gmail.com This update is for the l10n of upcoming git 1.8.1. You can get it from the usual place: https://github.com/git-l10n/git-po/ -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Sabo jewelry is a tradition built
The particular assortment contains 450 coronary heart elegance necklaces may be utilized necklaces, phones used to merely, jewelry and also necklaces. Thankfully there exists a right in law to style and also generate one thing of one's gorgeous household relative to this kind of goal. Right now there is going to be a single that's not constrained you ought to get some good interest and also imagination. We have been extremely probably greater than 500 Thomas Sabo throughout the world. Bear in mind specific activities basic breathtaking items to make certain they may be wonderful. [url=http://www.thomassabobraceletsshop.co.uk/]thomas sabo uk[/url] are characterized by a series of colossal as the selection of Thomas Sabo Gold. From the variety of a number of silver pendants, diamond earrings and a bracelet-type gold charm available for sale. Thomas Sabo jewelry is a tradition built and incredibly fine detail. http://www.thomassabobraceletsshop.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/Thomas-Sabo-jewelry-is-a-tradition-built-tp7572427.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 p2 1/2] fast-export: don't handle uninteresting refs
On Thu, Nov 29, 2012 at 2:16 AM, Max Horn post...@quendi.de wrote: 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 ;-). Yeah, they point to the same object. 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: Yeah, the next part was added afterwards. 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... Well, we do check fro the UNINTERESTING flag, but on the ref, not on the commit. 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? It's actually revs.cmdline, I typed the wrong one. If you have two refs pointing to the same object, and you do 'one ^two', the object (e.g. 8c7a786) will get the UNINTERESTING flag, but that doesn't tell us anything about the ref being a positive or a negative one, and revs.pending only has the object flags. On the other hand revs.cmdline does have the flags for the refs. Does that explain it? 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 :-(. Indeed. For all the concerns given I made a response to how that either is not true, or doesn't really matter, and in the case of the latter, I asked for examples where it would matter, only to receive nothing. For whatever reason involved people are not responding, not a single valid concern has been raised and remained. So I think it's good. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
swarovski schmuck assortment incorporates ravenscroft
Swarovski crystals are made with precision and are machine cut which provides flawless consistency, rich colour and a captivating sparkle. Swarovski crystals come in a variety of colours, shapes and sizes and are normally produced as beads that are used to make superb jewellery.[url=http://www.swarovskischmuckohrringe.de/]swarovski steine[/url] also design figurines, crystal objects and crystal lighting and the company draws its richness of expression from the culturalheritage of central Europe.For less formal wear, Swarovski crystal beads can be used to create more fun and casual jewellery, including a simple crystal charm bracelet. Adding crystal beads of different colours to a simple charm bracelet type chain gives you an instant mood enhancer even on the dullest of days! These simple bracelets are ideal for little girls, as the crystal beads come in such a huge spectrum of colours that there are bound to be some in your child's favourite tones. As Swarovski crystal beads are very cheap to buy and easy to use, you can even encourage your children to join in and create their own jewellery. It can start a lifetime love of jewellery making and it's rare to find a little girl who doesn't love creating her own jewellery from beads, so why not encourage that creativity? http://www.swarovskischmuckohrringe.de/ -- View this message in context: http://git.661346.n2.nabble.com/swarovski-schmuck-assortment-incorporates-ravenscroft-tp7572429.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
Typically the swarovski presents a variety of less significant
Less expensive compared to utilizing semi-precious as well as valuable gemstones, Swarovski deposits provide the stunning twinkle in order to any kind of jewelry, actually official eveningwear designs. These people may be used to spice up easy denim jeans as well as golf tee clothing or even provide you with a contact associated with glamour as well as individualism at the office. Via their own pure flexibility, absolutely no question they stay the perennial favorite within jewelry making.[url=http://www.bijouxswarovskiboutique.com/]swarovski[/url] have been used in jewellery making for over a century and their continued popularity is testament to the sheer quality and range of jewellery you can design incorporating these iridescent gems. http://www.bijouxswarovskiboutique.com/ -- View this message in context: http://git.661346.n2.nabble.com/Typically-the-swarovski-presents-a-variety-of-less-significant-tp7572430.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
links of london sale has become a 2010 usual list the model owners
The organization right now offers shops in the united states, North america, Hong Kong along with the UNITED KINGDOM. The organization attempts to permit logos of the items by giving room with regard to engravings as well as embossing, in addition to generating a variety of necklaces for people to select from to create sweetheart anklet bracelets their very own. The actual demonstration associated with products is actually outstanding; the organization prides by itself for making every item unique, by using unique containers, laces and ribbons as well as bows. This particular provides an additional sensation associated with luxurious towards the components of jewelry, producing your own present or even buy even more thrilling. [url=http://www.cheaplinksoflondonbracelets.co.uk/]links of london sale[/url] try to inject an element of British eccentricity and a sense of humour into their ranges,which further adds to their appeal in the UK and abroad. http://www.cheaplinksoflondonbracelets.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/links-of-london-sale-has-become-a-2010-usual-list-the-model-owners-tp7572431.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
Am 11/29/2012 21:48, schrieb Junio C Hamano: I've tested this with the testpen set on vfat mounted on my Linux box, ... and it seems to work OK, Works well here on Windows, too. Thanks, -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
