* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-22 18:55 UTC (permalink / raw)
To: Adam Brewster; +Cc: Daniel Cordero, git
In-Reply-To: <c376da900910220824g2948dc2sa1156bda59b49405@mail.gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> > > The offending config is:
> > > [svn-remote "svn"]
> > > url = http://svn.collab.net/repos/svn
> > > branches = /*:refs/remotes/*
> > >
> >
> > Reverting the left hand side of these two regexps from Adam's commit
> > seems to fix the problem.
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index eb4b75a..56af221 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1765,7 +1765,7 @@ sub read_all_remotes {
> > my $use_svm_props = eval { command_oneline(qw/config --bool
> > svn.useSvmProps/) };
> > $use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
> > - my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
> > + my $svn_refspec = qr{\s*(.*?)\s*:\s*(.+?)\s*};
> > foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
> > if (m!^(.+)\.fetch=$svn_refspec$!) {
> > my ($remote, $local_ref, $remote_ref) = ($1, $2,
> > $3);
> > @@ -1979,7 +1979,7 @@ sub find_ref {
> > my ($ref_id) = @_;
> > foreach (command(qw/config -l/)) {
> > next unless m!^svn-remote\.(.+)\.fetch=
> > - \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
> > + \s*(.*?)\s*:\s*(.+?)\s*$!x;
> > my ($repo_id, $path, $ref) = ($1, $2, $3);
> > if ($ref eq $ref_id) {
> > $path = '' if ($path =~ m#^\./?#);
> > ---
> >
> > I'm not sure why Adam decided the leading slash needed to be removed for
> > the git refspec. That said, the globbing/branching code still makes me
> > want to hide under a rock and I'm generally afraid to touch it.
> > I'll wait for Adam to chime in since he's braver than I am :)
> >
> >
> How's this for brave: I'm not sure why I did that either.
>
> Looking at it again it seems correct for the leading / to be ignored because
> it has no meaning. What's the difference between the above config and
> "branches = *:refs/remotes/*" (besides the fact that one works and one
> doesn't)? In both cases I think I've asked for all of the top-level
> directories to be branches. But that has nothing to do with the rest of the
> patch, so it shouldn't have been included.
>
> Given all of that I would be more inclined to fix this with something like
> the following:
>
> diff --git a/git-svn.perl b/git-svn.perl
> index eb4b75a..cd8a93b 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1768,7 +1768,7 @@ sub read_all_remotes {
> my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
> foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
> if (m!^(.+)\.fetch=$svn_refspec$!) {
> - my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
> + my ($remote, $local_ref, $remote_ref) = ($1, "/$2", $3);
> die("svn-remote.$remote: remote ref '$remote_ref' "
> . "must start with 'refs/'\n")
> unless $remote_ref =~ m{^refs/};
> @@ -1780,7 +1780,7 @@ sub read_all_remotes {
> $r->{$1}->{url} = $2;
> } elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
> my ($remote, $t, $local_ref, $remote_ref) =
> - ($1, $2, $3, $4);
> + ($1, $2, "/$3", $4);
> die("svn-remote.$remote: remote ref '$remote_ref' ($t) "
> . "must start with 'refs/'\n")
> unless $remote_ref =~ m{^refs/};
> @@ -1980,7 +1980,7 @@ sub find_ref {
> foreach (command(qw/config -l/)) {
> next unless m!^svn-remote\.(.+)\.fetch=
> \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
> - my ($repo_id, $path, $ref) = ($1, $2, $3);
> + my ($repo_id, $path, $ref) = ($1, "/$2", $3);
> if ($ref eq $ref_id) {
> $path = '' if ($path =~ m#^\./?#);
> return ($repo_id, $path);
> --
> 1.6.5.1.63.ga9d7.dirty
>
> That is, continue disregard the / on the actual input because it means
> nothing, and add a / in places where the code will crash if it's not there.
> Even better would be to find out _why_ $path and $local_ref need a leading /
> and fix it that way, but that's more work that I don't have time for right
> now.
Thanks for the feedback Adam,
Yeah, I'm confused by that myself :x /me kicks himself again
> On the other hand it doesn't really matter because git svn init won't accept
> -b '' (to create the configuration I proposed above), so I have no practical
> objection to Eric's solution.
Meanwhile, your patch looks good to me. Let me know if you want write
a commit message for it or if you want me to do it.
I actually tried editing my $GIT_CONFIG in $EDITOR to have a bare '*' as
the ref glob:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = *:refs/remotes/*
Since I've tried it, I suspect others may try editing $GIT_CONFIG in the
same way as well.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Stephen Boyd @ 2009-10-22 18:50 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87iqe7zspn.fsf@jondo.cante.net>
Jari Aalto wrote:
> +--stat::
> +-n::
> +--no-stat::
> + Show a diffstat at the end of the merge. The diffstat is also
> + controlled by the configuration option merge.stat.
> +
> + With -n or --no-stat do not show a diffstat at the end of the
> + merge.
I thought we needed a plus before new paragraphs in these situations?
^ permalink raw reply
* Re: [msysGit] [PATCH v5 7/8] mingw: enable OpenSSL
From: Johannes Sixt @ 2009-10-22 18:38 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, Erik Faye-Lund
In-Reply-To: <1256144691-2908-8-git-send-email-kusmabite@gmail.com>
On Mittwoch, 21. Oktober 2009, Erik Faye-Lund wrote:
> Since we have OpenSSL in msysgit now, enable it to support SSL
> encryption for imap-send.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Sixt @ 2009-10-22 18:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: msysgit, Erik Faye-Lund, git, Erik Faye-Lund, Junio C Hamano,
Marius Storm-Olsen
In-Reply-To: <200910222011.02737.j6t@kdbg.org>
Since NO_OPENSSL is no longer defined on Windows, BLK_SHA1 is not defined
anymore implicitly. Define it explicitly.
As a nice side-effect, we no longer link against libcrypto.dll, which has
non-trivial startup costs because it depends on 6 otherwise unneeded
DLLs.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
On Donnerstag, 22. Oktober 2009, Johannes Sixt wrote:
> ... and I have one more patch to be applied on top of the series.
Here it is. I haven't tested the MSVC aspect of the patch. I would
appreciate feedback in this regard.
-- Hannes
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 5403fad..f666d2f 100644
--- a/Makefile
+++ b/Makefile
@@ -911,6 +911,7 @@ ifdef MSVC
NO_REGEX = YesPlease
NO_CURL = YesPlease
NO_PTHREADS = YesPlease
+ BLK_SHA1 = YesPlease
CC = compat/vcbuild/scripts/clink.pl
AR = compat/vcbuild/scripts/lib.pl
@@ -960,6 +961,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
UNRELIABLE_FSTAT = UnfortunatelyYes
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
+ BLK_SHA1 = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/fnmatch
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/fnmatch/fnmatch.o compat/winansi.o
--
1.6.5.rc3.70.gfc1aa
^ permalink raw reply related
* Re: [msysGit] Re: [PATCH v5 0/8] imap-send: Windows support
From: Johannes Sixt @ 2009-10-22 18:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.0910221942150.1263@felix-maschine>
On Donnerstag, 22. Oktober 2009, Johannes Schindelin wrote:
> If there are no objections, I will apply them tomorrow.
The series is already in pu (FYI), and I have one more patch to be applied on
top of the series.
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH v5 0/8] imap-send: Windows support
From: Johannes Schindelin @ 2009-10-22 17:42 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-1-git-send-email-kusmabite@gmail.com>
Hi,
On Wed, 21 Oct 2009, Erik Faye-Lund wrote:
> Here's the 5th iteration of my patches for Windows-compatibility in
> imap-send.
>
> - Patch 1-3 is about getting rid of or rewriting
> code with portability issues.
> - Patch 4 fixes a compilation error on Windows
> - Patch 5 enables compilation of imap-send
> - Patch 6-7 enables SSL-suport for mingw
> - Patch 8 enables imap-send and SSL for msvc
>
> The only change compared to the previous iteration
> is that patch 7 and 8 enables NEEDS_CRYPTO_WITH_SSL.
>
> Please note that I haven't tested Patch 8 with
> NEEDS_CRYPTO_WITH_SSL under MSVC, as I don't have a
> working setup with both msysgit and MSVC installed.
>
> I'd love it if someone with such a working setup
> could verify that it works, preferrably also with
> BLK_SHA1 enabled.
If there are no objections, I will apply them tomorrow.
Ciao,
Dscho
^ permalink raw reply
* remove broken refloc
From: Tobias Richter @ 2009-10-22 16:57 UTC (permalink / raw)
To: git
Hi,
>From using git-svn I've imported a (git-wise) broken reference. This isn't
a huge problem, as I don't need that ref anyway. But 'git gc' no longer
works and that results in frequent errors when updating:
$ git gc
error: cannot lock ref 'refs/remotes/release_7.5.'
error: failed to run reflog
As far as I understand I could expire that ref, but that fails as well:
$ git reflog expire --expire=0 --all
error: cannot lock ref 'refs/remotes/release_7.5.'
Is there a way to forcefully remove that broken ref?
Then I may be able to stop git-svn from re-importing that using the config,
I hope.
Thanks,
Tobias
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Sverre Rabbelier @ 2009-10-22 17:11 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git, Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <4AE0190E.8020803@gmail.com>
Heya,
On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> Junio C Hamano wrote:
>> * ks/precompute-completion (2009-10-05) 1 commit.
>> (merged to 'next' on 2009-10-14 at adf722a)
>> + Speedup bash completion loading
>>
>> Are people happy with this?
>
> No. I now have rebase.sh, am.sh, etc. in my completion
I would really like it if running 'make && make install' in git.git
would also build the completion script, I don't want to have to
remember to run 'cd contrib/completion && make' every time we get new
completion options :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git bisect Vs branch
From: Santi Béjar @ 2009-10-22 16:50 UTC (permalink / raw)
To: Grégory Romé; +Cc: git
In-Reply-To: <4AE07EEB.2010101@maxim-ic.com>
On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
> Considering the following story what is the method to find the regression
> with bisect?
>
> I cloned a git repository (origin) which derives from another one
> (first-origin). A merge is done from first-origin to origin at each stable
> release (identified by a tag).
>
> first-origin/master *---A---------B-----------------------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \ master
> ------------U'----------C''-
>
> Now, after that I merged C' I fixed the conflicts and compiled without error
> but I have a regression. It could come from any commit between B and C or U
> and C', and I need to modify my code to correct the issue.
>
> I would like to find the commit which introduce this regression by using git
> bisect but as the history is not linear it is not so easy (1). It though to
> create a linear history but I have no idea how to proceed...
You just have to proceed as normal, but you may test more commits than
with a linear history.
The only problem is iff the culprit is a merge commit (as in the
user-manual chapter you linked). And the "problem" is to know where
exactly in the (merge) commit is the bug, but not the procedure.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Alex Riesen @ 2009-10-22 16:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <f1e86b9095d63c6541d0a8df6a1cf8eadfe247bb.1256226187.git.trast@student.ethz.ch>
On Thu, Oct 22, 2009 at 17:44, Thomas Rast <trast@student.ethz.ch> wrote:
> @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> printf("%s\n", find_unique_abbrev(sha1, abbrev));
> return;
> }
> - die("cannot describe '%s'", sha1_to_hex(sha1));
> + if (unannotated_cnt)
> + die("cannot describe '%s'"
> + " with only\nannotated tags. Try --tags.",
> + sha1_to_hex(sha1));
> + else
> + die("cannot describe '%s'"
> + " with tags\nTry --always, or create some tags.",
> + sha1_to_hex(sha1));
These are quite verbose. Could they be conditional on something like
advice.describeHints?
^ permalink raw reply
* git bisect Vs branch
From: Grégory Romé @ 2009-10-22 15:48 UTC (permalink / raw)
To: git
Considering the following story what is the method to find the
regression with bisect?
I cloned a git repository (origin) which derives from another one
(first-origin). A merge is done from first-origin to origin at each
stable release (identified by a tag).
first-origin/master *---A---------B-----------------------C-
\ \ \
origin/master ----------B'----------U-----------C'-
\ \ \
master ------------U'----------C''-
Now, after that I merged C' I fixed the conflicts and compiled without
error but I have a regression. It could come from any commit between B
and C or U and C', and I need to modify my code to correct the issue.
I would like to find the commit which introduce this regression by using
git bisect but as the history is not linear it is not so easy (1). It
though to create a linear history but I have no idea how to proceed...
Thanks,
Grégory
(1)
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
^ permalink raw reply
* Proper attribution for modified files
From: alexandrul @ 2009-10-22 16:23 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have started from git-instaweb script and modified it
in order to support my custom setup. The original script
starts with:
#!/bin/sh
#
# Copyright (c) 2006 Eric Wong
#
What would be the proper attribution to place in my modified script
in order to make it available for public download?
Have a nice day,
A.
^ permalink raw reply
* [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-22 15:44 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220810n389d065di349339ab38909ef7@mail.gmail.com>
Users seem to call git-describe without reading the manpage, and then
wonder why it doesn't work with unannotated tags by default.
Make a minimal effort towards seeing if there would have been
unannotated tags, and tell the user. Specifically, we say that --tags
could work if we found any unannotated tags. If not, we say that
--always would have given results.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Eugene Sajine wrote:
> [git-describe fails if you don't have annotated tags]
>
> Thanks! It is working ok.
> Although it is probably not the best error handling.
> I believe git should fail with some meaningful message in this case...
We already had most of the information available, so hey, why not.
builtin-describe.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 2dcfd3d..1ffa0d8 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -96,8 +96,6 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
if (!all) {
if (!prio)
return 0;
- if (!tags && prio < 2)
- return 0;
}
add_to_known_names(all ? path + 5 : path + 10, commit, prio, sha1);
return 0;
@@ -184,6 +182,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ unsigned int unannotated_cnt = 0;
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -217,7 +216,9 @@ static void describe(const char *arg, int last_one)
seen_commits++;
n = c->util;
if (n) {
- if (match_cnt < max_candidates) {
+ if (!tags && !all && n->prio < 2) {
+ unannotated_cnt++;
+ } else if (match_cnt < max_candidates) {
struct possible_tag *t = &all_matches[match_cnt++];
t->name = n;
t->depth = seen_commits - 1;
@@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
printf("%s\n", find_unique_abbrev(sha1, abbrev));
return;
}
- die("cannot describe '%s'", sha1_to_hex(sha1));
+ if (unannotated_cnt)
+ die("cannot describe '%s'"
+ " with only\nannotated tags. Try --tags.",
+ sha1_to_hex(sha1));
+ else
+ die("cannot describe '%s'"
+ " with tags\nTry --always, or create some tags.",
+ sha1_to_hex(sha1));
}
qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
--
1.6.5.1.70.g1383ae
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johannes Schindelin @ 2009-10-22 15:33 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200910191125.19997.johan@herland.net>
Hi Johan,
On Mon, 19 Oct 2009, Johan Herland wrote:
> On Monday 19 October 2009, Junio C Hamano wrote:
> > * jh/notes (2009-10-09) 22 commits.
> > - fast-import: Proper notes tree manipulation using the notes API
> > - Refactor notes concatenation into a flexible interface for combining notes
> > - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> > - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> > - Notes API: get_note(): Return the note annotating the given object
> > - Notes API: add_note(): Add note objects to the internal notes tree structure
> > - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> > - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> > - Add selftests verifying concatenation of multiple notes for the same commit
> > - Refactor notes code to concatenate multiple notes annotating the same object
> > - Add selftests verifying that we can parse notes trees with various fanouts
> > - Teach the notes lookup code to parse notes trees with various fanout schemes
> > - Teach notes code to free its internal data structures on request
> > - Add '%N'-format for pretty-printing commit notes
> > - Add flags to get_commit_notes() to control the format of the note string
> > - t3302-notes-index-expensive: Speed up create_repo()
> > - fast-import: Add support for importing commit notes
> > - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> > - Add an expensive test for git-notes
> > - Speed up git notes lookup
> > - Add a script to edit/inspect notes
> > - Introduce commit notes
>
> > Is this good for 'next' now?
>
> Not all of it.
>
> I suspect the first 14 patches are stable and 'next'-worthy, although
> it would be nice if Dscho had the time to ACK them.
As you probably realized, I have little time for Git these days (mainly
due to work), so please do not wait for me.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: skillzero @ 2009-10-22 15:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, Git Mailing List
In-Reply-To: <fcaeb9bf0910220415v69c22ed9o4ab85b8858fbf187@mail.gmail.com>
On Thu, Oct 22, 2009 at 4:15 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> * nd/sparse (2009-08-20) 19 commits.
>>> - sparse checkout: inhibit empty worktree
>>> - Add tests for sparse checkout
>>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>>> - unpack-trees(): ignore worktree check outside checkout area
>>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>>> - unpack-trees.c: generalize verify_* functions
>>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>>> - Introduce "sparse checkout"
>>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>>> - excluded_1(): support exclude files in index
>>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>>> - Read .gitignore from index if it is skip-worktree
>>> - Avoid writing to buffer in add_excludes_from_file_1()
>>> - Teach Git to respect skip-worktree bit (writing part)
>>> - Teach Git to respect skip-worktree bit (reading part)
>>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>>> - Add test-index-version
>>> - update-index: refactor mark_valid() in preparation for new options
>>
>> Hmmm... what is happening with that series?
>
> Junio concerned about CE_MATCH_IGNORE_VALID being used by both
> assume-unchanged and skip-worktree bits, which I did not resolve yet.
> I should really get back to the series when I have time.
Just an FYI, but I've been using this series for a while. I'm actually
relying on sparse support in our internal build system (via my private
build with this series) so I hope it doesn't go away :) I haven't
really noticed any problems (I thought the index state got out of sync
once, but I couldn't reproduce the problem later). Here's some
feedback though:
1. I found it confusing to have to append '/' to directories in the
sparse pattern list for directories. I always forget it requires them.
It would be nice to support the same rules as .gitignore in terms of
'/'.
2. It would be nice to have built-in support for a sparse modules file
and switching between them. Maybe .gitmodules could support "module"
or "sparsemodule" sections to list the patterns for that sparse
module. I've written a simple script to do this and it's what I use.
It just parses the INI-style file:
[module "MyProject"]
App1
Shared1
!FolderIDontWant
Then I have a "module" script to read that file for a specified module
and switch to it:
git module switch MyProject
The script just parses `git show HEAD:.gitmodules` (so it works
without a working directory) and switches sparse modules by enabling
sparse, writing info/sparse-checkout, and doing a checkout:
sub cmd_switch
{
# Enable sparse.
my $currentCmd = "git config core.sparsecheckout true";
system( $currentCmd ) == 0 or die( "error: $currentCmd\n" );
# Write sparse patterns.
my $gitDir = `git rev-parse --git-dir`;
chop( $gitDir );
my $sparsePath = $gitDir . "/info/sparse-checkout";
if( $? != 0 ) { die( "error: read git directory failed $?\n" ); }
open( FILE, ">", $sparsePath ) or die( "error: can't open '$sparsePath'\n" );
foreach( @{$gModules->{$gModuleName}} )
{
print( FILE "$_\n" );
}
close( FILE );
# Checkout using new sparse patterns.
system( "git checkout" ) == 0 or die( "error: switch module failed\n" );
}
That said, the current level of sparse support provided by this series
is good enough for me because I can build my own scripts like this on
top of it to automate things.
^ permalink raw reply
* Re: git describe is failing
From: Eugene Sajine @ 2009-10-22 15:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910221702.39452.trast@student.ethz.ch>
> man git-describe:
>
> DESCRIPTION
> The command finds the most recent tag that is reachable from a
> commit.
> [...]
> By default (without --all or --tags) git describe only shows
> annotated tags. For more information about creating annotated
> tags see the -a and -s options to git-tag(1).
>
> If there is no such tag, it refuses to work. Annotate your tags, or
> try --always.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Thanks! It is working ok.
Although it is probably not the best error handling.
I believe git should fail with some meaningful message in this case...
Thanks,
Eugene
^ permalink raw reply
* Re: git describe is failing
From: Thomas Rast @ 2009-10-22 15:02 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
Eugene Sajine wrote:
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
man git-describe:
DESCRIPTION
The command finds the most recent tag that is reachable from a
commit.
[...]
By default (without --all or --tags) git describe only shows
annotated tags. For more information about creating annotated
tags see the -a and -s options to git-tag(1).
If there is no such tag, it refuses to work. Annotate your tags, or
try --always.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git describe is failing
From: Mikael Magnusson @ 2009-10-22 14:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
2009/10/22 Eugene Sajine <euguess@gmail.com>:
> Hi,
>
> I have a test repo which I'm playing with. It has about 15 commits and
> one branch only (master) and couple of tags. Somehow it got to a state
> when
>
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
>
> The command is working ok with my other repo. It doesn't seem that the
> test repo is corrupted. I can commit, push and pull, see the history
> with gitk... How can I check or repair it?
>
> Thanks,
> Eugene
Your tags are probably not annotated (lightweight tags), use git
describe --tags.
--
Mikael Magnusson
^ permalink raw reply
* git describe is failing
From: Eugene Sajine @ 2009-10-22 14:47 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
I have a test repo which I'm playing with. It has about 15 commits and
one branch only (master) and couple of tags. Somehow it got to a state
when
$ git describe
gives:
fatal: cannot describe 'SHA-1'
The command is working ok with my other repo. It doesn't seem that the
test repo is corrupted. I can commit, push and pull, see the history
with gitk... How can I check or repair it?
Thanks,
Eugene
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Daniel Barkalow @ 2009-10-22 14:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Shawn O. Pearce, Johan Herland, git
In-Reply-To: <20091022192149.6117@nanako3.lavabit.com>
On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
> Quoting "Shawn O. Pearce" <spearce@spearce.org>
>
> > Actually, after some further research, the bug is not Johan's but is
> > actually Daniel's. Johan, I apologize for claiming it was your bug.
> > ...
> > Long story short, transport_close() is what is supposed to perform
> > the work that disconnect_helper does, as its the final thing right
> > before we free the struct transport block. Free'ing the data block
> > inside of the fetch or push functions is wrong.
> >
> > Its fine to close the helper and restart it within the single
> > lifespan of a struct transport, but dammit, don't free the
> > struct helper_data until transport_close().
>
> Ping? Are there any progress on this issue?
Ah, right. Shawn's analysis is correct, and I should have a different
function to just finish the helper, but leave the rest of the data alone.
(when I wrote it originally, I didn't have anything other than the
connection in there, so it was right to clear it, but now there's a real
helper_data and it needs to do the right things).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Documentation/git-pull.txt: Add subtitles above included option files
From: Jari Aalto @ 2009-10-22 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-pull.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
>> checking where else this file is included. Then the patch certainly is
>> understandable. It would probably make git-fetch.{1,html} easier to scan,
>> while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
>
> OPTIONS
> -------
>
> Options related to merging <---- added
> ~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
> include::merge-options.txt[]
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7578623..51534dd 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -26,6 +26,10 @@ Also note that options meant for 'git-pull' itself and underlying
OPTIONS
-------
+
+Options related to merging
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::merge-options.txt[]
:git-pull: 1
@@ -47,6 +51,9 @@ unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
+Options related to fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jeff King @ 2009-10-22 11:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Jari Aalto, git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
On Thu, Oct 22, 2009 at 07:21:52PM +0900, Nanako Shiraishi wrote:
> > Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> > checking where else this file is included. Then the patch certainly is
> > understandable. It would probably make git-fetch.{1,html} easier to scan,
> > while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
Yes, that was my first thought when reading this thread, too (sorry, no
patch here, either. I need to sleep and then get on a plane).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Nguyen Thai Ngoc Duy @ 2009-10-22 11:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m3ljj3es02.fsf@localhost.localdomain>
On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> * nd/sparse (2009-08-20) 19 commits.
>> - sparse checkout: inhibit empty worktree
>> - Add tests for sparse checkout
>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>> - unpack-trees(): ignore worktree check outside checkout area
>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>> - unpack-trees.c: generalize verify_* functions
>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>> - Introduce "sparse checkout"
>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>> - excluded_1(): support exclude files in index
>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>> - Read .gitignore from index if it is skip-worktree
>> - Avoid writing to buffer in add_excludes_from_file_1()
>> - Teach Git to respect skip-worktree bit (writing part)
>> - Teach Git to respect skip-worktree bit (reading part)
>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>> - Add test-index-version
>> - update-index: refactor mark_valid() in preparation for new options
>
> Hmmm... what is happening with that series?
Junio concerned about CE_MATCH_IGNORE_VALID being used by both
assume-unchanged and skip-worktree bits, which I did not resolve yet.
I should really get back to the series when I have time.
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Can't we introduce subsections in the OPTIONS section to
group them together, like this (sorry, not a patch)?
OPTIONS
-------
Options related to merging <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::merge-options.txt[]
:git-pull: 1
--rebase::
Instead of a merge, perform a rebase after fetching. If
there is a remote ref for the upstream branch, and this branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes. To make this the default
for branch `<name>`, set configuration `branch.<name>.rebase`
to `true`.
+
[NOTE]
This is a potentially _dangerous_ mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
Options related to fetching <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Daniel Barkalow, Johan Herland, git
In-Reply-To: <20091015204543.GP10505@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>
> Actually, after some further research, the bug is not Johan's but is
> actually Daniel's. Johan, I apologize for claiming it was your bug.
> ...
> Long story short, transport_close() is what is supposed to perform
> the work that disconnect_helper does, as its the final thing right
> before we free the struct transport block. Free'ing the data block
> inside of the fetch or push functions is wrong.
>
> Its fine to close the helper and restart it within the single
> lifespan of a struct transport, but dammit, don't free the
> struct helper_data until transport_close().
Ping? Are there any progress on this issue?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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