* Re: [RFC] git-publish
From: Petr Baudis @ 2006-09-24 12:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Daniel Barkalow, git
In-Reply-To: <46a038f90608131653k1a2d0480x411be91bdc3f60ca@mail.gmail.com>
Dear diary, on Mon, Aug 14, 2006 at 01:53:07AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 8/14/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >Like how "pull" is "fetch" + "merge",
>
> Slightly OT... I thought git-publish host:/path/to/repo.git would be
> something to automate the initial "publishing" actions, which for me
> are:
>
> ssh host 'mkdir path/to/repo.git'
> ssh host 'GIT_DIR=path/to/repo.git git init-db'
> ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'
> git-push git+ssh://host:/path/to/repo.git
>
> Hmmmm. Would this be git publish-repo maybe?
Actually, this is a nice idea for cg-admin-setuprepo, thanks. :-) It now
accepts a git+ssh URL just as well as a local path. (It won't work with
git-shell, but that's a good thing.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Alex Riesen @ 2006-09-24 11:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060924110816.GK20017@pasky.or.cz>
Petr Baudis, Sun, Sep 24, 2006 13:08:16 +0200:
> > > > This patch removes Git.xs from the repository for the time being. This
> > > > should hopefully enable Git.pm to finally make its way to master.
> > >
> > > It's a bit sad, but I think this is a sane thing to do.
> > >
> > > I suspect Alex still has problem with Makefile.PL due to issues
> > > around ActiveState (slash vs bs and CRLF line ending if I recall
> > > correctly)?
> >
> > Absolutely.
>
> I'm sorry but I don't even have a Windows installation on my machine and
> I don't intend to personally work on Windows support. If you need to
> keep ActiveState working seamlessly, please post patches. I hate to say
> it, but that's just how it should work - if someone cares about Git
> working on a non-mainstream (for Git audience) platform, he needs to
> maintain it, not ask the "core" developers do it. ...
Ain't asking you nor anyone. Ain't actually care, activetstate's perl
being just another stupid windows program done badly. Can't promise,
but will try to post my workarounds to that particular combination
on list (never demanded to include them).
The original mail was more of a word of warning for anyone unhappy to
work with the sh%t.
Aside from that, any chance of making Git.xs optional (enabled by
default, but disableable)? Disabling Git.xs will disable related
scripts, sure, but also gives you an installation with one external
(libperl) dependency less (probably with ability to install git and
Git.xs separately).
^ permalink raw reply
* [PATCH] gitweb: Consolidate escaping/validation of query string
From: Petr Baudis @ 2006-09-24 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <ef4csl$7vk$1@sea.gmane.org>
Consider:
http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e
(click on the funny =__ify file)
We ought to handle anything in filenames and I actually see no reason why
we don't, modulo very little missing escaping that this patch hopefully
also fixes.
I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
buggy and [?=] just feels better escaped. ;-) YMMV.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 28 +++++++++-------------------
1 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2c6b197..f3c5bd8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -212,19 +212,9 @@ if (defined $project) {
}
}
+# We have to handle those containing any characters:
our $file_name = $cgi->param('f');
-if (defined $file_name) {
- if (!validate_input($file_name)) {
- die_error(undef, "Invalid file parameter");
- }
-}
-
our $file_parent = $cgi->param('fp');
-if (defined $file_parent) {
- if (!validate_input($file_parent)) {
- die_error(undef, "Invalid file parent parameter");
- }
-}
our $hash = $cgi->param('h');
if (defined $hash) {
@@ -305,7 +295,7 @@ sub evaluate_path_info {
$action ||= "blob_plain";
}
$hash_base ||= validate_input($refname);
- $file_name ||= validate_input($pathname);
+ $file_name ||= $pathname;
} elsif (defined $refname) {
# we got "project.git/branch"
$action ||= "shortlog";
@@ -416,7 +406,7 @@ # quote unsafe chars, but keep the slash
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
my $str = shift;
- $str =~ s/([^A-Za-z0-9\-_.~();\/;?:@&=])/sprintf("%%%02X", ord($1))/eg;
+ $str =~ s/([^A-Za-z0-9\-_.~()\/:@])/sprintf("%%%02X", ord($1))/eg;
$str =~ s/\+/%2B/g;
$str =~ s/ /\+/g;
return $str;
@@ -1289,7 +1279,7 @@ sub git_header_html {
if (defined $action) {
$title .= "/$action";
if (defined $file_name) {
- $title .= " - $file_name";
+ $title .= " - " . esc_html($file_name);
if ($action eq "tree" && $file_name !~ m|/$|) {
$title .= "/";
}
@@ -2439,7 +2429,7 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ open ($fd, "-|", git_cmd(), "blame", '-l', '--', $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -3135,7 +3125,7 @@ sub git_blobdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => qq(inline; filename="${file_name}.patch"));
+ -content_disposition => qq(inline; filename=") . quotemeta($file_name) . qq(.patch"));
print "X-Git-Url: " . $cgi->self_url() . "\n\n";
@@ -3155,8 +3145,8 @@ sub git_blobdiff {
} else {
while (my $line = <$fd>) {
- $line =~ s!a/($hash|$hash_parent)!a/$diffinfo{'from_file'}!g;
- $line =~ s!b/($hash|$hash_parent)!b/$diffinfo{'to_file'}!g;
+ $line =~ s!a/($hash|$hash_parent)!'a/'.esc_html($diffinfo{'from_file'})!eg;
+ $line =~ s!b/($hash|$hash_parent)!'b/'.esc_html($diffinfo{'to_file'})!eg;
print $line;
@@ -3585,7 +3575,7 @@ XML
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
next;
}
- my $file = validate_input(unquote($7));
+ my $file = esc_html(unquote($7));
$file = decode("utf8", $file, Encode::FB_DEFAULT);
print "$file<br/>\n";
}
^ permalink raw reply related
* Re: [PATCH] git-project-version
From: Santi @ 2006-09-24 11:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20060923235153.GH20017@pasky.or.cz>
2006/9/24, Petr Baudis <pasky@suse.cz>:
> Dear diary, on Fri, Aug 04, 2006 at 11:48:25PM CEST, I got a letter
> where Santi Béjar <sbejar@gmail.com> said that...
> > Introduce an easy way for projects to get its git version. This is
> > something that other projects using git would like to do, and we don't
> > want them all reinventing the wheel.
> >
> > Signed-off-by: Santi Béjar <sbejar@gmail.com>
>
> Perhaps it would be more useful to have a flag for git-describe to
> describe not the (HEAD) commit but your working copy (thus HEAD + check
> for the dirtyness).
>
Sure.
^ permalink raw reply
* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Petr Baudis @ 2006-09-24 11:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef4csl$7vk$1@sea.gmane.org>
Dear diary, on Sun, Sep 24, 2006 at 12:36:13AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
> > (click on the funny =__ify file)
>
> Aaargh? Why this name?
You tell me... ;-)
> > I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
> > buggy and [?=] just feels better escaped. ;-) YMMV.
..snip..
> I'd rather have new esc_param() or esc_param_value() quote like escape
> subroutine from CGI::Util, with the esception of _not_ escaping '/'
> (it makes funny bookmark, and lot less readable query string), and rename
> current esc_param() to esc_query_string() or esc_params().
Huh, well, what's the point with the rename and why not keep it as it is
with just removing the four characters above? Escaped stuff looks ugly
in a URL. ;-)
BTW, looking at CGI::Util innards, what sick mind serves CGIs from an
EBCDIC machine?
> Perhaps we should have also esc_arg() for things like title attribute
> of <a> (link) element (or other element)
Yes. I wanted to implement your few months old wish to have full string
of abbreviated column contents in title attributes but delayed it for
now because we have no such function yet.
> and filename="..." part of Content-disposition: HTTP header.
This is not HTML-ish so you need quotemeta() here, using entities makes
no sense in this case.
> By the way, the validate_input() should be split into separate subroutines:
> validate_ref() for validating hash, hash_base, hash_parent, hash_parent_base,
> and validate_path() for validating project,
Yes, that would be nice.
> file_name and file_parent parameters.
What's the point in validating those?
> We should _never_ use esc_html except during the output, or just before output.
> It certainly shouldn't take place in parse_* subroutine (or in the fake parse
> like in git_blobdiff)!
Yes, I agree. Will send a fixed patch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Petr Baudis @ 2006-09-24 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilpo Järvinen, git
In-Reply-To: <7virjem3tp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Sep 24, 2006 at 03:49:22AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Mon, Aug 07, 2006 at 12:30:13PM CEST, I got a letter
> > where Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> said that...
> >> Old algorithm:
> >> - printed IDs of identical patches with minus (-) sign; they
> >> should not be printed at all
> >> - did not print anything from the changes in the upstream
> >>
> >> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> >
> > Ping? Is this patch bogus or was it just forgotten?
>
> These are not fixes to "algorithmic flaws". It's more like that
> Ilpo is writing a different program to fill different needs, and
> I did not see what workflow wanted to have the list of changes
> that were in the upstream and our changes. Maybe what Ilpo
> wanted to see was something like "git log upstream...mine"
> (three-dots not two to mean symmetric difference). I dunno.
> That operation certainly did not exist when we did git-cherry
> originally.
>
> The original purpose of git-cherry (which probably is different
> from what Ilpo wanted to have, and that is why Ilpo modified it
> into a different program) is for a developer in the contributor
> role to see which ones of local patches have been accepted
> upstream and which ones still remain unapplied -- the intent is
> to help rebase only the latter and keep trying to convince
> upstream that these remaining ones are also worth applying.
>
> So minus (-) lines are very much needed to if you want to see
> which ones have been accepted. Plus lines are used to pick
> which ones to rebase by older version of git-rebase, but I do
> not think we do that anymore. And in any case we are _not_
> interested in whatever happened in the upstream that did not
> come from the branch we are looking at.
Hmm, well, what's curious is that the documentation says
Every commit with a changeset that doesn't exist in the other branch
has its id (sha1) reported, prefixed by a symbol. Those existing only
in the <upstream> branch are prefixed with a minus (-) sign, and those
that only exist in the <head> branch are prefixed with a plus (+)
symbol.
which is in contradiction of Ilpo's description of the old algorithm
(and also your description of it). It would seem he just wants to fix it
according to the documented behaviour.
I guess the documentation is what's broken then?
--
Petr "Pasky the Let's See How Long I Can
Manage Arguing Without Actually
Looking at the Code" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Petr Baudis @ 2006-09-24 11:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20060924105016.GA5732@steel.home>
Dear diary, on Sun, Sep 24, 2006 at 12:50:16PM CEST, I got a letter
where Alex Riesen <fork0@t-online.de> said that...
> Junio C Hamano, Sun, Sep 24, 2006 12:38:22 +0200:
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > This patch removes Git.xs from the repository for the time being. This
> > > should hopefully enable Git.pm to finally make its way to master.
> >
> > It's a bit sad, but I think this is a sane thing to do.
> >
> > I suspect Alex still has problem with Makefile.PL due to issues
> > around ActiveState (slash vs bs and CRLF line ending if I recall
> > correctly)?
> >
>
> Absolutely.
I'm sorry but I don't even have a Windows installation on my machine and
I don't intend to personally work on Windows support. If you need to
keep ActiveState working seamlessly, please post patches. I hate to say
it, but that's just how it should work - if someone cares about Git
working on a non-mainstream (for Git audience) platform, he needs to
maintain it, not ask the "core" developers do it. It's like if you
withheld random kernel features because they break m68k and noone is
around to fix it.
If someone cares, we'll get patches.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Petr Baudis @ 2006-09-24 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Sep 24, 2006 at 12:37:57PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - git-resolve is deprecated on "master" and will continue to be
> so until 1.4.3. We will remove it before 1.4.4 happens.
Woo-hoo!
> - We should deprecate git-tar-tree. However, it has been
> around and advertised for quite some time, so we need to make
> sure people would not get burned too badly. It might be
> worthwhile to rewrite git-tar-tree as a thin wrapper to
> "git-archive --format=tar" and remove git-upload-tar now (in
> other words, "git-tar-tree --remote" will continue to work,
> but it will talk with "git-upload-archive", not with
> "git-upload-tar" on the other end), release 1.4.3 with it
> with a deprecation warning, and then remove it in 1.4.5.
I believe this is way too rushed, please consider keeping git-tar-tree
as the thin wrapper _much_ longer.
We still have ssh-pull and ssh-push around after more than a year of
their deprecation. (BTW, we might as well consider removing those. ;)
> - packed-refs still has a few issues before it can hit
> "master".
>
> - deleting branches does not really work yet, as there have
> been some discussions on the list.
>
> - dumb transports are unaware of it. Trying to fetch a
> ref that is packed would not work.
This is a big problem.
> I feel this series to be a significant enough change that
> deserve a bit careful handling. Perhaps in 1.4.4 release.
I agree, there are some subtle changes there (like the heads ordering)
that could cause unforeseen problems, better be careful about it.
> - Git.pm lost Git.xs which hopefully would make it a bit easier
> to work for wider audiences. Hopefully we can push it out to
> "master" soon and see if anybody screams. Depending on what
> happens, it may be in 1.4.3 release.
Woo-hoo!
> - git-show-ref and git-for-each-ref serve similar purpose (when
> viewed in a bigger picture) but with different interface and
> different set of features. We should consolidate them into
> one command before they hit in any released version.
Do I understand it correctly that those are the only interfaces for
scripts to access packed refs?
Ideally there would be some transition period provided so that I can
teach Cogito about them without having it broken for repositories with
packed refs for some time. But since packing refs is optional and
explicit action, perhaps it's not so critical.
Still, I looked forward for having those tools in the next release so
that Cogito can use them. Oh well. :)
> Implementing "buffer-wide AND" will involve updating git-grep
> but as a side effect we will also be able to say "find files
> that have word A and B in them", which would be a useful
> thing. I'd push the current implementation out to "master"
> soon and release 1.4.3 with it, and defer implementation of
> the buffer-wide AND to a later version.
Yes. Those options are cool as they are and they can speed up gitweb's
search as well as cg-log -u.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Alex Riesen @ 2006-09-24 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwt7ta6sh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Sep 24, 2006 12:38:22 +0200:
> Petr Baudis <pasky@suse.cz> writes:
>
> > This patch removes Git.xs from the repository for the time being. This
> > should hopefully enable Git.pm to finally make its way to master.
>
> It's a bit sad, but I think this is a sane thing to do.
>
> I suspect Alex still has problem with Makefile.PL due to issues
> around ActiveState (slash vs bs and CRLF line ending if I recall
> correctly)?
>
Absolutely.
^ permalink raw reply
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Junio C Hamano @ 2006-09-24 10:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Alex Riesen
In-Reply-To: <20060923181849.28753.56984.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This patch removes Git.xs from the repository for the time being. This
> should hopefully enable Git.pm to finally make its way to master.
It's a bit sad, but I think this is a sane thing to do.
I suspect Alex still has problem with Makefile.PL due to issues
around ActiveState (slash vs bs and CRLF line ending if I recall
correctly)?
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-09-24 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vu035u4c3.fsf@assigned-by-dhcp.cox.net>
* The 'maint' branch has these fixes since the last announcement.
t3403-rebase-skip failed when run while its standard input is
connected to /dev/null. It turns out that an earlier safety
check to prevent git-am to be fed a new patch while there is
a leftover .dotest/ directory was incorrect. Fixed.
There was an unnecessary xmalloc() in builtin-add. Removed.
* The 'master' branch has these since the last announcement.
Recent change to http-fetch.c did not play well with older
curl releases. Fixed.
Clean-up of gitweb continues. Notably, generation the
summary page makes fewer call to git executable.
Receive-pack has an added safety check that lets the
repository owner to forbid non-fast-forward push into a
shared repository by setting receive.denyNonFastforwards
configuration variable.
Output from git-describe can now be used as an abbreviated
object name.
git-resolve is now officially deprecated. The next "master"
release (1.4.3) will ship with a version that gives an
annoying "deprecation warning" message, and the command will
be removed from the release after that.
There was a build problem in upload-archive on OpenBSD. Fixed.
git-zip-tree is now superseded by "git-archive --format=zip".
Miscellaneous clean-ups and documentation updates.
* The 'next' branch, in addition, has these.
A new command git-show-ref was added to list and verify local
references.
A new command git-for-each-ref was added to help Porcelains
to make smaller number of calls to git binary to obtain
summary information for refs.
cvsimport was updated to use git-for-each-ref.
Git.pm topic lost Git.xs for now.
The resolve_ref() internal API was straightened out to work
solely on refname (i.e. string that begins with "refs/"),
instead of pathnames. To deal with many refs efficiently,
there is now a "packed-ref" format where many refs are stored
in a single flat file instead of the traditional
one-ref-per-file format.
git-diff --color highlights trailing whitespaces and SP
followed by TAB in indentation as common whitespace errors.
git-daemon now has a virtual host support.
upload-pack stops the fetch-pack on the other side when
downloader has more roots than uploader; otherwise the
downloader would send "have" from a development line that
the uploader does not know about til its root.
git-log learned --author=, --committer= and --grep= options
to filter commits.
pack-objects now creates version 3 packs; this allows a copy
of larger block of data to be expressed.
Per branch configuration items branch."branchname".remote can
specify what remotes/ file instead of usual "origin" should
be used when no option is given to "git fetch" while on the
named branch. Similarly, branch."branchname".merge can
specify which remote branches to be merged while on the named
branch.
git-svnimport learned a new trick to parse log message for
Signed-off-by: lines and pick authorship information from
there. I haven't heard Ack nor Nack from any subversion
users, but we will hopefully hear somebody scream if it
breaks things after pushing it out to "master".
* The 'pu' branch, in addition, has these.
git-apply --whitespace learned to notice SP before TAB in
indent as a common whitespace error, in addition to the
trailing whitespaces it already knew about.
git-diff output is unfriendly to GNU patch when the filename
contained a SP. Appending a TAB after filename in this case
works the problem around. However, git-apply needs to learn
about it as well, so it did.
There is one new data type in the pack format that records
delta base object by offset in the stream instead of 20-byte
object name. This reduces the resulting packsize by 3 to 5%.
One additional test for git-branch is in, but the current
implementation of git-branch fails it.
^ permalink raw reply
* What will happen to git.git in the near future
From: Junio C Hamano @ 2006-09-24 10:37 UTC (permalink / raw)
To: git
Here are some random thoughts on the short-term plan. We are
currently at 1.4.2 release (and "maint" is at 1.4.2.1).
I do not know when the changes are big enough to start the 1.5
series, so tentatively I'll call the next one 1.4.3, the one
that follows 1.4.4, and so on, in the following description.
- git-resolve is deprecated on "master" and will continue to be
so until 1.4.3. We will remove it before 1.4.4 happens.
- We will deprecate the original merge-recursive written in
Python by renaming it to merge-recursive-old, and make
merge-recur to take its place. 1.4.3 will ship that way.
Sometime in not so distant future we will remove
merge-recursive-old and merge-recur, perhaps in 1.4.5.
- We should deprecate git-tar-tree. However, it has been
around and advertised for quite some time, so we need to make
sure people would not get burned too badly. It might be
worthwhile to rewrite git-tar-tree as a thin wrapper to
"git-archive --format=tar" and remove git-upload-tar now (in
other words, "git-tar-tree --remote" will continue to work,
but it will talk with "git-upload-archive", not with
"git-upload-tar" on the other end), release 1.4.3 with it
with a deprecation warning, and then remove it in 1.4.5.
- virtual hosting by git-daemon should be ready. I will push
it out to "master" before 1.4.3 release.
- packed-refs still has a few issues before it can hit
"master".
- deleting branches does not really work yet, as there have
been some discussions on the list.
- dumb transports are unaware of it. Trying to fetch a
ref that is packed would not work.
I feel this series to be a significant enough change that
deserve a bit careful handling. Perhaps in 1.4.4 release.
- The per-branch configuration to control git-fetch is Ok in
itself, and we might want to push it out to "master" and
release 1.4.3 with it in its current form. But the topic
might want to learn other tricks to have more comprehensive
per-branch configuration support. We will see how it plays
out.
- Git.pm lost Git.xs which hopefully would make it a bit easier
to work for wider audiences. Hopefully we can push it out to
"master" soon and see if anybody screams. Depending on what
happens, it may be in 1.4.3 release.
- git-show-ref and git-for-each-ref serve similar purpose (when
viewed in a bigger picture) but with different interface and
different set of features. We should consolidate them into
one command before they hit in any released version.
- git-log's support for --committer=, --author= and --grep= is
Ok by itself, but I feel we should do a bit more to make it
useful. Currently we cannot say "written by A and committed
by B", or "written by C and have word D in the log". Because
the boolean logic between match patterns we use internally
are line oriented, borrowing --and from git-grep is not
enough ("--committer=A --and --author=B" would mean 'if the
commit object has a header line that matches "^committer .*A"
and "^author .*B" at the same time', which is not what we
want). We would need a "buffer-wide AND" that can express
'see if there is a header line that matches "^committer .*A"
and a header line, which may be different from the
"committer" one, that matches "^author .*B"'.
Implementing "buffer-wide AND" will involve updating git-grep
but as a side effect we will also be able to say "find files
that have word A and B in them", which would be a useful
thing. I'd push the current implementation out to "master"
soon and release 1.4.3 with it, and defer implementation of
the buffer-wide AND to a later version.
- generation of version 3 pack files is 1.4.3 material.
- new pack object format to express delta base object by the
offset in the stream will start cooking in "next" soon; I
just haven't got around to merge it yet. I feel this to be
significant enough change that can deserve a bit careful
handling. Perhaps in 1.4.4 or 1.4.5 release.
- windowed mmap() of pack data is an important change (I do not
mean to pressure Shawn by saying this) and needs to be cooked
carefully. I do not expect it to be ready until 1.4.5
release at the earliest.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Junio C Hamano @ 2006-09-24 10:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef5jkv$gep$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Don't forget about final s,\n,<br/>\n,gm if we parse it as a whole,
> and not line by line.
Yes, the driver and individual tag markers need to have a
convention on who is responsible for doing <br />.
One reasonable convention would be to make the driver side
responsible for taking \n and turns it into <br /> in plain
strings, and make the tag markers responsible for doing so in
their marked-up output.
For example, when bugzilla_tagger is annotating this commit
message:
This rewrites frotz() routine to work around Bug
#22574. The fix was confirmed by Xyzzy.
Thanks for everybody who helped with this rewrite.
it would match with a regexp /\b(?i:bug)\s*#?(\d+)/s
to pick up "Bug\n#22574", extract 22574, and produce:
('This rewrites frotz() routine to work around ',
\'<a href="/cgi-bin/bugzilla.cgi?id=22574">Bug<br/>#22574</a>',
'. The fix was confirmed by Xyzzy.\n\nThanks for everybody...')
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-24 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <7v4puys3ye.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> The idea of doing committag parsing, and preserving replacements
>> from matching committag and being subject to HTML escaping by using
>> reference to string has it's merits.
>>
>> I'd have to think about it.
>
> Good. My obviously buggy illustration would be easier to read
> with this patch ;-).
Don't forget about final s,\n,<br/>\n,gm if we parse it as a whole,
and not line by line.
By the way, I think that only the driver (i.e. format_log_line_html) has to
be changed...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: The GPL: No shelter for the Linux kernel?
From: Jan Engelhardt @ 2006-09-24 7:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, David Schwartz, linux-kernel, git
In-Reply-To: <20060923181406.GC11916@pasky.or.cz>
>> Side note: in "git", we kind of discussed this. And because the project
>> was started when the whole GPL version discussion was already in bloom,
>> the git project has a note at top of the COPYING file that says:
>>
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> HOWEVER, in order to allow a migration to GPLv3 if that seems like
>> a good idea, I also ask that people involved with the project make
>> their preferences known. In particular, if you trust me to make that
>> decision, you might note so in your copyright message, ie something
>> like
>>
>> This file is licensed under the GPL v2, or a later version
>> at the discretion of Linus.
>>
>
> Actually, this didn't catch on very well anyway, I guess because most
>people just know it's GPLv2 and don't even bother to peek at COPYING, we
>are a bit sloppy about copyright notices and most of them don't mention
>licence at all (if there are any in the file at all), and adding
>explicit copyright notices to mails isn't too popular either.
Would every file that does not contain an explicit license (this
excludes MODULE_LICENSE) falls under COPYING?
> $ git grep 'discretion'
> COPYING: at the discretion of Linus.
> git-annotate.perl:# at the discretion of Linus Torvalds.
> git-relink.perl:# Later versions of the GPL at the discretion of Linus Torvalds
> git-request-pull.sh:# at the discretion of Linus Torvalds.
>
>and I've found no patches with such special assignment.
Jan Engelhardt
--
^ permalink raw reply
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Christian Couder @ 2006-09-24 4:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veju2nthl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > You are right, so what about moving ".git/refs/heads/frotz"
> > to ".git/deleted-refs/heads/frotz.ref"
> > or ".git/deleted-refs/heads/frotz~ref" (because "~" is forbidden in ref
> > names).
>
> But wouldn't it bring up the issue of locking among deleters,
> updaters/creators, and traversers?
Yes, it will get worse.
> If we choose to use packed-refs.lock as the "set of all refs"
> lock, the whole sequence would become something like this. Note
> that this tries to make readers lockless but I am sure there are
> nasty race condition issues. I am not sure what we would want
> to do about them.
>
> = Looking up a ref $frotz.
We could acquire .git/$frotz.lock here if we want to be sure that nothing
will happen to it while we read it, but anyway something could happen to it
just after we read it and before we use it. So the right thing to do is
perhaps to let the caller acquire the lock if it needs to. We should just
check in the other cases below that nothing can happen to the ref if
someone acquired .git/$frotz.lock.
> - check if .git/$frotz exists, and use it if it does.
>
> - check if .git/deleted-refs/$frotz~ref exists, and return "no
> such ref" if it does.
>
> - find $frotz in .git/packed-refs.
>
> = Looping over refs.
Same as above. Depending on what the caller wants to do, it could
acquire .git/packed-refs.lock or some .git/$frotz.lock to make sure nothing
happens to all or only some refs.
> - grab all .git/refs/ and subtract all .git/deleted-refs/
>
> - walk .git/packed-refs and the result from the above in
> parallel as in the current code.
>
> = Storing a new value in ref $frotz.
>
> - acquire .git/packed-refs.lock
>
> - lock .git/$frotz.lock.
>
> - write into .git/$frotz.lock.
>
> - create or update .git/logs/$frotz as needed.
>
> - if .git/deleted-refs/$frotz~ref exists, unlink it.
>
> - rename .git/$frotz.lock to .git/$frotz to unlock it.
>
> - unlink .git/packed-refs.lock
>
> = Deleting a ref $frotz.
>
> - acquire .git/packed-refs.lock
- acquire .git/$frotz.lock seems needed too
> - look up $frotz; if it does not exist either barf or return
> silent (haven't thought it through yet).
>
> - create .git/deleted-refs/$frotz~ref
or move .git/$frotz to .git/deleted-refs/$frotz~ref if .git/$frotz exists
> - remove .git/logs/$frotz
- unlink .git/$frotz.lock
> - unlink .git/packed-refs.lock
>
> = Packing refs, with optional pruning.
>
> - lock .git/packed-refs.lock
>
> - loop over refs:
> - write it out to .git/packed-refs.lock unless a symref.
> - if it is a loose one (not a symref), remember it for pruning.
>
> - if pruning:
> - remove the entire .git/deleted-refs/ hierarchy
> - remove the remembered ones
Perhaps we should acquire .git/$frotz.lock for each $frotz that we remove
when pruning.
> - rename .git/packed-refs.lock to .git/packed-refs
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/6] many cleanups to sha1_file.c
From: Nicolas Pitre @ 2006-09-24 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7izvug3b.fsf@assigned-by-dhcp.cox.net>
On Sat, 23 Sep 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Those cleanups are mainly to set the table for the support of deltas
> > with base objects referenced by offsets instead of sha1. This means
> > that many pack lookup functions are converted to take a pack/offset
> > tuple instead of a sha1.
>
> There still remains some "struct pack_entry" and I wonder if it
> would make sense to get rid of them if only for consistency's
> sake.
Maybe. But since those are the minimum needed for base offset support
I'd prefer if the extra cleanup is made separate not to mix too many
issues at once.
> > diff --git a/sha1_file.c b/sha1_file.c
> > index b89edb9..6fae766 100644
> > --- a/sha1_file.c
> > +++ b/sha1_file.c
> > @@ -926,8 +925,8 @@ static int packed_delta_info(unsigned ch
> >
> > memset(&stream, 0, sizeof(stream));
> >
> > - data = stream.next_in = base_sha1 + 20;
> > - stream.avail_in = left - 20;
> > + data = stream.next_in = (unsigned char *) p->pack_base + offset;;
> > + stream.avail_in = p->pack_size - offset;
> > stream.next_out = delta_head;
> > stream.avail_out = sizeof(delta_head);
> >
>
> ";;"?
Typo.
> > @@ -989,75 +988,60 @@ int check_reuse_pack_delta(struct packed
> > ...
> > +static int packed_object_info(struct packed_git *p, unsigned long offset,
> > char *type, unsigned long *sizep)
> > {
> > + unsigned long size;
> > enum object_type kind;
> >
> > - if (use_packed_git(p))
> > - die("cannot map packed file");
> > + offset = unpack_object_header(p, offset, &kind, &size);
> >
>
> Do all callers of packed_object_info() call use_packed_git to
> make sure p is mapped?
Easy since the function is static.
> Ah sha1_object_info() is the only one
> except packed_delta_info() that calls itself and it protects it
> with use_packed_git(), so you are safe.
Right. The only entry point to those functions is sha1_object_info()
where I moved the use/unuse and all the other call instances are due to
recursion. > It seemed to me a bit wasteful to call use() so many times
to unuse() the same amount afterwards while only once is needed.
> We would need to revamp use/unuse code when we implement the
> partial mapping anyway, but we still need to get this right for
> now.
Probably moving them near the actual pack content access.
May I assume you'll take care of the extra ; typo?
Nicolas
^ permalink raw reply
* Re: [PATCH 1/2] use SHA_DIGEST_LENGTH
From: David Rientjes @ 2006-09-24 3:33 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64N.0609232011050.14284@attu4.cs.washington.edu>
On Sat, 23 Sep 2006, David Rientjes wrote:
> @@ -202,16 +202,17 @@ int cmd_name_rev(int argc, const char **
> #define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
> if (!ishex(*p))
> forty = 0;
> - else if (++forty == 40 &&
> + else if (++forty == 2 * SHA_DIGEST_LENGTH &&
> !ishex(*(p+1))) {
> - unsigned char sha1[40];
> + unsigned char sha1[2 * SHA_DIGEST_LENGTH];
> const char *name = "undefined";
> char c = *(p+1);
>
> forty = 0;
>
> *(p+1) = 0;
> - if (!get_sha1(p - 39, sha1)) {
> + if (!get_sha1(p - (SHA_DIGEST_LENGTH + 1),
> + sha1)) {
> struct object *o =
> lookup_object(sha1);
> if (o)
Off by 18 error.
Signed-off-by: David Rientjes <rientjes@cs.washington.edu>
---
builtin-name-rev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index f522664..ed99679 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -211,7 +211,7 @@ #define ishex(x) (isdigit((x)) || ((x) >
forty = 0;
*(p+1) = 0;
- if (!get_sha1(p - (SHA_DIGEST_LENGTH + 1),
+ if (!get_sha1(p - 2 * SHA_DIGEST_LENGTH + 1,
sha1)) {
struct object *o =
lookup_object(sha1);
^ permalink raw reply related
* Re: [PATCH 4/4 (take 4)] Add test for the default merges in fetch.
From: Junio C Hamano @ 2006-09-24 1:49 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87sliie20o.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> + cd .. &&
> + git clone . three &&
> + cd three &&
> + git repo-config branch.master.remote two
> + git repo-config branch.master.merge refs/heads/one
> + {
> + echo "URL: ../two/.git/"
> + echo "Pull: refs/heads/master:refs/heads/two"
> + echo "Pull: refs/heads/one:refs/heads/one"
> + } >.git/remotes/two
> '
Please string them with && unless there is a compelling reason
not to.
That would catch a potential error exit from repo-config,
although it is not a focus of this test. We have caught
breakage of parts of the system by tests meant for unrelated
parts of the system number of times.
> +test_expect_success "fetch test for-merge" '
> + cd "$D" &&
> + cd three &&
> + git fetch &&
> + test -f .git/refs/heads/two &&
> + test -f .git/refs/heads/one &&
> + {
> + echo -e "not-for-merge branch \047master\047 of ../two/"
> + echo -e " branch \047one\047 of ../two/"
> + } > expected &&
> + cut -f 2- .git/FETCH_HEAD > actual &&
> + diff expected actual'
Testing for the explicit implementation detail (namely, the
human readable part of the merge log message per branch) makes
me feel uneasy. Also I've stayed away from "echo -e" for some
inexplicable fear of portability issues and I do not see a
reason to use it here. Time to learn to use '\'' perhaps?
I would have:
- arranged branch tips of all the repos that are potentially
involved to have different object names;
- checked for the commit object names at the beginning of the
resulting FETCH_HEAD and not-for-merge markers;
- ignored the "branch 'foo' of repo" log message pieces;.
In other words, this on top of yours, which I am going to
commit.
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 2d8da59..df0ae48 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -30,8 +30,8 @@ test_expect_success "clone and setup chi
cd .. &&
git clone . three &&
cd three &&
- git repo-config branch.master.remote two
- git repo-config branch.master.merge refs/heads/one
+ git repo-config branch.master.remote two &&
+ git repo-config branch.master.merge refs/heads/one &&
{
echo "URL: ../two/.git/"
echo "Pull: refs/heads/master:refs/heads/two"
@@ -57,11 +57,13 @@ test_expect_success "fetch test for-merg
git fetch &&
test -f .git/refs/heads/two &&
test -f .git/refs/heads/one &&
+ master_in_two=`cd ../two && git rev-parse master` &&
+ one_in_two=`cd ../two && git rev-parse one` &&
{
- echo -e "not-for-merge branch \047master\047 of ../two/"
- echo -e " branch \047one\047 of ../two/"
- } > expected &&
- cut -f 2- .git/FETCH_HEAD > actual &&
+ echo "$master_in_two not-for-merge"
+ echo "$one_in_two "
+ } >expected &&
+ cut -f -2 .git/FETCH_HEAD >actual &&
diff expected actual'
test_done
^ permalink raw reply related
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Junio C Hamano @ 2006-09-24 1:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, Ilpo Järvinen, git
In-Reply-To: <20060924000051.GI20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Aug 07, 2006 at 12:30:13PM CEST, I got a letter
> where Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> said that...
>> Old algorithm:
>> - printed IDs of identical patches with minus (-) sign; they
>> should not be printed at all
>> - did not print anything from the changes in the upstream
>>
>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> Ping? Is this patch bogus or was it just forgotten?
These are not fixes to "algorithmic flaws". It's more like that
Ilpo is writing a different program to fill different needs, and
I did not see what workflow wanted to have the list of changes
that were in the upstream and our changes. Maybe what Ilpo
wanted to see was something like "git log upstream...mine"
(three-dots not two to mean symmetric difference). I dunno.
That operation certainly did not exist when we did git-cherry
originally.
The original purpose of git-cherry (which probably is different
from what Ilpo wanted to have, and that is why Ilpo modified it
into a different program) is for a developer in the contributor
role to see which ones of local patches have been accepted
upstream and which ones still remain unapplied -- the intent is
to help rebase only the latter and keep trying to convince
upstream that these remaining ones are also worth applying.
So minus (-) lines are very much needed to if you want to see
which ones have been accepted. Plus lines are used to pick
which ones to rebase by older version of git-rebase, but I do
not think we do that anymore. And in any case we are _not_
interested in whatever happened in the upstream that did not
come from the branch we are looking at.
I suspect we do not use it anywhere anymore. Maybe we can
remove it?
... goes and looks ...
git grep -e git.cherry --and --not -e git.cherry-pick
Nah, no such luck. One of the documentation suggests that you
drive cvsexportcommit using its output, like this:
git cherry cvs mine | sed -n -e 's/^\+ //p' |
xargs -L 1 git-cvsexportcommit -c -p -v
and I can see why cherry is (perhaps slightly) more desirable
than "git rev-list cvs..mine"
So unless we come up with an alternative way to do this, we
cannot change it or drop it. Not yet.
^ permalink raw reply
* builtin-upload-archive.c broken on openbsd
From: Randal L. Schwartz @ 2006-09-24 0:20 UTC (permalink / raw)
To: git
Looks like ctype again. Gotta be careful with that on BSD releases:
$ gmake prefix=/opt/git all
GIT_VERSION = 1.4.2.GIT
gcc -o builtin-upload-archive.o -c -g -O2 -Wall -I/usr/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR builtin-upload-archive.c
In file included from /usr/include/sys/poll.h:54,
from builtin-upload-archive.c:11:
/usr/include/ctype.h:68: error: syntax error before ']' token
/usr/include/ctype.h:69: error: syntax error before ']' token
/usr/include/ctype.h:71: error: syntax error before ']' token
/usr/include/ctype.h:76: error: syntax error before ']' token
/usr/include/ctype.h:79: error: syntax error before '(' token
/usr/include/ctype.h:80: error: syntax error before '(' token
/usr/include/ctype.h:98: error: syntax error before "c"
In file included from /usr/include/sys/poll.h:54,
from builtin-upload-archive.c:11:
/usr/include/ctype.h:96:1: unterminated #if
/usr/include/ctype.h:40:1: unterminated #ifndef
In file included from builtin-upload-archive.c:11:
/usr/include/sys/poll.h:53:1: unterminated #ifndef
/usr/include/sys/poll.h:28:1: unterminated #ifndef
gmake: *** [builtin-upload-archive.o] Error 1
This fixes it:
>From 5a7951c5294fc05e2754a1b6f503e36cd7b2a2f0 Mon Sep 17 00:00:00 2001
From: Charlie <root@blue.stonehenge.com>
Date: Sat, 23 Sep 2006 17:19:53 -0700
Subject: [PATCH] local patch for openbsd
---
builtin-upload-archive.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index 0596865..45c92e1 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -2,13 +2,13 @@
* Copyright (c) 2006 Franck Bui-Huu
*/
#include <time.h>
+#include <sys/wait.h>
+#include <sys/poll.h>
#include "cache.h"
#include "builtin.h"
#include "archive.h"
#include "pkt-line.h"
#include "sideband.h"
-#include <sys/wait.h>
-#include <sys/poll.h>
static const char upload_archive_usage[] =
"git-upload-archive <repo>";
--
1.4.2.1.g3d5c-dirty
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Petr Baudis @ 2006-09-24 0:00 UTC (permalink / raw)
To: junkio; +Cc: Ilpo Järvinen, git
In-Reply-To: <Pine.LNX.4.58.0608071328200.22971@kivilampi-30.cs.helsinki.fi>
Dear diary, on Mon, Aug 07, 2006 at 12:30:13PM CEST, I got a letter
where Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> said that...
> Old algorithm:
> - printed IDs of identical patches with minus (-) sign; they
> should not be printed at all
> - did not print anything from the changes in the upstream
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Ping? Is this patch bogus or was it just forgotten?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] git-project-version
From: Petr Baudis @ 2006-09-23 23:51 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <87bqr0tbo6.fsf@gmail.com>
Dear diary, on Fri, Aug 04, 2006 at 11:48:25PM CEST, I got a letter
where Santi Béjar <sbejar@gmail.com> said that...
> Introduce an easy way for projects to get its git version. This is
> something that other projects using git would like to do, and we don't
> want them all reinventing the wheel.
>
> Signed-off-by: Santi Béjar <sbejar@gmail.com>
Perhaps it would be more useful to have a flag for git-describe to
describe not the (HEAD) commit but your working copy (thus HEAD + check
for the dirtyness).
--
Petr "Pasky the Hater of Too Many
Commands" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Petr Baudis @ 2006-09-23 23:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Shawn Pearce, git
In-Reply-To: <tnxirln5mqy.fsf@arm.com>
Mailcromancy for fun'n'profit.
Dear diary, on Mon, Jul 24, 2006 at 12:19:01PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> said that...
> The StGIT feature wish-list after the OLS is:
>
> - patch history (I'll probably use reflogs as you suggested)
> - configurable pull command (currently uses git-pull only)
> - commit directly to a patch which is not top
> - patch synchronisation between between branches (as some people,
> including me have the same patches based on different branches and
> they have scripts for moving the changes in one to the others)
> - document the workflow on the StGIT wiki
> - maybe a separate undo command rather than passing a --undo option to
> push and refresh
After talking with some more random and less random people, another
_big_ wishlist item is having something like a series file (not
necessarily used for storing stuff but just as a user interface), so
that you can easily _reorder_ your patches - that's an onerous task with
StGIT currently, involving a lot of involved popping and pushing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Jakub Narebski @ 2006-09-23 22:41 UTC (permalink / raw)
To: git
In-Reply-To: <ef4csl$7vk$1@sea.gmane.org>
Jakub Narebski wrote:
> I'd rather have new esc_param() or esc_param_value() quote like escape
> subroutine from CGI::Util, with the esception of _not_ escaping '/'
> (it makes funny bookmark, and lot less readable query string), and rename
> current esc_param() to esc_query_string() or esc_params().
Or just esc_url()
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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