* Re: [PATCH 6/7] git rm: Support for removing submodules
From: Petr Baudis @ 2008-07-17 12:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807170038430.4318@eeepc-johanness>
Hi,
On Thu, Jul 17, 2008 at 12:41:57AM +0200, Johannes Schindelin wrote:
> On Wed, 16 Jul 2008, Petr Baudis wrote:
>
> > This patch adds support for removing submodules to 'git rm', including
> > removing the appropriate sections from the .gitmodules file to reflect
> > this
>
> I have no time to look at the whole series, or even at the patch, but I
> have concerns. Do you really remove the whole directory? Because if you
> do, you remove more than what can be possibly reconstructed from the
> object store.
no; I remove only the index entry and the empty directory made for
non-checked-out submodules (I just try rmdir() and ignore ENOTEMPTY
error). I make that clear in git rm documentation, but not in the patch
description; I will fix that.
> I wonder if it really makes sense to integrate that into git-rm, and not
> git-submodule, if only to introduce another level of consideration for the
> user before committing what is potentially a big mistake.
That is good question and I forgot to elaborate on this in the cover
letter. However, I believe that integrating this functionality into the
basic commands makes for a smoother user experience, following the
principle of the least surprise. It is difficult for me to argue
extensively in further favor of this choice, though. :-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Petr Baudis @ 2008-07-17 12:29 UTC (permalink / raw)
To: gitster; +Cc: git, Heikki Orsila
In-Reply-To: <20080717121813.GC10151@machine.or.cz>
This patch rewrites the general description yet again, first clarifying
the high-level concept, mentioning the difference to remotes and using
the subtree merge strategy, then getting to the details about tree
entries and .gitmodules file.
The patch also makes few smallar grammar fixups of the rest of the
description and clarifies how does 'init' relate to 'update --init'.
Cc: Heikki Orsila <shdl@zakalwe.fi>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-submodule.txt | 39 +++++++++++++++++++++++++++------------
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bb4e6fb..01d0d91 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -18,24 +18,35 @@ SYNOPSIS
DESCRIPTION
-----------
-Submodules are a special kind of tree entries which refer to a particular tree
-state in another repository. The tree entry describes
-the existence of a submodule with the given name and the exact revision that
-should be used, while an entry in `.gitmodules` file gives the location of
-the repository.
-
-When checked out, submodules will maintain their own independent repositories
-within their directories; the only link between the submodule and the "parent
-project" is the tree entry within the parent project mentioned above.
+Submodules allow foreign repositories to be embedded within a dedicated
+subdirectory of the source tree, always pointed at a particular commit.
+They are not to be confused with remotes, which are meant mainly for branches
+of the same project; submodules are meant for different projects you would like
+to make part of your source tree, while the history of the two projects still
+stays completely independent and you cannot modify the contents of the
+submodule from within the main project. In case you want to merge the project
+histories, possibly make local modifications within the tree, but also do not
+mind that your repository will bulk up with all the contents of the other
+project, consider adding a remote for the other project and using the 'subtree'
+merge strategy instead of setting up a submodule.
+
+Submodules are composed from a special kind of tree entry (so-called `gitlink`)
+in the main repository that refers to a particular commit object within
+the (completely separate) inner repository, and a record in the `.gitmodules`
+file at the root of the source tree, assigning a logical name to the submodule
+and describing the default URL the submodule shall be cloned from. The logical
+name can be used for overriding this URL within your local repository
+configuration (see 'submodule init').
This command will manage the tree entries and contents of the gitmodules file
-for you, as well as inspecting the status of your submodules and updating them.
+for you, as well as inspect the status of your submodules and update them.
When adding a new submodule to the tree, the 'add' subcommand is to be used.
However, when pulling a tree containing submodules, these will not be checked
out by default; the 'init' and 'update' subcommands will maintain submodules
checked out and at appropriate revision in your working tree. You can inspect
the current status of your submodules using the 'submodule' subcommand and get
-an overview of changes 'update' would perform using the 'summary' subcommand.
+an overview of the changes 'update' would perform using the 'summary'
+subcommand.
COMMANDS
@@ -81,7 +92,11 @@ init::
Initialize the submodules, i.e. register in .git/config each submodule
name and url found in .gitmodules. The key used in .git/config is
`submodule.$name.url`. This command does not alter existing information
- in .git/config.
+ in .git/config. You can then customize the submodule clone URLs in
+ .git/config for your local setup and proceed to 'git submodule update';
+ you can also just use 'git submodule update --init' without
+ the explicit 'init' step if you do not intend to customize any
+ submodule URLs.
update::
Update the registered submodules, i.e. clone missing submodules and
^ permalink raw reply related
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 12:21 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <320075ff0807170520r200e546ejbad2ed103bd65f82@mail.gmail.com>
On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> When doing a git submodule update, it fetches any missing submodule
>> commits from the repository specified in .gitmodules.
>
> Huh? It takes what is in .git/config! Not what is in .gitmodules.
>
Huh? And where does .git/config get it from? Oh, that's right, .gitmodules.
> So if you have another remote (or URL, e.g. if you have ssh:// access, but
> the .gitmodules file lists git://), just edit .git/config.
>
So for my usecase, you'd have me go in and change *evey single one* of
my submodule refs from the centralised repository, *every time* I want
to do a peer review?
Doesn't the current system strike you as being somewhat centralised in nature?
> I meant, that is the whole _point_ of having a two-step init/update
> procedure.
>
Are you just determined that submodules should remain useless for "the
rest of us"?
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: [PATCHv2] Documentation/git-submodule.txt: Add Description section
From: Petr Baudis @ 2008-07-17 12:18 UTC (permalink / raw)
To: Junio C Hamano, Heikki Orsila; +Cc: git
In-Reply-To: <7vej5tr5kv.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 12:29:03PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> > index 76702a0..87c4ece 100644
> > --- a/Documentation/git-submodule.txt
> > +++ b/Documentation/git-submodule.txt
> > @@ -16,6 +16,28 @@ SYNOPSIS
> > 'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
> >
> >
> > +DESCRIPTION
> > +-----------
> > +Submodules are a special kind of tree entries which refer to a particular tree
> > +in another repository (living at a given URL). ...
>
> In the documentation, "tree" has a specific meaning. Perhaps "a
> particular tree state" is a better wording than another alternative "a
> particular commit", because you mention "the exact revision" in the
> following sentence.
The two sentences are now highly redundant, so...
> I'd suggest dropping " (living at a given URL)" from here, though.
...actually, in the end I have completely rewritten this yet again. The
description was too low-level (and kind of in fact explained gitlinks
instead of submodules), while we should carefully explain the high-level
concept of submodules first, only then talk about tree entries.
> > ... The tree entry describes
> > +the existence of a submodule with the given name and the exact revision that
> > +should be used, while the location of the repository is described in the
> > +`/.gitmodules` file.
>
> Strictly speaking, ".gitmodules" merely gives a hint to be used by
> "submodule init", the canonical location from which the repository is
> expected to be cloned. I do not think this overview needs to go into such
> a detail. The description of "init" subcommand might need clarification,
> though.
I believe we should mention it. The users *will* see this file e.g.
during submodule merges, as well as in git status output when
manipulating submodules.
On Thu, Jul 17, 2008 at 01:41:24PM +0300, Heikki Orsila wrote:
> On Wed, Jul 16, 2008 at 08:44:12PM +0200, Petr Baudis wrote:
> > I have adjusted the description a bit; however, I believe mentioning
> > remotes in
> > the description would only raise the danger of confusion - I emphasized the
> > level of separation, though.
>
> I think not doing a comparison actually creates confusion. My immediate
> thought about submodules was "how does this differ from remotes? why do
> submodules exist rather than just remotes?"
Ok, now I realize this is a good point, and it's a nice chance to give a
plug for the subtree merge strategy as an alternative. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Johannes Schindelin @ 2008-07-17 12:13 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170508j3d3c1ef8j49df576fc47debe2@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
> When doing a git submodule update, it fetches any missing submodule
> commits from the repository specified in .gitmodules.
Huh? It takes what is in .git/config! Not what is in .gitmodules.
So if you have another remote (or URL, e.g. if you have ssh:// access, but
the .gitmodules file lists git://), just edit .git/config.
I meant, that is the whole _point_ of having a two-step init/update
procedure.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 12:08 UTC (permalink / raw)
To: Git Mailing List
When doing a git submodule update, it fetches any missing submodule
commits from the repository specified in .gitmodules. If you instead
want to pull from another repository, you currently need to do a fetch
in each submodule by hand.
Signed-off-by: Nigel Magnay <nigel.magnay@gmail.com>
---
This is my first attempt at adding things to help everyday usage of
git submodule.
I don't usually write much shell script; and it's my first patch, so
it's possible there are better ways to do these things..
git-submodule.sh | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 9228f56..40e1aa1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update
[-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] <path>]|[status|init|update [-i|--init]
[-o|--origin <repository>] [-r|-refspec <refspec>]|summary
[-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
@@ -15,6 +15,8 @@ command=
branch=
quiet=
cached=
+repository=
+refspec=
#
# print stuff on stdout unless -q was specified
@@ -270,6 +272,14 @@ cmd_update()
shift
cmd_init "$@" || return
;;
+ -o|--origin)
+ shift
+ repository=$1
+ ;;
+ -r|--refspec)
+ shift
+ refspec=$1
+ ;;
--)
shift
break
@@ -311,7 +321,9 @@ cmd_update()
if test "$subsha1" != "$sha1"
then
- (unset GIT_DIR; cd "$path" && git-fetch &&
+ set_submodule_repository "$repository" "$path"
+
+ (unset GIT_DIR; cd "$path" && git-fetch "$subrepo" "$refspec" &&
git-checkout -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
@@ -320,6 +332,23 @@ cmd_update()
done
}
+#
+# If we asked for a repository such as 'origin', just pass this through
+# otherwise, try to calculate what the repository URL might be by
+# adding the submodule path to the url, subtracting any /.git first
+#
+set_submodule_repository() {
+
+ if [ -z `echo "$1" | grep '/'` ]
+ then
+ # This is not a URL - just use the name
+ subrepo="$1"
+ else
+ # This is a URL. Chop off /.git if it's there, and add submodule path
+ subrepo="${1/%\/.git/}/$2"
+ fi
+}
+
set_name_rev () {
revname=$( (
unset GIT_DIR
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] guilt(1): fix path to git-sh-setup
From: Johannes Schindelin @ 2008-07-17 11:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Chiang, jeffpc, git
In-Reply-To: <20080717100217.GT32184@machine.or.cz>
Hi,
On Thu, 17 Jul 2008, Petr Baudis wrote:
> On Wed, Jul 16, 2008 at 05:23:39PM -0600, Alex Chiang wrote:
> > diff --git a/guilt b/guilt
> > index 50414a4..ba4593a 100755
> > --- a/guilt
> > +++ b/guilt
> > @@ -23,7 +23,7 @@ esac
> > # we change directories ourselves
> > SUBDIRECTORY_OK=1
> >
> > -. git-sh-setup
> > +. `git --exec-path`/git-sh-setup
>
> Beware of the proverbial "/Program Files/Git" location, however.
Indeed. And when trying to stray not _too_ far away from the coding style
of git.git, avoid the backticks, too, like so:
. "$(git --exec-path)"/git-sh-setup
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsserver: Add testsuite for packed refs
From: Johannes Schindelin @ 2008-07-17 11:54 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, fabian.emmes
In-Reply-To: <1216288877-12140-4-git-send-email-lars@public.noschinski.de>
Hi,
On Thu, 17 Jul 2008, Lars Noschinski wrote:
> + grep "^M master[ ]\+master$" < out
As I said, I am not versed enough in the Teachings of CVS to know if this
is correct.
If the old behaviour ("E cvs ...") was "more" correct, this needs
changing, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsserver: Add support for packed refs
From: Johannes Schindelin @ 2008-07-17 11:50 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, fabian.emmes
In-Reply-To: <1216288877-12140-3-git-send-email-lars@public.noschinski.de>
Hi,
On Thu, 17 Jul 2008, Lars Noschinski wrote:
> req_update still parses /refs/heads manually. Replace this by
> a call to show-ref.
>
> Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
> ---
> git-cvsserver.perl | 25 +++++++++----------------
> 1 files changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index b00d1c2..0e4f5f9 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -947,24 +947,17 @@ sub req_update
> # projects (heads in this case) to checkout.
> #
> if ($state->{module} eq '') {
> - my $heads_dir = $state->{CVSROOT} . '/refs/heads';
> - if (!opendir HEADS, $heads_dir) {
> - print "E [server aborted]: Failed to open directory, "
> - . "$heads_dir: $!\nerror\n";
> - return 0;
> - }
> - print "E cvs update: Updating .\n";
> - while (my $head = readdir(HEADS)) {
> - if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
> - print "E cvs update: New directory `$head'\n";
> - }
> - }
> - closedir HEADS;
> - print "ok\n";
> - return 1;
> + my $showref = `git show-ref --heads`;
> + for my $line (split '\n', $showref) {
> + if ( $line =~ m% refs/heads/(.*)$% ) {
> + print "M $1\t$1\n";
In the removed part, I see that this changes behaviour from "E cvs update:
..." to "M ...".
I do not know the CVS protocol well enough to know if that is still
correct.
BTW from the removed part, it seems that the indentation was done with
tabs formerly, and with spaces now; please use tabs instead.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Testsuite: Unset CVS_SERVER
From: Johannes Schindelin @ 2008-07-17 11:45 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, fabian.emmes
In-Reply-To: <1216288877-12140-2-git-send-email-lars@public.noschinski.de>
Hi,
On Thu, 17 Jul 2008, Lars Noschinski wrote:
> From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
>
> The CVS_SERVER environment variable cane cause some of the cvsimport tests
s/cane/can/
Otherwise uncontroversial, I'd say.
Ciao,
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: David Kastrup @ 2008-07-17 11:18 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0807161605550.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> You're simply wrong. A ref isn't a name for a commit (the point of
> having a ref is that it doesn't persist in naming the same commit). A
> commit isn't a blob. If you start telling people complicated and wrong
> things, they're surely going to be confused.
>
> Git maintains history as a directed graph, with each commit pointing
> back at its history. Refs are the what holds the newest commits that
> nothing else points back to. If directed graphs aren't in your users'
> experience, you can put it this way: git maintains history like
> knitting, where each new stitch holds on to one or more previous
> stitches, and refs are the knitting needles that hold the ends where
> you're working (except that knitting is a lot wider than software
> development). gitk --all even provides the diagram you want to explain
> it.
Complicated and right things are not much less confusing...
> SVN branches are incredible confusing because they fail to distinguish
> the directory structure of the project's source tree from the
> arrangement of available latest versions.
That is because there _is_ no difference. You just store different
versions in different places. What they are named is a convention,
nothing more, nothing less.
> And the version numbers for your branch increase when changes are made
> to other branches.
You are confusing "version numbers" which are assigned by humans with
"revision numbers" which are just an administrational timeline for the
whole repository.
Really, Subversion is rather simple to understand. But it is not a
DVCS. Moving a history from one repository to another is not really
feasible unless you are doing straight mirroring.
--
David Kastrup
^ permalink raw reply
* Re: [PATCHv2] Documentation/git-submodule.txt: Add Description section
From: Heikki Orsila @ 2008-07-17 10:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080716184248.6524.38463.stgit@localhost>
On Wed, Jul 16, 2008 at 08:44:12PM +0200, Petr Baudis wrote:
> I have adjusted the description a bit; however, I believe mentioning
> remotes in
> the description would only raise the danger of confusion - I emphasized the
> level of separation, though.
I think not doing a comparison actually creates confusion. My immediate
thought about submodules was "how does this differ from remotes? why do
submodules exist rather than just remotes?"
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* [PATCH] Testsuite: Unset CVS_SERVER
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-1-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
The CVS_SERVER environment variable cane cause some of the cvsimport tests
to fail. So unset this variable at the beginning of the test script.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9600-cvsimport.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 1e01e5c..0d7786a 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -5,6 +5,7 @@ test_description='git-cvsimport basic tests'
CVSROOT=$(pwd)/cvsroot
export CVSROOT
+unset CVS_SERVER
# for clean cvsps cache
HOME=$(pwd)
export HOME
--
1.5.6.2
^ permalink raw reply related
* Some cvs related fixes and enhancements
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes
This patch series
- fixes a small bug in the cvsimport testsuite
- adds support for packed-refs to cvsserver
- adds basic support cvs co -c to cvsserver
---
git-cvsserver.perl | 38 ++++++++++++++++++++++----------------
t/t9400-git-cvsserver-server.sh | 25 +++++++++++++++++++++++++
t/t9600-cvsimport.sh | 1 +
3 files changed, 48 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH] cvsserver: Add support for packed refs
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-2-git-send-email-lars@public.noschinski.de>
req_update still parses /refs/heads manually. Replace this by
a call to show-ref.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 25 +++++++++----------------
1 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index b00d1c2..0e4f5f9 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -947,24 +947,17 @@ sub req_update
# projects (heads in this case) to checkout.
#
if ($state->{module} eq '') {
- my $heads_dir = $state->{CVSROOT} . '/refs/heads';
- if (!opendir HEADS, $heads_dir) {
- print "E [server aborted]: Failed to open directory, "
- . "$heads_dir: $!\nerror\n";
- return 0;
- }
- print "E cvs update: Updating .\n";
- while (my $head = readdir(HEADS)) {
- if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
- print "E cvs update: New directory `$head'\n";
- }
- }
- closedir HEADS;
- print "ok\n";
- return 1;
+ my $showref = `git show-ref --heads`;
+ for my $line (split '\n', $showref) {
+ if ( $line =~ m% refs/heads/(.*)$% ) {
+ print "M $1\t$1\n";
+ }
+ }
+ closedir HEADS;
+ print "ok\n";
+ return 1;
}
-
# Grab a handle to the SQLite db and do any necessary updates
my $updater = GITCVS::updater->new($state->{CVSROOT}, $state->{module}, $log);
--
1.5.6.2
^ permalink raw reply related
* [PATCH] cvsserver: Add cvs co -c support
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-4-git-send-email-lars@public.noschinski.de>
Implement cvs checkout's -c option by returning a list of all "modules".
This is more useful than displaying a perl warning if -c is given.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 0e4f5f9..afd9789 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -801,6 +801,19 @@ sub req_co
argsplit("co");
+ # Provide list of modules, if -c was used.
+ if (exists $state->{opt}{c}) {
+ my $showref = `git show-ref --heads`;
+ for my $line (split '\n', $showref) {
+ if ( $line =~ m% refs/heads/(.*)$% ) {
+ print "M $1\t$1\n";
+ }
+ }
+ closedir HEADS;
+ print "ok\n";
+ return 1;
+ }
+
my $module = $state->{args}[0];
$state->{module} = $module;
my $checkout_path = $module;
--
1.5.6.2
^ permalink raw reply related
* [PATCH] cvsserver: Add testsuite for packed refs
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-3-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Check that req_update shows refs, even if all refs are packed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index e97aaa6..d181b5b 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -438,6 +438,20 @@ test_expect_success 'cvs update (-p)' '
test -z "$(cat failures)"
'
+cd "$WORKDIR"
+cat > get_update_modules <<EOF
+Root $SERVERDIR
+Directory .
+$SERVERDIR
+update
+EOF
+
+test_expect_success 'cvs update (module list supports packed refs)' '
+ git pack-refs --all &&
+ git cvsserver server < get_update_modules > out &&
+ grep "^M master[ ]\+master$" < out
+'
+
#------------
# CVS STATUS
#------------
--
1.5.6.2
^ permalink raw reply related
* [PATCH] testsuite for cvs co -c
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-5-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Check that all branches are displayed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index d181b5b..3a59b9f 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -484,4 +484,15 @@ test_expect_success 'cvs status (no subdirs in header)' '
! grep / <../out
'
+#------------
+# CVS CHECKOUT
+#------------
+
+cd "$WORKDIR"
+test_expect_success 'cvs co -c (shows module database)' '
+ GIT_CONFIG="$git_config" cvs co -c > out &&
+ grep "^master[ ]\+master$" < out &&
+ ! grep -v "^master[ ]\+master$" < out
+'
+
test_done
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] guilt(1): fix path to git-sh-setup
From: Petr Baudis @ 2008-07-17 10:02 UTC (permalink / raw)
To: Alex Chiang, jeffpc, git
In-Reply-To: <20080716232339.GC22919@ldl.fc.hp.com>
On Wed, Jul 16, 2008 at 05:23:39PM -0600, Alex Chiang wrote:
> diff --git a/guilt b/guilt
> index 50414a4..ba4593a 100755
> --- a/guilt
> +++ b/guilt
> @@ -23,7 +23,7 @@ esac
> # we change directories ourselves
> SUBDIRECTORY_OK=1
>
> -. git-sh-setup
> +. `git --exec-path`/git-sh-setup
Beware of the proverbial "/Program Files/Git" location, however.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-17 9:47 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807160843k25f1d7d3u8bfecd6c1c6eab91@mail.gmail.com>
On Wed, Jul 16, 2008 at 4:43 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On 7/16/08, Nigel Magnay <nigel.magnay@gmail.com> wrote:
>> I wonder if this is a fairly common pattern. We tend to have modules
>> as git repositories, and projects that tie together those git
>> repositories as submodules. [and submodules are necessary because they're
>> shared between multiple supermodules].
>
> I have exactly the same problem as you, and have been working on
> improving my own workflow so that someday I can offer patches that
> might be generally applicable.
>
> In the meantime, my solution is... some shell scripts checked in at
> the top level of my project. :)
>
> In one of my applications, I have a /wv submodule, which provides a
> cross-platform build environment. That environment respectively
> contains a /wv/wvstreams submodule, which is a library that we use.
>
> When I make a change to wvstreams that's needed for my application, I
> need to check into wvstreams, then check that link into wv, then check
> that link into the application. Then, when I push, I have to make
> sure to always push wvstreams first, then wv, then application, or
> else other users can end up with "commit id xxxxxx not found" type
> errors.
>
> So basically, committing is always harmless, since I can do anything I
> want in my own repo (and I want to be able to update wvstreams
> *without* always updating wv, and so on). The tricky part is pushing.
> Here's the script I wrote to make sure I don't screw up when pushing:
>
>
> ~/src/vx-lin $ cat push-git-modules
> #!/bin/sh -x
> set -e
> test -e wv/wvstreams/Makefile
> (cd wv/wvstreams && git push origin HEAD:master) &&
> (cd wv && git push origin HEAD:master) &&
> git push origin HEAD:master ||
> echo "Failed!"
>
>
> Now, this script is pretty flawed. Notably, it always pushes to the
> 'master' branch, which is stupid. However, it works in our particular
> workflow, because wvstreams isn't being modified by too many
> developers and it's okay if we all commit to master. This is also
> aided by the fact that people are trained to push only after they've
> made all the unit tests pass, etc. And further, individual apps don't
> have to update their wvstreams to the latest anyway unless they really
> need the latest changes, which is a wonderful feature of git
> submodules.
>
Yes - I use something rather similar on my desktop. The unfortunate
thing is that I know how submodules work, and am happy with the
scripts. My users are sometimes in the 'git gui' types - not as
technically literate, and likely on Windows.
> Now, sometimes the above push script will fail. In my experience,
> this is only when someone else has pushed in something before you,
> which means a fast-forward is not possible on at least one of the
> repos. When that happens, you have to pull first, using this script:
>
> ~/src/vx-lin $ cat newest-git-modules
> #!/bin/sh -x
> set -e
> test -e wv/wvstreams/Makefile
> git pull origin master &&
> (cd wv && git pull origin master) &&
> (cd wv/wvstreams && git pull origin master) ||
> echo "Failed!"
>
> This pulls in the latest version of application, wv, and wvstreams, in
> that order, and stops in case of any merge conflicts so that you can
> resolve them by hand. It's safe to run the above script more than
> once in case you're not sure if it's done or not.
>
> After pulling the new modules, you may need to make new commits to
> update to the latest submodule commits - if that's indeed what you
> want. And then you can run push-git-modules, and be reasonably
> assured that it will work (unless someone made another push while you
> were fixing conflicts).
>
Yeah - this happens a lot. If someone else commits to the
super-project before you, it's always a conflict. What's annoying is
there's no way around it (though resolution is easy - force to current
- but it this is a big bit of what confuses my users. They say 'but I
already resolved the merges in the submodule itself'. I'm not sure
there's an easy way around it though - and this is part of my worry
that there's hidden complexity with trying to make it 'look like 1 big
repo').
> Finally, I have another script that retrieves the *currently linked*
> version of the git modules. I wish git-checkout would do this
> automatically, but it doesn't, for apparently-difficult-to-resolve
> safety reasons. Anyway, note that this script uses the existence of
> submodule/Makefile as "proof" that the submodule was checked out
> correctly.
>
>
> ~/src/vx-lin $ cat get-git-modules
> #!/bin/sh -x
> set -e
> git submodule init
> git submodule update
> test -e wv/Makefile
> (cd wv && git submodule init && git submodule update)
> test -e wv/wvstreams/Makefile
>
>
>> I guess it probably gets sticky when there are merge conflicts. Is
>> anyone working on this kind of thing; I might be able to give some
>> time to help work on it?
>
> So as you can see, my scripts are crappy. However, they have already
> drastically reduced the number of mistakes made by developers in my
> group (especially commits lost due to 'git submodule update' at the
> wrong time, and pushes of the supermodule before the submodule).
>
Yeah. I have an additional usecase, which is around pulling from
another user. If they've made changes in their tree(s) that they want
to get reviewed, normally I could do something like
git fetch ssh://joebloggs.computer/blah +refs/heads/*:refs/remotes/joebloggs/*
But if they've made cross-module changes, I'm SOL, as fetching their
super-project will have references to commits that aren't in the repo
mentioned in .gitmodules (only in joebloggs's tree) - so doing git
submodule update doesn't help. I have to go into each submodule and
explicitly fetch. It feels wierdly centralised for this otherwise
distributed tool.
> If you want to work with me on my new submodule workflow (and I'd
> certainly appreciate it!) then I'd suggest one or more of the
> following starting points:
>
> - Take the recursive push, pull, and update operations described
> above, make them general (ie. not referring to my submodules by name
> :)), and add them as commands in the real git-submodule script. The
> trickiest part here will be figuring out which remote branch to
> push/pull.
>
What's bugging me is I'm not sure that it's the right place. It seems
(to me) that having the only place that knows about submodules being
the 'git submodules' script isn't right. What users want is 'git fetch
<blah>' to do the lot - that, for the most, it ought to do the
submodule init, update and clever stuff automatically. That if 'git
fetch' is porcelain, then the porcelain needs to call the
git-submodule stuff.
But - perhaps it's best to approach it as scripts for now :)
> - Perhaps add a "recursive commit" operation that recursively
> auto-commits submodule refs, for use after running the
> newest-git-modules script. The commit message could be auto-generated
> using something like "git-whatchanged" on the submodule.
>
Hm - I'd be happy with the same commt message in all modules. What I
want is to be able to do (from the top) 'git commit -a' or the same
with the GUI, and see all the files to be committed regardless of
whether they're in a submodule or not.
I'm guessing you probably need to build a tree of submodules, and
commit from the tips backwards towards the top level superproject.
This is what the users want - something that mirrors 'svn ci' at the
top level - "Please Check All My stuff in".
> - See what can be done about making git-checkout automatically
> git-submodule-update *if and only if* the currently checked-out commit
> of the submodule exactly matches the one that was checked out last
> time, *and* the desired commit is already available in the submodule
> repo (which is not necessarily the case, if you haven't fetched it
> yet). That is, as with any file in git, if it hasn't changed from the
> one in the repo, you know you won't lose any information if you just
> auto-replace it with the new version.
>
> - Fix git-submodule-update to not just switch submodule branches if
> you've made checkins in that submodule. Right now, commits to a
> submodule by default don't go to any branch, so if you subsequently
> run git-submodule-update, your commits are lost (except for the
> reflog). This is very un-git-like in general, and
> git-submodule-update should be much more polite.
We always move back onto a branch immediately after submodule update,
which is another thing to forget!
>
> Note that git-submodule is only about 800 lines of shell. It's
> remarkably straightforward to make it do whatever you want. The hard
> part is figuring out what you want, and making sure you don't stomp on
> *other* people's workflows while you're there.
>
Totally.
> Also note that even if you don't contribute any of the above, I'm
> planning to someday make time to do it myself :) But don't hold your
> breath. I've been busy.
>
Ditto.
> Have fun,
>
> Avery
>
^ permalink raw reply
* Re: (Remaining) problems with the http backend ?
From: Petr Baudis @ 2008-07-17 9:08 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20080717080419.GA23489@glandium.org>
Hi,
On Thu, Jul 17, 2008 at 10:04:20AM +0200, Mike Hommey wrote:
> PS: Answers to this post will be used to fill my GIT-HTTP-TODO list.
could you please post the final todo list, possibly as a patch for the
todo branch? (I wonder how Junio would feel about that.) I have actually
been pondering to do the same, with some of my more interesting TODO
lists.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Patterns work unexpectedly with "git log" commit limiting
From: Petr Baudis @ 2008-07-17 8:59 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <20080717074706.GA5392@mithlond.arda.local>
Hi,
On Thu, Jul 17, 2008 at 10:47:06AM +0300, Teemu Likonen wrote:
> 3. What is the supposed behaviour of -F (--fixed-strings) when combined
> with --author= ?
>
> --author=pattern -F
>
> doesn't seem to match anything. I also tried putting the entire raw
> author field (i.e. including the raw date) but no match. With -F
> before the --author= it behaves like no -F at all.
>
> "--grep=fixedstring -F" seems to work, though.
this is actually very high on my TODO list, since it makes
author/committer search in gitweb disfunctional. I plan to post a patch
fixing this in a few days, unless someone beats me to it as usual. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git-svn: Trouble after project has moved in svn
From: Michael J Gruber @ 2008-07-17 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <510143ac0807161512w44a612bcndc53713639b0b70a@mail.gmail.com>
Jukka Zitting venit, vidit, dixit 17.07.2008 00:12:
> Hi,
>
> Somewhat related to the recent thread about Apache Synapse, I'm having
> trouble making a git-svn clone of a project that has been moved around
> in a Subversion repository.
>
> See the script at the end of this message for a simple test case that
> does the following svn commits:
>
> PREPARE: creates projectA with the standard trunk,branches,tags structure
> VERSION1: first version of README.txt in projectA/trunk
> TAG1: tags projectA/trunk to projectA/tags/v1
> MOVE: moves projectA to projectB
> VERSION2: second version of README.txt in projectB/trunk
> TAG2: tags projectB/trunk to projectB/tags/v2
>
> The resulting repository structure is:
>
> /projectB/
> trunk/
> README.txt # version 2
> branches/
> tags/
> v1/
> README.txt # version 1
> v2/
> README.txt # version 2
>
> Here's the git commit graph created by the test case:
>
> * TAG2 <- refs/remotes/tags/v2
> | * VERSION2 <- refs/remotes/trunk
> |/
> * MOVE
> * VERSION1 <- refs/remotes/trunk@3
> | * MOVE <- refs/remotes/tags/v1
> | * TAG1 <- refs/remotes/tags/v1@3
> |/
> * PREPARE <- refs/remotes/tags/v1@1
>
> The most pressing issue is that the refs/remotes/tags/v1 branch starts
> directly from the first PREPARE commit instead of VERSION1. Also, the
> branch point of refs/remotes/tags/v2 seems to be incorrect, it should
> be based on the VERSION2 commit instead of MOVE.
In the script below, you use copies inside your svn working copy for
tagging, which is generally a bad idea: it stores the exact state of
your wc as a "tag". Use this for creating "mixed states", but not for
ordinary tagging (or make sure you svn up). See the detailed comments below.
If you want to create an svn tag (as far as svn has tags at all) use
repo urls, or make sure your wc is up to date.
> =====
> #!/bin/sh
>
> REPO=`pwd`/repo
> svnadmin create $REPO
>
> svn checkout file://$REPO checkout
> cd checkout
>
> svn mkdir projectA
> svn mkdir projectA/trunk
> svn mkdir projectA/branches
> svn mkdir projectA/tags
> svn commit -m PREPARE
>
> echo VERSION1 > projectA/trunk/README.txt
> svn add projectA/trunk/README.txt
> svn commit -m VERSION1
Now, README.txt is at r2, but trunk is still at r1.
Use "svn update" here to get trunk to r2!
> svn copy projectA/trunk projectA/tags/v1
This copies r1 of trunk to the tags dir (unless you've inserted svn up
above)!
> svn commit -m TAG1
> svn update
>
> svn move projectA projectB
> svn commit -m MOVE
>
> echo VERSION2 > projectB/trunk/README.txt
> svn commit -m VERSION2
Now, README.txt is at r5, but trunk is at r4.
"svn update"!
> svn copy projectB/trunk projectB/tags/v2
This tags (copies to tags/) r4 of trunk
> svn commit -m TAG2
> svn update
This produces r6: the tagging.
>
> mkdir ../git
> cd ../git
>
> git svn init -s file://$REPO/projectB
> git svn fetch
The results perfectly as expected. Compare "svn log -v" with git-svn's
results, and you'll see that git (tag) branches fork off exactly at the
revisions which you tagged in svn. Because the last commit occurs on
tags/v2, git-svn checks out that branch as master, the supposedly
"active" branch.
If you insert the two missing "svn update" commands which bring your wc
up to date before tagging your git-svn results will be what you expected.
Cheers,
Michael
^ permalink raw reply
* Contributors, please check your names
From: Junio C Hamano @ 2008-07-17 8:22 UTC (permalink / raw)
To: git
A handy way to look at the list of contributors is:
$ git shortlog -s --since=6.month
This shows the number of patches in our history for each contributor. The
patch author name (excluding e-mail part) is used for summarizing, and
this allows the same person to send patches under more than one e-mail
address and still count these patches as authored by one person.
Your name however can appear more than once in different spellings, if you
sent patches using different human-readable names on From: line of your
patch submission from the same (or different) e-mail address. E.g. these
two patches are counted under different authors:
Author: A. U. Thor <author@example.xz>
Date: Wed Jul 09:23:06 2008 -0700
The first patch...
Author: A U Thor <author@example.xz>
Date: Wed Jul 09:23:07 2008 -0700
The second patch...
There is a "mailmap" mechanism to consolidate them; it allows us to
specify what human-readable name should be used for given e-mail address.
The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
from me, <author@example.xz>, are marked without abbreviating periods in
my name", and we can add this entry to the toplevel .mailmap file to fix
it:
A. U. Thor <author@example.xz>
It tells the shortlog (and --pretty=format:%aN in recent enough git)
mechanism to give huma readable name "A. U. Thor" anytime it sees
<author@example.xz> e-mail address, regardless of what the Author:
header in the commit object says.
If your name appears more than once in the output from the "shortlog"
command at the beginning of this message, you may want to tell me to fix
it.
Thanks.
^ permalink raw reply
* Re: Patterns work unexpectedly with "git log" commit limiting
From: Junio C Hamano @ 2008-07-17 8:17 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <20080717074706.GA5392@mithlond.arda.local>
Teemu Likonen <tlikonen@iki.fi> writes:
> 1. Option order changes the behaviour. "git log" with
> ...
> 2. Internally --author= and --committer= fields contain more stuff than
> ...
> 3. What is the supposed behaviour of -F (--fixed-strings) when combined
I won't have time right now to comment on the previous three, because they
are not my code (meaning, I need to dig around before I can intelligently
answer -- maybe when I have free time). What you expected does sound very
sensible, though.
> 4. Logical AND/OR operation.
The --grep and --author search of "log" family shares git-grep logical
expression engine, so if you somehow can come up with a way to pass --and
(or even better, --all-match) from the command line just like we can give
them to git-grep, searching with combinations of and/or/not should be doable.
^ 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