* [PATCH v2] Introduce receive.denyDeletes
From: Jan Krüger @ 2008-11-01 14:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20081031143022.GQ14786@spearce.org>
Occasionally, it may be useful to prevent branches from getting deleted from
a centralized repository, particularly when no administrative access to the
server is available to undo it via reflog. It also makes
receive.denyNonFastForwards more useful if it is used for access control
since it prevents force-updating by deleting and re-creating a ref.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Like this, then?
Documentation/config.txt | 4 ++++
builtin-receive-pack.c | 12 ++++++++++++
t/t5400-send-pack.sh | 11 +++++++++++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 29369d0..965ed74 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1188,6 +1188,10 @@ receive.unpackLimit::
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
+receive.denyDeletes::
+ If set to true, git-receive-pack will deny a ref update that deletes
+ the ref. Use this to prevent such a ref deletion via a push.
+
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index 9f60f31..2c0225c 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -11,6 +11,7 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
+static int deny_deletes = 0;
static int deny_non_fast_forwards = 0;
static int receive_fsck_objects;
static int receive_unpack_limit = -1;
@@ -23,6 +24,11 @@ static int capabilities_sent;
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ if (strcmp(var, "receive.denydeletes") == 0) {
+ deny_deletes = git_config_bool(var, value);
+ return 0;
+ }
+
if (strcmp(var, "receive.denynonfastforwards") == 0) {
deny_non_fast_forwards = git_config_bool(var, value);
return 0;
@@ -185,6 +191,12 @@ static const char *update(struct command *cmd)
"but I can't find it!", sha1_to_hex(new_sha1));
return "bad pack";
}
+ if (deny_deletes && is_null_sha1(new_sha1) &&
+ !is_null_sha1(old_sha1) &&
+ !prefixcmp(name, "refs/heads/")) {
+ error("denying ref deletion for %s", name);
+ return "deletion prohibited";
+ }
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
!is_null_sha1(old_sha1) &&
!prefixcmp(name, "refs/heads/")) {
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 544771d..6fe2f87 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -103,6 +103,17 @@ unset GIT_CONFIG GIT_CONFIG_LOCAL
HOME=`pwd`/no-such-directory
export HOME ;# this way we force the victim/.git/config to be used.
+test_expect_failure \
+ 'pushing a delete should be denied with denyDeletes' '
+ cd victim &&
+ git config receive.denyDeletes true &&
+ git branch extra master &&
+ cd .. &&
+ test -f victim/.git/refs/heads/extra &&
+ test_must_fail git send-pack ./victim/.git/ :extra master
+'
+rm -f victim/.git/refs/heads/extra
+
test_expect_success \
'pushing with --force should be denied with denyNonFastforwards' '
cd victim &&
--
1.6.0.3.524.g86cf.dirty
^ permalink raw reply related
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Alex Riesen @ 2008-11-01 14:39 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: Johannes Schindelin, Nicolas Pitre, git, gitster
In-Reply-To: <b97024a40810312035v5416b578v51b5bed528ca8d39@mail.gmail.com>
Tom Preston-Werner, Sat, Nov 01, 2008 04:35:20 +0100:
> Maybe this is worth asking the question: does anybody use git-daemon
> for private code? If so, why are they not using SSH instead? And in
> that case, how are informative error messages a security risk?
Yes. I use both in my private network, with only ssh open to the
internet. git-daemon is smaller and faster (started from inetd). And
I'm absolutely sure wont ever accidentally push something in the
mirrored repos.
I never had the error reporting problem in this setup, though. It is a
fully controled environment and I can just look in syslog.
I support the original reason for not doing the errors, BTW. It cannot
be on by default.
Heh, try the patch for your private repos and private repos of your
employer, who can sack you for exposing confidential information, and
open them to internet. Than come back and tell us how safe you feel :)
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-11-01 14:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <alpine.DEB.1.00.0811010121570.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
>
> Well, if you install Git for Windows (as opposed to cygwin), it is minimum
> hassle, and Perl is delivered right with it.
>
I'd like to try it again, but weren't ther some fatal problems with
cygwin1.dll being in PATH? I always work either in Cygwin's bash or
just have to have it in PATH, because of the build environment even
being strictly Windows based (case-insensitive and alike) just have to
use sane tooling in its scripts.
>
> P.S.: some guys at the GSoC mentor summit convinced me in at least trying
> to fix _their_ problems on msysGit, so chances are good I'll fix issues
> you would encounter in the same run.
>
Do you still plan to distribute MinGW with it? It's very nice to be
able to track Junio's repo, have own branches and rebuild Git from
time to time. For me, at least.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-11-01 13:50 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano,
Pieter de Bie, git, Scott Chacon
In-Reply-To: <20081101110120.GA3819@artemis.corp>
On Sat, 1 Nov 2008, Pierre Habouzit wrote:
> Well, you can't return _sanely_ an error through a pointer. The &1
> method is broken as soon as you return a char* (there is an alignment
> requirement for malloc, not for any pointer out there), hence shall not
> be used, as it would not be the sole way to test for error.
>
> Another option, that is _theorically_ not portable, but is ttbomk on all
> the platforms we intend to support (IOW POSIX-ish and windows), is to
> use "small" values of the pointers for errors. [NULL .. (void *)(PAGE_SIZE - 1)[
> cannot exist, which gives us probably always 512 different errors, and
4095 actually. You don't need to align error codes.
> the test is ((uintptr_t)ptr < (PAGE_SIZE)) which is cheap. It's butt
> ugly, but encoding errors into pointers is butt ugly in the first place.
Or use "negative" pointers. Again, please have a look at
include/linux/err.h. The pointer range from 0xffffffff (or
0xffffffffffffffff on 64-bit machines) down to the range you want is for
errors, and the top of the address range is almost certain to never be
valid in user space either.
Nicolas
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Theodore Tso @ 2008-11-01 13:39 UTC (permalink / raw)
To: Florian Weimer; +Cc: Jakub Narebski, git
In-Reply-To: <87abcjpvy2.fsf@mid.deneb.enyo.de>
On Sat, Nov 01, 2008 at 11:44:21AM +0100, Florian Weimer wrote:
> > Now Mercurial has chosen to use in-tree '.hgtags' file to have global
> > tags transferable. Never mind the fact that it had to treat this file
> > in special way to have it non-versioned
>
> Oops, thought this file was versioned. Things like
>
> <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
.hgtags is stored as a versioned file in Mercurial. That's one of the
problems, and it leads to no shortage of headaches.
Some of the problems are discussed here:
http://www.selenic.com/mercurial/wiki/index.cgi/Tag
Specifically, to quote the Mercurial Wiki:
The fact that tags identify changesets and are also parts of
changesets has some potentially confusing implications:
* The changeset that a tag refers to is always older than the
changeset that commits the tag itself.
* Updating a working dir to a particular tag will take that
directory back to a point before the tag itself existed.
* Cloning a repo to a particular tag will give you a new repo that
does not have that tag.
In addition, Mercurial has to play interesting special case games in a
repository which has multiple heads (in git terms, "branches"). When
looking up a tag, it has to take the union of all of the .hgtags files
at the tips of each of the branches. So if you have a large number of
heads in your Mercurial repository, tags access doesn't scale well at
all. Mercurial is very much optimized for having a single or at best
a few heads/branches in a repository.
As I mentioned earlier this makes it much more difficult to do a
bidrectional hg/git gateway, since the two DAG's are not toplogically
equivalent, and in fact, *when* you add a tag to a particular
commit/revision can make a distinct difference to the shape of the
DAG. If you tag right after creating the revision in question, then
there is a tag commit right after the revision. If you commit a few
dozen changes into the repository, and *then* tag a point many commits
earlier, then the tag commit will be tacked onto the head of whatever
branch you happened to be on.
In fact, in the worst case, if you accidentally tag a revision on the
"maint" branch while you happened to be on the "devel" branch, the tag
for the commit in the "maint" branch will be attached to the "devel"
branch, and while it will work just fine for *you*, someone who only
fetches the "maint" branch might never see the tag that you placed on
the maint branch --- unless they happen to also pull the devel branch.
What fun, eh?
- Ted
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-11-01 13:25 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: Matthieu Moy, Jakub Narebski, git
In-Reply-To: <f1d2d9ca0811010454u203a7c88x1e09735b3fc1358f@mail.gmail.com>
On Sat, 1 Nov 2008, Thanassis Tsiodras wrote:
> Thanks to everybody for your help.
>
> I will setup an alias to always use "git push --thin".
> For the reverse direction, I don't see a --thin for "git pull",
>
> My understanding is that "git pull" is optimal,
> and does what --thin does for push anyway, right?
Exact.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Ian Hilt @ 2008-11-01 13:00 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081101110439.GB3819@artemis.corp>
On Sat, Nov 01, 2008 at 12:04:39PM +0100, Pierre Habouzit wrote:
> I didn't do it for a very good reason: the To field is tricker to parse
> because very fast it's multiline, and must be split along the ',' when
> parsed back and so on.
Right. So my patch is broken in that it doesn't parse the addresses
correctly. This _should_ be easy to fix. I knew my patch sucked, but I
wanted to get the idea out there. For me, I don't like specifying all
that information on the command-line. It would be nice to be able to
edit the To and Cc fields in the editor.
> And even moreuseful than the To is the Cc list that git-send-email
> bloats to death and that I would like to reduce very often.
You mean git-send-email adds too many addresses to the Cc list, or the
code for those fields is already bloated to death?
> But sadly that needs an expertise of perl I absolutely don't have. We
> probably even want to depend on some MIME perl library that knows about
> those kind of issues and do it for us well.
I'm confused here. Why would a MIME library help?
> But yeah, I knew I left out those, and this was the reason.
Anyway, do you, or does anyone else, think it's even worth coding the
possibility for the user to edit the To and Cc fields?
Ian
^ permalink raw reply
* Re: [PATHv2 7/8] gitweb: embed snapshot format parameter in PATH_INFO
From: Giuseppe Bilotta @ 2008-11-01 12:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811010118.14191.jnareb@gmail.com>
On Sat, Nov 1, 2008 at 1:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 19 Oct 2008, Giuseppe Bilotta wrote:
>
> I'm sorry for the delay.
No problem.
>> When PATH_INFO is active, get rid of the sf CGI parameter by embedding
>> the snapshot format information in the PATH_INFO URL, in the form of an
>> appropriate extension.
>
> The question is: should we use format suffix (e.g. 'tar.gz'),
> or format name (e.g. 'tgz')? The latter is later easier to parse,
> see comments to first patch in better snapshot support for path_info.
I think it's essentially a matter of deciding which extension to use
by default on output, and accepting either extension on input.
>> + # since we destructively absorb parameters, we keep this
>> + # boolean that remembers if we're handling a snapshot
>> + my $is_snapshot = $params{'action'} eq 'snapshot';
>> +
>
> Side note: we destructively absorb parameters, because parameters
> which are not absorbed are then used to generate query string part
> of URL.
>
> Deleting parameter but remembering the fact that it was used is one
> (but not only) solution.
Well, in the specific case of the 'action' parameter we could just
keep it around and only discard it at the end.
>> + if (!$fmt) {
>> + my @snapshot_fmts = gitweb_check_feature('snapshot');
>> + @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
>> + $fmt = $snapshot_fmts[0];
>> + }
>
> I anderstand that the above code is improved with new patch?
Yup, I followed your suggestion of putting the refactoring earlier.
>> + $href .= $known_snapshot_formats{$fmt}{'suffix'};
>
> Again: should we use snapshot prefix, or snapshot name, which means here
> do we use $known_snapshot_formats{$fmt}{'suffix'}; or just $fmt; ?
I really don't know, either is fine for me.
Maybe using $fmt has the benefit that it copes better with some buggy
versions of some browser (like Opera) that tend to strip the .gz from
.tar.gz files ...
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Thanassis Tsiodras @ 2008-11-01 11:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.00.0810311549570.13034@xanadu.home>
Thanks to everybody for your help.
I will setup an alias to always use "git push --thin".
For the reverse direction, I don't see a --thin for "git pull",
My understanding is that "git pull" is optimal,
and does what --thin does for push anyway, right?
On 10/31/08, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 31 Oct 2008, Matthieu Moy wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > Thanassis Tsiodras wrote:
>> >
>> >> So I have to git-gc on my side (after the commits), git-gc on the
>> >> remote,
>> >> and then git-push?
>> >
>> > Perhaps I haven't made myself clear.
>> >
>> > On the local side: git-commit creates loose (compressed, but not
>> > deltified) objects. git-gc packs and deltifies.
>> >
>> > On the remote side (for smart protocols, i.e. git and ssh): git
>> > creates _thin_ pack, deltified;
>>
>> I don't understand this point: the OP talks about pushing, so isn't
>> the pack created on the _local_ machine (and then sent to the remote)?
>
> Yes, the pack is created on the fly when pushing, regardless if the repo
> is already packed or not locally. The only difference a locally packed
> repo provides is a shorter "Compressing objects" phase when pushing
> that's all. The packedness of the remote has no effect at all.
>
>
> Nicolas
>
--
What I gave, I have; what I spent, I had; what I kept, I lost. -Old Epitaph
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Andreas Ericsson @ 2008-11-01 11:53 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jakub Narebski, Pierre Habouzit, git
In-Reply-To: <20081031190157.GG17651@mit.edu>
Theodore Tso wrote:
> On Fri, Oct 31, 2008 at 09:36:33AM -0700, Jakub Narebski wrote:
>>> +#if 0
>>> + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
>>> +#endif
>> By the way, Mercurial names this command IIRC 'hg backout'.
>
> By the way, BitKeeper names this command "bk undo" (which is another
> reason why I would advocate against "git undo" as a syntatic sugar for
> "git checkout HEAD -- $*") --- not that I think there are too many BK
> refugees that might want to switch to git, but it shows that "undo"
> has its own ambiguities; gk uses "undo" the same way we currently use
> "git revert".
>
> For people who argue that "git cherry-pick --revert" or "git
> cherry-pick -R" is too long, I'd argue that for most people its not a
> common command, and for those for which it is common, they can always
> make in alias for "git pick".
>
Probably "git unpick" in that case.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Andreas Ericsson @ 2008-11-01 11:34 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: Johannes Schindelin, Nicolas Pitre, git, gitster
In-Reply-To: <b97024a40810312035v5416b578v51b5bed528ca8d39@mail.gmail.com>
Tom Preston-Werner wrote:
> On Fri, Oct 31, 2008 at 7:35 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Fri, 31 Oct 2008, Nicolas Pitre wrote:
>>
>>> On Sat, 1 Nov 2008, Johannes Schindelin wrote:
>>>
>>>> On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
>>>>
>>>>> The current behavior of git-daemon is to simply close the connection
>>>>> on any error condition. This leaves the client without any
>>>>> information as to the cause of the failed fetch/push/etc.
>>>>>
>>>>> This patch allows get_remote_heads to accept a line prefixed with
>>>>> "ERR" that it can display to the user in an informative fashion.
>>>>> Once clients can understand this ERR line, git-daemon can be made to
>>>>> properly report "repository not found", "permission denied", or
>>>>> other errors.
>>>>>
>>>>> Example
>>>>>
>>>>> S: ERR No matching repository.
>>>>> C: fatal: remote error: No matching repository.
>>>> Makes sense to me.
>>> Note that this behavior of not returning any reason for failure was
>>> argued to be a security feature in the past, by Linus I think.
>> Yes. And it might still be considered one. You do not need to patch
>> git-daemon to use that facility (note that Tom's patch was only for the
>> client side).
>>
>> But for hosting sites such as repo.or.cz or GitHub, that security feature
>> just does not make sense, but it makes for support requests that could be
>> resolved better with a proper error message.
>
> We could also have the error messages sent back conditionally based on
> a command line switch. I've begun porting the changes I made in our
> Erlang git-daemon back to the C code, so maybe I'll give that a try.
> We *definitely* need good error messages for GitHub and I see no
> security risk in doing so.
>
> Maybe this is worth asking the question: does anybody use git-daemon
> for private code? If so, why are they not using SSH instead? And in
> that case, how are informative error messages a security risk?
>
Because it can potentially allow attackers to gain a lot of information
about your system. For instance, if you have /var/lib/rpm on your system,
you're likely running an RPM-based installation. Otoh, if you have
/usr/bin/apt-get, you're most likely running a dpkg-based one. Such info
is vital for the attacker to know what version of a certain server-program
you're using, and can then be used to scan the very helpful world wide web
for security issues concerning your exact distribution.
I'm not saying that's possible with git-daemon now (although I haven't tried),
but if, one day, a git-daemon were to accept a path such as ../../../, we'd
be in real trouble, and an attacker would have no problems what so ever
doing educated guesses on exactly what kind of software is running on your
server.
So, please don't enable any such feature by default. Bury it somewhere deep
in documentation so that users do not enable it by default, or attach a big
fat warning to the docs mentioning it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Andreas Ericsson @ 2008-11-01 11:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Tom Preston-Werner, git, gitster
In-Reply-To: <alpine.LFD.2.00.0810312218300.13034@xanadu.home>
Nicolas Pitre wrote:
> On Sat, 1 Nov 2008, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
>>
>>> The current behavior of git-daemon is to simply close the connection on
>>> any error condition. This leaves the client without any information as
>>> to the cause of the failed fetch/push/etc.
>>>
>>> This patch allows get_remote_heads to accept a line prefixed with "ERR"
>>> that it can display to the user in an informative fashion. Once clients
>>> can understand this ERR line, git-daemon can be made to properly report
>>> "repository not found", "permission denied", or other errors.
>>>
>>> Example
>>>
>>> S: ERR No matching repository.
>>> C: fatal: remote error: No matching repository.
>> Makes sense to me.
>
> Note that this behavior of not returning any reason for failure was
> argued to be a security feature in the past, by Linus I think.
>
By me actually. I wrote the patch for it. Showing "no matching repository"
means git-daemon can be used to disclose information about the remote
server's filesystem layout. While I understand that it's sometimes a useful
feature, please don't ever enable it by default.
That said, I like this patch, as it only works client-side and just enables
others to write code that let's the daemon (if configured to do so) ship a
more informative error message.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Jakub Narebski @ 2008-11-01 12:26 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87abcjpvy2.fsf@mid.deneb.enyo.de>
On Sat, 1 Nov 2008, Florian Weimer wrote:
> * Jakub Narebski:
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>> * Theodore Tso:
>>>
>>>> In the past I've looked at the possibility of creating a
>>>> bi-directional, incremental gateway between hg and git repositories.
>>>> The main thing which makes this difficult is that hg stores tags
>>>> in-band inside the change-controlled .hgtags file. This means that if
>>>> you cut a release, tag it, and then create a commit to further modify
>>>> the repository, the new commit is descended from the tag commit,
>>>> whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
>>>> but not part of the revision history.
>>>
>>> Couldn't you just keep the .hgtags file and have everyone interested
>>> in the tags use special scripts?
>>>
>>> (Admittedly, I'm horribly totally by Git's behavior in this area. I
>>> haven't figured out yet under what circumstances tags are pushed and
>>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
>> Do you agree that global tags should be both non-versioned and
>> trasferable?
>
> Yes, I do. In case of Git, I've got trouble with understanding how to
> actually implement the "transferable" part with Git. The Mercurial
> way is easier to understand, but it means that tags may need some sort
> of "tag at this revision" qualifier to disambiguate, which is rather
> problematic.
In first page of git-fetch(1):
When <refspec> stores the fetched result in tracking branches, the tags
that point at these branches are automatically followed. This is done by
first fetching from the remote using the given <refspec>s, and if the
repository has objects that are pointed by remote tags that it does not yet
have, then fetch those missing tags. If the other end has tags that point
at branches you are not interested in, you will not get them.
You push tags explicitly (using "tag <tagname>" refspec, or specifying
--tags, --all or --mirror, or setting it up in a config) in git.
>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
>> tags transferable. Never mind the fact that it had to treat this file
>> in special way to have it non-versioned
>
> Oops, thought this file was versioned. Things like
>
> <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
>
> suggest it was at some point.
It is half-versioned... :-X From what I remember of discussion on
#revctrl and reading hgbok it is treated in special way: if you
switch branches or rewind to some older version, .hgtags is always
checked out the most recent version.
I don't know how Mercurial deals with situation where one reposityr
added one tag, and other repository add other...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 11:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081031220133.GA14786@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>>> * proper public "stuff" naming (I e.g. realy like types names -- not
>>> struct or enum tags, that I don't really care -- ending with _t as
>>> it helps navigating source.
>> *_t types are reserved by POSIX for future implementations, so that's
>> a no-go (although I doubt POSIX will ever make types named git_*_t).
>
> Yikes. Anyone know where a concise list of the reserved names are?
>
The ones I know of off the top of my head are:
* Anything ending with _t (posix)
pthread_t, size_t, socklen_t, ...
* str/mem/? function name prefix NOT followed by an underscore (C lib)
strlen, strchr, memcmp, memcpy, ...
(strbuf_ stuff doesn't break this, as it contains an underscore in the
name - the underscore following it doesn't have to be immediate).
* Double underscore prefix (compiler / C lib)
__WORDSIZE, __cplusplus, ...
It's also a good idea to stay away from single underscore prefix for
generic-ish names, as some compilers/architectures abuse it extensively.
Prefixing all public functions and macros of the library with 'git_'
(lower-case for functions and function-like macros, upper-case for
the rest) will probably see us through safe. Exceptions can probably
be made for already completed API's, such as the arg-parsing stuff
and the strbuf code.
>> Apart from that, please consider reading Ulrich Drepper's musings on
>> library design at http://people.redhat.com/drepper/goodpractice.pdf
>
> I think I've read that before, but I'll skim over it again.
> Thanks for the link.
>
I swear by it at work, where I'm "the library guy". I'll make sure to
review stuff and can chip in code or thoughts to make the library fly
with a minimum amount of problems and maintenance burden.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Florian Weimer @ 2008-11-01 11:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <87abcjpvy2.fsf@mid.deneb.enyo.de>
* Florian Weimer:
>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
>> tags transferable. Never mind the fact that it had to treat this file
>> in special way to have it non-versioned
>
> Oops, thought this file was versioned. Things like
>
> <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
>
> suggest it was at some point.
Okay, checked it--.hgtags files are in fact versioned. So my
suggestion to preserve the .hgtags file on the Git side remains.
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Pierre Habouzit @ 2008-11-01 11:05 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <gegn38$lku$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Sat, Nov 01, 2008 at 04:48:38AM +0000, Edward Z. Yang wrote:
> I was wondering if there was any way to run `git reset --hard $revlike`,
> or a command with the same effect, without having Git touch every file?
git checkout HEAD -- <list of the files>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Pierre Habouzit @ 2008-11-01 11:04 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <20081101022649.GB17961@sys-0.hiltweb.site>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
On Sat, Nov 01, 2008 at 02:26:49AM +0000, Ian Hilt wrote:
> On Fri, Oct 31, 2008 at 06:01:49PM -0400, Ian Hilt wrote:
> > I've thought something like this would be a good thing. An editor makes
> > things easier to fix than the command-line.
>
> Speaking of which, maybe let's add the To field to the list.
I didn't do it for a very good reason: the To field is tricker to parse
because very fast it's multiline, and must be split along the ',' when
parsed back and so on.
And even moreuseful than the To is the Cc list that git-send-email
bloats to death and that I would like to reduce very often.
But sadly that needs an expertise of perl I absolutely don't have. We
probably even want to depend on some MIME perl library that knows about
those kind of issues and do it for us well.
But yeah, I knew I left out those, and this was the reason.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-01 11:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, Pieter de Bie,
git, Scott Chacon
In-Reply-To: <alpine.DEB.1.00.0811010320370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]
On Sat, Nov 01, 2008 at 02:26:45AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
>
> > Nicolas Pitre <nico@cam.org> wrote:
> > > On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
> > >
> > > > > Both the negative code and errno style are lightweight in the
> > > > > common "no error" case. The errno style is probably more handy
> > > > > for those functions returning a pointer which should be NULL in
> > > > > the error case.
>
> Unfortunately, errno would not be thread-safe, unless you can guarantee
> that errno is a thread-local variable.
Well, TLS afaict is implemented on arches that have GNU ld, or on win32
with a recent enough mingw. Though this is quite a requirement.
> > Oh, good point. We could also stagger the errors so they are
> > always odd, and never return an odd-alignment pointer from a
> > successful function. Thus IS_ERR can be written as:
> >
> > #define IS_ERR(ptr) (((intptr_t)(ptr)) & 1)
> >
> > which is quite cheap, and given the (probably required anyway)
> > aligned allocation policy means we still have 2^31 possible
> > error codes available.
>
> Oh boy, both solutions are ugly as hell. Although the &1 method does not
> limit the memory space as much (except if you plan to work in
> space-contrained environments, where you do not want to be forced to
> word-align structs).
>
> The only pointer game I would remotely consider clean is if you had
>
> const char *errors[] = {
> ...
> };
>
> inline int is_error(void *ptr) {
> return ptr >= errors && ptr < errors + ARRAY_SIZE(errors);
> }
Well, you can't return _sanely_ an error through a pointer. The &1
method is broken as soon as you return a char* (there is an alignment
requirement for malloc, not for any pointer out there), hence shall not
be used, as it would not be the sole way to test for error.
Another option, that is _theorically_ not portable, but is ttbomk on all
the platforms we intend to support (IOW POSIX-ish and windows), is to
use "small" values of the pointers for errors. [NULL .. (void *)(PAGE_SIZE - 1)[
cannot exist, which gives us probably always 512 different errors, and
the test is ((uintptr_t)ptr < (PAGE_SIZE)) which is cheap. It's butt
ugly, but encoding errors into pointers is butt ugly in the first place.
Another option that is what I would prefer, would be for the use of
errno where it makes sense. E.g. if you want a function that fetches an
object, this is somehow what read(3) would look like on our store, more
or less, and errno's are enough. For the other functions where errno
cannot be used, I'm pretty sure we will always pass a handle to some
kind of libgit2 stuff, like the "repository" we're working on. The
_easiest_ way is to put the "last error" into that structure and use
that. I mean, if we want libgit2 to be useful for _everyone_ we *WILL*
have to pass a repository context around. I see almost no way around it.
And there, NULL means error, and if you want to know about the specific
error, git_repo_errno(&ctx) / git_repo_strerr(&ctx) is just easy.
Note: What is important is to be able to check for errors _fast_, I
don't think printing out the error and knowing which error it was would
be in the fast path, so it's less useful to have this information
immediately.
_My_ taste (but again, like the _t I would use what is there, and won't
make a fuss about it at all) is to see function return -1 or NULL for
errors, and "abuse" errno for system-like functions, or put the last
error into the context on which you're working (your "this" more or
less). We don't need a specific error context at all, because we already
have a repository context available.
I'm not really a fan of pointer semantics abuse (it's sometimes useful,
but as the public interface of a library, this is butt-ugly.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 10:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311756160.13034@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
>> Git is currently mostly "GPLv2 or later". A BSDish license was
>> mentioned, because it's the most permissive one and that nobody cared
>> that much, though a LGPL/GPL-with-GCC-exception would probably fly.
>
> I do care. I think the BSD license is too permissive. There are really
> nifty pieces of code in Git that I would be really sorry to see go
> proprietary.
>
I agree with Nicolas, for what it's worth. Although I realize my small
contributions to the git code can be trivially rewritten, I think that
will definitely be trickier with Nicolas' contributions.
>
>> OT: FWIW I prefer BSDish licenses (even the MIT actually) for libraries
>> because I believe that computing is overall better if everyone can use
>> the right tool for the task, and I don't want to prevent people from
>> using good stuff (I hope I write good stuff ;P) because of the license.
>
> Everybody can and does link against glibc on Linux which is LGPL. So
> that doesn't affect "usage".
>
For dynamic libraries, yes, as you can replace them in-flight if you need
to. For static libraries, it's a different matter. I think the gcc exception
is rather special, as parts of gcc is the dynamic linker initialization code,
which has to be shipped in object form and included in all executables
produced with gcc. Perhaps we'd be better off asking one of EFF's lawyers
what each license means, exactly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Florian Weimer @ 2008-11-01 10:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3prlffzk2.fsf@localhost.localdomain>
* Jakub Narebski:
> Florian Weimer <fw@deneb.enyo.de> writes:
>> * Theodore Tso:
>>
>> > In the past I've looked at the possibility of creating a
>> > bi-directional, incremental gateway between hg and git repositories.
>> > The main thing which makes this difficult is that hg stores tags
>> > in-band inside the change-controlled .hgtags file. This means that if
>> > you cut a release, tag it, and then create a commit to further modify
>> > the repository, the new commit is descended from the tag commit,
>> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
>> > but not part of the revision history.
>>
>> Couldn't you just keep the .hgtags file and have everyone interested
>> in the tags use special scripts?
>>
>> (Admittedly, I'm horribly totally by Git's behavior in this area. I
>> haven't figured out yet under what circumstances tags are pushed and
>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
>
> I think you don't understand the issue here.
Probably yes.
> Do you agree that global tags should be both non-versioned and
> trasferable?
Yes, I do. In case of Git, I've got trouble with understanding how to
actually implement the "transferable" part with Git. The Mercurial
way is easier to understand, but it means that tags may need some sort
of "tag at this revision" qualifier to disambiguate, which is rather
problematic.
> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
> tags transferable. Never mind the fact that it had to treat this file
> in special way to have it non-versioned
Oops, thought this file was versioned. Things like
<http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
suggest it was at some point.
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Jakub Narebski @ 2008-11-01 10:33 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ljw3zx8i.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> * Theodore Tso:
>
> > In the past I've looked at the possibility of creating a
> > bi-directional, incremental gateway between hg and git repositories.
> > The main thing which makes this difficult is that hg stores tags
> > in-band inside the change-controlled .hgtags file. This means that if
> > you cut a release, tag it, and then create a commit to further modify
> > the repository, the new commit is descended from the tag commit,
> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> > but not part of the revision history.
>
> Couldn't you just keep the .hgtags file and have everyone interested
> in the tags use special scripts?
>
> (Admittedly, I'm horribly totally by Git's behavior in this area. I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
I think you don't understand the issue here.
First, I think that we all agree here that by definition tags should
named reference (for example 'v1.0' or '1.0') to some immutable
snapshot of a state of repository, so for example when somebody says
'v1.0' everybody knows what it is. In Git tags are immutable (you
can't checkout a tag, you can only checkout state pointed by tag)
external pointers to commits in the DAG (graph) of revisions.
Global tags (tags used to mark releases like 'v1.0') have to _not
versioned_ and _transferable_. Transferable (global) because we want
to know for example what 'v1.0' version was in each clone / each
repository. Non-versioned because we want to have the same set of
tags independent on what branch we are (when we are on 'master', we
want to be able to know about 'v1.0.1' which is on 'maint'), and what
revision we have checked out (for example during bisection, we want to
be able to compare to 'v1.0' even if we have checked out revision
which is earlier than 'v1.0').
Do you agree that global tags should be both non-versioned and
trasferable?
Now Mercurial has chosen to use in-tree '.hgtags' file to have global
tags transferable. Never mind the fact that it had to treat this file
in special way to have it non-versioned (as opposed to for example
.*ignore file, which should be both transferable and versioned); the
fact that in-tree file is used means that tag is visible to outside
(transferable) only after you commit changes in .hgtags file.
In Git tags are external to object database; they reside in
refs/tags/* namespace. They are of course non-versioned, as not being
in-tree. In default configuration however (from what I understand) if
you transfer (get) some tagged commit, you also get a tag that points
to transferred commit. You don't need to create "PROJECT 1.0" (or
"Tagged v1.0") commit to make tag visible to outside.
In short, if you want to have bi-directional gateway between Mercurial
and Git, Git has to be limited:
* no octopus merges (with more than two parents)
* always create 'tagging commits' (bump version number for example)
for tagging purposes on Mercurial side.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Peter Krefting @ 2008-11-01 10:16 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailing List
In-Reply-To: <E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl>
Hi!
Pieter de Bie:
> What would you want that the fast-export/imports are lacking? I think
> they are excellent tools to build some integration on.
Speed. I am cloning from a rather overloaded server on the other side
of the globe (the US). If I were to go the fast-export/import route, I
fear it would take even longer.
> You might want to look at my git-bzr script
Looks very interesting. *adding to my things-to-examine list*
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Santi Béjar @ 2008-11-01 10:03 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ljw3zx8i.fsf@mid.deneb.enyo.de>
On Sat, Nov 1, 2008 at 9:06 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>
> (Admittedly, I'm horribly totally by Git's behavior in this area. I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
Tag are pushed when you tell it so, and pulled if they are pointing to
the history you have, or you can ask to fetch them explicitly.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Santi Béjar @ 2008-11-01 10:00 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git, Junio C Hamano
In-Reply-To: <b97024a40811010028l36606128v61172807f4cf503a@mail.gmail.com>
On Sat, Nov 1, 2008 at 8:28 AM, Tom Preston-Werner <tom@github.com> wrote:
> Gmail is one of the most popular email providers in the world. Now that Gmail
> supports IMAP, sending properly formatted patches via `git imap-send` is
> trivial. This section in SubmittingPatches explains how to do so.
>
> Signed-off-by: Tom Preston-Werner <tom@github.com>
> ---
> Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index a1e9100..f0295c6 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
>
> 5) Back in the compose window: add whatever other text you wish to the
> message, complete the addressing and subject fields, and press send.
> +
> +
> +Gmail
> +-----
> +
> +Submitting properly formatted patches via Gmail is simple now that
> +IMAP support is available. First, edit your ~/.gitconfig to specify your
> +account settings:
> +
> +[imap]
> + folder = "[Gmail]/Drafts"
> + host = imaps://imap.gmail.com
> + user = user@gmail.com
> + pass = p4ssw0rd
> + port = 993
> + sslverify = false
Warning: It is not secure.
> +
> +Next, ensure that your Gmail settings are correct. In "Settings" the
> +"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
> +
> +Once your commits are ready to send to the mailing list, run the following
> +command to send the patch emails to your Gmail Drafts folder.
> +
> + $ git format-patch -M --stdout origin/master | git imap-send
> +
> +Go to your Gmail account, open the Drafts folder, find the patch email, fill
> +in the To: and CC: fields and send away!
Are you sure the mail does not get whitespace damaged?
Santi
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Florian Weimer @ 2008-11-01 8:06 UTC (permalink / raw)
To: git
In-Reply-To: <20081028213144.GC10862@mit.edu>
* Theodore Tso:
> In the past I've looked at the possibility of creating a
> bi-directional, incremental gateway between hg and git repositories.
> The main thing which makes this difficult is that hg stores tags
> in-band inside the change-controlled .hgtags file. This means that if
> you cut a release, tag it, and then create a commit to further modify
> the repository, the new commit is descended from the tag commit,
> whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> but not part of the revision history.
Couldn't you just keep the .hgtags file and have everyone interested
in the tags use special scripts?
(Admittedly, I'm horribly totally by Git's behavior in this area. I
haven't figured out yet under what circumstances tags are pushed and
pulled, so I'm not totally opposed to the Mercurial model. 8-/)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox