* Re: [PATCH] Print progress message to stderr, not stdout
From: Catalin Marinas @ 2006-12-05 9:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, Karl Hasselström, git
In-Reply-To: <Pine.LNX.4.63.0612050841160.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On 05/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 4 Dec 2006, Catalin Marinas wrote:
> > I'll first move the message back to stdout.
>
> In other parts of git, the progress message is only printed if output goes
> to a tty. Why not do the same?
Thanks for the hint. This seems to me like the easiest solution.
--
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Karl Hasselström @ 2006-12-05 9:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Catalin Marinas, Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0612050841160.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On 2006-12-05 08:41:57 +0100, Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Catalin Marinas wrote:
>
> > I'll first move the message back to stdout.
>
> In other parts of git, the progress message is only printed if
> output goes to a tty. Why not do the same?
That sounds like a good idea for two reasons:
1. It will address all concerns raised in this thread (I think).
2. It will remove an unnecessary difference between git and stgit.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [RFC/PATCH] git-reset to remove "$GIT_DIR/MERGE_MSG"
From: Johannes Schindelin @ 2006-12-05 9:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, ltuikov
In-Reply-To: <45752F8E.9020405@op5.se>
Hi,
On Tue, 5 Dec 2006, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> >
> > The only possible exception I can think of: git-reset --mixed when a merge
> > failed.
>
> Indeed, but any invocation of git-reset means you'll quite likely have
> to re-do the merge to get all changes anyways.
But the working directory still contains the changes (and conflicts) with
--mixed. A valid workflow would then be to compare to the index directly,
instead of having to ask "git diff --ours" all the time. And if I'm not
mistaken, a commit (after cleaning up the conflicts) would not record the
merge as a merge.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Uwe Kleine-Koenig @ 2006-12-05 9:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Martin Waitz, Andy Parkins, git
In-Reply-To: <456F29A2.1050205@op5.se>
Hello,
Andreas Ericsson wrote:
> The only problem I'm seeing atm is that the supermodule somehow has to
> mark whatever commits it's using from the submodule inside the submodule
> repo so that they effectively become un-prunable, otherwise the
> supermodule may some day find itself with a history that it can't restore.
One could circumvent that by creating a separate repo for the submodule
at checkout time and pull the needed objects in the supermodule's odb
when commiting the supermodule. This way prune in the submodule cannot
do any harm, because in it's odb are no objects that are important for
the supermodule.
Uwe
--
Uwe Kleine-Koenig
^ permalink raw reply
* Re: [PATCH] git-explain
From: Johannes Schindelin @ 2006-12-05 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7v1wnekh6a.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
> >> ...
> >> > [PATCH] git-explain
> >> > ...
> >>
> >> What about calling it git-whatsup instead?
> >
> > No, clearly it should be git-wtf.
>
> Should I take these responses to mean that you two are negative
> about the approach [...]
I think they just were in the mood for some slashdot style
unimportant-aspects-in-a-funny-way discussion.
> An issue with this approach is that this can be the beginning of
> hardwiring the official "right way of doing things" in the set
> of tools. Pursuing this approach would enhance the set of state
> markers like "FAILED_MERGE" in the example, which means:
>
> - more commands would actively record what they were attempting
> to do, obviously;
... which is a good thing.
> - over time "git explain" will learn about these state markers,
> and we would hardwire the "best current practice" exits from
> various states in the help messages;
... which is also a good thing.
> - also commands other than "git explain" would learn about the
> state markers of other commands, and change their behaviour.
> For example, "git am" might learn to refuse running while a
> merge in progress much earlier than with the current
> implementation.
If the other commands are outside of git, it will be a problem.
> The last point [git-am refusing to run during a merge] can easily become
> a double-edged sword.
This particular behaviour seems like a good thing, too!
> Hardwiring the recommended workflow in the tools would reduce chances of
> mistakes, but it could rob the flexibility from them if we are not
> careful and forget to take into account some useful combination of tools
> when adding such safety valves.
As has been the case not at all long ago, a saftey valve which no longer
made sense was just removed.
As for the inflexibility of a recommended workflow: by now, long-time
gitsters have had enough time to fiddle around with git and to develop a
workflow which Just Works. It is just a nice gesture of old-time users
towards new-time users to pass that knowledge. And new-time users are
often not in the least interested in learning the ropes the hard way.
Besides, the recommended workflow(s) can be changed/replaced by other
porcelainish commands, because only those will contain the safety valves,
right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
From: Eric Wong @ 2006-12-05 8:58 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20061205051738.16552.22494.stgit@localhost>
Sam Vilain <sam@vilain.net> wrote:
> From: Sam Vilain <sam@vilain.net>
>
> If an SVN revision has a property, "svm:headrev", it is likely that
> the revision was created by "svk sync". The property contains a
> repository UUID and a revision. We want to make it look like we are
> mirroring the original URL, so introduce a helper function that
> returns the original identity trio, and use it when generating commit
> messages and dummy e-mail domains.
Upon further review, this would make 'git svn rebuild' behave
unexpectedly (it would make the git-svn metadata, including .rev_db
entries point to the original repo and not the SVK one). This may not
necessarily be a big deal, however.
Also, incremental fetches (or fetching more than 1k sequential
revisions) would probably fail. To fix this, read the offset of last
entry in .rev_db instead of git-svn-id: from the last commit to get the
last revision. But since rebuild won't work as expected; losing the
.rev_db file means you wouldn't be able to fetch from the SVK repo
anymore (but the original upstream one will be fine).
One last thing: feature should be made optional. I actually work
day-to-day on a repository that was created with svm/SVN::Mirror,
the original repository no longer exists; but the mirrored one
still has these properties (I suppose I could remove the props
server-side, but some people may not have the permissions).
--
^ permalink raw reply
* Re: [PATCH 1/5] git-svn: make test for SVK mirror path import
From: Eric Wong @ 2006-12-05 8:40 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
Sam Vilain <sam@vilain.net> wrote:
> From: <sam@vilain.net>
>
> A manual test that sets up a repository that looks like an SVK depot,
> and then imports it to check that it looks like we mirrored the
> 'original' source.
>
> There is also a minor modification to the git-svn test library shell
> file which sets a variable for the subversion repository's filesystem
> path.
> ---
>
> t/lib-git-svn.sh | 3 -
> t/t9107-git-svn-svk-mirrorpaths.sh | 92 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
> index 63c6703..dffd1fb 100644
> --- a/t/lib-git-svn.sh
> +++ b/t/lib-git-svn.sh
> @@ -45,6 +45,5 @@ else
> svnadmin create "$svnrepo"
> fi
>
> +rawsvnrepo="$svnrepo"
> svnrepo="file://$svnrepo"
> -
> -
> diff --git a/t/t9107-git-svn-svk-mirrorpaths.sh b/t/t9107-git-svn-svk-mirrorpaths.sh
> new file mode 100755
> index 0000000..130e786
> --- /dev/null
> +++ b/t/t9107-git-svn-svk-mirrorpaths.sh
> @@ -0,0 +1,92 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2006 Eric Wong
Huh? I didn't write this test.
> +test_description='git-svn on SVK mirror paths'
> +. ./lib-git-svn.sh
> +
> +if test -n "$GIT_SVN_NO_LIB" && test "$GIT_SVN_NO_LIB" -ne 0
> +then
> + echo 'Skipping: only implemented with SVN libraries'
> + test_done
> + exit 0
> +fi
> +
> +# ok, people who don't have SVK installed probably don't care about
> +# this test.
> +
> +# we set up the repository manually, because even if SVK is installed
> +# it is difficult to use it in a way that is idempotent.
> +
> +# we are not yet testing merge tickets..
> +
> +uuid=b00bface-b1ff-c0ff-f0ff-b0bafe775e1e
> +url=https://really.slow.server.com/foobar
I had to use --whitespace=strip with git-am above.
> +test_expect_success 'multi-fetch an SVK mirror path' "git-svn multi-fetch"
I had to use the following patch to get the multi-fetch test to pass
with GIT_SVN_DELTA_FETCH=1. (I discovered it while running make -C t
full-svn-test)
Is it safe to assume that svk-mirrored URLs will _always_ be file://?
If so, then the delta fetching code should never be needed.
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3017,8 +3017,7 @@ sub libsvn_fetch_delta {
my $ed = SVN::Git::Fetcher->new({ c => $last_commit, q => $_q });
my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
- my (undef, $last_rev, undef) = cmt_metadata($last_commit);
- $reporter->set_path('', $last_rev, 0, @lock, $pool);
+ $reporter->set_path('', ($rev - 1), 0, @lock, $pool);
$reporter->finish_report($pool);
$pool->clear;
unless ($ed->{git_commit_ok}) {
Also, unconditionally setting ($rev - 1) in the above patch disables the
ability to do squashed history[1] imports (not sure if anybody cares about
them, though).
[1] - like shallow clone, but shallow in the middle of history
> +test_expect_success 'got tag history OK' "test \`git-log --pretty=oneline remotes/tags/blah-1.0 | wc -l \` = 3"
But the above test breaks this one...
--
^ permalink raw reply
* Re: egit/jgit wishlist
From: Johannes Schindelin @ 2006-12-05 8:37 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Steven Grimm, git
In-Reply-To: <Pine.LNX.4.63.0612042235270.14187@alpha.polcom.net>
Hi,
On Mon, 4 Dec 2006, Grzegorz Kulewski wrote:
> But it will be working (== end user usable) after many months not days.
Not really. JNI is not that easy to get to work, you know? _Especially_
with cygwin, where you have to transform pathnames from native to posix
format.
It is much work, for just a temporary solution.
> And please note that Java is not that portable as many people are
> suggesting.
But it is.
There are more official Java engines than just those from Sun. For
example, I worked on an SGI machine, where I did not have enough quota to
install gcc and friends, but Java.
Also, now that it will be GPLed, you can be sure that even more platforms
become supported.
And the most important aspect of portability: You really can run the
compiled code anywhere. This is in stark contrast to C, C#, Perl, etc.
> Maybe it will change but currently I will bet C + bash + perl (+
> python?) is more portable than Java.
You lost.
> Java (J2SE) is officially supported mainly under Windows, Solaris, Linux
> and maybe Mac. There are more ports but unfortunatelly way too many of
> them are old, buggy, have not full library implementations or something
> like that.
Aha. But you don't need them. For example, you do not need a full working
CORBA library, or JDBC, or whatever. Java 1.1 should be sufficient (except
for that stupid mmap bug).
> Eclipse also currently works only under Windows, Linux and Mac.
This a completely different beef. IBM, in its infinite wisdom, decided to
scrap the platform independent Swing UI, and made its own (SWT). In C++.
Yes, you need to compile it for _every_ platform you want to run Eclipse
on. Brilliant.
> Can you name one system where Java (J2SE 1.4 or better 1.5) works
> (fully, not sometimes) and where GIT does not work?
As has been said, Windows. Oh, and some mobile phones. And some embedded
devices. Maybe even VMS.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-reset to remove "$GIT_DIR/MERGE_MSG"
From: Andreas Ericsson @ 2006-12-05 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, ltuikov
In-Reply-To: <Pine.LNX.4.63.0612050847340.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
>
>> * Marked as RFC because I suspect I am missing a valid use case
>> where a user might want to say "reset" as part of continuing
>> the conflicted merge resolution, although I do not think of
>> any offhand...
>
> I can only speak for myself, of course: When I use git-reset in a merge,
> more often than not I use "--hard", in which case I want to try something
> different. So yes, I like this patch.
>
> The only possible exception I can think of: git-reset --mixed when a
> merge failed.
>
Indeed, but any invocation of git-reset means you'll quite likely have
to re-do the merge to get all changes anyways.
Like most others, I also use the --hard option most of the times when I
have merge-errors (usually because I've forgotten to create a
topic-branch to do my work in, so I create one from 'master', reset
master to whatever it was last time I pulled and then try rebase'ing on
to it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC/PATCH] git-reset to remove "$GIT_DIR/MERGE_MSG"
From: Johannes Schindelin @ 2006-12-05 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, ltuikov
In-Reply-To: <7v4psbknvb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> * Marked as RFC because I suspect I am missing a valid use case
> where a user might want to say "reset" as part of continuing
> the conflicted merge resolution, although I do not think of
> any offhand...
I can only speak for myself, of course: When I use git-reset in a merge,
more often than not I use "--hard", in which case I want to try something
different. So yes, I like this patch.
The only possible exception I can think of: git-reset --mixed when a
merge failed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Johannes Schindelin @ 2006-12-05 7:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Marco Costalba, Karl Hasselström, git
In-Reply-To: <b0943d9e0612041413p4f303176x3d0fa95afd1c4a1@mail.gmail.com>
Hi,
On Mon, 4 Dec 2006, Catalin Marinas wrote:
> I'll first move the message back to stdout.
In other parts of git, the progress message is only printed if output goes
to a tty. Why not do the same?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Johannes Schindelin @ 2006-12-05 7:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el2cpj$cna$1@sea.gmane.org>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> Sam Vilain wrote:
>
> > For those who like to spawn interactive merge tools on a merge failure
> > or otherwise run some kind of script, allow a "merge.tool" repo-config
> > option that will take arguments as merge(1) does.
>
> How it goes together with merge-recursive rewrite using built-in merge tool
> >from xdiff, xdl_merge?
Not a big problem. If people like Sam's patch, it is easy to integrate,
since it only means that if merge.tool is set to something non-empty,
xdl_merge is not called, but the merge.tool is forked.
Ciao,
Dscho
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-05 7:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0612041317480.3476@woody.osdl.org>
Hi,
On Mon, 4 Dec 2006, Linus Torvalds wrote:
> [core]
> escapefilenames = true
I think this goes too far. The problem _only_ showed up with a made-up
test case for gitweb. Let's bite the apple when we _have_ to (which I
doubt will happen, because for the most part, developers understand that
spaces and umlauts have _no_ place in filenames, basically since UNIX was
invented by stupid US Americans who did not know anything about nice
filenames, let alone other languages than English and C).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-explain
From: Jeff King @ 2006-12-05 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7v1wnekh6a.fsf@assigned-by-dhcp.cox.net>
On Mon, Dec 04, 2006 at 10:09:17PM -0800, Junio C Hamano wrote:
> Should I take these responses to mean that you two are negative
> about the approach of spending extra cycles to commands that can
> leave the working tree in a "in the middle of doing something"
> state to help having a unified command to explain what the
> situation is and suggest the user possible exits, or are you
> saying that it might be a good idea but "git explain" is a bad
> name?
It seems like the point of this command is to show some state
information which would otherwise be hard to see. I think of 'git
status' as the way to look at the repository state. Perhaps we should
enhance the output of 'git status' to note things such as failed merges,
whether we're bisecting, in the middle of applying a patch series, etc.
There could be an optional verbosity switch to give "full explanations"
including recommended ways to deal with the situation.
> Hardwiring the recommended workflow in the tools would reduce
> chances of mistakes, but it could rob the flexibility from them
> if we are not careful and forget to take into account some
> useful combination of tools when adding such safety valves.
As long as the safety valves don't come up _routinely_ in certain
workflows, it seems OK to bypass them with a '-f' force switch. I
suspect the best way to figure out if such workflows are in use is to
put in the safety valves and see who complains; otherwise we're stuck
with brainstorming workflows and deciding whether they make sense.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-05 6:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20061205035123.GA8831@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
On Mon, 4 Dec 2006 22:51:23 -0500, Theodore Tso wrote:
>
> If adds aren't going done automatically (because otherwise you have
> problems with foo.c~ accidentally getting checked it), then it's
> non-symmetric to expect that deletes will also happen automatically.
> It's relatively rare that files are removed or renamed, and sometimes
> files accidentally disappear.
It's non-symmetric, yes, but it's what I would personally like. It's
not an essential aspect of the proposal, so it could go either way as
the git crowd decides.
To explain my personal preference, I like the notion of all files
being "untracked" until I inform the system about their
existence. After that, I'd like the system to take care of them and
notice when they get modified, or when they get deleted.
> So in the case where there are no pathnames given to "git
> commit-working-tree-content", I would argue that it does not do any
> implicit "git add" on new files NOR any implicit "git rm" on missing
> files unless the user actually specifies an --implicit-add or
> --implicit-delete option, respectively. If users want to make
> --implicit-add and/or --implicit-delete the default, that could be a
> configuration option, but I don't think it should be a default.
The ability to configure --implicit-delete and --implicit-add to
git-commit seems good. They're long enough arguments that
> What should happen to foo.c in the index? Should it be stay the same?
> Should the contents be replaced with version of foo.c that has just
> been commited? The latter seems to make sense, but runs the risk of
> losing the data (what was in the index). The former has the downside
> that the index might have a version of foo.c which is older than what
> has been just commited, which could be confusing. Or should git
> commit-working-tree abort with an error message if index != HEAD?
This case is already under debate in a separate thread. There "git
commit files", (which really is commit-working-tree-content already),
currently errors out in this case, but the proposal is to allow it to
proceed with the commit, (thereby "losing" the intermediate staged
content).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Junio C Hamano @ 2006-12-05 6:33 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, Carl Worth
In-Reply-To: <20061205035123.GA8831@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> A second issue which you left unspecified is what should
> commit-working-tree-content do if the index != HEAD. In particular,
> in this case:
>
> edit foo.c
> git update-index
> edit foo.c
> git commit-working-tree-content foo.c
>
> What should happen to foo.c in the index? Should it be stay the same?
> Should the contents be replaced with version of foo.c that has just
> been commited? The latter seems to make sense, but runs the risk of
> losing the data (what was in the index). The former has the downside
> that the index might have a version of foo.c which is older than what
> has been just commited, which could be confusing. Or should git
> commit-working-tree abort with an error message if index != HEAD?
That is exactly the "'commit --only' jumps the index" issue.
Updating the index with what is committed makes sense because
the commit after this --only commit happens builds on top of it,
and not doing so would mean the change to foo.c would be
reverted. As you mentioned above, updating the index with the
committed version of foo.c means information loss of what was
staged earliser, and the traditional behaviour has been to
"abort with an error if index != HEAD" at that path, which was a
safety valve.
However, In the recent discussion, everybody (Linus, Nico, and I
included) seems to think this information loss is acceptable and
in fact is even useful. I've sent a patch to remove the
obsolete safety valve for comments today, but haven't applied it
to any of my public branches yet, but most likely I will, and it
will happen sooner with encouragement from the list.
^ permalink raw reply
* Re: [RFC/PATCH] git-reset to remove "$GIT_DIR/MERGE_MSG"
From: Luben Tuikov @ 2006-12-05 6:19 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: ltuikov
In-Reply-To: <7v4psbknvb.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> An earlier commit a9cb3c6e changed git-commit to use the
> contents of MERGE_MSG even when we do not have MERGE_HEAD (the
> rationale is in its log message).
>
> However, the change tricks the following sequence to include a
> merge message in a completely unrelated commit:
>
> $ git pull somewhere
> : oops, the conflicts are too much. forget it.
> $ git reset --hard
> : work work work
> $ git commit
>
> To fix this confusion, this patch makes "git reset" to remove
> the leftover MERGE_MSG that was prepared when the user abandoned
> the merge.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Luben Tuikov <ltuikov@yahoo.com
>
> ---
>
> * Marked as RFC because I suspect I am missing a valid use case
> where a user might want to say "reset" as part of continuing
> the conflicted merge resolution, although I do not think of
> any offhand...
I also cannot think of any offhand. Should be safe to commit.
Luben
>
> git-reset.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-reset.sh b/git-reset.sh
> index 3133b5b..c0feb44 100755
> --- a/git-reset.sh
> +++ b/git-reset.sh
> @@ -63,6 +63,7 @@ case "$reset_type" in
> ;;
> esac
>
> -rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" "$GIT_DIR/SQUASH_MSG"
> +rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" \
> + "$GIT_DIR/SQUASH_MSG" "$GIT_DIR/MERGE_MSG"
>
> exit $update_ref_status
>
>
>
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Marco Costalba @ 2006-12-05 6:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0612041413p4f303176x3d0fa95afd1c4a1@mail.gmail.com>
On 12/4/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 04/12/06, Marco Costalba <mcostalba@gmail.com> wrote:
> > On 12/4/06, Karl Hasselström <kha@treskal.com> wrote:
> > > I introduced this since I wanted to divert the output to a file, and
> > > the progress message had no business being written to that file. But a
> > > command line option to suppress progress messages would work just as
> > > well if that's what git does.
> >
> > If you don't mind I would prefer a command line option to _enable_
> > progress messages, something like -v or --verbose so to keep back
> > compatibility with current versions of tools that do not expect stderr
> > messages.
>
> I'll first move the message back to stdout. Does qgit rely on the
> StGIT output to have a certain format/information? Does the progress
> message affect it in any way?
>
No. It just checks stderr for empty.
The only commands whose output is used by qgit are stg series/applied/u
^ permalink raw reply
* Re: [PATCH] git-explain
From: Junio C Hamano @ 2006-12-05 6:09 UTC (permalink / raw)
To: J. Bruce Fields, Nicolas Pitre; +Cc: git, Linus Torvalds
In-Reply-To: <20061205035721.GA26735@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
>> ...
>> > [PATCH] git-explain
>> > ...
>>
>> What about calling it git-whatsup instead?
>
> No, clearly it should be git-wtf.
Should I take these responses to mean that you two are negative
about the approach of spending extra cycles to commands that can
leave the working tree in a "in the middle of doing something"
state to help having a unified command to explain what the
situation is and suggest the user possible exits, or are you
saying that it might be a good idea but "git explain" is a bad
name?
An issue with this approach is that this can be the beginning of
hardwiring the official "right way of doing things" in the set
of tools. Pursuing this approach would enhance the set of state
markers like "FAILED_MERGE" in the example, which means:
- more commands would actively record what they were attempting
to do, obviously;
- over time "git explain" will learn about these state markers,
and we would hardwire the "best current practice" exits from
various states in the help messages;
- also commands other than "git explain" would learn about the
state markers of other commands, and change their behaviour.
For example, "git am" might learn to refuse running while a
merge in progress much earlier than with the current
implementation.
The last point can easily become a double-edged sword.
Hardwiring the recommended workflow in the tools would reduce
chances of mistakes, but it could rob the flexibility from them
if we are not careful and forget to take into account some
useful combination of tools when adding such safety valves.
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Junio C Hamano @ 2006-12-05 5:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git, Carl Worth, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612042225220.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@osdl.org> writes:
>>
>> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's
>> > the case when we want to have "git rm -f filename".
>>
>> Hmph. Wouldn't this lossage the same as the lossage we are
>> removing the "safety valve" for, when "commit --only" jumps the
>> index?
>
> Losing an intermediate file state is much less severe than losing the
> latest file state I would think.
Very true indeed.
^ permalink raw reply
* [PATCH 2/5] git-svn: let libsvn_ls_fullurl return properties too
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
From: Sam Vilain <sam@vilain.net>
Allow an extra parameter to be passed to the libsvn_ls_fullurl
function to collect and return the properties of the URL being listed.
---
git-svn.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3891122..93cfcc4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3321,18 +3321,19 @@ sub libsvn_commit_cb {
sub libsvn_ls_fullurl {
my $fullurl = shift;
+ my $want_props = shift;
my $ra = libsvn_connect($fullurl);
- my @ret;
+ my (@ret, @props);
my $pool = SVN::Pool->new;
my $r = defined $_revision ? $_revision : $ra->get_latest_revnum;
- my ($dirent, undef, undef) = $ra->get_dir('', $r, $pool);
+ my ($dirent, undef, $props) = $ra->get_dir('', $r, $pool);
foreach my $d (keys %$dirent) {
if ($dirent->{$d}->kind == $SVN::Node::dir) {
push @ret, "$d/"; # add '/' for compat with cli svn
}
}
$pool->clear;
- return @ret;
+ return ($want_props ? (\@ret, $props) : @ret);
}
^ permalink raw reply related
* [PATCH 5/5] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
From: Sam Vilain <sam@vilain.net>
If an SVN revision has a property, "svm:headrev", it is likely that
the revision was created by "svk sync". The property contains a
repository UUID and a revision. We want to make it look like we are
mirroring the original URL, so introduce a helper function that
returns the original identity trio, and use it when generating commit
messages and dummy e-mail domains.
---
git-svn.perl | 31 +++++++++++++++++++++++++++----
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 70c34b0..13a1f24 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2076,8 +2076,9 @@ sub git_commit {
or croak $!;
print $msg_fh $log_msg->{msg} or croak $!;
unless ($_no_metadata) {
- print $msg_fh "\ngit-svn-id: $SVN_URL\@$log_msg->{revision}",
- " $SVN_UUID\n" or croak $!;
+ my ($url, $uuid, $rev) = svn_commit_id($log_msg);
+ print $msg_fh "\ngit-svn-id: $url\@$rev $uuid\n"
+ or croak $!;
}
$msg_fh->flush == 0 or croak $!;
close $msg_fh or croak $!;
@@ -2109,14 +2110,36 @@ sub get_svm_url {
chomp($SVM_UUID = `git-repo-config --get svn.svkuuid`);
}
+sub svn_commit_id {
+ my $log_msg = shift;
+ my ($url, $uuid, $rev) = ($SVN_URL, $SVN_UUID, $log_msg->{revision});
+ my $svm_headrev = $log_msg->{revprops}{'svm:headrev'};
+ if ( $svm_headrev ) {
+ my ( $_uuid, $_rev) = split /:/, $svm_headrev;
+ chomp($_rev);
+ if ( !$SVM_URL ) {
+ get_svm_url();
+ }
+ if ( $_uuid ne $SVM_UUID ) {
+ warn "$uuid:$rev claims to be $_uuid:$_rev, but that's unknown";
+ } else {
+ ($url, $uuid, $rev) = ($SVM_URL, $SVM_UUID, $_rev);
+ }
+ }
+ ($url, $uuid, $rev);
+}
+
sub set_commit_env {
my ($log_msg) = @_;
my $author = $log_msg->{author};
if (!defined $author || length $author == 0) {
$author = '(no author)';
}
- my ($name,$email) = defined $users{$author} ? @{$users{$author}}
- : ($author,"$author\@$SVN_UUID");
+ my ($name,$email) = defined $users{$author} ? @{$users{$author}}
+ : do {
+ my (undef, $uuid, undef) = svn_commit_id($log_msg);
+ ($author,"$author\@$uuid")
+ };
$ENV{GIT_AUTHOR_NAME} = $ENV{GIT_COMMITTER_NAME} = $name;
$ENV{GIT_AUTHOR_EMAIL} = $ENV{GIT_COMMITTER_EMAIL} = $email;
$ENV{GIT_AUTHOR_DATE} = $ENV{GIT_COMMITTER_DATE} = $log_msg->{date};
^ permalink raw reply related
* [PATCH 1/5] git-svn: make test for SVK mirror path import
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
From: <sam@vilain.net>
A manual test that sets up a repository that looks like an SVK depot,
and then imports it to check that it looks like we mirrored the
'original' source.
There is also a minor modification to the git-svn test library shell
file which sets a variable for the subversion repository's filesystem
path.
---
t/lib-git-svn.sh | 3 -
t/t9107-git-svn-svk-mirrorpaths.sh | 92 ++++++++++++++++++++++++++++++++++++
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 63c6703..dffd1fb 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -45,6 +45,5 @@ else
svnadmin create "$svnrepo"
fi
+rawsvnrepo="$svnrepo"
svnrepo="file://$svnrepo"
-
-
diff --git a/t/t9107-git-svn-svk-mirrorpaths.sh b/t/t9107-git-svn-svk-mirrorpaths.sh
new file mode 100755
index 0000000..130e786
--- /dev/null
+++ b/t/t9107-git-svn-svk-mirrorpaths.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+
+test_description='git-svn on SVK mirror paths'
+. ./lib-git-svn.sh
+
+if test -n "$GIT_SVN_NO_LIB" && test "$GIT_SVN_NO_LIB" -ne 0
+then
+ echo 'Skipping: only implemented with SVN libraries'
+ test_done
+ exit 0
+fi
+
+# ok, people who don't have SVK installed probably don't care about
+# this test.
+
+# we set up the repository manually, because even if SVK is installed
+# it is difficult to use it in a way that is idempotent.
+
+# we are not yet testing merge tickets..
+
+uuid=b00bface-b1ff-c0ff-f0ff-b0bafe775e1e
+url=https://really.slow.server.com/foobar
+
+test_expect_success 'initialize repo' "
+ echo '#!/bin/sh' > $rawsvnrepo/hooks/pre-revprop-change &&
+ echo 'exit 0' >> $rawsvnrepo/hooks/pre-revprop-change &&
+ chmod +x $rawsvnrepo/hooks/pre-revprop-change &&
+
+ mkdir import &&
+ cd import &&
+ mkdir local &&
+ echo hello > local/readme &&
+ svn import -m 'random local work' . $svnrepo &&
+ cd .. &&
+
+ svn co $svnrepo wc &&
+ cd wc &&
+ mkdir -p mirror/foobar &&
+ svn add mirror &&
+ svn ps svm:source $url mirror/foobar &&
+ svn ps svm:uuid $uuid mirror/foobar &&
+ svn ps svm:mirror mirror/foobar . &&
+ svn commit -m 'setup mirror/foobar as mirror of upstream' &&
+ svn ps -r 2 --revprop svm:headrev $uuid:0 $svnrepo &&
+
+ mkdir mirror/foobar/trunk
+ echo hello, world > mirror/foobar/trunk/readme &&
+ svn add mirror/foobar/trunk &&
+ svn commit -m 'first upstream revision' &&
+ svn ps -r 3 --revprop svm:headrev $uuid:1 $svnrepo &&
+
+ svn up &&
+ svn mkdir mirror/foobar/branches &&
+ svn cp mirror/foobar/trunk mirror/foobar/branches/silly &&
+ svn commit -m 'make branch for silliness' &&
+ svn ps -r 4 --revprop svm:headrev $uuid:2 $svnrepo &&
+
+ svn up &&
+ echo random untested feature >> mirror/foobar/trunk/readme &&
+ svn commit -m 'add a c00l feature to trunk' &&
+ svn ps -r 5 --revprop svm:headrev $uuid:3 $svnrepo &&
+
+ svn up &&
+ echo bug fix >> mirror/foobar/branches/silly/readme &&
+ svn commit -m 'fix a bug' &&
+ svn ps -r 6 --revprop svm:headrev $uuid:4 $svnrepo &&
+
+ svn mkdir mirror/foobar/tags &&
+ svn cp mirror/foobar/branches/silly mirror/foobar/tags/blah-1.0 &&
+ svn commit -m 'make a release' &&
+ svn ps -r 7 --revprop svm:headrev $uuid:5 $svnrepo &&
+
+ cd ..
+ "
+
+test_expect_success 'multi-init an SVK mirror path' "git-svn multi-init -t tags -b branches $svnrepo/mirror/foobar"
+
+test_expect_success 'multi-fetch an SVK mirror path' "git-svn multi-fetch"
+
+test_expect_success 'got tag history OK' "test \`git-log --pretty=oneline remotes/tags/blah-1.0 | wc -l \` = 3"
+
+test_expect_success 're-wrote git-svn-id URL' "git-show HEAD | grep git-svn-id: | fgrep $url"
+test_expect_success 're-wrote git-svn-id UUID' "git-show HEAD | grep git-svn-id: | fgrep $uuid"
+test_expect_success 're-wrote git-svn-id revision' "git-show HEAD | grep git-svn-id: | fgrep '@3'"
+test_expect_success 're-wrote author e-mail domain UUID' "test \`git-show --pretty=fuller HEAD | grep '<.*@.*>' | fgrep $uuid | wc -l\` = 2"
+
+test_debug 'gitk --all &'
+
+test_done
^ permalink raw reply related
* [PATCH 3/5] git-svn: collect SVK source URL on mirror paths
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
From: Sam Vilain <sam@vilain.net>
If you use git-svn to import a mirror path within an SVK depot
directly (eg, file:///home/you/.svk/local/mirror/foo), then the URLs
and revisions in the generated commits will be of the wrong URL.
When we set up with git-svn multi-init, check whether the base URL is
(the root of) a mirror path, and store it for later. Set up a couple
of globals and helper functions for later use.
---
git-svn.perl | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 93cfcc4..800c579 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5,6 +5,7 @@ use warnings;
use strict;
use vars qw/ $AUTHOR $VERSION
$SVN_URL $SVN_INFO $SVN_WC $SVN_UUID
+ $SVM_URL $SVM_UUID
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $GIT_SVN_DIR $REVDB/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
@@ -733,6 +734,21 @@ sub multi_init {
init($_trunk);
sys('git-repo-config', 'svn.trunk', $_trunk);
}
+ if ( $url ) {
+ # check for the case of SVK mirror path
+ my ($ents, $props) = libsvn_ls_fullurl($url, "1");
+ if ( my $src = $props->{'svm:source'} ) {
+ $src =~ s{!$}{}; # don't know wtf a ! is there for
+ $src =~ s{(^[a-z\+]*://)[^/@]*@}{$1}; # username of no interest
+
+ # store the source as a repo-config item
+ sys('git-repo-config', 'svn.svkmirrorpath', $src);
+ my $uuid = $props->{'svm:uuid'};
+ $uuid =~ m{^[0-9a-f\-]{36,}}
+ or croak "doesn't look right - svm:uuid is '$uuid'";
+ sys('git-repo-config', 'svn.svkuuid', $uuid);
+ }
+ }
complete_url_ls_init($url, $_branches, '--branches/-b', '');
complete_url_ls_init($url, $_tags, '--tags/-t', 'tags/');
}
@@ -2084,6 +2100,11 @@ sub check_repack {
}
}
+sub get_svm_url {
+ chomp($SVM_URL = `git-repo-config --get svn.svkmirrorpath`);
+ chomp($SVM_UUID = `git-repo-config --get svn.svkuuid`);
+}
+
sub set_commit_env {
my ($log_msg) = @_;
my $author = $log_msg->{author};
^ permalink raw reply related
* [PATCH 4/5] git-svn: collect revision properties when fetching
From: Sam Vilain @ 2006-12-05 5:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
From: Sam Vilain <sam@vilain.net>
Perhaps there is information in the "revision properties" (unversioned
metadata associated with commits) that will affect the way that we
save the revision. Collect them.
---
Sorry for the long lines.
git-svn.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 800c579..70c34b0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -441,12 +441,16 @@ sub fetch_lib {
if ($last_commit) {
$log_msg = libsvn_fetch(
$last_commit, @_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg,
$last_commit,
@parents);
} else {
$log_msg = libsvn_new_tree(@_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg, @parents);
}
^ permalink raw reply related
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