Re: Server-side preventing some files from being overwritten
On Thu, 21 Jul 2016, Jakub Narębski wrote: > Or you can use third-party tools with support for such cases, such Not if the repository is already managed by some other tool (FusionForge, in this case). Thanks anyway, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe from this list: send the line "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: Server-side preventing some files from being overwritten
On Fri, 15 Jul 2016, Ævar Arnfjörð Bjarmason wrote: > I.e. it allows pushing a series which is a series of two commits which: > > 1. Change the forbidden file(s) > 2. Undo changes to the forbidden file(s) That’s precisely allowed. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe from this list: send the line "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: Server-side preventing some files from being overwritten
On Thu, 14 Jul 2016, Junio C Hamano wrote: > Can't this become simpler, e.g. > > if ! git diff-tree --quiet "$old" "$new" -- "$subdir" Thought about diff-tree, but additions are permitted, and diffing the actual file content has overhead too. Just counting the number of object hashes removed from the old tree (recursed) works out just fine. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe from this list: send the line "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: Server-side preventing some files from being overwritten
On Thu, 14 Jul 2016, Stefan Beller wrote: > go roughly like Thanks, that did the trick! Although I’m ordinarily loath to write GNU bash scripts, this helps avoiding temporary files. This works: -cutting here may damage your screen surface- #!/bin/bash export LC_ALL=C subdir=x/y while IFS=' ' read -r old new name; do test x"$name" = x"refs/heads/master" || continue if test x"0" != x"$(comm -23z \ <(git ls-tree -r -z "$old" "$subdir" | sort -z) \ <(git ls-tree -r -z "$new" "$subdir" | sort -z) | wc -c)"; then echo >&2 'Untouchable files touched, commit rejected!' exit 1 fi done exit 0 -cutting here may damage your screen surface- Of course, set “subdir” in line 3 correctly, and GNU coreutils are required for the NUL line termination, which is not an issue here. (BSD has “-R ''” for sort(1), for example.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Server-side preventing some files from being overwritten
Hi *, is there a way, for example with some sort of pre-receive hook, to prevent some files from being overwritten by a push? Use case: In some project, we use Flyway to manage the database schema, and Jenkins to automatically build master’s HEAD after each push (and install it, thus activating the schema files almost immediately). Now, I wish to prevent coworkers from changing anything in the SQL subdirectory that has ever been pushed, forcing them to push new SQL files with ALTER statements instead. (Yes, I am aware this will likely make me even less liked. No, this is not an issue.) As for the comparison, only the changes between the previous HEAD of master and the new HEAD of master after the push would have been accepted need to be taken into account; any intermediate commits, merges, etc. are no problem (because Jenkins does not build them, and because, once a push fails, the developer will have to add a commit reverting their change and moving it to another file on top, I’m no friend of rewriting). File matching would be “any files under a certain subdirectory”, nothing fancier than that. I’ve tried a web search (with two different search engines) for “git prevent pushed files from modification”, but this seems to only show people who want to ignore local changes or somesuch… I’ve asked in IRC, but with no answer for hours I thought that maybe this was the better place to ask for it. Thanks in advance, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe from this list: send the line "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] builtin/tag.c: Add tag name to user message
Display the tag name about to be added to the user during interactive editing. Signed-off-by: Thorsten Glaser t...@debian.org Signed-off-by: Richard Hartmann ric...@debian.org --- builtin/tag.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/tag.c b/builtin/tag.c index 6c7c6bd..8a7265b 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -278,11 +278,11 @@ static int do_sign(struct strbuf *buffer) } static const char tag_template[] = - N_(\nWrite a tag message\n + N_(\nWrite a message for tag:\n %s\n Lines starting with '%c' will be ignored.\n); static const char tag_template_nocleanup[] = - N_(\nWrite a tag message\n + N_(\nWrite a message for tag:\n %s\n Lines starting with '%c' will be kept; you may remove them yourself if you want to.\n); @@ -378,9 +378,9 @@ static void create_tag(const unsigned char *object, const char *tag, struct strbuf buf = STRBUF_INIT; strbuf_addch(buf, '\n'); if (opt-cleanup_mode == CLEANUP_ALL) - strbuf_commented_addf(buf, _(tag_template), comment_line_char); + strbuf_commented_addf(buf, _(tag_template), tag, comment_line_char); else - strbuf_commented_addf(buf, _(tag_template_nocleanup), comment_line_char); + strbuf_commented_addf(buf, _(tag_template_nocleanup), tag, comment_line_char); write_or_die(fd, buf.buf, buf.len); strbuf_release(buf); } -- 2.0.0.rc0 -- To unsubscribe from this list: send the line 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] fix shell syntax error in template
an if clause must not be empty; add a colon command Signed-off-by: Thorsten Glaser t.gla...@tarent.de --- templates/hooks--pre-push.sample | 1 + 1 file changed, 1 insertion(+) diff --git a/templates/hooks--pre-push.sample b/templates/hooks--pre-push.sample index 15ab6d8..1f3bceb 100755 --- a/templates/hooks--pre-push.sample +++ b/templates/hooks--pre-push.sample @@ -30,6 +30,7 @@ do if [ $local_sha = $z40 ] then # Handle delete + : else if [ $remote_sha = $z40 ] then -- 1.8.4.rc3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Matthieu Moy dixit: An opt-in auto-detection would be cool for people who really work in a controlled environment, so that the sysadmin could enable it from Sounds like a plan ;-) I think with several people chiming in on this, while that proposal would affect a majority of people, it would do so in a less intrusive way as the current behaviour of autodetection which negatively affects some users, although not few either, in a strong way. bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King dixit:
It was not clear to me whether his site has /etc/mailname. If it does
Some may, some may not but…
But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.
… that won’t happen. The problem is that they may have
the correct domain there but the localpart will still
be wrong because Kolab localparts are not Unix usernames.
Jonathan Nieder dixit:
I thought that on other operating systems people typically don't have
an /etc/mailname. How does trusting the file when present hurt?
Right, MirBSD doesn’t have it, and I don’t think OpenBSD
added it since we forked.
Jeff King dixit:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
For me that’s also true, but I set a default one at the moment
which is still better than having an unroutable one (on my private
laptop, ${unix_username}@${fqdn} does work, but only as long as my
laptop is powered on, has got IPv6 Internet, and the sending MTA
has IPv6 Internet, so… it’s mostly unroutable).
While I used a fallback for this scenario (me, privately), I’d
also benefit from git refusing to accept commits by default.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said please set
your identity before committing?
Exactly. That’s what I think he said, and what I asked for too.
Thanks,
//mirabilos (working with many OSS projects)
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jonathan Nieder dixit: Can you say a little more about your setup? In a university environment with sysadmin-managed email and /etc/mailname set up correctly it is handy that people can start working without doing Ah okay. We don’t have /etc/mailname set up I think and, additionally, the Unix user name doesn’t match the eMail localpart, so that won’t work anyway. Though we’re having a very heterogenous desktop environment nowadays so I can’t really know all specifics. At least, I think, most devs seem to use the Unix git client now, whereas for svn they use the one that comes with Eclipse… I wonder if it's too gentle and long to get the point across. Would something the following (including the guesses in the message for easier copy-pasting) help? Definitely not. It needs to fail hard if user.email is not set, i.e. refuse to accept the commit. is set and not set. Git already notices the cases where the guessed email address ends with .(none) and errors out, and it could make sense to be more aggressive. The guessed addresses are like 'de...@pc-bn-041.lan.tarent.de' instead of 'd.e...@tarent.de' which is the correct Kolab address (this information can be publicly accessed since the project I noticed it in is on our public FusionForge instance, so I don’t think sharing specifics is bad here, but please don’t hammer our poor trainee with spam now). So they’re a “correct” unix username at a correct FQDN (which, thanks to split-horizon, even would work internally, except there’s of course no MTA set up) and won’t be caught by *.(none) matches. Hope this helps. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple threads of compression
Brandon Casey dixit: The number of threads that pack uses can be configured in the global or system gitconfig file by setting pack.threads. […] The other setting you should probably look at is pack.windowMemory which should help you control the amount of memory git uses while packing. Also look at core.packedGitWindowSize and core.packedGitLimit if your repository is really large. OK, thanks a lot! I can’t really say much about the repositories beforehand because it’s a generic code hosting platform, several instances of which we run at my employer’s place (I also run one privately now), and which is also run by e.g. Debian. But I’ll try to figure out some somewhat sensible defaults. Running 'git gc' with --aggressive should be as safe as running it without --aggressive. OK, thanks. But, you should think about whether you really need to run it more than once, or at all. When you use --aggressive, git will perform the […] Great explanation! I think that I’d want to run it once, after the repository has been begun to be used (probably not correct English but you know what I want to say), but have to figure out a way to do so… but I’ll just leave out the --aggressive from the cronjob then. Much appreciated, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Multiple threads of compression
Hi,
I’m asking here informally first, because my information relates
to a quite old version (the one from lenny-backports). A tl;dr
is at the end.
On a multi-core machine, the garbage collection of git, as well
as pack compression on the server side when someone clones a
repository remotely, the compression is normally done automatically
using multiple threads of execution.
That may be fine for your typical setups, but in my cases, I have
two scenarios where it isn’t:
ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores
as I’m also running some VMs on the box which eat up a lot of CPU
and which I don’t want to slow down.
ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all
the load done by clients, but which is RAM-constrained to only
512 or, when lucky, 768 MiB. It previously served only http/https
and *yuk* Subversion, but now, git comes into the play, and I’ve
seen the one server box I think about go down *HARD* because git
ate up all RAM *and* swap when someone wanted to update their clone
of a repository after someone else committed… well, an ~100 MiB large
binary file they shouldn’t. (It required manual intervention on the
server to kill that revision and then the objects coupled with it,
but even *that* didn’t work, read on for more.)
In both cases, I had to apply a quick hack. One I can reproduce
by now is, that, on the first box, I added a --threads=2 to the
line calling git pack-objects in /usr/lib/git-core/git-repack,
like this:
83 args=$args $local ${GIT_QUIET:+-q} $no_reuse$extra
84 names=$(git pack-objects --threads=2 --keep-true-parents --honor-pack-
keep --non-empty --all --reflog $arg
85 exit 1
(By the way, wrapping source code at 80c is still way to go IMHO.)
On the second box, IIRC I added --threads=1, but that box got
subsequently upgraded from lenny to wheezy so any local modification
is lost (luckily, the problem didn’t occur again recently, or at
least I didn’t notice it, save for the VM load going up to 6-8
several times a day).
tl;dr: I would like to have a *global* option for git to restrict
the number of threads of execution it uses. Several subcommands,
like pack-objects, are already equipped with an optioin for this,
but unfortunately, these are seldom invoked by hand¹, so this can’t
work in my situations.
① automatic garbage collection, “git gc --aggressive --prune=now”,
and cloning are the use cases I have at hand right now.
À propos, while here: is gc --aggressive safe to run on a live,
online-shared repository, or does it break other users accessing
the repository concurrently? (If it’s safe I’d very much like to do
that in a, say weekly, cronjob on FusionForge, our hosting system.)
Thanks in advance!
//mirabilos
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
