* [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 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
* 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] 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
* 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
* 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: [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: [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] 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] 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
* [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] 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
* 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: 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
* [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 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
* Re: Considering teaching plumbing to users harmful
From: Dmitry Potapov @ 2008-07-17 12:38 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <487EF519.5070902@sneakemail.com>
On Thu, Jul 17, 2008 at 11:30 AM, "Peter Valdemar Mørch (Lists)"
<4ux6as402@sneakemail.com> wrote:
>
> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even
> sticking to porcelain, it is a feature-rich new tool I have in my hands!
>
> I'm missing clarity about what is porcelain and what is plumbing. `git help`
> shows
>
> "The most commonly used git commands are:" add .. tag.
>
> Is this list exactly the list of porcelain commands? Then say so there.
There are a few other commands that are considered as porcelain, but they
are not so often used or used for very specific purposes, such sending
patches by email. So, you do not have to bother about them right now.
In fact, even this list may be too long to be learned at once. It is
better to proceed step-wise, like this:
=== Getting started ===
1. Creating your repo
git init
git clone
2. Commiting your changes
git add
git commit
There are also git mv, git rm for those who need them.
3. Inspect your changes before committing them
git status
git diff
4. Inspecting history
git log
5. Synchronization with the upstream
git pull
git push
=== More commands ===
6. How to revert my changes?
6.1. reverting uncommitted changes
git checkout file
git checkout HEAD file
6.2. committed but not publish changes
git reset HEAD^
git reset --hard HEAD^
6.3. published changes
git revert
7. Who introduced this change?
git log -S as better alternative to git blame
8. Some useful "tricks"
git grep
git add -p
git diff --cached
git commit --amend
git show
git log -p
=== Working with branches ===
9. Creating branches and tags
git tag
git branch
git checkout
10. Merging is easy
git merge
By the way:
git pull = git fetch + git merge FETCH_HEAD
git merge branch = git pull . branch
11. What is rebase?
When can it be useful?
Advantages and disadvantages.
=== More "advanced" commands ===
12. git safety net
git log -g
13. Find the change that introduced a bug
git bisect
14. Short review other commands:
git gc
git archive
git-cherry-pick
git remote
git format-patch
git apply
git am
===
> Neither `git help diff` nor `git help ls-tree` say whether they are
> porcelain or plumbing commands. `git help diff` mentions git-diff-index,
> which i suspect is plumbing. When I read a man page, it would be nice to
> know whether a command (either the topic of the page or another mentioned
> command) is intended as porcelain or not.
I agree, it is very confusing for beginners. The rule of the thumb that
helped me when I started was that commands with dash in their names are
plumbing (there are a few exceptions though).
Dmitry
^ permalink raw reply
* Re: [PATCH] cvsserver: Add support for packed refs
From: Lars Noschinski @ 2008-07-17 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, fabian.emmes
In-Reply-To: <alpine.LSU.1.00.0807171346560.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hello!
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-17 14:31]:
>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 ...".
Good catch, this part is indeed somewhat busted. The tested clients did
not care, but this should be changed nevertheless to be the same as the
old behaviour.
>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.
Actually, the old indetation was wrong. The biggest part of the file
(and the surrounding code) is indented by spaces.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-17 12:55 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <487EF519.5070902@sneakemail.com>
On Thu, Jul 17, 2008 at 09:30:33AM +0200, "Peter Valdemar Mørch (Lists)" wrote:
>
> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even
> sticking to porcelain, it is a feature-rich new tool I have in my hands!
>
> I'm missing clarity about what is porcelain and what is plumbing. `git
> help` shows
The top-level man page has a listing of what is porcelain and what is
plumbing --- although there is some disagreement. Johannes was
complaining about people using git rev-parse in tutorials and saying
that there was no way that was porcelain, but in fact it is *not*
listed as plumbing in the git man page. So I don't think there is
really a strong black-and-white category, but rather a certain set of
shades of gray, as it were.
> Is this list exactly the list of porcelain commands? Then say so there.
> Neither `git help diff` nor `git help ls-tree` say whether they are
> porcelain or plumbing commands. `git help diff` mentions git-diff-index,
> which i suspect is plumbing. When I read a man page, it would be nice to
> know whether a command (either the topic of the page or another
> mentioned command) is intended as porcelain or not.
My personal long-standing complaint is that there are certain man
pages like "git log" where in order to see all of the options which it
can take, the man page for git-log redirects you to a man page for
plumbing. Great way to scare the users. :-)
Have you taken a look at the intro-level materials such as "Everyday
Git in 20 commands or so"[1], the git tutorial[2], the official "Git's
User Manual"[3], or the "Git-SVN crash course"[4]? Those are probably
the best place to begin --- and to basically treat the git man pages
as reference materials with a huge number of controls that you won't
use or need to use for a long time --- if ever. It's like the 10,000
features hidden inside Microsoft Office. The features are all
indispensable to *someone*, but everyone has a different set of the
100 features which they all *have* to have. (And of course, the 20 or
so features that everyone really uses. :-)
> All of this of course assumes that there is consensus and a clear
> distinction between what is porcelain and what is plumbing which I'm
> don't even know if there is.
I don't think so. It's like what the judge said about pornography ---
I know it when I see it. :-)
And note that there's nothing *wrong* with using plumbing commands.
It's just that from a pedagogical point of view, they might not
necessarily be the best place to start.
- Ted
[1] http://www.kernel.org/pub/software/scm/git/docs/everyday.html
[2] http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
[3] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
[4] http://git.or.cz/course/svn.html
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Johannes Schindelin @ 2008-07-17 12:58 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170521s26693381m60648468cce1c41c@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
> On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > 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.
Oh, that's right, after "git submodule init". Right before you are
supposed to change them if your setup commands that.
> > 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?
No.
> Doesn't the current system strike you as being somewhat centralised in
> nature?
No.
> > 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"?
No.
If you really need to change the "origin" back and forth between reviews,
while the committed state of the superproject stays the same, then
something is seriously awkward and needs to be streamlined in your setup.
Because when the superproject's revision stays the same, "git submodule
update" may fetch additional objects if you specify another remote, but it
will check out just the same revisions of the submodules. Because they
were committed as such.
But if you want to get objects from another server (as opposed to update
the submodules' working directories to the latest committed revisions),
which happens to have the identical layout of the principal server (which
I would deem another setup peculiarity to be fixed), you might want to
look into the recurse patch that was flying about on this list a few
months back.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 6/7] git rm: Support for removing submodules
From: Johannes Schindelin @ 2008-07-17 12:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717123501.GD10151@machine.or.cz>
Hi,
On Thu, 17 Jul 2008, Petr Baudis wrote:
> 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.
Thanks for explanation!
> > 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.
Makes sense,
Dscho
^ permalink raw reply
* Re: Sequencer migration patches
From: Stephan Beyer @ 2008-07-17 13:05 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Christian Couder, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <cover.1216233918.git.s-beyer@gmx.net>
Hi,
Stephan Beyer wrote:
> Rebasing 100 commits takes 10.1 seconds instead of only 4.8 seconds
> on my test machine.
Btw, the builtin-sequencer needs 1.7 seconds to pick that 100 commits
on my test machine.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 5/7] git mv: Support moving submodules
From: Petr Baudis @ 2008-07-17 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcapme0q.fsf@gitster.siamese.dyndns.org>
Hi!
On Wed, Jul 16, 2008 at 07:37:57PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... The horrid
> > index_path_src_sha1 hack is unfortunately much worse,
>
> This one certainly is ugly beyond words.
;-)
> By the way, why is it even necessary to rehash the contents when you run
> "mv"?
>
> IOW,
>
> $ >foo
> $ git add foo
> $ echo 1 >foo
> $ git mv foo bar
>
> makes "foo" disappear from the index and adds "bar", but it makes the
> local change added to the index at the same time.
>
> Side note. It actually is a lot worse than that. When you move
> something to another existing entry, the code does not even add
> the object name of moved entry recorded in the index, nor rehashes
> the moved file. This is totally inconsistent!
>
> I personally think these buggy behaviours you are trying to inherit are
> making this patch more complex than necessary. Perhaps this needs to be
> fixed up even further (you did some fix with the first patch) before
> adding new features? For example, I think it is a bug that the
> "overwrite" codepath does not work with symlinks.
I agree that it would be much cleaner to fix this; I got puzzled about
this behaviour a bit, but I was afraid to break the traditional
behaviour. However, if you are feeling this brave, patch to follow up
shortly. :-)
> * Then, only for case (1), you do not call add_file_to_cache() -- because
> you know you do not have anything you can rehash; instead, factor out
> the codepath "git-update-index --cacheinfo" uses and call that.
This is excellent hint, sort of what I hoped for, thanks! I forgot
about --cacheinfo completely, which is truly a shame especially when I
look at the history of this switch. ;-) (BTW, curiously, the commit
lists Linus as an author even though the patch is yours. Maybe this was
merely some imperfection of the early scripts around Git, though.)
I really did not touch git internals for way too long.
--
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: What's cooking in git.git (topics)
From: Stephan Beyer @ 2008-07-17 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk01hqzz.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> * sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
> . Migrate git-am to use git-sequencer
> . Add git-sequencer test suite (t3350)
> . Add git-sequencer prototype documentation
> . Add git-sequencer shell prototype
>
> I haven't looked at the updated series yet. I should, but nobody else
> seems to be looking at these patches, which is somewhat depressing but
> understandable. Summer is slower ;-)
imho there is no need to hurry, but if I can help, just tell me how.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Heikki Orsila @ 2008-07-17 13:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080717122911.32334.73465.stgit@localhost>
On Thu, Jul 17, 2008 at 02:29:20PM +0200, Petr Baudis wrote:
> +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.
That is nice, thanks!
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ 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