* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Joel Dice wrote:
> > Proposal:
> >
> > As with Subversion, the IRN state in Git would be specific to a given
> > repository and have no significance beyond that repository. Also like
> > Subversion, IRN state would be global across a repository, so that a
> > commit to any branch would increment the current IRN value. Every Git
> > command taking a revision parameter would accept an IRN using a syntax
> > such as "r$IRN". Every commit would report the IRN to the user as well as
> > the SHA ID. The IRN feature could be enabled or disabled via a
> > configuration option.
>
> This of course limits IRN much. Tags are valid across repositories.
> I'm not sure if many repositories are managed using shared repositories
> (centralized approach).
Not only that but its somewhat difficult to execute
`git log v1.4.0..v1.4.1` on a central repository; if IRNs are only
valid within that repository then that's the only way they could
even be used.
Note that somewhat difficult here means you need to:
- gain direct read-only access to the repository's files (not
all systems may be able to offer this to all users);
- set GIT_DIR environment variable OR pass --git-dir before
the subcommand;
- do all of that without doing something stupid in the
repository directory such as `rm *` without realizing
where you are;
- but still maintain write access so you can push.
and that latter GIT_DIR/--git-dir part users are bound to forgot as
its not as natural as just assuming the repository is the directory
you are in. Of course that could be probably fixed...
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Linus Torvalds @ 2006-09-19 22:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Joel Dice, git
In-Reply-To: <20060919220604.GE8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> > It might be that "r1.56" was done on another branch, and is totally
> > unrelated to "r1.57" (other than they sharing some common ancestor far
> > back).
>
> This is actually exactly how SVN revision numbering works. There's just
> a single number (no '1.') and it indeed jumps randomly if you have
> several concurrent branches in your (ok, Linus does not have any, just
> someone's) repository.
Oh, ok, if it's just a single numbering, then that's easy to do. It won't
_mean_ anything, and you're seriously screwed if you ever merge anything
else (or use a git that doesn't update the refcache or whatever), but it
is simple and stable within a single repo.
Linus
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Unfortunately, one cannot (as of now) use result of git-describe as
> <commit-ish>. I'd rather have it fixed, than port idea from _centralized_
> SCM do distributed SCM.
This doesn't work?
git log $(git describe | cut -d- -f2 | sed 's/^g//')
Its obviously so clear and easy to type! :-)
That should be pretty easy to teach sha1_name.c:get_sha1_basic to
look for the pattern commonly used by git-describe, break on "-g",
verify the tag, then unabbreviate the ID.
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Jakub Narebski @ 2006-09-19 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
Jakub Narebski wrote:
> Joel Dice wrote:
>
>> I'm considering adopting Git for a medium-sized project which is currently
>> managed using Subversion. I've used Git for a few smaller projects
>> already, and the thing I've missed most from Subversion is the convenience
>> of incrementing revision numbers. The following is a proposal to add this
>> feature to Git.
>>
>>
>> Rationale:
>>
>> Incrementing revision numbers (IRNs - an acronym I just made up) are
>> useful in that they can be treated as auto-generated tags which are easier
>> to remember and communicate than SHA hashes, yet do not require extra
>> effort to create like real tags. Also, they have the advantage of being
>> chronologically ordered, so if I assert that a bug was fixed in revision
>> 42 of a shared repository, everyone may assume that revision 45 has that
>> fix as well.
>
> That is true _only_ if you have linear history. If you have multiple
> concurrent branches, revision 42 can be in branch 'next', revision '45' in
> topic branch 'xx/topic' which forked before revision 42, and do not have
> the fix.
Additionally, what does _chronological_ mean? Time the commit is recorded?
Remember that in distributed development commits can be fetched from other
repository, or arrive via email and applied using git-am. In git you can
also rebase branch. Git records merges, and said merges are sometimes
just fast-forward. All those difficulties have to be solved for IRNs.
By the way, there was similar proposal to add either hidden field ('note'
like) to commit object denoting _generation_ of commit, or add cache of
commits' generation numbers. Generation number of root (parentless) commit
is 0, generation number of a commit is maximum of generation numbers of its
parents plus 1. But this proposal was for easier and faster generation of
topological order.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix broken sha1 locking
From: Linus Torvalds @ 2006-09-19 22:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060919212340.GC8259@pasky.or.cz>
On Tue, 19 Sep 2006, Petr Baudis wrote:
>
> lock_ref_sha1_basic() never strdup()s ref (at least the reference used
> for git_path() later).
Ahh. So how did that ever work? Even in the current "master" branch, we
call "resolve_ref()", which calls "git_path()", and historically we only
had a single buffer..
So we're doing
lock_ref_sha1_basic(git_path("refs/%s", ref),...
with that single buffer, and we _do_ do "xstrdup(path)" in between.
[ looks.. ]
Ahh.
We re-assign the "path" to point to the result value of the resolve_ref(),
and so we do re-use the buffer, but we apparently never have any
overlapping use. The packed-ref changes make us need pathnames in the
middle, which we didn't use to do.
I do agree that we tend to use too many static buffers there. The static
buffers are fine for the low-level functions ("mkpath()" and
"git_path()"), but once they start getting passed around as arguments to
other functions, they should be xstrdup'd or something.
Linus
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Petr Baudis @ 2006-09-19 22:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
Dear diary, on Wed, Sep 20, 2006 at 12:07:08AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Joel Dice wrote:
> > Rationale:
> >
> > Incrementing revision numbers (IRNs - an acronym I just made up) are
> > useful in that they can be treated as auto-generated tags which are easier
> > to remember and communicate than SHA hashes, yet do not require extra
> > effort to create like real tags. Also, they have the advantage of being
> > chronologically ordered, so if I assert that a bug was fixed in revision
> > 42 of a shared repository, everyone may assume that revision 45 has that
> > fix as well.
>
> That is true _only_ if you have linear history. If you have multiple
> concurrent branches, revision 42 can be in branch 'next', revision '45' in
> topic branch 'xx/topic' which forked before revision 42, and do not have
> the fix.
Oops, I've completely overlooked that bit of the rationale. Of course
IRNs cannot assure this.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:09 UTC (permalink / raw)
To: Joel Dice; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
Joel Dice <dicej@mailsnare.net> wrote:
> I'm considering adopting Git for a medium-sized project which is currently
> managed using Subversion. I've used Git for a few smaller projects
> already, and the thing I've missed most from Subversion is the convenience
> of incrementing revision numbers. The following is a proposal to add this
> feature to Git.
I can't say I miss that particular feature. Abbrevations of
SHA1 IDs tend to work very well for the projects I use Git on;
6-8 characters is easily more than enough to uniquely identify
a revision. Heck half the time even 4 hex characters is enough.
> Rationale:
>
> Incrementing revision numbers (IRNs - an acronym I just made up) are
> useful in that they can be treated as auto-generated tags which are easier
> to remember and communicate than SHA hashes, yet do not require extra
> effort to create like real tags. Also, they have the advantage of being
> chronologically ordered, so if I assert that a bug was fixed in revision
> 42 of a shared repository, everyone may assume that revision 45 has that
> fix as well.
But with respect to what branch?
Branches in a Git repository are very common:
o------o-o-o-o-o-o--- B1
/
-o--o--o-----o--------o B2
Assuming the branch point on the left was r60, what is the latest
commit on B1? On B2? What about if I merge B1 and B2 together?
Or are you proposing that the commits are ordered by the time that
they arrive into the repository?
But even if that's the case lets say I fix the bug on B1 in r42
but a commit on B2 gets assigned r45. The bug isn't fixed in r45;
not unless B1 was merged into B2 in r43, r44 or r45. But there's
no way to know that from just an IRN.
I fail to see how IRNs simplify commit naming or determining where
a feature or bug fix is within the branching structure.
> A simple, efficient implementation of this feature would be based on a
> single file, $GIT_DIR/history, which would contain a newline-delimited
> list of SHA commit IDs in chronological order, oldest first. The current
> repository IRN would be calculated as the size of that file divided by the
> SHA+newline length, and the commit ID of any IRN could be determined by
> seeking to the correct offset in that file. Every commit would cause a
> new line to be appended to the history file with that commit's ID.
> Finally, a history file could be generated for an existing repository by
> serializing the commit history based on chronological order.
How about just using bare tags under the namespace 'refs/tags/r/'?
With the new packed refs implemention these would cost you a tiny
amount of overhead over what you propose (due to the ref name also
being stored) but its already implemented and does the job just
as well.
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Jakub Narebski @ 2006-09-19 22:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
Joel Dice wrote:
> I'm considering adopting Git for a medium-sized project which is currently
> managed using Subversion. I've used Git for a few smaller projects
> already, and the thing I've missed most from Subversion is the convenience
> of incrementing revision numbers. The following is a proposal to add this
> feature to Git.
>
>
> Rationale:
>
> Incrementing revision numbers (IRNs - an acronym I just made up) are
> useful in that they can be treated as auto-generated tags which are easier
> to remember and communicate than SHA hashes, yet do not require extra
> effort to create like real tags. Also, they have the advantage of being
> chronologically ordered, so if I assert that a bug was fixed in revision
> 42 of a shared repository, everyone may assume that revision 45 has that
> fix as well.
That is true _only_ if you have linear history. If you have multiple
concurrent branches, revision 42 can be in branch 'next', revision '45' in
topic branch 'xx/topic' which forked before revision 42, and do not have
the fix.
Unfortunately, one cannot (as of now) use result of git-describe as
<commit-ish>. I'd rather have it fixed, than port idea from _centralized_
SCM do distributed SCM.
> Proposal:
>
> As with Subversion, the IRN state in Git would be specific to a given
> repository and have no significance beyond that repository. Also like
> Subversion, IRN state would be global across a repository, so that a
> commit to any branch would increment the current IRN value. Every Git
> command taking a revision parameter would accept an IRN using a syntax
> such as "r$IRN". Every commit would report the IRN to the user as well as
> the SHA ID. The IRN feature could be enabled or disabled via a
> configuration option.
This of course limits IRN much. Tags are valid across repositories.
I'm not sure if many repositories are managed using shared repositories
(centralized approach).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Petr Baudis @ 2006-09-19 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joel Dice, git
In-Reply-To: <Pine.LNX.4.64.0609191416500.4388@g5.osdl.org>
Dear diary, on Tue, Sep 19, 2006 at 11:51:49PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> Another thing you CAN do, is to just number them in time in a single repo.
> Every time you do a commit, you can create a "r1.<n+1>" revision, and that
> would work. It wouldn't look like the SVN numbers do, and it would only
> work _within_ that repository, but it would work.
>
> But it would mean that "r1.57" is _not_ necessarily the child of "r1.56".
> It might be that "r1.56" was done on another branch, and is totally
> unrelated to "r1.57" (other than they sharing some common ancestor far
> back).
This is actually exactly how SVN revision numbering works. There's just
a single number (no '1.') and it indeed jumps randomly if you have
several concurrent branches in your (ok, Linus does not have any, just
someone's) repository.
> You're going to hit a few confusing issues if you really want to call
> things "r1.x.y.z"
Noone does, that indeed would be horrible. But having the commits
numbered inside a repository would indeed make for simple usage if you
need to type in commit ids frequently, and could make Git a bit
friendlier to newcomers.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Petr Baudis @ 2006-09-19 22:00 UTC (permalink / raw)
To: Joel Dice; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com>
Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter
where Joel Dice <dicej@mailsnare.net> said that...
> On Tue, 19 Sep 2006, Petr Baudis wrote:
> >Also, multiple IRNs could refer to a single real commit if you do e.g.
> >cg-admin-uncommit, since revlog logs revision updates, not new revisions
> >created. This may or may not be considered a good thing. If you rather
> >want to just create a new IRN at commit object creation time, also note
> >that some tools _might_ validly create commit objects and then throw
> >them away, which would generate non-sensical (and after prune, invalid)
> >IRNs.
>
> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN
> feature is intended mainly for shared repositories. I would suggest that
> such commands simply be disallowed for such repositories.
What kind of shared repositories? You yourself said that IRNs are
local to a repository, thus they are not preserved over cloning/fetching
from a repository, if you mean that.
> The problem of temporary commits certainly needs to be addressed. In this
> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so,
> perhaps I could somehow hook into the git-update-ref step. Is that what
> the revlog code does?
Yes. But not every commit is always recorded to something in refs/.
The simplest case is if you fetch from a remote repository (or push to
your repository), only the latest commit is recorded.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Jakub Narebski @ 2006-09-19 21:58 UTC (permalink / raw)
To: git
In-Reply-To: <20060919211844.GB8259@pasky.or.cz>
Petr Baudis wrote:
> We already have support for recording something similar, it's called a
> revlog. You would just need to modify it to aggregate all the branches
> in a single file.
_reflog_, not revlog.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Linus Torvalds @ 2006-09-19 21:51 UTC (permalink / raw)
To: Joel Dice; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
On Tue, 19 Sep 2006, Joel Dice wrote:
>
> I'd be happy to put together a patch that implements this, but first I'd like
> to get some feedback. If something like this has already been proposed,
> please point me to the discussion. Thanks.
I really don't think you can do it sanely.
The thing is, the reason subversion can do it is simply that SVN is
terminally broken.
Really. SVN is crap. It may be prettier crap than CVS, but it's literaly
no different from putting confectioners sugar on top of a cowpatty. It's
not really "fixing" anything. And the revision numbering is actually very
much part of the problem.
The thing is, you can limit yourself to a single repository, and once you
have branches, you _still_ cannot sanely number the commits with anything
like "r1.3.4.1".
Here's an example. Let's say that you start out with just a regular
"master" branch, and you number the commits "r1.1", "r1.2" and so on (of
course, that extra "1." at the beginning doesn't actually make any
_sense_, but let's keep it just to not confuse CVS/SVN users any more than
they are already confused).
Now, you've done five commits, and are at "r1.5", and everything looks
beautiful, and you're getting comfy, so you start and check out a branch
called "test". What do you call it?
The thing is, you need to call it "r1.5", because the _commit_ is still
exactly the same as the master one. Creation of a branch in git doesn't
actually create any new commits, it just creates a new pointer.
So far so fine. We can ignore that, and make the rules be:
- when creating a commit, we look at the branch name. If the branch name
is "master", we increment the second number, and drop all other
numbers.
- if the branch name is anything else, we look whether the current state
is the same any other branch, in which case we just add a ".1" at the
end relative to the branch (or a ".2" if a ".1" already exists and so
on). Otherwise we increment the last number.
that's not a wonderful set of rules, but it might work. So what happens is
that when we create the next commit (on the "test" branch), that commit
will be called "r1.5.1" (which is what you'd expect). Go along a bit, and
you get "r1.5.2" and "r1.5.3" too. Wonderful.
Now you decide to merge this back into "master". Which, btw, hasn't had
any actual development happen, so it's stil at 1.5. You check out "master"
and do a "git pull . test" (or "git pull . r1.5.3", which is obviously the
same thing), and what happens?
That's right, we now fast-forward master to that revision, since nothing
happened on master. Which means that your master branch is now comprised
of revisions "r1.1" .. "r1.5" "r1.5.1" .. "r1.5.3". That makes no sense at
all, but it works. The next commit would be called "r1.6".
In other words, the SVN numbering is just insane in a git repo, although
you can "make it work" in a limited sense (but the numbering would jump in
odd ways. The thing is, all the things that are true in a distributed
environment are true in a single repository too, so limiting yourself to
a single repo doesn't really make them go away.
Another thing you CAN do, is to just number them in time in a single repo.
Every time you do a commit, you can create a "r1.<n+1>" revision, and that
would work. It wouldn't look like the SVN numbers do, and it would only
work _within_ that repository, but it would work.
But it would mean that "r1.57" is _not_ necessarily the child of "r1.56".
It might be that "r1.56" was done on another branch, and is totally
unrelated to "r1.57" (other than they sharing some common ancestor far
back).
See? The SVN (and CVS) revision numbering really only makes sense because
it's fundamentally a non-distributed model.
Git is so _fundamentally_ distributed that even within one single
repository, each branch is totally independent ("distributed"). In
CVS/SVN, branches aren't independent of each other, and that's why they
show up in the revision numbering.
So you can really only number things as long as you never do any branches
at all, and just do a linear development. In that case, and in that case
only, does numbering work. Or you'd have to have a very "non-git" approach
to branches (the above silly rules _can_ be used - possibly with some
fixes - to give you essentially SVN-like revision numbers, if you _always_
generate a commit when you merge).
It doesn't seem to make a whole lot of sense, does it?
Btw, along the same issues, BK actually had RCS/CVS/SVN-like revision
numbers, but to solve the distributed problem (BK didn't have branches) BK
had a different approach.
So BK actually _did_ number things as "1.1" and "1.4.6" etc, and was
obviously distributed, and the revision numbers actually matched the shape
of the development history the same way CVS/SVN does. But if you do that,
what happens is that a merge will _change_ the numbers: you may have
started with two different branches that both were at "r1.2", but at the
end of it one of them got renamed to "r1.1.1", and the final result was
called "r1.3".
So if you allow malleable revision numbers, you can definitely do it. That
ends up being _really_ confusing. I know a number of people who otherwise
were smart really never understood why "r1.576" might not stay as "r1.576"
forever, but might suddenly become "1.401.3.55" when merged into another
repository.
Anyway, what I'm trying to say is that you're probably better off trying
to get used to the git numbering than trying to force the SVN model.
You're going to hit a few confusing issues if you really want to call
things "r1.x.y.z"
Linus
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 21:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060919211844.GB8259@pasky.or.cz>
On Tue, 19 Sep 2006, Petr Baudis wrote:
> Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter
> where Joel Dice <dicej@mailsnare.net> said that...
>> Implementation:
>>
>> A simple, efficient implementation of this feature would be based on a
>> single file, $GIT_DIR/history, which would contain a newline-delimited
>> list of SHA commit IDs in chronological order, oldest first. The current
>> repository IRN would be calculated as the size of that file divided by the
>> SHA+newline length, and the commit ID of any IRN could be determined by
>> seeking to the correct offset in that file. Every commit would cause a
>> new line to be appended to the history file with that commit's ID.
>> Finally, a history file could be generated for an existing repository by
>> serializing the commit history based on chronological order.
>
> We already have support for recording something similar, it's called a
> revlog. You would just need to modify it to aggregate all the branches
> in a single file.
Thanks - I'll look at that.
> Also, multiple IRNs could refer to a single real commit if you do e.g.
> cg-admin-uncommit, since revlog logs revision updates, not new revisions
> created. This may or may not be considered a good thing. If you rather
> want to just create a new IRN at commit object creation time, also note
> that some tools _might_ validly create commit objects and then throw
> them away, which would generate non-sensical (and after prune, invalid)
> IRNs.
I'm not too worried about cg-admin-uncommit or git-reset, since the IRN
feature is intended mainly for shared repositories. I would suggest that
such commands simply be disallowed for such repositories.
The problem of temporary commits certainly needs to be addressed. In this
case, may I assume nothing under $GIT_DIR/refs is ever modified? If so,
perhaps I could somehow hook into the git-update-ref step. Is that what
the revlog code does?
- Joel
^ permalink raw reply
* [RFC][PATCH] gitweb: Make the Git logo link target to point to the homepage
From: Petr Baudis @ 2006-09-19 21:27 UTC (permalink / raw)
To: git
It provides more useful information for causual Git users than the Git docs
(especially about where to get Git and such).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c77270c..7ecd7df 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1312,7 +1312,7 @@ EOF
print "</head>\n" .
"<body>\n" .
"<div class=\"page_header\">\n" .
- "<a href=\"http://www.kernel.org/pub/software/scm/git/docs/\" title=\"git documentation\">" .
+ "<a href=\"http://git.or.cz/\" title=\"Git homepage\">" .
"<img src=\"$logo\" width=\"72\" height=\"27\" alt=\"git\" style=\"float:right; border-width:0px;\"/>" .
"</a>\n";
print $cgi->a({-href => esc_param($home_link)}, $home_link_str) . " / ";
^ permalink raw reply related
* Re: [PATCH] Fix broken sha1 locking
From: Petr Baudis @ 2006-09-19 21:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0609191411460.4388@g5.osdl.org>
Dear diary, on Tue, Sep 19, 2006 at 11:16:04PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 19 Sep 2006, Petr Baudis wrote:
> >
> > Current git#next is totally broken wrt. cloning over HTTP, generating refs
> > at random directories. Of course it's caused by the static get_pathname()
> > buffer. lock_ref_sha1() stores return value of mkpath()'s get_pathname()
> > call, then calls lock_ref_sha1_basic() which calls git_path(ref) which
> > calls get_pathname() at that point returning pointer to the same buffer.
>
> Hmm. This was exactly the schenario why I did commit
> e7676d2f6454c9c99e600ee2ce3c7205a9fcfb5f - allowing a couple of
> overlapping paths
>
> Isn't that in the "next" branch too?
Yes, and between the mkpath() and git_path() calls exactly three other
get_pathname() calls happen.
Of course you could just enlarge the cache, but that will merely make
the bugs even harder to spot, let alone track down. I argue that having
this cache at all is harmful and will result in bugs over time as new
get_pathname() calls are added in the middle of currently safe
"concurrent" calls.
> Of course, that still assumes that you strdup() the result at _some_ time,
> and can't just save it away, but lock_ref_sha1_basic() should do that.
lock_ref_sha1_basic() never strdup()s ref (at least the reference used
for git_path() later).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Petr Baudis @ 2006-09-19 21:18 UTC (permalink / raw)
To: Joel Dice; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter
where Joel Dice <dicej@mailsnare.net> said that...
> Implementation:
>
> A simple, efficient implementation of this feature would be based on a
> single file, $GIT_DIR/history, which would contain a newline-delimited
> list of SHA commit IDs in chronological order, oldest first. The current
> repository IRN would be calculated as the size of that file divided by the
> SHA+newline length, and the commit ID of any IRN could be determined by
> seeking to the correct offset in that file. Every commit would cause a
> new line to be appended to the history file with that commit's ID.
> Finally, a history file could be generated for an existing repository by
> serializing the commit history based on chronological order.
We already have support for recording something similar, it's called a
revlog. You would just need to modify it to aggregate all the branches
in a single file.
Also, multiple IRNs could refer to a single real commit if you do e.g.
cg-admin-uncommit, since revlog logs revision updates, not new revisions
created. This may or may not be considered a good thing. If you rather
want to just create a new IRN at commit object creation time, also note
that some tools _might_ validly create commit objects and then throw
them away, which would generate non-sensical (and after prune, invalid)
IRNs.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Fix broken sha1 locking
From: Linus Torvalds @ 2006-09-19 21:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060919205823.18579.59604.stgit@machine.or.cz>
On Tue, 19 Sep 2006, Petr Baudis wrote:
>
> Current git#next is totally broken wrt. cloning over HTTP, generating refs
> at random directories. Of course it's caused by the static get_pathname()
> buffer. lock_ref_sha1() stores return value of mkpath()'s get_pathname()
> call, then calls lock_ref_sha1_basic() which calls git_path(ref) which
> calls get_pathname() at that point returning pointer to the same buffer.
Hmm. This was exactly the schenario why I did commit
e7676d2f6454c9c99e600ee2ce3c7205a9fcfb5f - allowing a couple of
overlapping paths
Isn't that in the "next" branch too?
Of course, that still assumes that you strdup() the result at _some_ time,
and can't just save it away, but lock_ref_sha1_basic() should do that.
Linus
^ permalink raw reply
* Re: Enable the packed refs file format
From: Linus Torvalds @ 2006-09-19 21:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20060919205554.GA8259@pasky.or.cz>
On Tue, 19 Sep 2006, Petr Baudis wrote:
> Dear diary, on Thu, Sep 14, 2006 at 07:14:47PM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> > + ref_file = git_path(ref);
>
> You slip...
> You fall...
> *BLAMMMM!!!*
Gaah. Yes. I fixed one such mistake already.
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.
Linus
^ permalink raw reply
* Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 21:07 UTC (permalink / raw)
To: git
Hello, all.
I'm considering adopting Git for a medium-sized project which is currently
managed using Subversion. I've used Git for a few smaller projects
already, and the thing I've missed most from Subversion is the convenience
of incrementing revision numbers. The following is a proposal to add this
feature to Git.
Rationale:
Incrementing revision numbers (IRNs - an acronym I just made up) are
useful in that they can be treated as auto-generated tags which are easier
to remember and communicate than SHA hashes, yet do not require extra
effort to create like real tags. Also, they have the advantage of being
chronologically ordered, so if I assert that a bug was fixed in revision
42 of a shared repository, everyone may assume that revision 45 has that
fix as well.
Proposal:
As with Subversion, the IRN state in Git would be specific to a given
repository and have no significance beyond that repository. Also like
Subversion, IRN state would be global across a repository, so that a
commit to any branch would increment the current IRN value. Every Git
command taking a revision parameter would accept an IRN using a syntax
such as "r$IRN". Every commit would report the IRN to the user as well as
the SHA ID. The IRN feature could be enabled or disabled via a
configuration option.
Implementation:
A simple, efficient implementation of this feature would be based on a
single file, $GIT_DIR/history, which would contain a newline-delimited
list of SHA commit IDs in chronological order, oldest first. The current
repository IRN would be calculated as the size of that file divided by the
SHA+newline length, and the commit ID of any IRN could be determined by
seeking to the correct offset in that file. Every commit would cause a
new line to be appended to the history file with that commit's ID.
Finally, a history file could be generated for an existing repository by
serializing the commit history based on chronological order.
I'd be happy to put together a patch that implements this, but first I'd
like to get some feedback. If something like this has already been
proposed, please point me to the discussion. Thanks.
- Joel
^ permalink raw reply
* [PATCH] Fix broken sha1 locking
From: Petr Baudis @ 2006-09-19 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Current git#next is totally broken wrt. cloning over HTTP, generating refs
at random directories. Of course it's caused by the static get_pathname()
buffer. lock_ref_sha1() stores return value of mkpath()'s get_pathname()
call, then calls lock_ref_sha1_basic() which calls git_path(ref) which
calls get_pathname() at that point returning pointer to the same buffer.
So now you are sprintf()ing a format string into itself, wow! The resulting
pathnames are really cute. (If you've been paying attention, yes, the
mere fact that a format string _could_ write over itself is very wrong
and probably exploitable here. See the other mail I've just sent.)
I've never liked how we use return values of those functions so liberally,
the "allow some random number of get_pathname() return values to work
concurrently" is absolutely horrible pit and we've already fallen in this
before IIRC. I consider it an awful coding practice, you add a call
somewhere and at some other point some distant caller of that breaks since
it reuses the same return values. Not to mention this takes quite some time
to debug.
My gut feeling tells me that there might be more of this. I don't have
time to review the rest of the users of the refs.c functions though.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
refs.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 134c0fc..7bd36e4 100644
--- a/refs.c
+++ b/refs.c
@@ -462,10 +462,12 @@ static struct ref_lock *lock_ref_sha1_ba
struct ref_lock *lock_ref_sha1(const char *ref,
const unsigned char *old_sha1, int mustexist)
{
+ char refpath[PATH_MAX];
if (check_ref_format(ref))
return NULL;
- return lock_ref_sha1_basic(mkpath("refs/%s", ref),
- 5 + strlen(ref), old_sha1, mustexist);
+ strcpy(refpath, mkpath("refs/%s", ref));
+ return lock_ref_sha1_basic(refpath, strlen(refpath),
+ old_sha1, mustexist);
}
struct ref_lock *lock_any_ref_for_update(const char *ref,
^ permalink raw reply related
* Re: Enable the packed refs file format
From: Petr Baudis @ 2006-09-19 20:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609141005440.4388@g5.osdl.org>
Dear diary, on Thu, Sep 14, 2006 at 07:14:47PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> + ref_file = git_path(ref);
You slip...
You fall...
*BLAMMMM!!!*
Cloning a repository with '%s' tag over HTTP now dumps core nicely, and
I guess this kind of bugs tends to be exploitable.
--
Petr "Pasky Yay for Obscure ADOM
References" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH (amend)] gitweb: Require project for almost all actions
From: Jakub Narebski @ 2006-09-19 19:53 UTC (permalink / raw)
To: git
Require that project (repository) is given for all actions except
project_list, project_index and opml.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 034cdf1..34311ee 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -341,6 +341,10 @@ if (defined $project) {
if (!defined($actions{$action})) {
die_error(undef, "Unknown action");
}
+if ($action !~ m/^(opml|project_list|project_index)$/ &&
+ !$project) {
+ die_error(undef, "Project needed");
+}
$actions{$action}->();
exit;
--
1.4.2.1
^ permalink raw reply related
* [PATCH] gitweb: Fix thinko in git_tags and git_heads
From: Jakub Narebski @ 2006-09-19 18:47 UTC (permalink / raw)
To: git
git_get_refs_list always return reference to list (and reference to
hash which we ignore), so $taglist (in git_tags) and $headlist (in
git_heads) are always defined, but @$taglist / @$headlist might be
empty. Replaced incorrect "if (defined @$taglist)" with
"if (@$taglist)" in git_tags and respectively in git_heads.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 34311ee..9445fa7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2565,7 +2565,7 @@ sub git_tags {
git_print_header_div('summary', $project);
my ($taglist) = git_get_refs_list("tags");
- if (defined @$taglist) {
+ if (@$taglist) {
git_tags_body($taglist);
}
git_footer_html();
@@ -2578,7 +2578,7 @@ sub git_heads {
git_print_header_div('summary', $project);
my ($headlist) = git_get_refs_list("heads");
- if (defined @$headlist) {
+ if (@$headlist) {
git_heads_body($headlist, $head);
}
git_footer_html();
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] Skip t3403 selftests if stdin is not a terminal
From: Gerrit Pape @ 2006-09-19 17:04 UTC (permalink / raw)
To: git
In-Reply-To: <7v3base3l5.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 15, 2006 at 11:19:02PM -0700, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Gerrit Pape <pape@smarden.org> writes:
> >> sh t3403-rebase-skip.sh </dev/null fails because stdin is not connected
> >> to a terminal, as in the Debian autobuild environment. This disbales
> >> the test 3 and 7 in this case.
> >
> > Disabling these tests somehow feels as if you are shooting the
> > messenger who reports breakage of the commands they try to test.
> >
> > Is it expected that the git Porcelainish commands involved in
> > these particular tests not to work without terminal? If not
> > maybe we should fix them, not the test.
>
> How about this instead?
Yes, this is the better fix, I agree. The selftests work fine for me
with this patch applied.
Thanks, Gerrit.
^ permalink raw reply
* Re: [PATCH] Build on Debian GNU/Hurd
From: Gerrit Pape @ 2006-09-19 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6yce5ky.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > Patch from Cyril Brulebois to make the build process detect and support the
> > Debian GNU/Hurd architecture, see
> > http://bugs.debian.org/379841
> >
> > Signed-off-by: Gerrit Pape <pape@smarden.org>
> >
> > +ifeq ($(uname_S),GNU)
> > + # GNU stands for GNU/Hurd
> > + NO_STRLCPY = YesPlease
> > + ALL_CFLAGS += -DPATH_MAX=4096
> > +endif
>
> Two questions come to mind. (1) Does GNU stand for GNU/Hurd and
> nobody else? (2) Does everybody else have PATH_MAX?
I'm not that familiar with the Hurd, but (1) seems to be so according
to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU
or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly
git$ grep -B7 -A3 PATH_MAX Makefile
ifeq ($(uname_S),IRIX64)
NO_IPV6=YesPlease
NO_SETENV=YesPlease
NO_STRCASESTR=YesPlease
NO_STRLCPY = YesPlease
NO_SOCKADDR_STORAGE=YesPlease
SHELL_PATH=/usr/gnu/bin/bash
ALL_CFLAGS += -DPATH_MAX=1024
# for now, build 32-bit version
ALL_LDFLAGS += -L/usr/lib32
endif
that's where I got it from.
> Adding NO_STRLCPY I do not have much problems with, but
> something like the attached may be cleaner to deal with PATH_MAX;
> of course now there is an issue of what the appropriate value
> for that symbol should be.
It's been so before it seems, I'm not sure why it changed.
http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot
expect PATH_MAX to be defined on a POSIX system, so defining it
conditionally IMHO is the right thing.
git$ PAGER=cat git log -p 579d1fb..8e76483
commit 8e76483ce0ce256b01345abc4ca97b1f94aed354
Author: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Date: Sun Jul 30 17:00:40 2006 +0100
Fix header breakage due to redefining PATH_MAX.
The header builtin.h was, incorrectly, redefining PATH_MAX which
causes a header order dependency in builtin-write-tree.c. The fix
is to simply include <limits.h> directly to obtain the correct
definition of PATH_MAX.
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff --git a/builtin.h b/builtin.h
index 1c8637a..88c4d84 100644
--- a/builtin.h
+++ b/builtin.h
@@ -2,10 +2,7 @@ #ifndef BUILTIN_H
#define BUILTIN_H
#include <stdio.h>
-
-#ifndef PATH_MAX
-# define PATH_MAX 4096
-#endif
+#include <limits.h>
extern const char git_version_string[];
HTH, Gerrit.
^ 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