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 " > 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
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index af13fcc..0b77eb1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2404,6 +2404,8 @@ __gitk_main ()
if [[ -n ${ZSH_VERSION-} ]]; then
echo "WARNING: this script is deprecated, please see
git-completion.zsh" 1>&2
+ autoload -U +X compinit && compinit
+
__gitcomp ()
{
emulate -L zsh
--
1.8.0.1
--
To unsubscribe from this list: send the line "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 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 --- 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 : > 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 > 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 > > commit 131fa518f10521b4a534863331decbfef2875f24 > Author: Tran Ngoc Quan > 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 > > 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 : > On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano wrote: > > Steven Michalske 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. -- http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "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 "" :-)
> I don't really have one :) so I'm fine with using .
>
>> 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] [...]"
> @@ -4521,7 +4521,7 @@ msgstr "erzeugt Kopfknoten des Referenzprotokolls
> (Standard)"
>
> #: builtin/fsck.c:620
> msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""
"alternate objects" (hopefully) don't change much, so that "wechselnde"
is misleading.
Is there a set translation standard for the "alternative object store"
mechanism in git (alternates)? Otherwise "alternative Objekte" may be
choice which is close to the original and conveys the aspect that they
are objects from an alternative store.
> #: builtin/grep.c:817
> msgid "indicate hit with exit status without output"
> -msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
> +msgstr "zeigt Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
maybe "zeigt Übereinstimmungen nur durch Beendigungsstatus an"
"mit" sounds like "including", "additionally". Also, nothing is shown
("zeigt"), but something is indicated ("zeigt an").
> #: builtin/log.c:102
> msgid "decorate options"
> -msgstr "Ausgabeoptionen"
> +msgstr "decorate Optionen"
"decorate-Optionen" (unless we want to match the standard set by the bad
old K&R translation ;) )
> #: builtin/log.c:1098
> msgid "add To: header"
> -msgstr "fügt Kopfteil \"To:\" hinzu"
> +msgstr "fügt \"To:\" Header hinzu"
Here and in the following I'd a "-", e.g.
msgstr "fügt \"To:\"-Header hinzu"
> #: builtin/log.c:1100
> msgid "add Cc: header"
> -msgstr "fügt Kopteil \"Cc:\" hinzu"
> +msgstr "fügt \"Cc:\" Header hinzu"
...
> -"lädt Konfiguration für beim Überschreiben von Versionen "
> +"lädt Konfiguration für 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 : > > 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. -- http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "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
---
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 : > > 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". > -- > http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "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 : > 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. -- http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "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
Signed-off-by: Holger Arnold
---
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 --- 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 ] [--]
[]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--commit] [--rebase] [--reference ] [--merge] [--recursive] [--]
[...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive]
or: $dashless [--quiet] sync [--] [...]"
@@ -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 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 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
> ---
> 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" writes: > Felipe Contreras : >> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano wrote: >> > Steven Michalske 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 135599 +0900 committer C O Mitter 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 Signed-off-by: C O Mitter -- To unsubscribe from this list: send the line "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 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
---
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 --- 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 `` 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 `` 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 `` +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 `` 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 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
> Signed-off-by: Holger Arnold
> ---
> 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 --- 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 writes: > Adam Tkac 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 writes: > Johannes Sixt 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 --- 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 `` 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 `` 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 `` > +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 `` 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 or 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 or 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);
- u
Re: [RFC/PATCH 1/2] reset: learn to reset to tree
Martin von Zweigbergk 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 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 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//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 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//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..local-branch, > submodule..remote-repository, and submodule..remote-branch > to configure > > $ git checkout submodule..local-branch > $ git pull submodule..remote-repository submodule..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 arc
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 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 : > 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 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 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. --- -- http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "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 wrote:
> Martin von Zweigbergk 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 --- 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 `` 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 `` 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 `` 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
---
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 writes:
> Martin von Zweigbergk 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 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..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 wrote: > Jeff King 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 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 `` 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 `` 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 `` >> +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 `` 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 `` > >> +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 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 > --- > 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 `` 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 `` 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 `` 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 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 `` 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 `` 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] t4049: avoid test failures on filemode challenged file systems (Windows)
Junio C Hamano writes: > Junio C Hamano writes: >> ... >> 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. I've tested this with the testpen set on vfat mounted on my Linux box, i.e. $ cd t $ sh t4049-diff-stat-count.sh --root=/media/5599-553B/test -v and it seems to work OK, so I'll be merging the topic with this patch to 'master' later today. Thanks for noticing. > -- >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 > --- > 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 -- To unsubscribe from this list: send the line "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
---
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 " \n";
+ print "" . esc_html($project) . "\n";
print "\n" .
"description" .
esc_html($descr) . "\n";
unless ($omit_owner) {
--
1.7.10.4
On 13.11.2012 01:46, Junio C Hamano wrote:
> Jeff King 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
>>> ---
>>> 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 " \n";
>>> + print "$project\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 writes: > struct msg_data stored (char *, len) of the data to be included in a That (, ) 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 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 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
---
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 "readme\n" .
+ "\n";
+ insert_file("$projectroot$path/README.html");
+ print "\n\n"; # class="readme"
+ }
+ print "projects\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 "
> -msgstr ""
> +msgstr "lässt Objekte älter als 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] -- [...]\n"
> +" or: git rev-parse --sq-quote [...]\n"
> +" or: git rev-parse [Optionen] [...]\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
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'
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 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 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 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..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
> ---
> 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 "readme\n" .
> + "\n";
> + insert_file("$projectroot$path/README.html");
> + print "\n\n"; # class="readme"
> + }
> + print "projects\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 wrote: > Nguyen Thai Ngoc Duy 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
---
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)
tr
[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
---
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
---
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
---
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 `:` is omitted, the same ref as
will be
updated.
+
The object referenced by is used to update the reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward . By having the optional leading `+`,
-you can tell git to update the ref even when the update is not a
-fast-forward. This does *not* attempt to merge into . See
-EXAMPLES below for details.
+on the remote side. By default this is only allowed if is not
+under refs/tags/, and then only if it can fast-forward . By having
+the optional leading `+`, you can tell git to update the ref even
+if it is not allowed by default (e.g., it is not a fast-forward.) This
+does *not* attempt to merge into . See EXAMPLES below for
+details.
+
`tag ` means the same as `refs/tags/:refs/tags/`.
+
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 (!force_ref_update) {
+
[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
---
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 --- 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 --- 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
---
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 is used to update the reference
on the remote side. By default this is only allowed if is not
-under refs/tags/, and then only if it can fast-forward . By having
-the optional leading `+`, you can tell git to update the ref even
-if it is not allowed by default (e.g., it is not a fast-forward.) This
-does *not* attempt to merge into . See EXAMPLES below for
-details.
+a tag (annotated or lightweight), and then only if it can fast-forward
+. By having the optional leading `+`, you can tell git to update
+the ref even if it is not allowed by default (e.g., it is not a
+fast-forward.) This does *not* attempt to merge into . See
+EXAMPLES below for details.
+
`tag ` means the same as `refs/tags/:refs/tags/`.
+
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 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..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..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 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 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 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 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 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. > > >> 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
