* Re: [PATCH] bash completion: Add more long options for 'git log'
From: Shawn O. Pearce @ 2008-08-02 21:00 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217638613-57366-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> Options added: --parents --children --full-history
>
> Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 30d8701..7132a68 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -853,6 +853,7 @@ _git_log ()
> --stat --numstat --shortstat
> --decorate --diff-filter=
> --color-words --walk-reflogs
> + --parents --children --full-history
> "
> return
> ;;
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Daniel Stenberg @ 2008-08-02 21:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20080802205702.GA24723@spearce.org>
On Sat, 2 Aug 2008, Shawn O. Pearce wrote:
> Well, over git:// (or any protocol that wraps git:// like ssh) we assume a
> full-duplex channel. Some proxy systems are able to do such a channel.
> HTTP however does not offer it.
Yes it does. The CONNECT method is used to get a full-duplex channel to a
remote site through a HTTP proxy. The downside with that is of course that
most proxies are setup to disallow CONNECT to other ports than 443 (the https
default port).
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH] bash completion: Add completion for 'git grep'
From: Shawn O. Pearce @ 2008-08-02 21:05 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217638593-57321-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> +_git_grep ()
> +{
> + __git_has_doubledash && return
> +
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "
> + --cached
> + --text --ignore-case --word-regexp --invert-match
> + --full-name
> + --extended-regexp --basic-regexp --fixed-strings
> + --files-with-matches --name-only
> + --files-without-match
> + --count
> + --and --or --not --all-match
> + "
> + return
> + ;;
> + esac
> + COMPREPLY=()
> +}
Hmm. The has_doubledash test seems redundant since we don't do
anything with args that aren't --foo. Even though git-grep will
accept a tree-ish and thus completion of __git_refs here may
make sense.
I wonder if we shouldn't just add to the end something like:
__gitcomp "$(__git_refs)"
like the _git_reset function does. Then we can complete a tree-ish
for searching, as well as honor -- to stop tree-ish completion and
go back to file/directory completion.
But that is very much a user question. Do users mostly search a
file in the current working directory, or do they mostly search
a tree-ish?
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-02 21:08 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Git Mailing List
In-Reply-To: <alpine.LRH.1.10.0808022257470.25900@yvahk3.pbagnpgbe.fr>
Daniel Stenberg <daniel@haxx.se> wrote:
> On Sat, 2 Aug 2008, Shawn O. Pearce wrote:
>
>> Well, over git:// (or any protocol that wraps git:// like ssh) we
>> assume a full-duplex channel. Some proxy systems are able to do such a
>> channel. HTTP however does not offer it.
>
> Yes it does. The CONNECT method is used to get a full-duplex channel to a
> remote site through a HTTP proxy. The downside with that is of course
> that most proxies are setup to disallow CONNECT to other ports than 443
> (the https default port).
Ah, yes. CONNECT. Very few servers wind up supporting it I think.
I know one very big company who cannot use or support Git because
Git over HTTP is too slow to be useful. They support other tools
like Subversion instead. :-|
Really we just need smart protocol support in half-duplex RPC like
hpa was going after. Then it doesn't matter what we serialize it
into, almost any RPC system will be useful. Of course the only
one that probably matters in practice is HTTP.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Update German translation
From: Shawn O. Pearce @ 2008-08-02 21:10 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <200808020956.20070.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> The subject says it all. Thanks for the new features.
Thanks for taking care of this. I was just about to post something
to ask translators for assitance before the 1.6 release goes final.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-02 21:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Petr Baudis, git
In-Reply-To: <1217701021.8296.35.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> On za, 2008-08-02 at 10:36 -0700, Junio C Hamano wrote:
>
>> > You forgot to document your option. (And possibly write a testcase.)
>>
>> I am not sure if this is generic enough to be in git-svn.perl itself, or
>> perhaps there should be a hook make_log_entry() would call in the form of
>> some Perl scriptlet given by the user to munge $log_entry{log}, which
>> would be very specific to each project.
>
> If you're not sure, please make up your mind.
That's something you would say when I cannot decide the color of
bikeshed. I do not think your change falls into that category.
We could add an ad-hoc preprocessing option like this, and keep adding
more for different patterns, and at certain point we may be fed up with
millions of such options and try to introduce a more generic mechanism.
While doing so, the resulting code needs to support the ad-hoc ones that
are added earlier, forever.
We've done that in the past with other commands (cc-suppression scheme in
send-email comes to mind). It was very unpleasant.
> ... Doing this in a single
> regexp is a bit tricky and asking a user to write a perl snippet is even
> worse, imho.
What you are saying is that a built-in one, no matter what, won't be
sufficient for many projects. Unless a user writes Perl snippet to match
his project's needs, the noise at the beginning of the log won't be
stripped for him.
That's fine. I do not expect a single built-in transformation would fit
everybody's needs. I am not asking for miracles.
But you could at least keep the door open for people who are _willing_ to
write such transformation for their projects, right?
For one thing, your --cut-changelog-bits has one fixed pattern. Later
people either have to come up with different option, or modify your
pattern (potentially breaking your project). Neither is good.
Perhaps doing something like this a (admittedly slightly) better option?
It allows you to choose from a canned set, or give a series of s///
rewriting rules (or whatever you would want to have in the custom function)..
---
git-svn.perl | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..eaf6a56 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format);
+ $_git_format, $_clean_changelog, $_clean_log_message);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -109,9 +109,11 @@ my %cmd = (
fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision,
'fetch-all|all' => \$_fetch_all,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts } ],
clone => [ \&cmd_clone, "Initialize and fetch revisions",
{ 'revision|r=s' => \$_revision,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts, %init_opts } ],
init => [ \&cmd_init, "Initialize a repo for tracking" .
" (requires URL argument)",
@@ -238,6 +240,33 @@ my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
$Git::SVN::default_repo_id = $_[1] });
exit 1 if (!$rv && $cmd && $cmd ne 'log');
+my %canned_changelog_cleaner =
+(
+ 'ooo' => sub {
+ local ($_) = @_;
+ s/(^|\n)\s*((\n|\s)*(199[0-9]|20[0-1][0-9])(-[0-9]{2}){2}\s+.*<.*>\s*\n\s+)?/$1/g;
+ s/(^|\n)\* /\n$1/g;
+ s/^[\n\s]*//;
+ s/\n\s*/ /g if length ($_) < 81;
+ "\n";
+ }
+);
+
+if (defined $_clean_changelog) {
+ if (exists $canned_changelog_cleaner{$_clean_changelog}) {
+ $_clean_log_message = $canned_changelog_cleaner{$_clean_changelog};
+ } elsif ($_clean_changelog ne '') {
+ $_clean_log_message = eval "
+ sub { local(\$_) = \@_; $_clean_changelog; return \$_; }
+ ";
+ if ($@) {
+ die "$!: $_clean_changelog";
+ }
+ } else {
+ die "$_clean_changelog: unknown way to clean log message";
+ }
+}
+
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
@@ -2463,6 +2492,9 @@ sub make_log_entry {
close $un or croak $!;
$log_entry{date} = parse_svn_date($log_entry{date});
+ if ($_clean_log_message) {
+ $log_entry{log} = $_clean_log_message->($log_entry{log});
+ }
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
^ permalink raw reply related
* git-gui translators - please update translations if necessary
From: Shawn O. Pearce @ 2008-08-02 21:17 UTC (permalink / raw)
To: git
We're getting ready for the git 1.6 release in the not-too-distant
future, and that will ship with gitgui-0.11.
The current tip of my master branch builds as follows. There have
not been many changes in the interface so I don't think there is
much (if any) translation work for this release.
MSGFMT po/de.msg 402 translated.
MSGFMT po/fr.msg 391 translated.
MSGFMT po/hu.msg 391 translated.
MSGFMT po/it.msg 390 translated, 1 untranslated.
MSGFMT po/ja.msg 391 translated.
MSGFMT po/ru.msg 387 translated, 4 untranslated.
MSGFMT po/sv.msg 391 translated.
MSGFMT po/zh_cn.msg 367 translated, 7 fuzzy, 17 untranslated.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Petr Baudis @ 2008-08-02 21:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Stenberg, Git Mailing List
In-Reply-To: <20080802210828.GE24723@spearce.org>
On Sat, Aug 02, 2008 at 02:08:28PM -0700, Shawn O. Pearce wrote:
> I know one very big company who cannot use or support Git because
> Git over HTTP is too slow to be useful. They support other tools
> like Subversion instead. :-|
On what projects? I'm currently using Git over HTTP (read-only) a lot
and it doesn't seem really all that impractical to me. Maybe just using
a more dumb-friendly packing scheme could help a lot?
Petr "Pasky" Baudis
^ permalink raw reply
* gitweb status for 1.6.0?
From: Junio C Hamano @ 2008-08-02 21:28 UTC (permalink / raw)
To: Jakub Narebski, Petr Baudis; +Cc: git, Shawn O. Pearce
In-Reply-To: <20080802211714.GG24723@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We're getting ready for the git 1.6 release in the not-too-distant
> future, and that will ship with gitgui-0.11.
Thanks.
There have been a handful gitweb patches on the list recently (I think
they were all post -rc0 feature enhancements, but I may be mistaken). I'm
wondering what their status are. Does any of them matter in the current
cycle?
By the way, I've privately pinged Paul for gitk status.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-02 21:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Stenberg, Git Mailing List
In-Reply-To: <20080802212357.GU32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Aug 02, 2008 at 02:08:28PM -0700, Shawn O. Pearce wrote:
> > I know one very big company who cannot use or support Git because
> > Git over HTTP is too slow to be useful. They support other tools
> > like Subversion instead. :-|
>
> On what projects? I'm currently using Git over HTTP (read-only) a lot
> and it doesn't seem really all that impractical to me. Maybe just using
> a more dumb-friendly packing scheme could help a lot?
They tested by taking the SVN source code and importing it into
both Git and Hg, then cloned them both over a WAN link. Git was
22x slower. I suspect they didn't pack the Git repository at all,
so Git had to issue thousands of HTTP GET requests for the loose
objects. But I also suspect there was bias in the testing so they
didn't realize they needed to repack, and didn't care to find out.
I've probably already said too much. I'm under NDAs.
But anyway. The point I was trying to make was that there are
not just some proxy servers, but also some server platforms, that
cannot handle bidirectional communiction. E.g. servers that are
behind reverse proxies, where the reverse proxy is acting as a sort
of firewall or content cache accelerator.
--
Shawn.
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Junio C Hamano @ 2008-08-02 21:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080802211714.GG24723@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We're getting ready for the git 1.6 release in the not-too-distant
> future, and that will ship with gitgui-0.11.
>
> The current tip of my master branch builds as follows. There have
> not been many changes in the interface so I don't think there is
> much (if any) translation work for this release.
>
> MSGFMT po/de.msg 402 translated.
> MSGFMT po/fr.msg 391 translated.
> MSGFMT po/hu.msg 391 translated.
> MSGFMT po/it.msg 390 translated, 1 untranslated.
> MSGFMT po/ja.msg 391 translated.
> MSGFMT po/ru.msg 387 translated, 4 untranslated.
> MSGFMT po/sv.msg 391 translated.
> MSGFMT po/zh_cn.msg 367 translated, 7 fuzzy, 17 untranslated.
Hmm, I am confused.
Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
po/de.msg is much more recent than po/git-gui.pot and all others are
translating the same POT.
Perhaps you wanted to update git-gui.pot first before sending this request
out?
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Shawn O. Pearce @ 2008-08-02 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4bccx8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
> po/de.msg is much more recent than po/git-gui.pot and all others are
> translating the same POT.
>
> Perhaps you wanted to update git-gui.pot first before sending this request
> out?
Oh. Its updated now, but msgmerge on my system is busted and won't
update the po files themselves. *sigh*
--
Shawn.
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Junio C Hamano @ 2008-08-02 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080802214930.GA25311@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
>> po/de.msg is much more recent than po/git-gui.pot and all others are
>> translating the same POT.
>>
>> Perhaps you wanted to update git-gui.pot first before sending this request
>> out?
>
> Oh. Its updated now, but msgmerge on my system is busted and won't
> update the po files themselves. *sigh*
I think that's Ok. msgmerge and edit are in the translators' bailiwick.
^ permalink raw reply
* [PATCH] diff: chapter and part in funcname for tex
From: Giuseppe Bilotta @ 2008-08-02 21:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <7vprormh7a.fsf@gitster.siamese.dyndns.org>
This patch enhances the tex funcname by adding support for
chapter and part sectioning commands. It also matches
the starred version of the sectioning commands.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
As recommended by Junio, use \{0,1\} instead of \?
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index c253015..776bce1 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,7 +1380,7 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
- { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+ { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
};
--
1.5.6.3
^ permalink raw reply related
* [PATCH] Fix reference to Everyday Git, which is an HTML document and not a man page.
From: Jon Jensen @ 2008-08-02 21:41 UTC (permalink / raw)
To: git; +Cc: Jon Jensen
Signed-off-by: Jon Jensen <jon@endpoint.com>
---
Documentation/git.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 44ea35e..3da5bf0 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -602,7 +602,7 @@ contributors on the git-list <git@vger.kernel.org>.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
linkgit:gitcli[7], link:user-manual.html[The Git User's Manual]
--
1.6.0.rc1.48.g2b6032
^ permalink raw reply related
* git-pull sets write bit, git-push does not
From: Alexander E Genaud @ 2008-08-02 22:32 UTC (permalink / raw)
To: git
git-pull sets write bit, git-push does not
Hello,
Background: I am using Git locally with ClearCase upstream. I
initialized a Git repository on top of a ClearCase snapshot view,
while my work branches are in a clone. As ClearCase is particular
about the write bit, I have come to depend on an undocumented feature
of Git. Namely, that git-push preserves read only permissions, while
git-pull sets modified files writable.
Can git-push be relied upon to preserve the write bit (readonly)? Why
is git-pull different? Is it a side effect of the plumbing?
Thanks,
Alex
http://genaud.net/2008/08/clearcase-globally-git-locally/
Simplified case:
echo --
echo create a repo r1 with files A and B committed
echo --
mkdir r1
cd r1
echo A > A
echo B > B
git init
git add .
git commit -m init
echo --
echo create an identical repo r2 whose files are readonly
echo --
cp -r ../r1 ../r2
chmod u-w ../r2/[AB]
echo --
echo push a modification of A from r1 to r2
echo --
echo AA > A
git commit -a -m modA
git push ../r2
echo --
echo pull a modification of B from r1 to r2
echo --
echo BB > B
git commit -a -m modB
cd ../r2
git pull ../r1
echo --
echo notice that pushed A remains readonly
echo while pulled B has become writable
echo --
ls -l
--
[ alex@genaud.net ][ http://genaud.net ]
[ B068 ED90 F47B 0965 2953 9FC3 EE9C C4D5 3E51 A207 ]
^ permalink raw reply
* Re: git-pull sets write bit, git-push does not
From: Matt Pearson @ 2008-08-02 23:18 UTC (permalink / raw)
To: Alexander E Genaud; +Cc: git
In-Reply-To: <ee521d6f0808021532k66bc5b24ma2eeb51021fb5f36@mail.gmail.com>
On Sat, Aug 2, 2008 at 6:32 PM, Alexander E Genaud <alex@genaud.net> wrote:
> git-pull sets write bit, git-push does not
>
> Hello,
>
> Background: I am using Git locally with ClearCase upstream. I
> initialized a Git repository on top of a ClearCase snapshot view,
> while my work branches are in a clone. As ClearCase is particular
> about the write bit, I have come to depend on an undocumented feature
> of Git. Namely, that git-push preserves read only permissions, while
> git-pull sets modified files writable.
>
> Can git-push be relied upon to preserve the write bit (readonly)? Why
> is git-pull different? Is it a side effect of the plumbing?
Push and pull are not opposite operations: the opposite of push is
fetch. This is because pull updates the working copy, while push does
not (like fetch, it only modifies the ref).
>
> Thanks,
> Alex
>
> http://genaud.net/2008/08/clearcase-globally-git-locally/
>
>
> Simplified case:
>
> echo --
> echo create a repo r1 with files A and B committed
> echo --
> mkdir r1
> cd r1
> echo A > A
> echo B > B
> git init
> git add .
> git commit -m init
>
> echo --
> echo create an identical repo r2 whose files are readonly
> echo --
> cp -r ../r1 ../r2
> chmod u-w ../r2/[AB]
>
> echo --
> echo push a modification of A from r1 to r2
> echo --
> echo AA > A
> git commit -a -m modA
> git push ../r2
>
> echo --
> echo pull a modification of B from r1 to r2
> echo --
> echo BB > B
> git commit -a -m modB
> cd ../r2
> git pull ../r1
>
> echo --
> echo notice that pushed A remains readonly
> echo while pulled B has become writable
> echo --
> ls -l
>
After running this:
$ cat A
A
$ cat ../r1/A
AA
The working copy in r2 was not updated with the changes you pushed to
it (both the content and the mode change).
^ permalink raw reply
* Re: git-pull sets write bit, git-push does not
From: Matt Pearson @ 2008-08-03 1:15 UTC (permalink / raw)
To: Alexander E Genaud; +Cc: git
In-Reply-To: <706b4240808021618y5604b7c9h915237c30d87dace@mail.gmail.com>
On Sat, Aug 2, 2008 at 7:18 PM, Matt Pearson <404emailnotfound@gmail.com> wrote:
> The working copy in r2 was not updated with the changes you pushed to
> it (both the content and the mode change).
Hm, your test case is more complicated than I originally thought. I
get that result with the git from Ubuntu Hardy, but current master
dies on the pull complaining B is not uptodate (has local changes). I
guess this was a bug that was fixed, but there's no way I'm going to
bisect or look at release notes over half a year (or more) of changes
:)
What it mainly comes down to is that git has only two possible file
modes: 644 and 755. These are the only ones that will ever be stored
in the object database. It seems like older git would ignore
permission changes to the working copy, and reset the permissions to
the "normalized" version when updating a file that was modified by the
pull.
Here's a blow-by-blow explanation. I'll use numbers to refer to the
commits, where 1 is the initial commit, 2 is the commit you pushed,
and 3 is the one you pulled. After the cp -r, both repos have a clean
working tree; the chmod dirties the working tree of r2.
The push causes both repos to have 2 be the HEAD commit, but r2 keeps
the dirty working tree changes, including (what now appears to be,
from git's POV) a change in the content of A from 'AA' to the 'A' in
the initial commit. (The content change will appear as a staged change
when running status in r2, because the index isn't updated either)
When pulling 3, git thinks that these changes were made on top of 2,
and you want to keep them. So it doesn't modify the contents of A
because A was not changed in commit 3---if it was, you'd get a "not
uptodate" message.
B, however, *was* changed in 3, so it tries to apply those changes.
With the older version, it seems to ignore the permissions change and
simply fast-forward to the state B was in after commit 3 (content
'BB', mode 644). With the newer version, it does see that the mode has
been changed, and aborts due to a conflict. In fact, it doesn't seem
to like any mode change---it still dies with a conflict if I change
the chmod to 'a+x'.
Hope that clears it up better---figuring this out helped me learn some
stuff about git. Now I'll wait for someone more knowledgeable than I
to tell me I'm wrong. :)
Matt
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-03 2:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <20080802205702.GA24723@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> > I have investigated a bit what it would take to support git protocol
> > (smart transport) over HTTP POST transactions.
>
> I have started to think about this more myself, not just for POST
> put also for some form of GET that can return an efficient pack,
> rather than making the client walk the object chains itself.
...
> HTTP POST is actually trivial if you don't want to support the new
> tell-me-more extension that was added to git-push. Hell, I could
> write the CGI in a few minutes I think. Its really just a small
> wrapper around git-receive-pack.
So I have this draft of how smart push might work. Its slated
for the Documentation/technical directory. Thus far I have only
written about push support, but Ilari on #git has some ideas about
how to do a smart fetch protocol.
Implementation wise in C git I think this is just a new C
program (git-http-backend?) that turns around and proxies
into git-receive-pack, at least for the push support.
What I don't know is how we could configure URI translation from
/path/to/repository.git received out of the $PATH_INFO in the
CGI environment to a physical directory. Should we rely on the
server's $PATH_TRANSLATED?
Smart HTTP transfer protocols
=============================
Git supports two HTTP based transfer protocols. A "dumb" protocol
which requires only a standard HTTP server on the server end of the
connection, and a "smart" protocol which requires a Git aware CGI
(or server module). This document describes the "smart" protocol.
Authentication
--------------
Standard HTTP authentication is used, and must be configured and
enforced by the HTTP server software.
Chunked Transfer Encoding
-------------------------
For performance reasons the HTTP/1.1 chunked transfer encoding is
used frequently to transfer variable length objects. This avoids
needing to produce large results in memory to compute the proper
content-length.
Detecting Smart Servers
-----------------------
HTTP clients can detect a smart Git-aware server by sending the
show-ref request (below) to the server. If the response has a
status of 200 and the magic x-application/git-refs content type
then the server can be assumed to be a smart Git-aware server.
If any other response is received the client must assume dumb
protocol support, as the server did not correctly response to
the request.
Show Refs
---------
Obtains the available refs from the remote repository. The response
is a sequence of git "packet lines", one per ref, and a final flush
packet line to indicate the end of stream.
C: GET /path/to/repository.git?show-ref HTTP/1.0
S: HTTP/1.1 200 OK
S: Content-Type: x-application/git-refs
S: Transfer-Encoding: chunked
S:
S: 62
S: 003e95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
S:
S: 63
S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
S:
S: 59
S: 003b2cb58b79488a98d2721cea644875a8dd0026b115 refs/heads/pu
S:
S: 4
S: 0000
S: 0
Push Pack
---------
Uploads a pack and updates refs. The start of the stream is the
commands to update the refs and the remainder of the stream is the
pack file itself. See git-receive-pack and its network protocol
in pack-protocol.txt, as this is essentially the same.
C: POST /path/to/repository.git?receive-pack HTTP/1.0
C: Content-Type: x-application/git-receive-pack
C: Transfer-Encoding: chunked
C:
C: 103
C: 006395dcfa3633004da0049d3d0fa03f80589cbcaf31 d049f6c27a2244e12041955e262a404c7faba355 refs/heads/maint
C: 4
C: 0000
C: 12
C: PACK
...
C: 0
S: HTTP/1.0 200 OK
S: Content-type: x-application/git-status
S: Transfer-Encoding: chunked
S:
S: ...<output of receive-pack>...
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] TopGit - A different patch queue manager
From: Petr Baudis @ 2008-08-03 3:14 UTC (permalink / raw)
To: git
Hi,
I'd like to announce TopGit v0.1, the first (while also the youngest)
project from my Rhine pipeline (sitting at the river shore, hacking
free of all online distractions; the only catch is that the offline
distractions can be plentiful as well - too many pretty girls tend
to cluster around the water in the hot summer days for some strange
reason.)
TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
and others, of course in an attempt to Get It Right this time around.
TopGit is absolutely minimal porcelain layer that will manage your
patch queue for you using topic branches, one patch per branch.
And do _ONLY_ that. Unlike with StGIT, you can actually use the index.
TopGit aims to scratch three of my long-term patch management itches:
(i) Let you freely specify patch dependencies, instead of
forcing you to linearize your patches into a series
(ii) Keep your development history rigorously - it is to be
cleaned up only once, and that is when submitted upstream
(iii) Actually _WORK_ in the distributed environment;
you can have several repositories and develop your patches
in all of them
You can get TopGit at
http://repo.or.cz/w/topgit.git
and read up on its design, usage and implementation at:
http://repo.or.cz/w/topgit.git?a=blob;f=README
This is v0.1. I started working on it last evening (by spending over
two hours writing the README from scratch up to pretty much its current
state), got it feature complete few hours ago and testing it out the
rest of the evening. So yes, it probably still has some bugs, but it
should be ready for general practical usage, so please give it a try.
I just recreated
http://repo.or.cz/w/git/gitweb.git
with it and plan to use it pretty much exclusively for all my Git
patches from now on (and it turns out there is quite a few, I just had
no good way to organize and submit them so far).
Besides that, some utility commands are still missing, some of them
are TODO'd in the README. Most notably, the distributed workflow still
has no explicit support within TopGit which makes it a little awkward,
and there is actually no way to mail your patches yet ;-) - tg patch
will only dump a single one on stdout and you need to do the rest.
TopGit is not very well optimized so far; I made little to no
benchmarks and I'm focused on getting things work right first. Still,
I believe that most operations should not take noticeably long until
you get into many tens of densely dependent patches. One exception
is 'tg summary', which is unfortunately dog-slow and I couldn't
figure out how to speed it up further so far.
P.S.: git/gitweb.git is mentioned here just as an example of
real-world TopGit usage; ignore the contents. I actually do intend
to revive this repository, but there's still a lot of work to do.
P.P.S.: Can I get trademark on the (ironically) /[^p]g/ porcelains
now? ;-)
Have fun,
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: More on git over HTTP POST
From: Junio C Hamano @ 2008-08-03 3:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20080803025602.GB27465@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Show Refs
> ---------
>
> Obtains the available refs from the remote repository. The response
> is a sequence of git "packet lines", one per ref, and a final flush
> packet line to indicate the end of stream.
As the initial protocol exchange request, I suspect that you would regret
if you do not leave room for some "capability advertisement" in this
exchange.
With the git native protocol, we luckily found space to do so after the
ref payload (because pkt-line is "length + payload" format but the code
that reads payload happened to ignore anything after NUL). You would want
to define how these are given by the server to the client over HTTP
channel. For example, putting them on extra HTTP headers is probably Ok.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-03 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <7v63qiydzg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Show Refs
> > ---------
> >
> > Obtains the available refs from the remote repository. The response
> > is a sequence of git "packet lines", one per ref, and a final flush
> > packet line to indicate the end of stream.
>
> As the initial protocol exchange request, I suspect that you would regret
> if you do not leave room for some "capability advertisement" in this
> exchange.
>
> With the git native protocol, we luckily found space to do so after the
> ref payload (because pkt-line is "length + payload" format but the code
> that reads payload happened to ignore anything after NUL). You would want
> to define how these are given by the server to the client over HTTP
> channel. For example, putting them on extra HTTP headers is probably Ok.
Yea, I thought that the HTTP headers would be more than enough
space to add capability advertisements. Most client libraries
will happily parse and store these for the application, and won't
make a fuss if the application doesn't read them.
Hence there's more than enough room in the protocol to extend it
in the future with additional capabilities.
We do have to be careful though. Any cachable resource must only
rely upon the URI and the standard headers which compute into the
cache key for a request. There aren't many, though I think the
Content-Type header may be among them.
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 3:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <7v63qiydzg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> With the git native protocol, we luckily found space to do so after the
> ref payload (because pkt-line is "length + payload" format but the code
> that reads payload happened to ignore anything after NUL). You would want
> to define how these are given by the server to the client over HTTP
> channel. For example, putting them on extra HTTP headers is probably Ok.
I think that would be a mistake, just because it's one more thing for
proxies to screw up on. It's better to have negotiation information in
the payload, before the "real" data.
Obviously one thing that needs to be included in each transaction is a
transaction ID that will be reported back on the next transaction, since
you can't rely on a persistent connection.
-hpa
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 3:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20080803025602.GB27465@spearce.org>
Shawn O. Pearce wrote:
> Chunked Transfer Encoding
> -------------------------
>
> For performance reasons the HTTP/1.1 chunked transfer encoding is
> used frequently to transfer variable length objects. This avoids
> needing to produce large results in memory to compute the proper
> content-length.
Note: you cannot rely on HTTP/1.1 being supported by an intermediate
proxy; you might have to handle HTTP/1.0, where the data is terminated
by connection close.
-hpa
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 4:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20080803025602.GB27465@spearce.org>
Shawn O. Pearce wrote:
> Chunked Transfer Encoding
> -------------------------
>
> For performance reasons the HTTP/1.1 chunked transfer encoding is
> used frequently to transfer variable length objects. This avoids
> needing to produce large results in memory to compute the proper
> content-length.
One more thing about chunked transfer encodings: you cannot assume that
a proxy will maintain chunk boundaries, any more than you can assume
that a firewall will maintain TCP packet boundaries.
> Detecting Smart Servers
> -----------------------
>
> HTTP clients can detect a smart Git-aware server by sending the
> show-ref request (below) to the server. If the response has a
> status of 200 and the magic x-application/git-refs content type
> then the server can be assumed to be a smart Git-aware server.
>
> If any other response is received the client must assume dumb
> protocol support, as the server did not correctly response to
> the request.
I think it should be application/x-git-refs, but that's splitting hairs.
> Obtains the available refs from the remote repository. The response
> is a sequence of git "packet lines", one per ref, and a final flush
> packet line to indicate the end of stream.
>
> C: GET /path/to/repository.git?show-ref HTTP/1.0
>
I really think it would make more sense to use POST requests for
everything, and have the command part of the POSTed payload. Putting
stuff in the URL just complicates the namespace to the detriment of the
admin.
> S: HTTP/1.1 200 OK
> S: Content-Type: x-application/git-refs
> S: Transfer-Encoding: chunked
Transfer-encoding: chunked is illegal with a HTTP/1.0 client.
-hpa
^ 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