* Re: [PATCH] Fix reduce_heads
From: Johannes Schindelin @ 2008-07-14 9:30 UTC (permalink / raw)
To: Sverre Hvammen Johansen; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <402c10cd0807132107s29c470f7hb834bd5c00ef399e@mail.gmail.com>
Hi,
On Sun, 13 Jul 2008, Sverre Hvammen Johansen wrote:
> Reduce_heads used by build in merge failed to find the correct
> heads in cases where duplicate heads are specified.
I liked Junio's explanation better.
> This should fix the last breakage I found. ([PATCH/Test] Build in
> merge is broken)
> I have squashed in Miklos's fix and the two tests cases to protect this.
I'd rather not have it squashed in. Miklos is a GSoC student, and at the
end I want to show the shortlog to tell Google how he fared.
Unfortunately, Miklos is on holiday this week, so he cannot send a mail of
his own. Junio, could you fake a commit message with a sign-off for
Miklos, or do you want me to do it?
Ciao,
Dscho
^ permalink raw reply
* I want delete fault commit from my git repository
From: chongyc @ 2008-07-14 9:24 UTC (permalink / raw)
To: git
I have found buggy commit object which I had committed into git
repository wrongly
So I am going to delete it from my git repository
How to do it ?
please help me.
^ permalink raw reply
* Re: Errors importing Apache Synapse SVN using Git
From: Michael J Gruber @ 2008-07-14 9:14 UTC (permalink / raw)
To: git; +Cc: normalperson, asankha
In-Reply-To: <20080714081615.GB10304@hand.yhbt.net>
Eric Wong venit, vidit, dixit 14.07.2008 10:16:
> Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
>> Asankha C. Perera venit, vidit, dixit 10.07.2008 14:01:
>>> Hi All
>>>
>>> I am an Apache Synapse developer, and want to import the Synapse SVN
>>> repo into Git, so that Ohloh can properly get the Synapse history
>>> (http://www.ohloh.net/topics/1326?page=1#post_6287)
>>>
>>> However, when I try the command: "git svn clone --trunk=trunk
>>> --tags=tags --branches=branches http://svn.apache.org/repos/asf/synapse"
>>> it seems to take forever, (or at least until the next network glitch),
>>> and keeps filling up a file with just plain zeros ("0") :
>>> ./.git/svn/trunk/.rev_db.13f79535-47bb-0310-9956-ffa450edef68
>
> The latest versions of git-svn should be vastly more space efficient
> with .rev_map files.
>
>> Okay, besides the zero offset, there seems to be big problem with the
>> svn repo:
>>
>> svn list -r 234478 http://svn.apache.org/repos/asf/synapse
>> branches/
>> site/
>> tags/
>> trunk/
>>
>> svn list -r 234478 http://svn.apache.org/repos/asf|grep synapse
>
> Ah, that's because it started off in the /incubator directory, not /synapse:
>
> $ svn log -v -r 234478 http://svn.apache.org/repos/asf
> ------------------------------------------------------------------------
> r234478 | dims | 2005-08-22 05:39:51 -0700 (Mon, 22 Aug 2005) | 3 lines
> Changed paths:
> A /incubator/synapse/branches
> A /incubator/synapse/site
> A /incubator/synapse/tags
> A /incubator/synapse/trunk
>
> init synapse SVN
Yes, and later on there was some more moving around to
"webservices/synapse/synapse", ".../syaps2", ".../synapse" (i.e.
renaming "synapse/synapse" to "synapse") and then to the final destination.
Some svn client command know how to follow moves, other don't. I can't
make them return results by using peg revisions, but I don't know how
git-svn handles them.
> ------------------------------------------------------------------------
>
>> Right, nothing returned.
>>
>> git-svn insists on using http://svn.apache.org/repos/asf as the base
>> URL, which is basically correct, but doesn't work for this repo.
>>
>> Even editing .git/config and .git/svn/metadata (after git svn init,
>> befire the first fetch) to change the url doesn't help. git svn still
>> uses .../asf. Is this as intended? cc'ing the git svn author.
>
> Can you try using the latest git-svn and also --no-follow-parent?
>
> --no-follow-parent won't traverse copy history so it may be faster,
> but you'll get an incomplete history.
>
> On the other hand, it looks like the asf repo is hopelessly slow
> for history retrieval.
>
> I'm pulling the asf log (svn log -v http://svn.apache.org/repos/asf >
> tmp.log) but it's taking forever... git-svn uses basically the same
> operation as 'svn log -v' and I've yet to see an SVN server take this
> long to show history.
>
> I've gotten 70,000 revisions after over one hour with the above svn log
> command. I'm going to restart this from a server with a better
> connection since I need to power off this one when I sleep.
Note that I'm not the OP, I'm just a git-svn user who got curious about
that post. I think the asf repo shows exactly those mistakes which svn
drives its users into (and which I've made also, on a much smaller
scale, of course). As far as I understand, the synapse repo there is
historical, and they need to convert to git in order to feed it into a
CMS. I don't know if OP is still interested.
Michael
^ permalink raw reply
* [PATCH] t/lib-git-svn: fix SVN_HTTPD tests to work with "trash directory"
From: Eric Wong @ 2008-07-14 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/lib-git-svn.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 5d3bd9d..a841df2 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -98,7 +98,7 @@ LoadModule dav_module $SVN_HTTPD_MODULE_PATH/mod_dav.so
LoadModule dav_svn_module $SVN_HTTPD_MODULE_PATH/mod_dav_svn.so
<Location /$repo_base_path>
DAV svn
- SVNPath $rawsvnrepo
+ SVNPath "$rawsvnrepo"
</Location>
EOF
"$SVN_HTTPD_PATH" -f "$GIT_DIR"/httpd.conf -k start
--
1.5.6.3.316.g20ed6
^ permalink raw reply related
* Re: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
From: Eric Wong @ 2008-07-14 9:12 UTC (permalink / raw)
To: João Abecasis; +Cc: git
In-Reply-To: <7bf6f1d20807081908kdf9f615taa532ae579b457d7@mail.gmail.com>
João Abecasis <joao@abecasis.name> wrote:
> find-rev and rebase error out on svm because git-svn doesn't trace the original
> svn revision numbers back to git commits. The updated test case, included in the
> patch, shows the issue and passes with the rest of the patch applied.
>
> This fixes Git::SVN::find_by_url to find branches based on the svm:source URL,
> where useSvmProps is set. Also makes sure cmd_find_rev and working_head_info use
> the information they have to correctly track the source repository. This is
> enough to get find-rev and rebase working.
>
> Signed-off-by: João Abecasis <joao@abecasis.name>
> ---
> Incidentally, I've tried submitting these fixes before, but failed to
> get much attention, so I could be doing something wrong... Any input
> on the patch or my approach to this list is appreciated. This time I
> reworded the commit message and added Eric Wong to the CC list, since
> he seems to be Ack'ing git-svn patches.
Hi João,
Sorry, I haven't been following the mailing list much lately, and
even keeping up with my inbox is getting to be a chore :(
The commit message should be wrapped at 72 characters or less.
Some further notes below (mostly whitespace issues, but one
regression).
> sub read_all_remotes {
> my $r = {};
> + my $usesvmprops = eval { command_oneline(qw/config --bool
> + svn.useSvmProps/) };
> + $usesvmprops = $usesvmprops eq 'true' if $usesvmprops;
Always use tabs for indentation (but spaces for alignment is alright).
I'd also rather not propagate the crazy alllowercasewithoutunderscores
convention of git-config into code, either. $uses_svm_props is much
easier to parse when I'm half-awake :)
> foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
> if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
> my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
> $local_ref =~ s{^/}{};
> $r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
> + $r->{$remote}->{svm} = {} if $usesvmprops;
> + } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
> + $r->{$1}->{svm} = {};
> } elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
> $r->{$1}->{url} = $2;
> } elsif (m!^(.+)\.(branches|tags)=
> @@ -1437,6 +1443,21 @@ sub read_all_remotes {
> }
> }
> }
> +
> + map {
> + if (defined $r->{$_}->{svm}) {
> + my $svm;
> + eval {
> + my $section = "svn-remote.$_";
> + $svm = {
> + source => tmp_config('--get', "$section.svm-source"),
> + replace => tmp_config('--get', "$section.svm-replace"),
> + }
> + };
> + $r->{$_}->{svm} = $svm;
> + }
> + } keys %$r;
> +
Please wrap all code at 80-columns.
> @@ -1563,13 +1584,21 @@ sub find_by_url { # repos_root and, path are optional
> }
> my $p = $path;
> my $rwr = rewrite_root({repo_id => $repo_id});
> + my $svm = $remotes->{$repo_id}->{svm}
> + if defined $remotes->{$repo_id}->{svm};
> unless (defined $p) {
> $p = $full_url;
> my $z = $u;
> + my $prefix = '';
> if ($rwr) {
> $z = $rwr;
> + } elsif (defined $svm) {
> + $z = $svm->{source};
> + $prefix = $svm->{replace};
> + $prefix =~ s#^\Q$u\E(?:/|$)##;
> + $prefix =~ s#/$##;
> }
> - $p =~ s#^\Q$z\E(?:/|$)## or next;
> + $p =~ s#^\Q$z\E(?=/|$)#$prefix# or next;
This broke t9100 for me at: 'able to dcommit to a subdirectory'
Changing the ?= back to ?: works.
Thanks for the patch, please let us know if that change is OK.
--
Eric Wong
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-14 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlokhpk7.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 14, 2008 at 12:50:48AM -0700, Junio C Hamano wrote:
> By default, packfiles created with this version uses delta-base-offset
> encoding introduced in v1.4.4. Pack idx files are using version 2 that
> allows larger packs and added robustness thanks to its CRC checking,
> introduced in v1.5.2.
Oh, I thought this was some earlier change when I noticed it few days
ago on repo.or.cz, but seems there is still a chance to turn this over -
please reconsider...? :-)
Can't we by default use the version 2 only in case we actually _need_ to
store the larger packs? The CRC checking may be nice, but not critical,
and we could wait a bit more with it yet.
I'm saying this because I believe the best conservative upper bound for
backwards compatibility is Git version in Debian stable. It gets
probably the most stale from all the widely used software distributions
using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
fails miserably on the new packs:
Getting alternates list for http://repo.or.cz/r/repo.git/
Getting pack list for http://repo.or.cz/r/repo.git/
Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
error: non-monotonic index
/usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"
P.S.: AFAIK new Debian stable release is scheduled on Fall.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Jakub Narebski @ 2008-07-14 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlokhpk7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> GIT v1.6.0 Release Notes (draft)
> ================================
> * By default, stash entries never expire. Set reflogexpire in [gc
> "refs/stash"] to a reasonable value to get traditional auto-expiration
> behaviour back
And, of course, one can set up reflog expiration per ref or per
ref type (for example never expiring stash, making expiration for
HEAD longer than default, and for remote-tracking branches shorter).
> * git-stash also learned branch subcommand to create a new branch out of
> stashed changes.
Typography: wouldn't it be better to use "learned 'branch' subcommand"?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Sixt @ 2008-07-14 8:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <alpine.DEB.1.00.0807132141130.8950@racer>
Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> > ### Installation rules
> >
> > ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for? Did the original line stop working?
Hmpf! This new line doesn't work in the intended way if the installation
destination does not exist. I'll have to find a better solution...
-- Hannes
^ permalink raw reply
* Re: Git describe question
From: Mark Burton @ 2008-07-14 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdz8hp3d.fsf@gitster.siamese.dyndns.org>
Thanks for the speedy response.
> A longer answer. v1.5.6.X releases are from 'maint'. The branch has
> forked from the mainline loooong time ago (at v1.5.6, to be exact), and
> has only fixes. 'master' is a separate branch for development that would
> eventually lead to the next major release (planned to be v1.6.0).
Ok, I understand what it's doing now - but that makes me wonder if it
would be useful/possible to be able to specify that git describe only
considers the commits on top of the tag for the current (or some
specified branch). i.e. at the moment, gitk shows 8 commits on top of
v1.5.6.3 in the master branch.
As the master branch is the checked out branch and the v1.5.6.3 tag
tags a commit in that branch (via the merge) is it not possible to only
consider the commits between the tag and the HEAD on that branch?
Sorry, I don't understand the git internals (yet) so I don't know if
this is a stupid question and I am certainly not in a position to try
and implement it myself (yet).
Cheers,
Mark
^ permalink raw reply
* [PATCH] bash: Add long option completion for 'git send-email'
From: Teemu Likonen @ 2008-07-14 8:21 UTC (permalink / raw)
To: git; +Cc: spearce, gitster
Add the following long options to be completed with 'git send-email':
--bcc --cc --cc-cmd --chain-reply-to --compose --dry-run
--envelope-sender --from --identity --in-reply-to
--no-chain-reply-to --no-signed-off-by-cc --no-suppress-from
--no-thread --quiet --signed-off-by-cc --smtp-pass --smtp-server
--smtp-server-port --smtp-ssl --smtp-user --subject --suppress-cc
--suppress-from --thread --to
Short ones like --to and --cc are not usable for actual completion
because of the shortness itself and because there are longer ones which
start with same letters (--thread, --compose). It's still useful to have
these shorter options _listed_ when user presses TAB key after typing
two dashes. It gives user an idea what options are available (and --to
and --cc are probably the most commonly used).
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---
contrib/completion/git-completion.bash | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d268e6f..b15f3a9 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -905,6 +905,24 @@ _git_rebase ()
__gitcomp "$(__git_refs)"
}
+_git_send_email ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--bcc --cc --cc-cmd --chain-reply-to --compose
+ --dry-run --envelope-sender --from --identity
+ --in-reply-to --no-chain-reply-to --no-signed-off-by-cc
+ --no-suppress-from --no-thread --quiet
+ --signed-off-by-cc --smtp-pass --smtp-server
+ --smtp-server-port --smtp-ssl --smtp-user --subject
+ --suppress-cc --suppress-from --thread --to"
+ return
+ ;;
+ esac
+ __git_complete_file
+}
+
_git_config ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1376,6 +1394,7 @@ _git ()
rebase) _git_rebase ;;
remote) _git_remote ;;
reset) _git_reset ;;
+ send-email) _git_send_email ;;
shortlog) _git_shortlog ;;
show) _git_show ;;
show-branch) _git_log ;;
@@ -1435,6 +1454,7 @@ complete -o default -o nospace -F _git_rebase git-rebase
complete -o default -o nospace -F _git_config git-config
complete -o default -o nospace -F _git_remote git-remote
complete -o default -o nospace -F _git_reset git-reset
+complete -o default -o nospace -F _git_send_email git-send-email
complete -o default -o nospace -F _git_shortlog git-shortlog
complete -o default -o nospace -F _git_show git-show
complete -o default -o nospace -F _git_stash git-stash
--
1.5.6.3.316.g01fc
^ permalink raw reply related
* Re: Errors importing Apache Synapse SVN using Git
From: Eric Wong @ 2008-07-14 8:16 UTC (permalink / raw)
To: Michael J Gruber
In-Reply-To: <48774A0F.2070805@fastmail.fm>
Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> Asankha C. Perera venit, vidit, dixit 10.07.2008 14:01:
> >Hi All
> >
> >I am an Apache Synapse developer, and want to import the Synapse SVN
> >repo into Git, so that Ohloh can properly get the Synapse history
> >(http://www.ohloh.net/topics/1326?page=1#post_6287)
> >
> >However, when I try the command: "git svn clone --trunk=trunk
> >--tags=tags --branches=branches http://svn.apache.org/repos/asf/synapse"
> >it seems to take forever, (or at least until the next network glitch),
> >and keeps filling up a file with just plain zeros ("0") :
> >./.git/svn/trunk/.rev_db.13f79535-47bb-0310-9956-ffa450edef68
The latest versions of git-svn should be vastly more space efficient
with .rev_map files.
> Okay, besides the zero offset, there seems to be big problem with the
> svn repo:
>
> svn list -r 234478 http://svn.apache.org/repos/asf/synapse
> branches/
> site/
> tags/
> trunk/
>
> svn list -r 234478 http://svn.apache.org/repos/asf|grep synapse
Ah, that's because it started off in the /incubator directory, not /synapse:
$ svn log -v -r 234478 http://svn.apache.org/repos/asf
------------------------------------------------------------------------
r234478 | dims | 2005-08-22 05:39:51 -0700 (Mon, 22 Aug 2005) | 3 lines
Changed paths:
A /incubator/synapse/branches
A /incubator/synapse/site
A /incubator/synapse/tags
A /incubator/synapse/trunk
init synapse SVN
------------------------------------------------------------------------
> Right, nothing returned.
>
> git-svn insists on using http://svn.apache.org/repos/asf as the base
> URL, which is basically correct, but doesn't work for this repo.
>
> Even editing .git/config and .git/svn/metadata (after git svn init,
> befire the first fetch) to change the url doesn't help. git svn still
> uses .../asf. Is this as intended? cc'ing the git svn author.
Can you try using the latest git-svn and also --no-follow-parent?
--no-follow-parent won't traverse copy history so it may be faster,
but you'll get an incomplete history.
On the other hand, it looks like the asf repo is hopelessly slow
for history retrieval.
I'm pulling the asf log (svn log -v http://svn.apache.org/repos/asf >
tmp.log) but it's taking forever... git-svn uses basically the same
operation as 'svn log -v' and I've yet to see an SVN server take this
long to show history.
I've gotten 70,000 revisions after over one hour with the above svn log
command. I'm going to restart this from a server with a better
connection since I need to power off this one when I sleep.
--
Eric Wong
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Sixt @ 2008-07-14 8:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <7vzlokhpk7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> * git-gui learned to stage changes per-line.
This has usability issues. In particular, it is impossible to stage only
the change "old1"->"new1" or unstage the change "old2"->"new2" of this hunk:
@@ -1,4 +1,4 @@
ctxt1
-old1
-old2
+new1
+new2
ctxt2
Being able to do that was one of the goals, and I missed it :-( Since
that's my personal itch, I'll come up with a patch rather sooner than later.
-- Hannes
^ permalink raw reply
* Re: Git describe question
From: Junio C Hamano @ 2008-07-14 8:00 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20080714085557.246f52b9@crow>
Mark Burton <markb@ordern.com> writes:
> Having just pulled the latest updates, git describe says:
>
> v1.5.6.3-315-g10ce020
>
> Why does it think there are 315 commits on top of the v1.5.6.3 tag?
Short answer. Because there are. Count'em ;-)
$ git rev-list v1.5.6.3..master | wc -l
A longer answer. v1.5.6.X releases are from 'maint'. The branch has
forked from the mainline loooong time ago (at v1.5.6, to be exact), and
has only fixes. 'master' is a separate branch for development that would
eventually lead to the next major release (planned to be v1.6.0).
^ permalink raw reply
* Git describe question
From: Mark Burton @ 2008-07-14 7:55 UTC (permalink / raw)
To: git
Hi,
Having just pulled the latest updates, git describe says:
v1.5.6.3-315-g10ce020
Why does it think there are 315 commits on top of the v1.5.6.3 tag? I
would have expected a much smaller number than that.
Thanks,
Mark
^ permalink raw reply
* Closing the merge window for 1.6.0
From: Junio C Hamano @ 2008-07-14 7:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzetjbif.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think most of the important stuff is already in 'next'. Let's start
> talking about closing the merge window for 1.6.0.
I think by the time we declare -rc0, we will have merged everything we
have in "Actively Cooking" list from tonight, perhaps except for the
"merge -Xtheirs", as there do not seem to be wide support for this
feature. All the Windows bits and myriad of s/git-foo/git foo/ patches
submitted over the weekend and queued in next/pu, and various smallish
topics in "New Topics" list will hopefully all appear in 1.6.0.
In essence, I am saying that the merge window is more-or-less closed, from
the point of view of "what will be in, and what won't be"; of course some
of the topics may not be merged in their current shape without further
fixes.
The reason I say more-or-less is because I am aware of a handful of
patches that are not even in 'pu' yet:
* A few patches from Mark Levedahl on git-submodule are still held in my
inbox; I haven't decided what to do with them.
Date: Wed, 9 Jul 2008 21:05:40 -0400
Subject: [PATCH] git-submodule - make "submodule add" more strict, and document it
Message-Id: <1215651941-3460-1-git-send-email-mlevedahl@gmail.com>
Date: Wed, 9 Jul 2008 21:05:41 -0400
Subject: [PATCH] git-submodule - register submodule URL if adding in place
Message-ID: <1215651941-3460-2-git-send-email-mlevedahl@gmail.com>
These two appeared at the end of a discussion, and as far as I can see,
there wasn't any objection to them. Unless somebody makes a convincing
argument against them, I am inclined to include them in 1.6.0
* Starting bisect with a forked good and bad pair, from Christian Couder,
is not queued yet. I think it is just the matter of Christian
resending the two patches squashed (or me applying them while squashing
them myself) --- I was busy cutting 1.5.6.3 release and tending other
topics, and haven't got around to do so.
Date: Thu, 10 Jul 2008 05:41:52 +0200
Subject: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
Message-Id: <20080710054152.b051989c.chriscool@tuxfamily.org>
* Alice and Bob prompt in tutorial, from Ian Katz, is not queued; they
should be safe to directly apply to 'master'. The only reason why I
haven't is because it takes a lot of time to generate and concentration
to eyeball the documentation markups to catch mistakes.
Date: Thu, 10 Jul 2008 14:27:30 -0400
Subject: Re: [PATCH] tutorial: prefix the prompts with names alice or bob,
to make it clear who is doing what
Message-ID: <dc5b80bf0807101127q63e3132fw207baf0d88db3d9d@mail.gmail.com>
Subject: [PATCH] tutorial: clarify "pull" is "fetch + merge"
Date: Thu, 10 Jul 2008 14:01:57 -0700
Message-ID: <7vskuho3lm.fsf_-_@gitster.siamese.dyndns.org>
* A git-svn patch from João Abecasis; I am waiting for Eric to act on it.
Subject: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
Date: Wed, 9 Jul 2008 03:08:27 +0100
Message-ID: <7bf6f1d20807081908kdf9f615taa532ae579b457d7@mail.gmail.com>
Here is the draft release notes as of tonight.
----------------------------------------------------------------
GIT v1.6.0 Release Notes (draft)
================================
User visible changes
--------------------
With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.
GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.
An ancient merge strategy "stupid" has been removed.
Updates since v1.5.6
--------------------
(subsystems)
* git-p4 in contrib learned "allowSubmit" configuration to control on
which branch to allow "submit" subcommand.
* git-gui learned to stage changes per-line.
(portability)
* Changes for MinGW port have been merged, thanks to Johannes Sixt and
gangs.
* Sample hook scripts shipped in templates/ are now suffixed with
*.sample. We used to prevent them from triggering by default by
relying on the fact that we install them as unexecutable, but on
some filesystems this approach does not work. Instead of running
"chmod +x" on them, the users who want to activate these samples
as-is can now rename them dropping *.sample suffix.
* perl's in-place edit (-i) does not work well without backup files on Windows;
some tests are rewritten to cope with this.
(documentation)
* Updated howto/update-hook-example
* Got rid of usage of "git-foo" from the tutorial and made typography
more consistent.
* Disambiguating "--" between revs and paths is finally documented.
(performance, robustness, sanity etc.)
* even more documentation pages are now accessible via "man" and "git help".
* reduced excessive inlining to shrink size of the "git" binary.
* verify-pack checks the object CRC when using version 2 idx files.
* When an object is corrupt in a pack, the object became unusable even
when the same object is available in a loose form, We now try harder to
fall back to these redundant objects when able. In particular, "git
repack -a -f" can be used to fix such a corruption as long as necessary
objects are available.
* git-clone does not create refs in loose form anymore (it behaves as
if you immediately ran git-pack-refs after cloning). This will help
repositories with insanely large number of refs.
* core.fsyncobjectfiles configuration can be used to ensure that the loose
objects created will be fsync'ed (this is only useful on filesystems
that does not order data writes properly).
* "git commit-tree" plumbing can make Octopus with more than 16 parents.
"git commit" has been capable of this for quite some time.
(usability, bells and whistles)
* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
the discovery process of the toplevel of working tree; this may be useful
when you are working in a slow network disk and are outside any working tree,
as bash-completion and "git help" may still need to run in these places.
* By default, stash entries never expire. Set reflogexpire in [gc
"refs/stash"] to a reasonable value to get traditional auto-expiration
behaviour back
* Longstanding latency issue with bash completion script has been
addressed. This will need to be backmerged to 'maint' later.
* pager.<cmd> configuration variable can be used to enable/disable the
default paging behaviour per command.
* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
manually.
* git-apply can handle a patch that touches the same path more than once
much better than before.
* git-apply can be told not to trust the line counts recorded in the input
patch but recount, with the new --recount option.
* git-apply can be told to apply a patch to a path deeper than what the
patch records with --directory option.
* git-archive can be told to omit certain paths from its output using
export-ignore attributes.
* With -v option, git-branch describes the remote tracking statistics
similar to the way git-checkout reports by how many commits your branch
is ahead/behind.
* git-bundle can read the revision arguments from the standard input.
* git-cherry-pick can replay a root commit now.
* git-clone can clone from a remote whose URL would be rewritten by
configuration stored in $HOME/.gitconfig now.
* git-diff --check now checks leftover merge conflict markers.
* When remote side used to have branch 'foo' and git-fetch finds that now
it has branch 'foo/bar', it refuses to lose the existing remote tracking
branch and its reflog. The error message has been improved to suggest
pruning the remote if the user wants to proceed and get the latest set
of branches from the remote, including such 'foo/bar'.
* fast-export learned to export and import marks file; this can be used to
interface with fast-import incrementally.
* "git rerere" can be told to update the index with auto-reused resolution
with rerere.autoupdate configuration variable.
* git-rev-list learned --children option to show child commits it
encountered during the traversal, instead of shoing parent commits.
* git-send-mail can talk not just over SSL but over TLS now.
* "git-stash save" learned --keep-index option. This lets you stash away the
local changes and bring the changes staged in the index to your working
tree for examination and testing.
* git-stash also learned branch subcommand to create a new branch out of
stashed changes.
* git-status gives the remote tracking statistics similar to the way
git-checkout reports by how many commits your branch is ahead/behind.
* You can tell "git status -u" to even more aggressively omit checking
untracked files with --untracked-files=no.
* Original SHA-1 value for "update-ref -d" is optional now.
* Error codes from gitweb are made more descriptive where possible, rather
than "403 forbidden" as we used to issue everywhere.
(internal)
Fixes since v1.5.6
------------------
All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.
* "git fetch" into an empty repository used to remind the fetch will
be huge by saying "no common commits", but it is already known by
the user anyway (need to backport 8cb560f to 'maint').
---
exec >/var/tmp/1
O=v1.5.6.3-315-g10ce020
echo O=$(git describe refs/heads/master)
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
^ permalink raw reply
* Re: [PATCH] Allow add_path() to add non-existent directories to the path
From: Johannes Sixt @ 2008-07-14 7:13 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, msysGit
In-Reply-To: <1215981083-10815-6-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt schrieb:
> +static const char *get_pwd_cwd(void)
> +{
> + static char cwd[PATH_MAX + 1];
> + char *pwd;
> + struct stat cwd_stat, pwd_stat;
> + if (getcwd(cwd, PATH_MAX) == NULL)
> + return NULL;
> + pwd = getenv("PWD");
> + if (pwd && strcmp(pwd, cwd)) {
> + stat(cwd, &cwd_stat);
> + if (!stat(pwd, &pwd_stat) &&
> + pwd_stat.st_dev == cwd_stat.st_dev &&
> + pwd_stat.st_ino == cwd_stat.st_ino) {
> + strlcpy(cwd, pwd, PATH_MAX);
git-bash users on Windows, please test this patch. The problem is that
with our custom stat implementation st_dev and st_ino are not reliable. It
works in my setup because $PWD is not set and this branch is never
entered, but with bash it makes a difference.
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/4] Proposed patches
From: Karl Hasselström @ 2008-07-14 7:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080713113853.18845.37686.stgit@localhost.localdomain>
On 2008-07-13 12:40:17 +0100, Catalin Marinas wrote:
> A new post of the proposed patches after implementing Karl's
> comments.
Looks good -- except for the places where I posted some more comments.
;-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 3/4] Convert git_id() to the new id format
From: Karl Hasselström @ 2008-07-14 7:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080713114047.18845.34899.stgit@localhost.localdomain>
On 2008-07-13 12:40:48 +0100, Catalin Marinas wrote:
> @@ -67,8 +64,8 @@ def func(parser, options, args):
> rev = strip_suffix('/', rev)
> if rev.endswith('/'):
> rev = strip_suffix('/', rev)
> - rev1 = rev + '//bottom'
> - rev2 = rev + '//top'
> + rev1 = rev + 'HEAD^'
> + rev2 = rev + 'HEAD'
This looks bogus. You probably want to s/HEAD// here.
I guess the test suite doesn't cover this? :-(
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/4] Implement a new patch identification scheme and id command
From: Karl Hasselström @ 2008-07-14 6:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080713114035.18845.45056.stgit@localhost.localdomain>
On 2008-07-13 12:40:35 +0100, Catalin Marinas wrote:
> The new scheme allows '[<branch>:]<patch>' and '[<branch>:]{base}'
> (the latter showing the base of a stack). The former format allows
> symbols like ^ and ^{...}.
You changed it, so s/The former format allows/You may append/ or
something.
> + # The stack base
> + if patch.startswith('{base}'):
> + base_id = repository.get_stack(branch).base.sha1
> + return repository.rev_parse(base_id + patch[6:])
We have a strip_prefix() function precisely so that we can avoid
error-prone and not-so-easy-to-read constants like that "6" ...
Hmm. I see that I feel strongly enough about this that I've defined no
less than two identical functions in utils.py to do this job:
strip_prefix() and strip_leading(). :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Sixt @ 2008-07-14 6:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <alpine.DEB.1.00.0807132141130.8950@racer>
Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> > ### Installation rules
> >
> > ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for? Did the original line stop working?
I could just have changed $(gitexecdir) to $(bindir), but in the
make-execpath-relative patch we will need the normalized gitexec_instdir
because its value is compared to $(bindir). So the extra $(shell...) in
_this_ patch is only that the final result looks consistent.
> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 8899e31..45f92eb 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -5,6 +5,7 @@
> >
> > extern char **environ;
> > static const char *argv_exec_path;
> > +static const char *argv0_path;
> >
> > static const char *builtin_exec_path(void)
> > {
> > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
> >
> > const char *system_path(const char *path)
> > {
> > - if (!is_absolute_path(path)) {
> > + if (!is_absolute_path(path) && argv0_path) {
> > struct strbuf d = STRBUF_INIT;
> > - strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> > + strbuf_addf(&d, "%s/%s", argv0_path, path);
> > path = strbuf_detach(&d, NULL);
> > }
> > return path;
> > }
> >
> > +void git_set_argv0_path(const char *path)
> > +{
> > + argv0_path = path;
> > +}
> > +
> > void git_set_argv_exec_path(const char *exec_path)
> > {
> > argv_exec_path = exec_path;
> > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> *path)
> > }
> > }
> >
> > -void setup_path(const char *cmd_path)
> > +void setup_path(void)
>
> It seems to me that this patch would not do anything different, but with
> less code change, if setup_path() would set argv0_path, and not a new
> function was introduced.
This is just to play a safe game. I had it that way, but I decided to have
the call to the new git_set_argv0_path() early in git.c because the call
to setup_path() in git.c is very late, and it could happen that we call
system_path() (which needs argv0_path) before that. Although I didn't audit
the code whether this really happens.
-- Hannes
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Björn Steinbrink @ 2008-07-14 6:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714064719.GA26446@atjola.homenet>
On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:
> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > > >
> > > > > Does it fix this one too:
> > > > >
> > > > > git show origin/pu:Makef<tab>
> > > > >
> > > > > which totally screws up and becomes
> > > > >
> > > > > git show Makefile
> > > > >
> > > > > dropping the version specifier?
> >
> > What is $COMP_WORDBREAKS set to in your shell? In mine it
> > appears to be:
> >
> > " \"'@><=;|&(:"
> >
> > which is the I believe the shell default.
> >
> > Björn Steinbrink (doener on #git) is running bash 3.2.39 from
> > Debian and has the same setting, and the completion works correctly
> > there too. He reports that removing : from COMP_WORDBREAKS will
> > get the behavior you are reporting as broken.
> >
> > I have to say, this sounds to me like you (or some package on your
> > system) modified COMP_WORDBREAKS away from the default that other
> > distributions use and that is what is breaking us here. Since we
> > can have only one setting for this variable in the shell I do not
> > thing it would be a good idea for our completion package to force
> > a specific setting upon the user.
>
> Seems that gvfs comes with a completion script that deliberately drops
> the : from COMP_WORDBREAKS. Do you have that installed Linus?
Ah crap, I should have mentioned which file I'm talking about... It's
/etc/profile.d/gvfs-bash-completion.sh
Björn, getting some coffee now
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Björn Steinbrink @ 2008-07-14 6:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714062755.GA15992@spearce.org>
On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > >
> > > > Does it fix this one too:
> > > >
> > > > git show origin/pu:Makef<tab>
> > > >
> > > > which totally screws up and becomes
> > > >
> > > > git show Makefile
> > > >
> > > > dropping the version specifier?
>
> What is $COMP_WORDBREAKS set to in your shell? In mine it
> appears to be:
>
> " \"'@><=;|&(:"
>
> which is the I believe the shell default.
>
> Björn Steinbrink (doener on #git) is running bash 3.2.39 from
> Debian and has the same setting, and the completion works correctly
> there too. He reports that removing : from COMP_WORDBREAKS will
> get the behavior you are reporting as broken.
>
> I have to say, this sounds to me like you (or some package on your
> system) modified COMP_WORDBREAKS away from the default that other
> distributions use and that is what is breaking us here. Since we
> can have only one setting for this variable in the shell I do not
> thing it would be a good idea for our completion package to force
> a specific setting upon the user.
Seems that gvfs comes with a completion script that deliberately drops
the : from COMP_WORDBREAKS. Do you have that installed Linus?
Björn
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-14 6:45 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <7vtzetjbif.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
> - gitweb: use new Git::Repo API, and add optional caching
> - Add new Git::Repo API
> - gitweb: add test suite with Test::WWW::Mechanize::CGI
>
> This does not pass t9710, at least for me X-<.
This is getting a bit boring and tiresome. Obviously I haven't checked
what _else_ is missing because I did not install Carp::Always myself to my
system.
t/t9710-perl-git-repo.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9710-perl-git-repo.sh b/t/t9710-perl-git-repo.sh
index ca67b87..2da3cd8 100755
--- a/t/t9710-perl-git-repo.sh
+++ b/t/t9710-perl-git-repo.sh
@@ -6,8 +6,8 @@
test_description='perl interface (Git/*.pm)'
. ./test-lib.sh
-perl -MTest::More -e 0 2>/dev/null || {
- say_color skip "Perl Test::More unavailable, skipping test"
+perl -MTest::More -MTest::Exception -MCarp::Always -e 0 2>/dev/null || {
+ say_color skip "Perl Test::{More,Exception}, Carp::Always unavailable, skipping test"
test_done
}
^ permalink raw reply related
* Re: [StGIT PATCH 3/4] Convert git_id() to the new id format
From: Karl Hasselström @ 2008-07-14 6:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807130420v37e36f30sef8b7745fa55b688@mail.gmail.com>
On 2008-07-13 12:20:25 +0100, Catalin Marinas wrote:
> 2008/6/22 Karl Hasselström <kha@treskal.com>:
>
> > Very nice parameter rename here, now that we have Branch objects
> > (and use a crappy language with no type system).
>
> It has a type system but no compile-time checking
Yeah, that's what I meant.
> (I'm more in favour of static typing but no time to rewrite stgit
> :-)).
Me too.
> > The corresponding TODO comment now would be that pick should be
> > able to pick patches from the past, from the stack log.
>
> How would the syntax look like?
We'd want to support <committish>:patch, for any committish that's a
stack log (either simplified or full). Not sure if we'd want a more
pretty-looking format as well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 2/2] Reuse the same temp index in a transaction
From: Karl Hasselström @ 2008-07-14 6:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807120324l7674c010w9a8e4a0bbdeeee65@mail.gmail.com>
On 2008-07-12 11:24:24 +0100, Catalin Marinas wrote:
> 2008/7/2 Karl Hasselström <kha@treskal.com>:
>
> > Instead of making a new temp index every time we need one, just
> > keep reusing the same one. And keep track of which tree is
> > currently stored in it -- if we do several consecutive successful
> > pushes, it's always going to be the "right" tree so that we don't
> > have to call read-tree before each patch application.
> >
> > The motivation behind this change is of course that it makes
> > things faster.
> >
> > (The same simple test as in the previous patch -- pushing 250
> > patches in a 32k-file repository, with one file-level merge
> > necessary per push -- went from 0.36 to 0.19 seconds per patch
> > with this patch applied.)
>
> That's an impressive improvement (together with the previous patch).
> Is this with the new patch log infrastructure?
Yes, with all the bells and whistles -- in particular, with the
overhead of the simplified log. (But note that it's a synthetic
benchmark, and not a real linux-kernel patch series.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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