* Re: [PATCH] Add testcase for merge.log
From: Miklos Vajna @ 2008-07-14 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1215678742-14042-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Thu, Jul 10, 2008 at 10:32:22AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Jul 10, 2008 at 12:50:59AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > The command forgot the configuration variable when rewritten in C.
>
> Thanks. Here is a testcase.
As far as I see this has been forgotten. Should I resend it on top of
current mv/merge-in-c?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-14 11:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080714085555.GJ32184@machine.or.cz>
Hi,
On Mon, 14 Jul 2008, Petr Baudis wrote:
> 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.
Can't we just hit Debian's Git maintainer with a clue bat or a bus,
whichever is easier, and force them to upgrade _in_ Etch? It's not like
we haven't had _several_ stable releases in-between.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix reduce_heads
From: Miklos Vajna @ 2008-07-14 11:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Hvammen Johansen, Junio C Hamano, git
In-Reply-To: <20080714114453.GL10347@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
On Mon, Jul 14, 2008 at 01:44:53PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> I'll go out tomorrow, so I can send that it today. Sorry for not sending
> a proper patch for the first time. ;-)
Ah, It's already in 'pu', so never mind.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Jakub Narebski @ 2008-07-14 11:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, git,
Stephan Hennig, Andreas Ericsson
In-Reply-To: <alpine.LSU.1.00.0807141216390.32392@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > The only other alternative I can come up with is to change pack-objects
> > (or at least its defaults) so we don't generate these massive delta
> > chains. But there are already packs in the wild that use these chains,
> > resulting in performance problems for clients.
>
> But the long chains make the pack actually as efficient as it is...
Perhaps Shawn thought here about limiting delta chain not by its
*length*, but by its *size* (as required when unpacking last object
in a delta chanin).
What do you think about this idea?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-14 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzetjbif.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 13 Jul 2008, Junio C Hamano wrote:
> * js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
> - Allow add_path() to add non-existent directories to the path
> - Allow the built-in exec path to be relative to the command
> invocation path
> - Fix relative built-in paths to be relative to the command
> invocation
> + help (Windows): Display HTML in default browser using Windows'
> shell API
> + help.c: Add support for htmldir relative to git_exec_path()
> + Move code interpreting path relative to exec-dir to new function
> system_path()
>
> The earlier parts are obvious; Dscho seemed to have some comments on the
> later ones that are in 'pu'.
Just one, and it seems that the next patch patched that ;-) Not really a
showstopper.
> * mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
> + reduce_heads(): thinkofix
Hmm. My earlier response to Sverre was based on an old "next", it seems.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix reduce_heads
From: Miklos Vajna @ 2008-07-14 11:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Hvammen Johansen, Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0807141128240.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Mon, Jul 14, 2008 at 11:30:24AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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?
I'll go out tomorrow, so I can send that it today. Sorry for not sending
a proper patch for the first time. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 11:44 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Junio C Hamano, git, Stephan Hennig,
Andreas Ericsson
In-Reply-To: <20080714031242.GA14542@spearce.org>
Hi,
On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Sun, 13 Jul 2008, Shawn O. Pearce wrote:
> >
> > > This should resolve the obscene memory usage of index-pack when
> > > resolving deltas for very large files.
> >
> > I don't like this. Not your patch, but rather the direction this whole
> > thing took in the first place, and now we have to bolt extra complexity
> > on top.
> >
> > I have the feeling this is not the best approach, especially since many
> > long delta chains are going deep and all those intermediate objects are
> > simply useless once the _only_ delta child has been resolved and
> > therefore could be freed right away instead.
>
> I thought about trying to free a base object if this is the last
> resolve_delta() call which would require that data, but I realized this
> is just a "tail-call optimization" and doesn't work in the more general
> case.
However, for cases like Stephan's I assume this is the rule. If you
think of it, most use cases for such a big blob are one-user,
append-only.
> The only other alternative I can come up with is to change pack-objects
> (or at least its defaults) so we don't generate these massive delta
> chains. But there are already packs in the wild that use these chains,
> resulting in performance problems for clients.
But the long chains make the pack actually as efficient as it is...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Sverre Rabbelier @ 2008-07-14 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807131929200.8950@racer>
On Sun, Jul 13, 2008 at 8:30 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 13 Jul 2008, Sverre Rabbelier wrote:
>> On Sun, Jul 13, 2008 at 3:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> > The data structure the revision traversal machinery uses does not support
>> > this "path-per-commit" natively.
>>
>> Would it be possible to go for a slightly less complicated approach
>> and instead of passing replacing the tracked file, append it?
>
> Maybe I miss something, but do you not have to keep track of the file
> names, in order to keep track of the proper statistics?
Hmm, no, this is just to get commits that touched a (set of) file(s).
I use it to limit the commits I have to check when searching for
reverts.
> If that is the case, appending does not cut it.
For the activity metric I think pretending that all files with the
same name or renamed versions of those would make sense, which is what
appending the new name would do. The downside is that all files with
the same name get grouped together, I'm not sure which is the lesser
of two evils. Leaving out information, or (possibly) including too
much.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/4] index-pack: Track the object_entry that creates each base_data
From: Johannes Schindelin @ 2008-07-14 10:15 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, git, Stephan Hennig, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <1216001267-33235-4-git-send-email-spearce@spearce.org>
Hi,
On Sun, 13 Jul 2008, Shawn O. Pearce wrote:
> This however means we must add the missing baes object to the end
> of our packfile prior to calling resolve_delta() on each of the
> dependent deltas. Adding the base first ensures we can read the
> base back from the pack we indexing, as if it had been included by
> the remote side.
s/baes/base/
Otherwise very clear.
Thanks,
Dscho
^ permalink raw reply
* 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
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