* Re: Enable the packed refs file format
From: Phil Richards @ 2006-09-20 20:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609191407340.4388@g5.osdl.org>
On 2006-09-19, Linus Torvalds <torvalds@osdl.org> wrote:
> Too bad that we can't get gcc to warn on these things. We do mark it as
> "format(printf)", but I don't know of any way to tell gcc that it _has_ to
> have that initial constant string.
Not sure if it just a gcc 4.x-ism, but -Wformat-nonliteral or -Wformat-security
might be what you are looking for.
`-Wformat-nonliteral'
If `-Wformat' is specified, also warn if the format string is not a
string literal and so cannot be checked, unless the format function
takes its format arguments as a `va_list'.
`-Wformat-security'
If `-Wformat' is specified, also warn about uses of format
functions that represent possible security problems. At present,
this warns about calls to `printf' and `scanf' functions where the
format string is not a string literal and there are no format
arguments, as in `printf (foo);'. This may be a security hole if
the format string came from untrusted input and contains `%n'.
(This is currently a subset of what `-Wformat-nonliteral' warns
about, but in future warnings may be added to `-Wformat-security'
that are not included in `-Wformat-nonliteral'.)
phil
--
change name before "@" to "phil" for email
^ permalink raw reply
* [PATCH] sha1_name: accept output of git-describe
From: Johannes Schindelin @ 2006-09-20 20:56 UTC (permalink / raw)
To: git, junkio
Now, 'git log $(git describe)' does the same as 'git log'.
NOTE: it might be possible that the unique abbreviation generated by
git-describe is no longer unique at a later stage. Evidently, in this
case the sha1 resolution fails.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
sha1_name.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b497528..c1f6cca 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -159,6 +159,18 @@ static int get_short_sha1(const char *na
if (len < MINIMUM_ABBREV)
return -1;
+
+ /* check for output of git-describe */
+ if (len > MINIMUM_ABBREV + 2) {
+ int i;
+ for (i = len - MINIMUM_ABBREV - 2; i > 0 && name[i] != '-'; i--)
+ ; /* do nothing */
+ if (i > 0 && name[i + 1] == 'g') {
+ name += i + 2;
+ len -= i + 2;
+ }
+ }
+
hashclr(res);
memset(canonical, 'x', 40);
for (i = 0; i < len ;i++) {
--
1.4.2.1.ga0df5-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: Even more support for PATH_INFO based URLs
From: Martin Waitz @ 2006-09-20 21:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Matthias Lederhofer
In-Reply-To: <200609200049.52036.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
hoi :)
On Wed, Sep 20, 2006 at 12:49:51AM +0200, Jakub Narebski wrote:
> Now the following types of path based URLs are supported:
>
> * project overview (summary) page of project
> * project/branch shortlog of branch
> * project/branch:file file in branch, blob_plain view
> * project/branch:dir/ directory listing of dir in branch, tree view
>
> The following shortcuts works (see explanation below):
>
> * project/branch: directory listing of branch, main tree view
> * project/:file file in HEAD (raw)
> * project/:dir/ directory listing of dir in HEAD
> * project/: directory listing of project's HEAD
very nice! thanks a lot!
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 21:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0609200915550.4388@g5.osdl.org>
Hi,
On Wed, 20 Sep 2006, Linus Torvalds wrote:
> On Wed, 20 Sep 2006, Petr Baudis wrote:
> >
> > I personally don't think "throwing away" history is an issue. You can
> > print the old sha1 and it is still in the database so you can recover
> > it.
>
> No it isn't. Once you've lost the reference, you can't really depend on it
> any more in the long run.
Exactly. And to add to that: you can lose the reference just by being not
fast enough. Example:
Some time ago, Junio was playing with colour in the output of git. He was
doing so in some branch he pulled into 'pu'. A few days later, he dropped
it. Now, I was lucky enough to have fetched pu within the short time span
where colour was part of 'pu', and some days (or weeks, don't remember)
later, I found some more time to play with the thing again, and
eventually submitted a patch reintroducing the colour thing.
So, you can lose things you actually never had!
Another, even more serious problems with rebasing: You can introduce a bug
by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
but the sum of your patches, and the patches you are rebasing on, is
buggy. And there is _no_ way to bisect this, since the "good" version can
be gone for good.
These two problems, combined with my love of history, make me never use
rebased branches myself, especially since I basically use git for projects
which I work on alone, just to synchronise between different sites.
As for the problem git-rebase tries to solve: you can get a clean branch
by cherry-picking what you have into a temporary branch, for the sole
purpose of being history clean.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 21:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Another, even more serious problems with rebasing: You can introduce a bug
> by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> but the sum of your patches, and the patches you are rebasing on, is
> buggy. And there is _no_ way to bisect this, since the "good" version can
> be gone for good.
True, however one would hope that you tested the commit before you
rebased it and found it to working. And bisect should point at the
new version of that commit as the break. And then you can debug
it there.
I've seen this happen very rarely, and usually its an initialization
or calling order type of bug and its usually has more to do with
other changes in the branch you are rebasing onto that aren't at the
side your patch affects.
Yes its something annoying to track down but certainly easy enough
with bisect, especially if you have relatively fine-grained commits
and a reasonably good test suite.
--
Shawn.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 21:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060920163437.GC23260@spearce.org>
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Of course an update hook finally took care of the problem, but having
> non fast-forward pushs be permitted on a shared, bare repository
> by default is interesting to say the least. :-)
Unfortunately, it is send-pack making the decision on the client side, not
receive-pack on the server side, the latter of which knows if the server
side is shared or not.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] describe: fall back to 'HEAD' if no appropriate tag exists
From: Johannes Schindelin @ 2006-09-20 21:25 UTC (permalink / raw)
To: git, junkio
Now, if no tag exists to say something like '<tag>-gfffffff', say
'HEAD-gfffffff' instead of erroring out.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
describe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/describe.c b/describe.c
index ab192f8..8b08a3f 100644
--- a/describe.c
+++ b/describe.c
@@ -136,7 +136,7 @@ static void describe(const char *arg, in
return;
}
}
- die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
+ printf("HEAD-g%s\n", find_unique_abbrev(cmit->object.sha1, abbrev));
}
int main(int argc, char **argv)
--
1.4.2.1.ga0df5-dirty
^ permalink raw reply related
* Re: [PATCH] sha1_name: accept output of git-describe
From: Junio C Hamano @ 2006-09-20 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609202255290.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, 'git log $(git describe)' does the same as 'git log'.
>
> NOTE: it might be possible that the unique abbreviation generated by
> git-describe is no longer unique at a later stage. Evidently, in this
> case the sha1 resolution fails.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
> sha1_name.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index b497528..c1f6cca 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -159,6 +159,18 @@ static int get_short_sha1(const char *na
>
> if (len < MINIMUM_ABBREV)
> return -1;
> +
> + /* check for output of git-describe */
> + if (len > MINIMUM_ABBREV + 2) {
> + int i;
> + for (i = len - MINIMUM_ABBREV - 2; i > 0 && name[i] != '-'; i--)
> + ; /* do nothing */
> + if (i > 0 && name[i + 1] == 'g') {
> + name += i + 2;
> + len -= i + 2;
> + }
> + }
> +
Shouldn't you also verify the leading ref (most likely a tag)
exists (and optionally check that it precedes the commit you
decoded into, but that is probably more expensive than it's
worth)?
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 21:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060920212101.GA24415@spearce.org>
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Another, even more serious problems with rebasing: You can introduce a bug
> > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> > but the sum of your patches, and the patches you are rebasing on, is
> > buggy. And there is _no_ way to bisect this, since the "good" version can
> > be gone for good.
>
> True, however one would hope that you tested the commit before you
> rebased it and found it to working. And bisect should point at the
> new version of that commit as the break. And then you can debug
> it there.
You misunderstood me. You can _introduce_ a bug by rebasing. _After_
testing that everything is fine. You can even test the rebased branch and
miss the bug, since your original tests were more thorough.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 21:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609202321390.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
>
> > Of course an update hook finally took care of the problem, but having
> > non fast-forward pushs be permitted on a shared, bare repository
> > by default is interesting to say the least. :-)
>
> Unfortunately, it is send-pack making the decision on the client side, not
> receive-pack on the server side, the latter of which knows if the server
> side is shared or not.
Huh?
The server side update hook is given the old and new value of
the ref by receive-pack; if it exists with a non-zero status the
update fails.
The server side could also check if the current value in the ref
(if it exists) is contained within the new value of the ref. Yes,
I know it doesn't today, but the point is it could. And I was
saying maybe it should when there is no update hook present.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] sha1_name: accept output of git-describe
From: Johannes Schindelin @ 2006-09-20 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64figrhu.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 20 Sep 2006, Junio C Hamano wrote:
> Shouldn't you also verify the leading ref (most likely a tag)
> exists (and optionally check that it precedes the commit you
> decoded into, but that is probably more expensive than it's
> worth)?
I debated this with myself. But there is the cost, and more importantly
the possibility that your victim^H^H^H^H^H^Hother side does not have the
tag at all (for whatever reasons).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] sha1_name: accept output of git-describe
From: Shawn Pearce @ 2006-09-20 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v64figrhu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, 'git log $(git describe)' does the same as 'git log'.
> >
> > NOTE: it might be possible that the unique abbreviation generated by
> > git-describe is no longer unique at a later stage. Evidently, in this
> > case the sha1 resolution fails.
[snip]
> Shouldn't you also verify the leading ref (most likely a tag)
> exists (and optionally check that it precedes the commit you
> decoded into, but that is probably more expensive than it's
> worth)?
I thought the same thing when I first posted that it was probably
an easy change to this code (and then didn't do it myself) and
again when I read Johannes' implementation. Both times I agreed
with you Junio that it was probably too expensive and not worth
doing.
Most of the time we assume not only that the SHA1 itself is unique
but also that it some hex character prefix is unique (such as 6 or
8 digits). One might be able to argue that if we have duplicate
commits (when abbreviated) that you might be able to break the tie by
looking at the tag but even then you may not always be able to do so.
So no, probably not worth it...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Junio C Hamano @ 2006-09-20 21:36 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060920162145.GA23260@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> > (the archive vs active repacking strategy we talked about,
>>
>> Hmm, I think I've missed this, I must look that in the archive.
>
> Junio pushed the core code out but nobody has done the Porecelain
> for it. The basic idea is to prevent repacking every pack all of
> the time; there's probably no reason to repack a 100 MiB pack file
> every time you repack your loose objects so you might want to keep
> say a <5 MiB "active pack" holding your recent created objects
> and repack that frequently and a larger 100+ MiB "history pack"
> holding everything else. Maybe you repack everything on a longer
> time scale, such as once a year.
And IIRC we were stuck on the convention to tell which ones are
archives and which ones are actives (i.e. fair game for
repacking). We were trying to figure out how to mark active
ones (whose name changes every time you repack).
I realized that there is a very simple and obvious solution for
it. Introduce $GIT_OBJECT_DIRECTORY/info/archived-packs, a flat
text file that lists the names of the archive packs. Any pack
not listed there are active one and are subject to repacking.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 21:37 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060920212747.GB24415@spearce.org>
Hi,
On Wed, 20 Sep 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 20 Sep 2006, Shawn Pearce wrote:
> >
> > > Of course an update hook finally took care of the problem, but having
> > > non fast-forward pushs be permitted on a shared, bare repository
> > > by default is interesting to say the least. :-)
> >
> > Unfortunately, it is send-pack making the decision on the client side, not
> > receive-pack on the server side, the latter of which knows if the server
> > side is shared or not.
>
> Huh?
>
> The server side update hook is given the old and new value of
> the ref by receive-pack; if it exists with a non-zero status the
> update fails.
>
> The server side could also check if the current value in the ref
> (if it exists) is contained within the new value of the ref. Yes,
> I know it doesn't today, but the point is it could. And I was
> saying maybe it should when there is no update hook present.
The point being that this check is not necessarily inexpensive. But you
are right, we could introduce this as a security measure. But is it really
intuitive to skip this test when an update hook is added?
I'd rather set another config variable with --shared, which tells git to
refuse receiving non-fast-forwards. This could be a sensible setting in
other setups than shared ones after all. Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 21:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609202325510.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Another, even more serious problems with rebasing: You can introduce a bug
> > > by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> > > but the sum of your patches, and the patches you are rebasing on, is
> > > buggy. And there is _no_ way to bisect this, since the "good" version can
> > > be gone for good.
> >
> > True, however one would hope that you tested the commit before you
> > rebased it and found it to working. And bisect should point at the
> > new version of that commit as the break. And then you can debug
> > it there.
>
> You misunderstood me. You can _introduce_ a bug by rebasing. _After_
> testing that everything is fine. You can even test the rebased branch and
> miss the bug, since your original tests were more thorough.
Why were your original tests more thorough and your rebased testing
was less so? Hmm? Perhaps the test suite needs to be extended as
part of the rebased commit(s).
Of course a rebase-introduced bug could also be in the test suite,
such that you miss the true bug. I've had bugs in the test suite
mask real bug, but never a bug both in the feature and in the test
due to a rebase or mad merge. I guess I've just been lucky there.
When rebasing and even when doing a non-fast forward merge one
needs to keep in mind that your code is being edited on your behalf.
Not much different then if you open it in your favorite editor and
whack away at a keyboard for a while. Sure these auto-edits work
most of the time, on their own and without user intervention, but
every once in while things get messed up. Heck, I've seen editors
mess up source files such that they won't compile anymore.
So moral of the story is you probably should be testing even after
rebasing or cherry picking, and the testing shouldn't be any less
extensive than before you did the rebase/cherry-pick. Which is one
reason why automated test suites can be useful, despite the risks
they also bring...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Shawn Pearce @ 2006-09-20 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslimfcf9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> > (the archive vs active repacking strategy we talked about,
> >>
> >> Hmm, I think I've missed this, I must look that in the archive.
> >
> > Junio pushed the core code out but nobody has done the Porecelain
> > for it. The basic idea is to prevent repacking every pack all of
> > the time; there's probably no reason to repack a 100 MiB pack file
> > every time you repack your loose objects so you might want to keep
> > say a <5 MiB "active pack" holding your recent created objects
> > and repack that frequently and a larger 100+ MiB "history pack"
> > holding everything else. Maybe you repack everything on a longer
> > time scale, such as once a year.
>
> And IIRC we were stuck on the convention to tell which ones are
> archives and which ones are actives (i.e. fair game for
> repacking). We were trying to figure out how to mark active
> ones (whose name changes every time you repack).
Yes. I had pretty much given up on a size threshold concept and
was thus in agreement with you that we just needed a way to flag
each pack file...
> I realized that there is a very simple and obvious solution for
> it. Introduce $GIT_OBJECT_DIRECTORY/info/archived-packs, a flat
> text file that lists the names of the archive packs. Any pack
> not listed there are active one and are subject to repacking.
Like that. :-)
--
Shawn.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Junio C Hamano @ 2006-09-20 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn Pearce
In-Reply-To: <Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'd rather set another config variable with --shared, which tells git to
> refuse receiving non-fast-forwards. This could be a sensible setting in
> other setups than shared ones after all. Thoughts?
If this option is meant to forbid fixing up an screw-up by doing
"git-push --force", I do not quite like it.
It sounds as if arguing that "rm -fr" is dangerous so presence
of -f and -r at the same time should imply -i option. I think
the right answer is not making -i implied, but train the user to
understand what -fr means before using it.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 21:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
> > The server side could also check if the current value in the ref
> > (if it exists) is contained within the new value of the ref. Yes,
> > I know it doesn't today, but the point is it could. And I was
> > saying maybe it should when there is no update hook present.
>
> The point being that this check is not necessarily inexpensive.
But its not _that_ expensive. If the option is set to refuse
non-fast forwards then you take the hit and do the check; if its
set to allow them then you can bypass the check entirely and let
the client direct it (like it does today). Speed vs. safety.
I currently use "git rev-list $2..$1" in my update hooks to make sure
the update is strictly a fast-foward type update for all branches.
Enabling this option and having the check run in receive-pack would
be faster than what I'm doing now (one less fork).
> But you
> are right, we could introduce this as a security measure. But is it really
> intuitive to skip this test when an update hook is added?
Now that you say it, no. These two things (update hook and non-fast
forward update) are unrelated. If the update hook wants to make
the decision on a per branch basis then the option to allow a
non-fast forward push must be enabled in the config file.
> I'd rather set another config variable with --shared, which tells git to
> refuse receiving non-fast-forwards. This could be a sensible setting in
> other setups than shared ones after all. Thoughts?
Agree completely.
--
Shawn.
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Johannes Schindelin @ 2006-09-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vodtafc4g.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 20 Sep 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I'd rather set another config variable with --shared, which tells git to
> > refuse receiving non-fast-forwards. This could be a sensible setting in
> > other setups than shared ones after all. Thoughts?
>
> If this option is meant to forbid fixing up an screw-up by doing
> "git-push --force", I do not quite like it.
>
> It sounds as if arguing that "rm -fr" is dangerous so presence
> of -f and -r at the same time should imply -i option. I think
> the right answer is not making -i implied, but train the user to
> understand what -fr means before using it.
I think it is more like being nice, and disallowing "rm -rf" via FTP,
forcing the user to do it locally.
In a shared repository I really, really, I mean: really, do not want to
mess a branch up that others pull from. And if I have to fix something, I
_can_ do it locally. (Plus the hassle reminds me of giving the pullers a
heads-up.)
Ciao,
Dscho
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Shawn Pearce @ 2006-09-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vodtafc4g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I'd rather set another config variable with --shared, which tells git to
> > refuse receiving non-fast-forwards. This could be a sensible setting in
> > other setups than shared ones after all. Thoughts?
>
> If this option is meant to forbid fixing up an screw-up by doing
> "git-push --force", I do not quite like it.
Yes, it is meant for stopping exactly that.
As the repository owner with direct access to the repository I
don't want anyone to be able to use --force to reset a branch.
If a branch reset needs to happen I want to do it directly on
the repository. Its a rather destructive operation, as we have
been saying. I don't want a user slamming in "--force" just because.
On the other hand you can also configure the option to allow
`git push --force` and craft a smart update hook which looks at
who is doing the push and if that is permissible to the ref in
question; exit'ing non-zero if not.
Basically I don't see why an update hook should be necessary to
disallow all non-fast forward pushes.
> It sounds as if arguing that "rm -fr" is dangerous so presence
> of -f and -r at the same time should imply -i option. I think
> the right answer is not making -i implied, but train the user to
> understand what -fr means before using it.
Some people cannot be trained. No matter how hard you may try.
--
Shawn.
^ permalink raw reply
* [PATCH] add receive.denyNonFastforwards config variable
From: Johannes Schindelin @ 2006-09-20 22:28 UTC (permalink / raw)
To: Junio C Hamano, git, Shawn Pearce
If receive.denyNonFastforwards is set to true, git-receive-pack will deny
non fast-forwards, i.e. forced updates. Most notably, a push to a repository
which has that flag set to true will fail.
As a first user, 'git-init-db --shared' sets this flag, since in a shared
setup, you are most unlikely to want forced pushes to succeed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-init-db.c | 1 +
cache.h | 1 +
environment.c | 1 +
receive-pack.c | 12 ++++++++++++
setup.c | 2 ++
5 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 36c3088..e6a2d7d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -310,6 +310,7 @@ int cmd_init_db(int argc, const char **a
*/
sprintf(buf, "%d", shared_repository);
git_config_set("core.sharedrepository", buf);
+ git_config_set("receive.denyNonFastforwards", "true");
}
return 0;
diff --git a/cache.h b/cache.h
index f2fdc00..2224c83 100644
--- a/cache.h
+++ b/cache.h
@@ -188,6 +188,7 @@ extern int prefer_symlink_refs;
extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int shared_repository;
+extern int deny_non_fast_forwards;
extern const char *apply_default_whitespace;
extern int zlib_compression_level;
diff --git a/environment.c b/environment.c
index 84d870c..63b1d15 100644
--- a/environment.c
+++ b/environment.c
@@ -20,6 +20,7 @@ int warn_ambiguous_refs = 1;
int repository_format_version;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = PERM_UMASK;
+int deny_non_fast_forwards = 0;
const char *apply_default_whitespace;
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
int pager_in_use;
diff --git a/receive-pack.c b/receive-pack.c
index 78f75da..c5ea2a1 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -2,6 +2,8 @@ #include "cache.h"
#include "refs.h"
#include "pkt-line.h"
#include "run-command.h"
+#include "commit.h"
+#include "object.h"
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
@@ -127,6 +129,16 @@ static int update(struct command *cmd)
return error("unpack should have generated %s, "
"but I can't find it!", new_hex);
}
+ if (deny_non_fast_forwards) {
+ struct commit *old_commit, *new_commit;
+ old_commit = (struct commit *)parse_object(old_sha1);
+ new_commit = (struct commit *)parse_object(new_sha1);
+ struct commit_list *bases = get_merge_bases(old_commit,
+ new_commit, 1);
+ if (!bases || hashcmp(old_sha1, bases->item->object.sha1))
+ return error("denying non-fast forward;"
+ " you should pull first");
+ }
safe_create_leading_directories(lock_name);
newfd = open(lock_name, O_CREAT | O_EXCL | O_WRONLY, 0666);
diff --git a/setup.c b/setup.c
index 2afdba4..9a46a58 100644
--- a/setup.c
+++ b/setup.c
@@ -244,6 +244,8 @@ int check_repository_format_version(cons
repository_format_version = git_config_int(var, value);
else if (strcmp(var, "core.sharedrepository") == 0)
shared_repository = git_config_perm(var, value);
+ else if (strcmp(var, "receive.denynonfastforwards") == 0)
+ deny_non_fast_forwards = git_config_bool(var, value);
return 0;
}
--
1.4.2.1.g7521-dirty
^ permalink raw reply related
* Re: git pull for update of netdev fails.
From: Jakub Narebski @ 2006-09-20 22:34 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0609202304270.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Another, even more serious problems with rebasing: You can introduce a bug
> by rebasing. Meaning: git-rebase can succeed, even compilation is fine,
> but the sum of your patches, and the patches you are rebasing on, is
> buggy. And there is _no_ way to bisect this, since the "good" version can
> be gone for good.
Well, you can always tag tip of branch before rebasing, and remove the tag
when rebased branch is tested.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Make git_get_refs_list do work of git_get_references
From: Jakub Narebski @ 2006-09-20 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veju6h0et.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski wrote:
>> + if (! $4) { # unpeeled, direct reference
>> + push @refs, { hash => $1, name => $3 }; # without type
>> + } elsif ($3 eq $refs[-1]{'name'}) {
>> + # most likely a tag is followed by its peeled
>> + # (deref) one, and when that happens we know the
>> + # previous one was of type 'tag'.
>> + $refs[-1]{'type'} = "tag";
>> + }
>>...
>> - return \@reflist;
>> + return (\@reflist, \%refs);
>
> You are maintaining reflist (an array of hashrefs each element
> of which describes name, type, hash and other parse_ref()
> information for the ref) and refs (a hash that maps from name to
> hash) separatly. I wonder if this really has the performance
> advantage over just compute and return reflist from here and
> have the callers who need the mapping to derive it from the list
> (i.e.
>
> my ($reflist) = git_get_refs_list();
> my %refs = map { $_->{name} => $_->{hash} } @$reflist;
> ).
The %refs hash contain also map from peeled (dereferenced) object
to ref name. The information about derefs is not present in @reflist.
So the answer is that you can't derive %refs from @reflist.
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH] add receive.denyNonFastforwards config variable
From: Junio C Hamano @ 2006-09-20 22:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn Pearce
In-Reply-To: <Pine.LNX.4.63.0609210027430.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If receive.denyNonFastforwards is set to true, git-receive-pack will deny
> non fast-forwards, i.e. forced updates. Most notably, a push to a repository
> which has that flag set to true will fail.
>
> As a first user, 'git-init-db --shared' sets this flag, since in a shared
> setup, you are most unlikely to want forced pushes to succeed.
I am Ok with the general idea, but ...
> @@ -127,6 +129,16 @@ static int update(struct command *cmd)
> return error("unpack should have generated %s, "
> "but I can't find it!", new_hex);
> }
> + if (deny_non_fast_forwards) {
> + struct commit *old_commit, *new_commit;
> + old_commit = (struct commit *)parse_object(old_sha1);
> + new_commit = (struct commit *)parse_object(new_sha1);
> + struct commit_list *bases = get_merge_bases(old_commit,
> + new_commit, 1);
> + if (!bases || hashcmp(old_sha1, bases->item->object.sha1))
> + return error("denying non-fast forward;"
> + " you should pull first");
> + }
> safe_create_leading_directories(lock_name);
>
> newfd = open(lock_name, O_CREAT | O_EXCL | O_WRONLY, 0666);
I am wondering if there can be more than one base and the old_sha1
is not returned as the first one.
^ permalink raw reply
* Re: [PATCH] describe: fall back to 'HEAD' if no appropriate tag exists
From: Junio C Hamano @ 2006-09-20 22:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0609202324210.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, if no tag exists to say something like '<tag>-gfffffff', say
> 'HEAD-gfffffff' instead of erroring out.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
> describe.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/describe.c b/describe.c
> index ab192f8..8b08a3f 100644
> --- a/describe.c
> +++ b/describe.c
> @@ -136,7 +136,7 @@ static void describe(const char *arg, in
> return;
> }
> }
> - die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
> + printf("HEAD-g%s\n", find_unique_abbrev(cmit->object.sha1, abbrev));
> }
Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
At least with tags, the user can assume NAME-gREV means commit
whose abbrev is REV that is descendant of NAME. HEAD is not
necessarily so.
Having said that, in order to avoid barfing, we have to have
something there, and HEAD is already special in many aspects
anyway (e.g. by only saying HEAD you cannot tell which branch's
tip you are talking about), it might be good enough.
I am just wondering if there is some other obvious substitute
that is better than HEAD. "GIT-g%s" is not it ("g" already
stands for GIT).
Another possibility is just to do
puts(sha1_to_hex(cmit->object.sha1))
in this case. I tend to like that better somehow; it makes
things more explicit.
^ 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