* Re: [PATCH] gitweb: merge boolean feature subroutines
From: Matt Kraai @ 2009-01-03 16:40 UTC (permalink / raw)
To: demerphq; +Cc: git
In-Reply-To: <9b18b3110901030818i242d81ccl20ef3f264ec64cad@mail.gmail.com>
On Sat, Jan 03, 2009 at 05:18:44PM +0100, demerphq wrote:
> 2009/1/3 Matt Kraai <kraai@ftbfs.org>:
> [...]
> > -sub feature_blame {
> > - my ($val) = git_get_project_config('blame', '--bool');
> > +sub feature_bool {
> > + my $key = shift;
> > + my ($val) = git_get_project_config($key, '--bool');
> >
> > if ($val eq 'true') {
> > return 1;
>
> Maybe that should be:
>
> return ($val eq 'true');
>
> as It is not a good idea to use 0 as a replacement for perls false, as
> the two have different behaviour.
>
> $perl -wle'my $val=shift; my $x=$val eq "true"; print "<$_>" for $x, 0+$x' false
> <>
> <0>
I don't think Perl has *a* false value, but rather has multiple values
that are treated as false, such as undef, zero, and the empty string.
Personally, I find 0 clearer than the empty string, but that's
probably just my C bias sneaking in.
All of the boolean feature values use 0 or 1, so if this should be
changed, I think it should probably be done as a separate patch.
--
Matt http://ftbfs.org/
^ permalink raw reply
* Bazaar's patience diff as GIT_EXTERNAL_DIFF
From: Adeodato Simó @ 2009-01-03 16:24 UTC (permalink / raw)
To: Jeff King; +Cc: Git ML
In-Reply-To: <20090102193904.GB9129@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
* Jeff King [Fri, 02 Jan 2009 14:39:04 -0500]:
> If you just want to see the results on some real-world cases (and don't
> care about measuring performance), try installing bzr and using their
> patiencediff test program as a GIT_EXTERNAL_DIFF.
> On Debian, it's:
> $ sudo apt-get install bzr
> $ cat >$HOME/patience <<'EOF'
> #!/bin/sh
> exec python /usr/share/pyshared/bzrlib/patiencediff.py "$2" "$5"
> EOF
> $ chmod 755 patience
> $ GIT_EXTERNAL_DIFF=$HOME/patience git diff
In case somebody's interested, I have this script lying around that does
that, and knows how to colorize the output using bzrtools, and honoring
color.{diff,ui}. No support for color.diff.<slot>, though.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- Oh my God, you're pimping me out for a new roof?
- And windows!
-- Andrew and Bree Van De Kamp
[-- Attachment #2: git_bzr_patience_diff --]
[-- Type: text/plain, Size: 1457 bytes --]
#! /usr/bin/python
import os
import sys
import stat
import subprocess
from bzrlib.patiencediff import unified_diff, PatienceSequenceMatcher
try:
from bzrlib.plugins.bzrtools.colordiff import DiffWriter
except ImportError:
_have_colordiff = False
else:
_have_colordiff = True
##
def main():
path = sys.argv[1]
file1 = open(sys.argv[2], 'rb')
file2 = open(sys.argv[5], 'rb')
if use_color():
writer = DiffWriter(sys.stdout, check_style=True)
else:
writer = sys.stdout
for line in unified_diff(
file1.readlines(), file2.readlines(),
path, path, sequencematcher=PatienceSequenceMatcher):
writer.write(line)
##
def use_color():
if not _have_colordiff:
return False
for c in ['color.diff', 'color.ui']:
p = subprocess.Popen(
['git', 'config', '--get', c], stdout=subprocess.PIPE)
if p.wait() == 0:
when = p.stdout.readline().strip()
break
else:
return False
if when == 'always':
return True
elif when in ['false', 'never']:
return False
elif when in ['true', 'auto']:
stdout = sys.stdout.fileno()
return (os.isatty(stdout) or
stat.S_ISFIFO(os.fstat(sys.stdout.fileno()).st_mode))
else:
return False
##
if __name__ == '__main__':
sys.exit(main())
^ permalink raw reply
* Re: [PATCH] gitweb: merge boolean feature subroutines
From: demerphq @ 2009-01-03 16:18 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1230996692-7182-1-git-send-email-kraai@ftbfs.org>
2009/1/3 Matt Kraai <kraai@ftbfs.org>:
[...]
> -sub feature_blame {
> - my ($val) = git_get_project_config('blame', '--bool');
> +sub feature_bool {
> + my $key = shift;
> + my ($val) = git_get_project_config($key, '--bool');
>
> if ($val eq 'true') {
> return 1;
Maybe that should be:
return ($val eq 'true');
as It is not a good idea to use 0 as a replacement for perls false, as
the two have different behaviour.
$perl -wle'my $val=shift; my $x=$val eq "true"; print "<$_>" for $x, 0+$x' false
<>
<0>
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] gitweb: merge boolean feature subroutines
From: Matt Kraai @ 2009-01-03 15:31 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 35 ++++++-----------------------------
1 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 99f71b4..4ba2a9b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -203,7 +203,7 @@ our %feature = (
# $feature{'blame'}{'override'} = 1;
# and in project config gitweb.blame = 0|1;
'blame' => {
- 'sub' => \&feature_blame,
+ 'sub' => sub { feature_bool('blame', @_) },
'override' => 0,
'default' => [0]},
@@ -241,7 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
- 'sub' => \&feature_grep,
+ 'sub' => sub { feature_bool('grep', @_) },
'override' => 0,
'default' => [1]},
@@ -255,7 +255,7 @@ our %feature = (
# $feature{'pickaxe'}{'override'} = 1;
# and in project config gitweb.pickaxe = 0|1;
'pickaxe' => {
- 'sub' => \&feature_pickaxe,
+ 'sub' => sub { feature_bool('pickaxe', @_) },
'override' => 0,
'default' => [1]},
@@ -363,8 +363,9 @@ sub gitweb_check_feature {
}
-sub feature_blame {
- my ($val) = git_get_project_config('blame', '--bool');
+sub feature_bool {
+ my $key = shift;
+ my ($val) = git_get_project_config($key, '--bool');
if ($val eq 'true') {
return 1;
@@ -387,30 +388,6 @@ sub feature_snapshot {
return @fmts;
}
-sub feature_grep {
- my ($val) = git_get_project_config('grep', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
-sub feature_pickaxe {
- my ($val) = git_get_project_config('pickaxe', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: pass the key to the feature subroutines
From: Matt Kraai @ 2009-01-03 15:31 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
In-Reply-To: <1230996692-7182-1-git-send-email-kraai@ftbfs.org>
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4ba2a9b..2edefda 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -203,7 +203,7 @@ our %feature = (
# $feature{'blame'}{'override'} = 1;
# and in project config gitweb.blame = 0|1;
'blame' => {
- 'sub' => sub { feature_bool('blame', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [0]},
@@ -241,7 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
- 'sub' => sub { feature_bool('grep', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [1]},
@@ -255,7 +255,7 @@ our %feature = (
# $feature{'pickaxe'}{'override'} = 1;
# and in project config gitweb.pickaxe = 0|1;
'pickaxe' => {
- 'sub' => sub { feature_bool('pickaxe', @_) },
+ 'sub' => \&feature_bool,
'override' => 0,
'default' => [1]},
@@ -344,7 +344,7 @@ sub gitweb_get_feature {
warn "feature $name is not overrideable";
return @defaults;
}
- return $sub->(@defaults);
+ return $sub->($name, @defaults);
}
# A wrapper to check if a given feature is enabled.
@@ -377,9 +377,9 @@ sub feature_bool {
}
sub feature_snapshot {
- my (@fmts) = @_;
+ my ($key, @fmts) = @_;
- my ($val) = git_get_project_config('snapshot');
+ my ($val) = git_get_project_config($key);
if ($val) {
@fmts = ($val eq 'none' ? () : split /\s*[,\s]\s*/, $val);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 2/3] unpack-trees: fix path search bug in verify_absent
From: Miklos Vajna @ 2009-01-03 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Clemens Buchacher, git, gitster
In-Reply-To: <alpine.DEB.1.00.0901022244240.27818@racer>
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
On Fri, Jan 02, 2009 at 10:59:43PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Just for the record, this patch fixes the testcase Miklos reported
> earlier.
Indeed, thanks for the notice.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] gitweb: Document that gitweb deals with bare repositories
From: Jakub Narebski @ 2009-01-03 13:23 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <200901012351.28864.jnareb@gmail.com>
Add reminders to gitweb/README and gitweb/INSTALL that gitweb works
with bare repositories. While it might be obvious to us, it is not
apparently as evident for newcomers.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
On Thu, 1 Jan 2009, Jakub Narebski wrote:
> The longer explanation (which probably should made into gitweb/README
> or gitweb/INSTALL) is that gitweb is meant to deal with _bare_
> repositories; gitweb doesn't touch and doesn't examine working area
> of "live" (non-bare) repository. If you host git repositories (like
> kernel.org, freedesktop.org or repo.or.cz) you usually host them bare
> (public repositories should be bare); but you might want to have
> gitweb for your own repository too.
And here it is.
By the way, I was wondering if to mark this patch as an RFC, because
I am not completely sure about the wording I used...
gitweb/INSTALL | 14 ++++++++++++++
gitweb/README | 12 +++++++-----
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 18c9ce3..f43e233 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -127,6 +127,20 @@ GITWEB_CONFIG file:
Gitweb repositories
-------------------
+- Gitweb deals with bare repositories, which means that gitweb scans for
+ (in the case where $projects_list is a directory to search for
+ repositories) or has to be provided with list of (in the case where
+ $projects_list is a text file) bare repositories, i.e. $GIT_DIR for
+ each repository. The consequence of that is the fact that if you use
+ gitweb to view non-bare repository named 'repo' then gitweb would show
+ (or would have to be provided with) 'repo/.git'.
+
+ If you want to view a buch of non-bare repositories in gitweb but want
+ them named 'repo.git' as is the standard for bare repositories, you
+ can as a workaround populare $projectroot / $project_list with
+ symbolic links to $GIT_DIR of each project you want to publish (have
+ shown) in gitweb.
+
- By default all git repositories under projectroot are visible and
available to gitweb. The list of projects is generated by default by
scanning the projectroot directory for git repositories (for object
diff --git a/gitweb/README b/gitweb/README
index 825162a..6dbfcd5 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -34,10 +34,11 @@ You can specify the following configuration variables when building GIT:
* GITWEB_LIST
Points to a directory to scan for projects (defaults to project root
if not set / if empty) or to a file with explicit listing of projects
- (together with projects' ownership). See "Generating projects list
- using gitweb" in INSTALL file for gitweb to find out how to generate
- such file from scan of a directory. [No default, which means use root
- directory for projects]
+ (together with projects' ownership). Note that gitweb deals with bare
+ repositories; it shows/uses $GIT_DIR for each repository. See also
+ "Generating projects list using gitweb" in INSTALL file for gitweb to
+ find out how to generate such file from scan of a directory.
+ [No default, which means use root directory for projects]
* GITWEB_EXPORT_OK
Show repository only if this file exists (in repository). Only
effective if this variable evaluates to true. [No default / Not set]
@@ -153,7 +154,8 @@ not include variables usually directly set during build):
Absolute filesystem path which will be prepended to project path;
the path to repository is $projectroot/$project. Set to
$GITWEB_PROJECTROOT during installation. This variable have to be
- set correctly for gitweb to find repositories.
+ set correctly for gitweb to find repositories. (Note that gitweb deals
+ with bare repositories.)
* $projects_list
Source of projects list, either directory to scan, or text file
with list of repositories (in the "<URI-encoded repository path> SP
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 2/3] unpack-trees: fix path search bug in verify_absent
From: Johannes Schindelin @ 2009-01-03 12:53 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, gitster
In-Reply-To: <20090103103904.GA4479@localhost>
Hi,
On Sat, 3 Jan 2009, Clemens Buchacher wrote:
> On Fri, Jan 02, 2009 at 10:59:47PM +0100, Johannes Schindelin wrote:
> > This explanation makes sense. However, this:
> >
> > > @@ -289,7 +289,8 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas
> > > return 0;
> > > }
> > >
> > > -static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)
> > > +static int unpack_callback(int n, unsigned long mask, unsigned long dirmask,
> > > + struct name_entry *names, struct traverse_info *info)
> > > {
> > > struct cache_entry *src[5] = { NULL, };
> > > struct unpack_trees_options *o = info->data;
> >
> > ... is distracting during review, and this:
> >
> > > @@ -517,22 +518,22 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
> > > namelen = strlen(ce->name);
> > > pos = index_name_pos(o->src_index, ce->name, namelen);
> > > if (0 <= pos)
> > > - return cnt; /* we have it as nondirectory */
> > > + return 0; /* we have it as nondirectory */
> > > pos = -pos - 1;
> > > for (i = pos; i < o->src_index->cache_nr; i++) {
> >
> > ... is not accounted for in the commit message. Intended or not, that is
> > the question.
>
> Those are trivial readability improvements in the context of the patch.
They are not trivial enough for me not to be puzzled. Reason enough to
explain in the commit message?
Ciao,
Dscho
^ permalink raw reply
* Re: git checkout does not warn about tags without corresponding commits
From: Henrik Austad @ 2009-01-03 12:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <7vr63k8vvf.fsf@gitster.siamese.dyndns.org>
On Saturday 03 January 2009 12:36:04 Junio C Hamano wrote:
> Henrik Austad <henrik@austad.us> writes:
> > On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
> >> Henrik Austad <henrik@austad.us> writes:
> >> > I recently tried to do a checkout of (what I thought was the first)
> >> > inux kernel in the linux git repo.
> >> >
> >> > git checkout -b 2.6.11 v2.6.11
> >>
> >> This should have barfed, and indeed I think it is a regression around
> >> v1.5.5. v1.5.4 and older git definitely fails to check out a tree
> >> object like that.
> >
> > You're right, I bisected it down to commit
> > 782c2d65c24066a5d83453efb52763bc34c10f81
>
> I am not surprised.
>
> That one discarded an implementation of "git checkout" in Bourne shell,
> with a complete reimplementation in C.
>
> I haven't looked at the code very closely, but I think this should fix
> it. Thorough reviewing (not just running the test suite) is much
> appreciated.
>
> -- >8 --
> Subject: git-checkout: do not allow switching to a tree-ish
>
> "git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
> rooted at the current HEAD, because in that case, the two structure fields
> used to see if the command was invoked without any argument (hence it
> needs to default to checking out the HEAD), were populated incorrectly.
>
> Upon seeing a command line argument that we took as a rev, we should store
> that string in new.name, even if that does not name a commit.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin-checkout.c | 2 +-
> t/t2011-checkout-invalid-head.sh | 4 ++++
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git c/builtin-checkout.c w/builtin-checkout.c
> index c2c0561..b5dd9c0 100644
> --- c/builtin-checkout.c
> +++ w/builtin-checkout.c
> @@ -681,8 +681,8 @@ int cmd_checkout(int argc, const char **argv, const
> char *prefix) argv++;
> argc--;
>
> + new.name = arg;
> if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> - new.name = arg;
> setup_branch_path(&new);
> if (resolve_ref(new.path, rev, 1, NULL))
> new.commit = lookup_commit_reference(rev);
this fixed my problem when i hacked this into master (git apply failed on the
patch, so I did a manual patch. Moving that line did the trick
Acked-by/Signed-off-by Henrik Austad <henrik@austad.us>
> diff --git c/t/t2011-checkout-invalid-head.sh
> w/t/t2011-checkout-invalid-head.sh index 764bb0a..798790d 100755
> --- c/t/t2011-checkout-invalid-head.sh
> +++ w/t/t2011-checkout-invalid-head.sh
> @@ -15,4 +15,8 @@ test_expect_success 'checkout master from invalid HEAD' '
> git checkout master --
> '
>
> +test_expect_success 'checkout should not start branch from a tree' '
> + test_must_fail git checkout -b newbranch master^{tree}
> +'
> +
> test_done
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-> henrik
^ permalink raw reply
* Re: "git reset --hard" == "git checkout HEAD" == "git reset --hard HEAD" ???
From: Sitaram Chamarty @ 2009-01-03 12:27 UTC (permalink / raw)
To: git
In-Reply-To: <7vprj4ae5y.fsf@gitster.siamese.dyndns.org>
On 2009-01-03, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>>>> It seems we have 2 ways to blow away work we haven't
>>>> checked in yet then right?
>>>
>>> Wrong.
>>
>> Strictly as asked, yes, but what if he adds a "-f" to the
>> middle command, making it "git checkout -f HEAD"? Wouldn't
>> that be the same as the others then?
>
> Yeah, but comparing reset and checkout misses a whole _dimension_ in the
> revision space continuum.
[snip]
> "checkout -f" and "reset --hard" work on different dimensions, and what
> they do intersect when (and only when) the <branch>/<commit> argument
> happen to be HEAD. "checkout -f <another>" and "reset --hard <another>"
> will do quite different things.
I teach git sometimes (internally) in my job. It seems to
me that people who don't like TMTOWTDI get stuck on this
"why are there 2 ways to do the same thing" aspect, even
after I explain all the *other* uses of the two commands to
show that they're actually quite different!
Your use of "dimension" and "degenerate case" gave me an
idea... most of my audience have decent math skills, so I
bet they get it if I say these are like two quite different
functions that just happen to intersect at x=0 :-)
Thank you very much!
^ permalink raw reply
* Re: git reset --hard <commit> superfluous?
From: Björn Steinbrink @ 2009-01-03 12:20 UTC (permalink / raw)
To: chris; +Cc: git
In-Reply-To: <20090103011319.GA24149@seberino.org>
On 2009.01.02 17:13:19 -0800, chris@seberino.org wrote:
> David
>
> git reset --hard <commit>
> "resets" the current branch head.
>
> Is this equivalent to deleting the branch
> and doing
>
> git branch <branch> <commit> ??
>
> So "git reset --hard" is syntactic sugar and 'unnecessary' right?
Deleting the branch also deletes the reflog, while using reset adds a
new entry to the reflog. So returning the branch head to its previous
state is pretty trivial if you used reset and might be pretty hard if
you deleted the branch. HEAD's reflog should probably have the right
entry as well, but chances are that it's hidden in a crapload of other
entries, especially if you rebase often.
Björn
^ permalink raw reply
* Re: git checkout does not warn about tags without corresponding commits
From: Junio C Hamano @ 2009-01-03 11:53 UTC (permalink / raw)
To: Henrik Austad; +Cc: git, Daniel Barkalow
In-Reply-To: <7vr63k8vvf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I haven't looked at the code very closely, but I think this should fix
> it. Thorough reviewing (not just running the test suite) is much
> appreciated.
Just for fun, this will apply to 782c2d6 (Build in checkout, 2008-02-07)
and seems to fix the issue ;-)
No, I am not going to issue a maintenance release for 1.5.5 just to
include this fix, even though I could. I do not think this is a grave
enough regression to warrant a backport beyond 1.6.0 series.
builtin-checkout.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git i/builtin-checkout.c w/builtin-checkout.c
index 59a0ef4..1d0de68 100644
--- i/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -435,6 +435,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argv++;
argc--;
} else if ((source_tree = parse_tree_indirect(rev))) {
+ new.name = arg;
argv++;
argc--;
}
^ permalink raw reply related
* Re: git checkout does not warn about tags without corresponding commits
From: Junio C Hamano @ 2009-01-03 11:36 UTC (permalink / raw)
To: Henrik Austad; +Cc: git, Daniel Barkalow
In-Reply-To: <200901031200.01883.henrik@austad.us>
Henrik Austad <henrik@austad.us> writes:
> On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
>> Henrik Austad <henrik@austad.us> writes:
>> > I recently tried to do a checkout of (what I thought was the first) inux
>> > kernel in the linux git repo.
>> >
>> > git checkout -b 2.6.11 v2.6.11
>>
>> This should have barfed, and indeed I think it is a regression around
>> v1.5.5. v1.5.4 and older git definitely fails to check out a tree object
>> like that.
>
> You're right, I bisected it down to commit
> 782c2d65c24066a5d83453efb52763bc34c10f81
I am not surprised.
That one discarded an implementation of "git checkout" in Bourne shell,
with a complete reimplementation in C.
I haven't looked at the code very closely, but I think this should fix
it. Thorough reviewing (not just running the test suite) is much
appreciated.
-- >8 --
Subject: git-checkout: do not allow switching to a tree-ish
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
rooted at the current HEAD, because in that case, the two structure fields
used to see if the command was invoked without any argument (hence it
needs to default to checking out the HEAD), were populated incorrectly.
Upon seeing a command line argument that we took as a rev, we should store
that string in new.name, even if that does not name a commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 2 +-
t/t2011-checkout-invalid-head.sh | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index c2c0561..b5dd9c0 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -681,8 +681,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argv++;
argc--;
+ new.name = arg;
if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
- new.name = arg;
setup_branch_path(&new);
if (resolve_ref(new.path, rev, 1, NULL))
new.commit = lookup_commit_reference(rev);
diff --git c/t/t2011-checkout-invalid-head.sh w/t/t2011-checkout-invalid-head.sh
index 764bb0a..798790d 100755
--- c/t/t2011-checkout-invalid-head.sh
+++ w/t/t2011-checkout-invalid-head.sh
@@ -15,4 +15,8 @@ test_expect_success 'checkout master from invalid HEAD' '
git checkout master --
'
+test_expect_success 'checkout should not start branch from a tree' '
+ test_must_fail git checkout -b newbranch master^{tree}
+'
+
test_done
^ permalink raw reply related
* Re: git checkout does not warn about tags without corresponding commits
From: Henrik Austad @ 2009-01-03 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wptcrhp.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
> Henrik Austad <henrik@austad.us> writes:
> > I recently tried to do a checkout of (what I thought was the first) inux
> > kernel in the linux git repo.
> >
> > git checkout -b 2.6.11 v2.6.11
>
> This should have barfed, and indeed I think it is a regression around
> v1.5.5. v1.5.4 and older git definitely fails to check out a tree object
> like that.
You're right, I bisected it down to commit
782c2d65c24066a5d83453efb52763bc34c10f81
It introduces quite a large change, adding checkout-builtin.c, which coud be
the cause I guess.
As of how to fix this (if a fix is desired) I have not yet any clue what so
ever :-)
I attached the bisect result (sorry if attachements are frowned upon, but my
email client tends to mutilate text-contents like that).
--
-> henrik
[-- Attachment #2: git_bisect_res.txt --]
[-- Type: text/plain, Size: 2270 bytes --]
782c2d65c24066a5d83453efb52763bc34c10f81 is first bad commit
commit 782c2d65c24066a5d83453efb52763bc34c10f81
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Thu Feb 7 11:40:23 2008 -0500
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 5cfadfd307d588a427e200576ba97a5227653a13 90c0dd8c43cd66008d29492bdfb6b21a17855a00 M Makefile
:000000 100644 0000000000000000000000000000000000000000 59a0ef4ec9770af6d031abe959adc587c9538a89 A builtin-checkout.c
:100644 100644 428160d0e48b2acf1ac54d6d73910fd93151ca22 25d91bbfb21ea3c1ea067b10f7ea033d3563936a M builtin.h
:040000 040000 098e84f3f9fc152debb0f92eb849127f460391d7 0860a331e5a98a88a143d32f371385e78a0121d8 M contrib
:100755 000000 5621c69d86062c7c75c0b8c2749d34efc78cafb4 0000000000000000000000000000000000000000 D git-checkout.sh
:100644 100644 114ea75eef55e2960ff111014a505c3eb678caae fc156863b0bbd7d264864c49c2529e47709abf4d M git.c
:040000 040000 49b19f06ce0395f99f5b9729a1e51b5fa7fd1875 4165e146453fa357ef5e76a9ad48e683301ae669 M t
^ permalink raw reply
* Re: [PATCH 2/3] unpack-trees: fix path search bug in verify_absent
From: Clemens Buchacher @ 2009-01-03 10:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901022248070.27818@racer>
On Fri, Jan 02, 2009 at 10:59:47PM +0100, Johannes Schindelin wrote:
> This explanation makes sense. However, this:
>
> > @@ -289,7 +289,8 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas
> > return 0;
> > }
> >
> > -static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)
> > +static int unpack_callback(int n, unsigned long mask, unsigned long dirmask,
> > + struct name_entry *names, struct traverse_info *info)
> > {
> > struct cache_entry *src[5] = { NULL, };
> > struct unpack_trees_options *o = info->data;
>
> ... is distracting during review, and this:
>
> > @@ -517,22 +518,22 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
> > namelen = strlen(ce->name);
> > pos = index_name_pos(o->src_index, ce->name, namelen);
> > if (0 <= pos)
> > - return cnt; /* we have it as nondirectory */
> > + return 0; /* we have it as nondirectory */
> > pos = -pos - 1;
> > for (i = pos; i < o->src_index->cache_nr; i++) {
>
> ... is not accounted for in the commit message. Intended or not, that is
> the question.
Those are trivial readability improvements in the context of the patch.
On Fri, Jan 02, 2009 at 10:59:43PM +0100, Johannes Schindelin wrote:
> Sign-off?
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
on all three patches.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2009-01-03 10:31 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200901030640.36426.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Le mardi 30 décembre 2008, Junio C Hamano a écrit :
>>
>> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
>> - bisect: add "--no-replace" option to bisect without using replace
>> refs
>> - rev-list: make it possible to disable replacing using "--no-
>> bisect-replace"
>> - bisect: use "--bisect-replace" options when checking merge bases
>> - merge-base: add "--bisect-replace" option to use fixed up revs
>> - commit: add "bisect_replace_all" prototype to "commit.h"
>> - rev-list: add "--bisect-replace" to list revisions with fixed up
>> history
>> - Documentation: add "git bisect replace" documentation
>> - bisect: add test cases for "git bisect replace"
>> - bisect: add "git bisect replace" subcommand
>>
>> I think a mechanism like this should be added to replace grafts,
>
> The problem with replacing grafts is that a graft can specify many parents
> for one commit while a ref associates only one object to a name.
Sorry, maybe I misunderstood your implementation. What I thought we
discussed during GitTogether was to write out the object name of the
replacement object in refs/replace/<sha1>.
When the caller asks read_sha1_file() for an object whose object name is
<sha1>, you see if there is refs/replace/<sha1> in the repository, and
read the ref to learn the object name of the object that replaces it. And
you return that as if it is the original object.
So if your commit cca1704897e7fdb182f68d4c48a437c5d7bc5203 looks like:
tree 7ccf394b2e80536442703e0013bf0dde86547e08
parent 3827210b91a7d363ea67bcf0b9c6ee1c91d2f3c5
author Johannes Schindelin <Johannes.Schindelin@gmx.de> 1230919672 +0100
committer Junio C Hamano <gitster@pobox.com> 1230931180 -0800
git wrapper: Make while loop more reader-friendly
...
and you would want to lie about its author (or add/subtract different
parent lines, or record a fixed-up tree, or whatever), you first prepare a
replacement commit object:
$ R=$(git cat-file commit cca17048 |
sed -e 's/Johannes /&E /' |
git hash-object -t commit --stdin -w)
$ git cat-file commit $R
tree 7ccf394b2e80536442703e0013bf0dde86547e08
parent 3827210b91a7d363ea67bcf0b9c6ee1c91d2f3c5
author Johannes E Schindelin <Johannes.Schindelin@gmx.de> 1230919672 +0100
committer Junio C Hamano <gitster@pobox.com> 1230931180 -0800
git wrapper: Make while loop more reader-friendly
...
and then tell git to replace the original object with this one:
$ git update-ref refs/replace/$(git rev-parse cca17048) $R
With such a layout, if your arrange the object reachability traverser
(e.g. fsck, pack-objects, bundle and prune) ignore refs/replace mechanism,
while everybody else pay attention to it, you will be able to safely
transfer the "graft" information via usual clone/fetch/push mechanism,
while making things like log, bisect and show just work, pretending as if
the commit cca17048 were made by JES and not by JS.
^ permalink raw reply
* Re: "git reset --hard" == "git checkout HEAD" == "git reset --hard HEAD" ???
From: Junio C Hamano @ 2009-01-03 10:15 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngltvrd.63u.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
>>> It seems we have 2 ways to blow away work we haven't
>>> checked in yet then right?
>>
>> Wrong.
>
> Strictly as asked, yes, but what if he adds a "-f" to the
> middle command, making it "git checkout -f HEAD"? Wouldn't
> that be the same as the others then?
Yeah, but comparing reset and checkout misses a whole _dimension_ in the
revision space continuum.
"git checkout <branch>" is primarily about checking out a different
branch, aka "switching branches".
When you switch branches, you generally do not want to lose your pending
changes, but would want to take them with you. A typical scenario is that
you start looking at one issue, you fiddle a few lines here and twiddle a
few lines there, and as you dig deeper, you realize that whatever the
final shape of the change you are going to make will be either (1) big
enough to deserve its own branch created anew, or (2) better done as an
extension to an existing branch. You realize that you are in the latter
situation by noticing that the modification you were making will be helped
by something you have implemented in the other branch but not yet
available in the current one (typically the latter is 'master').
In such a case, you will "git checkout <the-appropriate-topic>" to switch
to the branch, and you would want to take the change you already made to
your work tree files when you do so.
On the other hand, "git checkout -f <branch>" blows away your changes, but
it still _is_ about switching to a different branch.
Whether you use -f or not, you are allowed to ask to switch to the current
branch by (1) naming the branch explicitly, i.e. "git checkout -f master",
(2) using HEAD to mean the current one instead, or (3) omitting <branch>
altogether. But that is there merely for consistency and, even though
there may not make much sense to do so (because it is largely no-op except
that you would get the "you are ahead by N" notice), there is no strong
reason to forbid asking for a no-op.
For that reason, "git checkout -f HEAD" is "blow away my changes". But it
is merely a degenerated case of "switching to the current branch while
blowing away my changes."
"git reset --hard <commit>" is different. "reset" is primarily about
pointing the tip of the current branch to somewhere else. While "git
checkout <branch>" never changes what commit sits at the tip of any
branch, "git reset <commit>" modifies it for the current branch (--hard
variant matches the work tree files to the contents recorded by the
resetted-to commit while at it).
Again, you are allowed to ask to reset to the current HEAD by saying
"reset --hard HEAD". That is a degenerated case of "resetting the tip of
the current branch, while blowing away my changes". More general case
would be "reset --hard <some-commit>" and it won't just blow away your
changes (relative to the commit you started out with), but also blows away
the history leading to the commit the branch tip used to point at.
"checkout -f" and "reset --hard" work on different dimensions, and what
they do intersect when (and only when) the <branch>/<commit> argument
happen to be HEAD. "checkout -f <another>" and "reset --hard <another>"
will do quite different things.
^ permalink raw reply
* Re: git reset --hard <commit> superfluous?
From: Sitaram Chamarty @ 2009-01-03 6:34 UTC (permalink / raw)
To: git
In-Reply-To: <20090103011319.GA24149@seberino.org>
On 2009-01-03, chris@seberino.org <chris@seberino.org> wrote:
> git reset --hard <commit>
> "resets" the current branch head.
>
> Is this equivalent to deleting the branch
> and doing
>
> git branch <branch> <commit> ??
>
> So "git reset --hard" is syntactic sugar and 'unnecessary' right?
only if you don't have any local changes to the work tree or
the index :-)
If you do, however, the reset throws them away, while the
longer method tries to preserves them, to the point of not
letting you switch if there are too many changes.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Christian Couder @ 2009-01-03 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocyt1is2.fsf@gitster.siamese.dyndns.org>
Le mardi 30 décembre 2008, Junio C Hamano a écrit :
>
> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
> - bisect: add "--no-replace" option to bisect without using replace
> refs
> - rev-list: make it possible to disable replacing using "--no-
> bisect-replace"
> - bisect: use "--bisect-replace" options when checking merge bases
> - merge-base: add "--bisect-replace" option to use fixed up revs
> - commit: add "bisect_replace_all" prototype to "commit.h"
> - rev-list: add "--bisect-replace" to list revisions with fixed up
> history
> - Documentation: add "git bisect replace" documentation
> - bisect: add test cases for "git bisect replace"
> - bisect: add "git bisect replace" subcommand
>
> I think a mechanism like this should be added to replace grafts,
The problem with replacing grafts is that a graft can specify many parents
for one commit while a ref associates only one object to a name.
One way to overcome this could be to use many refs for each graft, for
example (in the packed ref format):
<1st parent sha1> refs/replace/grafts/<commit sha1>-<1st parent sha1>
<2nd parent sha1> refs/replace/grafts/<commit sha1>-<2nd parent sha1>
...
Another way would be to put all the parents in the ref name, for example:
<1st parent sha1> /refs/replace/grafts/<commit sha1>-<1st parent sha1>-<2nd
parent sha1>-<3rd parent sha1>
There is the same kind of problem to mark many "good" (and "skip") commits
when bisecting and we use something like the first solution above:
<1st good commit sha1> refs/bisect/good-<1st good commit sha1>
<2nd good commit sha1> refs/bisect/good-<2nd good commit sha1>
...
But I think the above solutions are not very clean and it might be better in
the long run to make it possible to associate more than one object to a
ref.
Am I missing something? Do you see another way?
Thanks and happy new year everybody,
Christian.
^ permalink raw reply
* Re: "git reset --hard" == "git checkout HEAD" == "git reset --hard HEAD" ???
From: Sitaram Chamarty @ 2009-01-03 6:02 UTC (permalink / raw)
To: git
In-Reply-To: <7v4p0hcp3w.fsf@gitster.siamese.dyndns.org>
On 2009-01-02, Junio C Hamano <gitster@pobox.com> wrote:
> chris@seberino.org writes:
>
>> Does "git reset --hard" == "git checkout HEAD" == "git reset --hard HEAD" ???
>
> No, but "reset --hard" without a commit-ish defaults to HEAD so the first
> one and the last one are equivalent.
>
>> It seems we have 2 ways to blow away work we haven't
>> checked in yet then right?
>
> Wrong.
Strictly as asked, yes, but what if he adds a "-f" to the
middle command, making it "git checkout -f HEAD"? Wouldn't
that be the same as the others then?
I always thought they were eqvt...
^ permalink raw reply
* [PATCH] fast-export: print usage when no options specified
From: Miklos Vajna @ 2009-01-03 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, jidanni, git
In-Reply-To: <87r63lus6k.fsf@jidanni.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I found that behaviour surprising as well when I saw it the first time.
git rev-list outputs some usage info in that case, git log just logs
HEAD. Given that unconditionally exporting HEAD with no arguments is
probably not something most users want, here is a patch to make the
behaviour like what git rev-list already has.
builtin-fast-export.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 8386338..e9ee2c7 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -497,6 +497,9 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)
OPT_END()
};
+ if (argc == 1)
+ usage_with_options (fast_export_usage, options);
+
/* we handle encodings */
git_config(git_default_config, NULL);
--
1.6.1
^ permalink raw reply related
* Re: how to track the history of a line in a file
From: david @ 2009-01-03 4:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901021554581.21567@asgard.lang.hm>
On Fri, 2 Jan 2009, david@lang.hm wrote:
> On Fri, 2 Jan 2009, david@lang.hm wrote:
>
>> On Fri, 2 Jan 2009, david@lang.hm wrote:
>>
>>> On Fri, 2 Jan 2009, Jeff King wrote:
>>>
>>>> The tricky thing here is what is "this line"? Using the line number
>>>> isn't right, since it will change based on other content coming in and
>>>> out of the file. You can keep drilling down by reblaming parent commits,
>>>> but remember that each time you do that you are manually looking at the
>>>> content and saying "Oh, this is the line I am still interested in." So I
>>>> a script would have to correlate the old version and new version of the
>>>> line and realize how to follow the "interesting" thing.
>>>>
>>>> In your case, I think you want to see any commit in Makefile which
>>>> changed a line with SUBLEVEL in it. Which is maybe easiest done as:
>>>>
>>>> git log -z -p Makefile |
>>>> perl -0ne 'print if /\n[+-]SUBLEVEL/' |
>>>> tr '\0' '\n'
>>>>
>>>> and is pretty fast. But obviously we're leveraging some content-specific
>>>> knowledge about what's in the Makefile.
>>>
>>> Ok, I hacked togeather a quick bash script to try this
>>>
>> <SNIP>
>>> the problem that this has is that line 3 of $COMMIT may not be line 3 of
>>> $COMMIT^, and if they aren't it ends up hunting down the wrong data
solving this problem was a bit more work than expected. I ended up
invoking git diff to do the step back and find what lines were replaced by
the one I care about.
this still can run into problems if the lines that are examined are not
unique (git blame only finds the first match)
#!/usr/bin/perl
# program to trace the history of a line through a git repository
#
# useage findlines pattern filespec
#
# finds all occurances of the pattern in the file and then uses git blame
# to find where those lines were introduced. It then takes a step back
and
# looks at what the line replaced (if anything) and does a git blame on
those
# lines as well
#
# written by David Lang and released under GPLv2
#
$target = shift @ARGV;
$file = shift @ARGV;
open($infile,"<$file");
$linecount=0;
# find all lines in the file that match the target pattern
# we have been provided. add them to a stack of items to research
while(<$infile>){
$linecount++;
if ($_ =~ /$target/) {
$items[++$#items]{line} = $linecount;
$items[$#items]{tree} = "HEAD";
chomp;
$items[$#items]{target} = $_;
}
}
# go through all the items and research them in turn
# (note that more items may be added to the list while inside this loop)
for ($i=0;$i<=$#items;$i++) {
# do a git blame to find where the lines came from
$result = `git blame -b -l -L "$items[$i]{line}",+1 -M $file
$items[$i]{tree}` ;
print "in ".$items[$i]{tree}." found:\n$result";
$commit=substr($result,0,40);
# if this is not the root commit,
# do a diff to find what lines may have been replaced by the line we
are looking for
if($commit ne " "){
$diff=`git diff -U0 $commit^..$commit $file`;
@lines=split("\n",$diff);
#strip the first four lines from the diff (as they just talk about the
file)
shift(@lines);
shift(@lines);
shift(@lines);
shift(@lines);
$match=0;
$hunk='';
# find what hunk of the diff introduced the lines we are looking for,
# add the lines that they replaced to the list of items to examine
foreach(@lines){
if ($_ =~ /^\@\@/ ) {
if ($match) {
process_hunk();
} else {
$hunk = '';
};
} else {
$hunk .= $_."\n";
if ($_ =~ /$items[$i]{target}/) {
$match = 1;
}
}
}
if ($match) {
process_hunk();
}
}
}
sub process_hunk(){
# find lines in the hunk of diff that are being replaced
foreach (split("\n",$hunk)){
if ($_ =~ /^-/ ){
# for now queue the line contents for further processing.
# this really should be the line number becouse otherwise
# git blame will use the first match it finds. since we are
# matching the entire line this is less of a problem than it could
be.
$items[++$#items]{line} = "/".substr($_,1)."/";
$items[$#items]{target} = substr($_,1);
$items[$#items]{tree} = "$commit^";
}
}
}
^ permalink raw reply
* git reset --hard <commit> superfluous?
From: chris @ 2009-01-03 1:13 UTC (permalink / raw)
To: git
David
git reset --hard <commit>
"resets" the current branch head.
Is this equivalent to deleting the branch
and doing
git branch <branch> <commit> ??
So "git reset --hard" is syntactic sugar and 'unnecessary' right?
cs
^ permalink raw reply
* Re: how to track the history of a line in a file
From: david @ 2009-01-03 2:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <200901030107.07228.trast@student.ethz.ch>
On Sat, 3 Jan 2009, Thomas Rast wrote:
> david@lang.hm wrote:
>> On Fri, 2 Jan 2009, Junio C Hamano wrote:
>>> You may find the --porcelain output format of git-blame useful to make
>>> your script safer and more robust.
>>
>> where is this output defined? I can look at it and understand it, but I
>> don't know what is guarenteeded to exist, what will be on a specific line,
>> and what may vanish on me.
>
> man git-blame | less -p PORCELAIN\ FORMAT
thanks,
am I missing something else or will git blame with a regex only return
info on the first line it matches?
David Lang
^ permalink raw reply
* git-fast-export bundle doc
From: jidanni @ 2009-01-03 0:52 UTC (permalink / raw)
To: git
Please improve git-fast-export.txt. It says
This program dumps the given revisions in a form suitable to be
piped into git-fast-import.
<revlist> isn't mentioned in the SYNOPSIS.
And there is no hyperlink to the git-fast-import man page, nor in SEE ALSO.)
You can use it as a human readable bundle replacement (see
git-bundle(1))
But I tried it and there are apparently a few steps not mentioned that
are needed after git-fast-import before you can actually see the files
again on the other side of the sneakernet.
I used --all, which is in EXAMPLES but not OPTIONS.
Else nothing happens and no error is caught:
$ git fast-export
$
Also the git-bundle man page should SEE ALSO git-fast-export and maybe
even git-fast-import, which itself makes no mention of git-fast-export.
^ 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