* Re: [EGIT PATCH] Remove src dir and entry in build.properties.
From: Robin Rosenberg @ 2007-09-19 18:28 UTC (permalink / raw)
To: Ben Konrath; +Cc: git
In-Reply-To: <20070918222057.GA11990@toast.toronto.redhat.com>
onsdag 19 september 2007 skrev Ben Konrath:
> Hi Robin,
>
> This is just a small clean up patch for the branding plugin.
>
> CHeers, Ben
>
> Signed-off-by: Ben Konrath <bkonrath@redhat.com>
> ---
> org.spearce.egit/build.properties | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
Now why didn't I see that? Thanks.
-- robin
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Junio C Hamano @ 2007-09-19 18:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Edgar Toernig, Shawn O. Pearce, git
In-Reply-To: <20070919133647.GA17192@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> ... in fact doing it twice is enough but either way I don't like to impose
> that to the caller :/
I do not think so either. We had a similar issue resolved with
4bf53833.
^ permalink raw reply
* [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-19 18:15 UTC (permalink / raw)
To: git; +Cc: David Brown
git-p4 was missing the execute bit setting if the file had other attribute
bits set.
---
contrib/fast-import/git-p4 | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index adaaae6..50850b8 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -932,7 +932,10 @@ class P4Sync(Command):
data = file['data']
mode = "644"
- if file["type"].startswith("x"):
+ if (file["type"].startswith("x") or
+ file["type"].startswith("cx") or
+ file["type"].startswith("kx") or
+ file["type"].startswith("ux")):
mode = "755"
elif file["type"] == "symlink":
mode = "120000"
--
1.5.3.1
^ permalink raw reply related
* Re: State of Perforce importing.
From: Reece Dunn @ 2007-09-19 18:56 UTC (permalink / raw)
To: Reece Dunn, Simon Hausmann, Git
In-Reply-To: <20070919182545.GA2266@old.davidb.org>
On 19/09/2007, David Brown <git@davidb.org> wrote:
> On Wed, Sep 19, 2007 at 07:23:41PM +0100, Reece Dunn wrote:
>
> >> I think it would be sufficient to check the first or second character for
> >> an 'x'. I'll make a change and give it a try later today.
> >
> >These are the old file types. If you read the output of `p4 help
> >filetypes`, the new way of specifying this is with file type
> >modifiers. Therefore, you also have things like text+x.
>
> So my patch I just sent may not be sufficient. Thing is, we set the file
> type as 'text+x' and it comes back as xtext, so I'm not sure if P4 ever
> gives out text+x or if that is just available as a new way of specifying
> them.
I'm not sure. The Perforce help says that xtext and its variants are
there for backward compatibility. If you are running an older server
with a new client, or the other way around, they may be doing a map
from text+x to xtext so that the old version can work properly. This
is just speculation, though.
I don't know enough to say what Perforce is doing. I find it strange
that it is reporting xtext, when you specified text+x.
Have you tried a combination that is not supported? Is xunicode
supported, in which case you could try unicode+x (if you have a file
that you can experiment with)?
- Reece
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.2
From: Junio C Hamano @ 2007-09-19 19:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.3.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.2-1.$arch.rpm (RPM)
GIT v1.5.3.2 Release Notes
==========================
Fixes since v1.5.3.1
--------------------
* git-push sent thin packs by default, which was not good for
the public distribution server (no point in saving transfer
while pushing; no point in making the resulting pack less
optimum).
* git-svn sometimes terminated with "Malformed network data" when
talking over svn:// protocol.
* git-send-email re-issued the same message-id about 10% of the
time if you fired off 30 messages within a single second.
* git-stash was not terminating the log message of commits it
internally creates with LF.
* git-apply failed to check the size of the patch hunk when its
beginning part matched the remainder of the preimage exactly,
even though the preimage recorded in the hunk was much larger
(therefore the patch should not have applied), leading to a
segfault.
* "git rm foo && git commit foo" complained that 'foo' needs to
be added first, instead of committing the removal, which was a
nonsense.
* git grep -c said "/dev/null: 0".
* git-add -u failed to recognize a blob whose type changed
between the index and the work tree.
* The limit to rename detection has been tightened a lot to
reduce performance problems with a huge change.
* cvsimport and svnimport barfed when the input tried to move
a tag.
* "git apply -pN" did not chop the right number of directories.
* "git svnimport" did not like SVN tags with funny characters in them.
* git-gui 0.8.3, with assorted fixes, including:
- font-chooser on X11 was unusable with large number of fonts;
- a diff that contained a deleted symlink made it barf;
- an untracked symbolic link to a directory made it fart;
- a file with % in its name made it vomit;
Documentation updates
---------------------
User manual has been somewhat restructured. I think the new
organization is much easier to read.
----------------------------------------------------------------
Changes since v1.5.3.1 are as follows:
Alexandre Julliard (1):
hooks--update: Explicitly check for all zeros for a deleted ref.
Benoit Sigoure (1):
Add test to check recent fix to "git add -u"
Carlos Rica (1):
git-tag -s must fail if gpg cannot sign the tag.
David Kastrup (1):
git-send-email.perl: Add angle brackets to In-Reply-To if necessary
Dmitry V. Levin (2):
Makefile: Add cache-tree.h to the headers list
git-commit: Disallow amend if it is going to produce an empty non-merge commit
Eric Wong (3):
git-svn: fix "Malformed network data" with svn:// servers
git-svn: understand grafts when doing dcommit
Documentation/git-svn: updated design philosophy notes
Gerrit Pape (2):
git-gui: lib/index.tcl: handle files with % in the filename properly
git-clone: improve error message if curl program is missing or not executable
J. Bruce Fields (13):
user-manual: adjust section levels in "git internals"
user-manual: move object format details to hacking-git chapter
user-manual: rename "git internals" to "git concepts"
user-manual: create new "low-level git operations" chapter
user-manual: rewrite index discussion
user-manual: reorder commit, blob, tree discussion
user-manual: rewrite object database discussion
user-manual: move packfile and dangling object discussion
user-manual: fix introduction to packfiles
user-manual: todo updates and cleanup
documentation: replace Discussion section by link to user-manual chapter
core-tutorial: minor cleanup
git-apply: fix whitespace stripping
Jari Aalto (1):
Documentation/git-archive.txt: a couple of clarifications.
Jean-Luc Herren (1):
stash: end index commit log with a newline
Jeff King (1):
git-push: documentation and tests for pushing only branches
Johannes Schindelin (2):
revision walker: --cherry-pick is a limited operation
apply --index-info: fall back to current index for mode changes
Junio C Hamano (13):
git-apply: do not read past the end of buffer
git-add -u: do not barf on type changes
git-format-patch --in-reply-to: accept <message@id> with angle brackets
diff --no-index: do not forget to run diff_setup_done()
Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot
Split grep arguments in a way that does not requires to add /dev/null.
git-sh-setup: typofix in comments
send-email: make message-id generation a bit more robust
git-commit: Allow partial commit of file removal.
git-commit: partial commit of paths only removed from the index
Document ls-files --with-tree=<tree-ish>
t/t4014: test "am -3" with mode-only change.
GIT 1.5.3.2
Linus Torvalds (1):
Fix the rename detection limit checking
Matthias Urlichs (1):
git-svnimport: Use separate arguments in the pipe for git-rev-parse
Michael Smith (1):
(cvs|svn)import: Ask git-tag to overwrite old tags.
Michele Ballabio (2):
git-gui: show unstaged symlinks in diff viewer
git-gui: handle "deleted symlink" diff marker
Mike Ralphson (1):
Documentation / grammer nit
Nicolas Pitre (1):
fix doc for --compression argument to pack-objects
Pierre Habouzit (1):
Fix lapsus in builtin-apply.c
Ramsay Allan Jones (1):
Fix a test failure (t9500-*.sh) on cygwin
Shawn O. Pearce (17):
git-gui: Correct starting of git-remote to handle -w option
git-gui: Fix detaching current branch during checkout
git-gui: Properly set the state of "Stage/Unstage Hunk" action
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
Cleanup unnecessary file modifications in t1400-update-ref
Include a git-push example for creating a remote branch
git-gui: Disable Tk send in all git-gui sessions
git-gui: Avoid use of libdir in Makefile
git-gui: Assume untracked directories are Git submodules
git-gui: Trim trailing slashes from untracked submodule names
Make --no-thin the default in git-push to save server resources
git-gui: Don't delete send on Windows as it doesn't exist
git-gui: Make backporting changes from i18n version easier
git-gui: Font chooser to handle a large number of font families
git-gui: Provide 'uninstall' Makefile target to undo an installation
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Disable native platform text selection in "lists"
Sven Verdoolaege (1):
git-diff: don't squelch the new SHA1 in submodule diffs
Ulrik Sverdrup (1):
Remove duplicate note about removing commits with git-filter-branch
Väinö Järvelä (1):
Fixed update-hook example allow-users format.
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: Simon Hausmann @ 2007-09-19 19:03 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <119022570352-git-send-email-git@davidb.org>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Wednesday 19 September 2007 20:15:03 David Brown wrote:
> git-p4 was missing the execute bit setting if the file had other attribute
> bits set.
> ---
> contrib/fast-import/git-p4 | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index adaaae6..50850b8 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -932,7 +932,10 @@ class P4Sync(Command):
> data = file['data']
>
> mode = "644"
> - if file["type"].startswith("x"):
> + if (file["type"].startswith("x") or
> + file["type"].startswith("cx") or
> + file["type"].startswith("kx") or
> + file["type"].startswith("ux")):
> mode = "755"
> elif file["type"] == "symlink":
> mode = "120000"
I'm fine with this, so unless you find a better way:
Acked-By: Simon Hausmann <simon@lst.de>
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-19 19:14 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200709192103.53526.simon@lst.de>
On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
>> git-p4 was missing the execute bit setting if the file had other attribute
>> bits set.
>> ---
>> contrib/fast-import/git-p4 | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
>> index adaaae6..50850b8 100755
>> --- a/contrib/fast-import/git-p4
>> +++ b/contrib/fast-import/git-p4
>> @@ -932,7 +932,10 @@ class P4Sync(Command):
>> data = file['data']
>>
>> mode = "644"
>> - if file["type"].startswith("x"):
>> + if (file["type"].startswith("x") or
>> + file["type"].startswith("cx") or
>> + file["type"].startswith("kx") or
>> + file["type"].startswith("ux")):
>> mode = "755"
>> elif file["type"] == "symlink":
>> mode = "120000"
>
>I'm fine with this, so unless you find a better way:
Well, I just tested it, and it still doesn't work, so I need to take some
time and try to figure out what is happening.
I'm sometimes getting back 'xtext', and sometimes things like 'text+mx'
back from perforce, so I need to read up, and really figure out what to
look for.
David
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: Dana How @ 2007-09-19 19:31 UTC (permalink / raw)
To: Simon Hausmann, git, danahow
In-Reply-To: <20070919191412.GA6475@old.davidb.org>
On 9/19/07, David Brown <git@davidb.org> wrote:
> On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
> >On Wednesday 19 September 2007 20:15:03 David Brown wrote:
> >> git-p4 was missing the execute bit setting if the file had other attribute
> >> bits set.
> >
> >I'm fine with this, so unless you find a better way:
>
> Well, I just tested it, and it still doesn't work, so I need to take some
> time and try to figure out what is happening.
>
> I'm sometimes getting back 'xtext', and sometimes things like 'text+mx'
> back from perforce, so I need to read up, and really figure out what to
> look for.
The output of "git p4 filetypes" was enough for me
when I wrote my p4 front-end to fast-import;
I never did read the p4 manual.
Have fun,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] User Manual: add a chapter for submodules
From: Junio C Hamano @ 2007-09-19 19:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, J. Bruce Fields
In-Reply-To: <20070919174250.GC16235@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Signed-off-by: Michael Smith <msmith@cbnco.com>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Thanks.
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index ecb2bf9..ce0cf38 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3155,6 +3155,181 @@ a tree which you are in the process of working on.
> If you blow the index away entirely, you generally haven't lost any
> information as long as you have the name of the tree that it described.
>
> +[[submodules]]
> +Submodules
> +==========
> +
> +This tutorial explains how to create and publish a repository with submodules
> +using the gitlink:git-submodule[1] command.
> +
> +Submodules maintain their own identity; the submodule support just stores the
> +submodule repository location and commit ID, so other developers who clone the
> +superproject can easily clone all the submodules at the same revision.
> +
> +To see how submodule support works, create (for example) four example
> +repository that can be used later as a submodule:
s/repository/repositories/;
> +-------------------------------------------------
> +$ mkdir ~/git
> +$ cd ~/git
> +$ for i in a b c d
> +do
> + mkdir $i
> + cd $i
> + git init
> + echo "module $i" > $i.txt
> + git add $i.txt
> + git commit -m "Initial commit, submodule $mod"
s/\$mod/$i/;
> + cd ..
> +done
> +-------------------------------------------------
> +
> +Now create the superproject and add all the submodules:
> +
> +-------------------------------------------------
> +$ mkdir super
> +$ cd super
> +$ git init
> +$ echo hi > super.txt
> +$ git add super.txt
> +$ git commit -m "Initial commit of empty superproject"
This is not *empty*; do you even need this step?
> +$ for i in a b c d
> +do
> + git submodule add ~/git/$i
> +done
> +-------------------------------------------------
> +
> +See what files `git submodule` created:
> +
> +-------------------------------------------------
> +$ ls -a
> +. .. .git .gitmodules a b c d super.txt
> +-------------------------------------------------
> +
> +The `git submodule add` command does a couple of things:
> +
> +- It clones the submodule under the current directory and by default checks out
> + the master branch.
> +- It adds the submodule's clone path to the `.gitmodules` file and adds this
> + file to the index, ready to be committed.
> +- It adds the submodule's current commit ID to the index, ready to be
> + committed.
> +
> +Commit the superproject:
> +
> +-------------------------------------------------
> +$ git commit -m "Add submodules a, b, c, d."
> +-------------------------------------------------
s/c, d./c and d./;
> +
> +Now clone the superproject:
> +
> +-------------------------------------------------
> +$ cd ..
> +$ git clone super cloned
> +$ cd cloned
> +-------------------------------------------------
> +
> +The submodule directories are there, but they're empty:
> +
> +-------------------------------------------------
> +$ ls -a a
> +. ..
> +$ git submodule status
> +-d266b9873ad50488163457f025db7cdd9683d88b a
> +-e81d457da15309b4fef4249aba9b50187999670d b
> +-c1536a972b9affea0f16e0680ba87332dc059146 c
> +-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
> +-------------------------------------------------
You might want to mention...
Note: the commit object names shown above would be different for
you, but they should match the HEAD commit object names of your
repositories. You can check it by doing:
$ git ls-remote ../a
> +Pulling down the submodules is a two-step process. First run `git submodule
> +init` to add the submodule repository URLs to `.git/config`:
> +
> +-------------------------------------------------
> +$ git submodule init
> +-------------------------------------------------
> +
> +Now use `git submodule update` to clone the repositories and check out the
> +commits specified in the superproject:
> +
> +-------------------------------------------------
> +$ git submodule update
> +$ cd a
> +$ ls -a
> +. .. .git a.txt
> +-------------------------------------------------
> +
> +One major difference between `git submodule update` and `git submodule add` is
> +that `git submodule update` checks out a specific commit, rather than the tip
> +of a branch. It's like checking out a tag: the head is detached, so you're not
> +working on a branch.
> +
> +-------------------------------------------------
> +$ git branch
> +* (no branch)
> + master
> +-------------------------------------------------
> +
> +If you want to make a change within a submodule, you should first check out a
> +branch, make your changes, publish the change within the submodule, and then
> +update the superproject to reference the new commit:
> +
> +-------------------------------------------------
> +$ git branch
> +* (no branch)
> + master
> +$ git checkout master
I am not so sure about this advice. Don't you want to see how
the detached HEAD and 'master' (or any other branches) are
related before doing this? You might even want to create a
"fix-up" branch that is rooted at the detached HEAD if the
change you are making is to fix minor details of the submodule
to suit what superproject wants (i.e. "little feature that is
applicable to the submodule as a standalone project, meant to
be pushed back to the submodule upstream").
> +$ echo "adding a line again" >> a.txt
> +$ git commit -a -m "Updated the submodule from within the superproject."
> +$ git push
> +$ cd ..
> +$ git add a
Before doing this "git add", it would be educational to have the
user do
$ git diff
which would say that now the submodule is being updated.
> +$ git commit -m "Updated submodule a."
> +$ git push
> +-------------------------------------------------
> +
> +NOTE: This means that you have to run `git submodule update` after `git pull`
> +if you want to update the subprojects, too.
I do not quite understand this note. I do understand the part
after "that you have to", but I do not know how the above
example relates to that --- iow, the above example does not
seem to "mean" such thing to me.
Also "submodule" is used consistently in the rest of the
document but this sentence talks about "subproject".
> +Problems with submodules
> +------------------------
The list is good, but are they Problems or pitfalls to watch out
for?
> +Always publish the submodule change before publishing the change to the
> +superproject that references it. If you forget to publish the submodule change,
> +others won't be able to clone the repository:
The same caution applies not to rewind branches in submodule
beyond commits that were ever recorded in any superproject.
> +-------------------------------------------------
> +$ echo i added another line to this file >> a.txt
> +$ git commit -a -m "doing it wrong this time"
It is not clear in which repository you are supposed to try this
command in the example sequence, as we crossed the section
boundary. I am _guessing_ that the above two commands are to be
run inside ~/git/cloned-2/a after redoing ~/git/cloned-2 the
same way as you did ~/git/cloned, but you may want to make it
clear.
> +$ cd ..
> +$ git add a
> +$ git commit -m "Updated submodule a again."
> +$ git push
> +$ cd ~/git/cloned
> +$ git pull
> +$ git submodule update
> +error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
> +Did you forget to 'git add'?
I sense there is a bug in "git submodule update" here. I do not
have time to look at what it's doing right now, but this is a
symptom of running:
$ git checkout 261dfac35...
without checking if that is a valid commit object name, and git
checkout cannot decide if the request is about detaching the
head at commit 261dfac35 or checking the path 261dfac35 out of
the current index. Porcelains should check with "cat-file -t"
first.
In addition we probably would want to teach "git checkout" about
the "--" separator, so that this can be disambiguated like this:
$ git checkout 261dfac35 --
> +Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
> +-------------------------------------------------
> +
> +It's not safe to run `git submodule update` if you've made changes within a
> +submodule. They will be silently overwritten:
You want to distinguish two cases here. Local uncommitted
changes, and committed changes. The latter case is switched
away without too much noise, which is what you are demonstrating
here. I _think_ local uncommitted changes will not be
overwritten at all, unless "submodule update" does "reset
--hard", which I suspect it doesn't.
> +-------------------------------------------------
> +$ cat a.txt
> +module a
> +$ echo line added from private2 >> a.txt
> +$ git commit -a -m "line added inside private2"
> +$ cd ..
> +$ git submodule update
> +Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
> +$ cd a
> +$ cat a.txt
> +module a
> +-------------------------------------------------
> +
> +NOTE: The changes are still visible in the submodule's reflog.
> +
> [[low-level-operations]]
> Low-level git operations
> ========================
> --
> 1.5.3.1.1.g1e61-dirty
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-19 19:49 UTC (permalink / raw)
To: Dana How; +Cc: Simon Hausmann, git
In-Reply-To: <56b7f5510709191231g22385e32y9c34d711d65b3bb7@mail.gmail.com>
On Wed, Sep 19, 2007 at 12:31:52PM -0700, Dana How wrote:
>On 9/19/07, David Brown <git@davidb.org> wrote:
>> On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
>> >On Wednesday 19 September 2007 20:15:03 David Brown wrote:
>> >> git-p4 was missing the execute bit setting if the file had other attribute
>> >> bits set.
>> >
>> >I'm fine with this, so unless you find a better way:
>>
>> Well, I just tested it, and it still doesn't work, so I need to take some
>> time and try to figure out what is happening.
>>
>> I'm sometimes getting back 'xtext', and sometimes things like 'text+mx'
>> back from perforce, so I need to read up, and really figure out what to
>> look for.
>
>The output of "git p4 filetypes" was enough for me
>when I wrote my p4 front-end to fast-import;
>I never did read the p4 manual.
I have a patch based on what 'p4 help filetypes'. I'm running it now on a
large test repository, and I'll compare the results when it is done.
Provided it works, I'll send a new patch in a little bit.
David
^ permalink raw reply
* [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-19 20:12 UTC (permalink / raw)
To: git; +Cc: David Brown
In-Reply-To: <119022570352-git-send-email-git@davidb.org>
git-p4 was missing the execute bit setting if the file had other attribute
bits set.
---
contrib/fast-import/git-p4 | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index adaaae6..557649a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -63,6 +63,14 @@ def system(cmd):
if os.system(cmd) != 0:
die("command failed: %s" % cmd)
+def isP4Exec(kind):
+ """Determine if a Perforce 'kind' should have execute permission
+
+ 'p4 help filetypes' gives a list of the types. If it starts with 'x',
+ or x follows one of a few letters. Otherwise, if there is an 'x' after
+ a plus sign, it is also executable"""
+ return (re.search(r"(^[cku]?x)|\+.*x", kind) != None)
+
def p4CmdList(cmd, stdin=None, stdin_mode='w+b'):
cmd = "p4 -G %s" % cmd
if verbose:
@@ -932,7 +940,7 @@ class P4Sync(Command):
data = file['data']
mode = "644"
- if file["type"].startswith("x"):
+ if isP4Exec(file["type"]):
mode = "755"
elif file["type"] == "symlink":
mode = "120000"
--
1.5.3
^ permalink raw reply related
* [PATCH] Add git-rev-list --invert-match
From: Bart Trojanowski @ 2007-09-19 20:26 UTC (permalink / raw)
To: git
Example usage:
git log --invert-match --grep="uninteresting"
This command will prune out all commits that match the grep pattern.
How it works:
The --invert-match flag sets invert_match, in rev_info. This boolean
is later checked in commit_match() and if set it inverts the result of
grep_buffer().
---
revision.c | 11 ++++++++++-
revision.h | 3 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 33d092c..57b2d0f 100644
--- a/revision.c
+++ b/revision.c
@@ -1182,6 +1182,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
regflags |= REG_ICASE;
continue;
}
+ if (!strcmp(arg, "--invert-match")) {
+ revs->invert_match = 1;
+ continue;
+ }
if (!strcmp(arg, "--all-match")) {
all_match = 1;
continue;
@@ -1383,11 +1387,16 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
static int commit_match(struct commit *commit, struct rev_info *opt)
{
+ int result;
+
if (!opt->grep_filter)
return 1;
- return grep_buffer(opt->grep_filter,
+
+ result = grep_buffer(opt->grep_filter,
NULL, /* we say nothing, not even filename */
commit->buffer, strlen(commit->buffer));
+
+ return opt->invert_match ? !result : result;
}
static struct commit *get_revision_1(struct rev_info *revs)
diff --git a/revision.h b/revision.h
index 98a0a8f..ead04a7 100644
--- a/revision.h
+++ b/revision.h
@@ -48,7 +48,8 @@ struct rev_info {
parents:1,
reverse:1,
cherry_pick:1,
- first_parent_only:1;
+ first_parent_only:1,
+ invert_match:1;
/* Diff flags */
unsigned int diff:1,
--
1.5.3.1.154.g734e65
^ permalink raw reply related
* Re: [PATCH] User Manual: add a chapter for submodules
From: J. Bruce Fields @ 2007-09-19 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vbqbyphil.fsf@gitster.siamese.dyndns.org>
On Wed, Sep 19, 2007 at 12:44:18PM -0700, Junio C Hamano wrote:
> Also "submodule" is used consistently in the rest of the
> document but this sentence talks about "subproject".
I never liked the terms "submodule" or "subproject" much--it seems to
focus attention in the wrong place. it's the "superproject" that's the
new and interesting thing here, while the submodules themselves are all
just standard git projects, right?
But I guess that's kind of a silly complaint, and late besides.
--b.
^ permalink raw reply
* Re: [EGIT PATCH] Change to simplified icon.
From: Robin Rosenberg @ 2007-09-19 20:57 UTC (permalink / raw)
To: Ben Konrath; +Cc: git, Shawn O. Pearce, David Watson
In-Reply-To: <200709192019.13096.robin.rosenberg.lists@dewire.com>
onsdag 19 september 2007 skrev Robin Rosenberg:
> I'll leave this one in my patch tree for now. The Egit icon contest is stil
open to all.
Here's another icon. The cup inspired the drug used to code the plugin. The
+/-'s from the git logo, the blue color to look better with the other icons
in Eclipse's about box and the rest comes form the fact that I cannot draw.
-- robin
^ permalink raw reply
* Re: [EGIT PATCH] Change to simplified icon.
From: Robin Rosenberg @ 2007-09-19 20:59 UTC (permalink / raw)
To: Ben Konrath; +Cc: git, Shawn O. Pearce, David Watson
In-Reply-To: <200709192257.39209.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
onsdag 19 september 2007 skrev Robin Rosenberg:
> onsdag 19 september 2007 skrev Robin Rosenberg:
> > I'll leave this one in my patch tree for now. The Egit icon contest is stil
> open to all.
>
> Here's another icon. The cup inspired the drug used to code the plugin. The
> +/-'s from the git logo, the blue color to look better with the other icons
> in Eclipse's about box and the rest comes form the fact that I cannot draw.
>
And the subject matter :)
-- robin
[-- Attachment #2: egit.png --]
[-- Type: image/png, Size: 1366 bytes --]
^ permalink raw reply
* Re: [PATCH] User Manual: add a chapter for submodules
From: Sven Verdoolaege @ 2007-09-19 21:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20070919174250.GC16235@genesis.frugalware.org>
On Wed, Sep 19, 2007 at 07:42:50PM +0200, Miklos Vajna wrote:
> +Submodules maintain their own identity; the submodule support just stores the
> +submodule repository location and commit ID, so other developers who clone the
> +superproject can easily clone all the submodules at the same revision.
[..]
> +-------------------------------------------------
> +$ mkdir super
> +$ cd super
> +$ git init
> +$ echo hi > super.txt
> +$ git add super.txt
> +$ git commit -m "Initial commit of empty superproject"
> +$ for i in a b c d
> +do
> + git submodule add ~/git/$i
> +done
> +-------------------------------------------------
You may want to warn the reader not to use local URLs here if they
plan to publish their superproject.
> +It's not safe to run `git submodule update` if you've made changes within a
> +submodule. They will be silently overwritten:
This is only true if they didn't follow your advise of checking out
a branch first.
skimo
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-19 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <1190232768445-git-send-email-git@davidb.org>
On Wed, Sep 19, 2007 at 01:12:48PM -0700, David Brown wrote:
>git-p4 was missing the execute bit setting if the file had other attribute
>bits set.
>---
> contrib/fast-import/git-p4 | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
I've tested this patch on our fairly large P4 repo, and at least the tip
exactly matches the files that P4 finds. So, it at least should be better.
git-p4 still has some problems with case-insensitive servers.
Dave
^ permalink raw reply
* Re: Problem with merge when renaming
From: Alex Riesen @ 2007-09-19 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Euresti, git
In-Reply-To: <7vejgvtv0a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Sep 19, 2007 01:27:01 +0200:
> > it happens with very recent git (as of today)
> >
> >> (2) if you do "git merge -s resolve" instead of just "git
> >> merge", do you see a difference?
> >
> > yes: it has more error output.
> >
> > Trying really trivial in-index merge...
> > warning: Merge requires file-level merging
> > Nope, a really trivial in-index merge not possible
> > Trying simple merge.
> > Simple merge failed, trying Automatic merge.
> > error: init: is a directory - add individual files instead
> > fatal: Unable to process path init
> > fatal: merge program failed
> > Automatic merge failed; fix conflicts and then commit the result.
>
> Isn't this the same as the known issue here?
>
> <http://permalink.gmane.org/gmane.comp.version-control.git/53402>
>
Yes, looks similar:
.../git/t$ ./t3031-df-3way.sh -d -v -i
...
Created commit 992a330: side moves and makes changes
6 files changed, 155 insertions(+), 153 deletions(-)
create mode 100644 D
create mode 100644 D.A
delete mode 100644 D/A
delete mode 100644 D/B
delete mode 100644 D/C
create mode 100644 D0C
* ok 1: setup
* expecting success:
git read-tree -m initial side master
fatal: Entry 'D/A' would be overwritten by merge. Cannot merge.
* FAIL 2: threeway
git read-tree -m initial side master
.../git/t$
^ permalink raw reply
* Re: State of Perforce importing.
From: Reece Dunn @ 2007-09-19 21:20 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git
In-Reply-To: <46F06C0F.3040609@vilain.net>
On 19/09/2007, Sam Vilain <sam@vilain.net> wrote:
> Reece Dunn wrote:
> > There is no need to create yet another Perforce importing tool, git-p4
> > works well in most cases. If we focus on improving git-p4, extending
> > it to support the functionality mentioned here, fix the issues that
> > there are with it, then that will be more beneficial to the community
> > as they will not have to learn another tool with a different set of
> > bugs and issues.
>
> I like my approach; it's clean and I think shows a tasteful level of
> distrust towards the sanity and integrity of the data held by Perforce.
> Actually it really helped me understand what was really going on;
> because the information as displayed by for instance "p4 integrate" is
> a lot more confusing than the underlying tables (IMHO).
I agree. What I wasn't clear about in that paragraph, but had eluded
to in other comments in that email, is that having both git-p4 and
git-p4raw is a good thing as they operate on two differing use cases.
What I was referring to there is to have another equivalent of git-p4
that interfaced using the p4 client.
- Reece
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Steven Burns @ 2007-09-19 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org>
To me, the only thing that C++ has that all other mentioned languages lack
is the power you get from the templates and generic programming.
Sorting will always be faster if you can call the comparison function
directly without using a function pointer, and the only way you can create a
generic sorting algorithm is that way.
Thinking about it with a cold head, most things to hate about C++ are not in
the language but in its libraries.
The only feature I hate from the language itself is the preprocessor
(macros), which you get in C too.
And maybe I also hate the fact that C++ allows for unexperienced programmers
to create a bunch of classes and hierarchies that make sense to nobody but
them. Or even worse, unexperienced programmers start writing their own
frameworks, wrapping and re-wrapping, the same good old C function one
thousand times.
I guess that is why most C++ based projects out there have a strict list of
rules and conventions, you cannot have a stable project without them.
But, nothing prevents anybody from programming in C++ the way you describe,
using simple and clear core structures with some basic methods that
complement them (not obscure them) and make it easier to write the
algorithms.
Sadly, once you start using std::string, their overly complicated and fancy
iostreams, and bulky classes that hide too much from you, I have no other
choice than to agree and call the whole thing a mess.
Steven Burns
"Linus Torvalds" <torvalds@linux-foundation.org> wrote in message
news:alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org...
>
>
> On Fri, 7 Sep 2007, Linus Torvalds wrote:
>>
>> The fact is, git is better than the other SCM's. And good taste (and C)
>> is
>> one of the reasons for that.
>
> To be very specific:
> - simple and clear core datastructures, with *very* lean and aggressive
> code to manage them that takes the whole approach of "simplicity over
> fancy" to the extreme.
> - a willingness to not abstract away the data structures and algorithms,
> because those are the *whole*point* of core git.
>
> And if you want a fancier language, C++ is absolutely the worst one to
> choose. If you want real high-level, pick one that has true high-level
> features like garbage collection or a good system integration, rather than
> something that lacks both the sparseness and straightforwardness of C,
> *and* doesn't even have the high-level bindings to important concepts.
>
> IOW, C++ is in that inconvenient spot where it doesn't help make things
> simple enough to be truly usable for prototyping or simple GUI
> programming, and yet isn't the lean system programming language that C is
> that actively encourags you to use simple and direct constructs.
>
> Linus
^ permalink raw reply
* quote/strbuf series, take 3
From: Pierre Habouzit @ 2007-09-19 22:42 UTC (permalink / raw)
To: gitster; +Cc: git
Here is the take 3. wrt last time: the need for strbuf_addvf has been
avoided. It was not really needed for many places, and I chose ad-hoc
solutions for each. It has been done in a new patch (inserted at slot
2).
Note that this patch 2/7 looks curious, especially the:
write_fd_or_whine(..., "\n", 1, ...)
it is rewritten in a following patch in the series, it's just to have
an intermediate working state. Don't really mind the bad look of it,
please :).
As a consequence, strbuf_addvf is no longer added nor used in the
series.
I just rebased it on the last next (with the new git-fetch).
^ permalink raw reply
* Re: [EGIT PATCH] Change to simplified icon.
From: Ben Konrath @ 2007-09-19 22:49 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200709192019.13096.robin.rosenberg.lists@dewire.com>
On Wed, 2007-09-19 at 20:19 +0200, Robin Rosenberg wrote:
> onsdag 19 september 2007 skrev Ben Konrath:
> > Hi Robin,
> >
> > Here's a patch that changes the icon to something that is a little more
> > aesthetically pleasing than the one I iniitially submitted. Feel free to
> > use the one you like best.
>
> The icon looks very similar to the one in GitWeb. The simplified is, without,
> making a bitwise compare, is seems identical to the Git icon. Is that
> appropriate? What do the author of that icon, and other Git developers, think?
I did actually make this icon with gimp but it is heavily inspired by
the GitWeb icon. But I think this is moot because the icon you just made
seems to be a better fit :)
Cheers, Ben
> The plugin. after all, does steal ideas and repository format from Git,
> but is in fact a completely separate implementation.
>
> I'll leave this one in my patch tree for now. The Egit icon contest is stil open to all.
>
> -- robin
>
^ permalink raw reply
* Re: Latest builtin-commit series
From: Junio C Hamano @ 2007-09-19 23:16 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Git Mailing List
In-Reply-To: <1190129009.23692.24.camel@hinata.boston.redhat.com>
This series somewhat collided with Pierre's strbuf clean-ups. I
queued it in 'pu' for now after fixing the conflicts up.
I haven't looked at the code enough to give any meaningful
comments yet, but I agree with most of the comments Dscho and
others raised on the topic already.
^ permalink raw reply
* Re: [PATCH 6/7] Export rerere() and launch_editor().
From: Junio C Hamano @ 2007-09-19 23:52 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1190074016669-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> +/* Export for builtin-commit. */
> +int rerere(void)
> +{
> + struct path_list merge_rr = { NULL, 0, 0, 1 };
> + int fd;
> +
> + git_config(git_rerere_config);
> + if (!is_rerere_enabled())
> + return 0;
> +
> + merge_rr_path = xstrdup(git_path("rr-cache/MERGE_RR"));
> + fd = hold_lock_file_for_update(&write_lock, merge_rr_path, 1);
> + read_rr(&merge_rr);
> + return do_plain_rerere(&merge_rr, fd);
> +}
Is it just me who sees a suboptimal cut and paste here?
BTW, [1-5/7] look good so far.
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 29d057c..2f51ae0 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -415,18 +415,39 @@ static int is_rerere_enabled(void)
return 1;
}
-int cmd_rerere(int argc, const char **argv, const char *prefix)
+static int setup_rerere(struct path_list *merge_rr)
{
- struct path_list merge_rr = { NULL, 0, 0, 1 };
- int i, fd = -1;
+ int fd;
git_config(git_rerere_config);
if (!is_rerere_enabled())
- return 0;
+ return -1;
merge_rr_path = xstrdup(git_path("rr-cache/MERGE_RR"));
fd = hold_lock_file_for_update(&write_lock, merge_rr_path, 1);
- read_rr(&merge_rr);
+ read_rr(merge_rr);
+ return fd;
+}
+
+int rerere(void)
+{
+ struct path_list merge_rr = { NULL, 0, 0, 1 };
+ int fd;
+
+ fd = setup_rerere(&merge_rr);
+ if (fd < 0)
+ return 0;
+ return do_plain_rerere(&merge_rr, fd);
+}
+
+int cmd_rerere(int argc, const char **argv, const char *prefix)
+{
+ struct path_list merge_rr = { NULL, 0, 0, 1 };
+ int i, fd;
+
+ fd = setup_rerere(&merge_rr);
+ if (fd < 0)
+ return 0;
if (argc < 2)
return do_plain_rerere(&merge_rr, fd);
^ permalink raw reply related
* [PATCH] User Manual: add a chapter for submodules
From: Miklos Vajna @ 2007-09-20 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7vbqbyphil.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Michael Smith <msmith@cbnco.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
[ 2nd version ]
On Wed, Sep 19, 2007 at 12:44:18PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > +To see how submodule support works, create (for example) four example
> > +repository that can be used later as a submodule:
>
> s/repository/repositories/;
fixed.
> > +$ for i in a b c d
> > +do
> > + mkdir $i
> > + cd $i
> > + git init
> > + echo "module $i" > $i.txt
> > + git add $i.txt
> > + git commit -m "Initial commit, submodule $mod"
>
> s/\$mod/$i/;
fixed
> > +$ echo hi > super.txt
> > +$ git add super.txt
> > +$ git commit -m "Initial commit of empty superproject"
>
> This is not *empty*; do you even need this step?
in fact, no :) removed.
> > +-------------------------------------------------
> > +$ git commit -m "Add submodules a, b, c, d."
> > +-------------------------------------------------
>
> s/c, d./c and d./;
fixed.
> > +$ ls -a a
> > +. ..
> > +$ git submodule status
> > +-d266b9873ad50488163457f025db7cdd9683d88b a
> > +-e81d457da15309b4fef4249aba9b50187999670d b
> > +-c1536a972b9affea0f16e0680ba87332dc059146 c
> > +-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
> > +-------------------------------------------------
>
> You might want to mention...
>
> Note: the commit object names shown above would be different for
> you, but they should match the HEAD commit object names of your
> repositories. You can check it by doing:
>
> $ git ls-remote ../a
i've added such a note.
> > +If you want to make a change within a submodule, you should first check out a
> > +branch, make your changes, publish the change within the submodule, and then
> > +update the superproject to reference the new commit:
> > +
> > +-------------------------------------------------
> > +$ git branch
> > +* (no branch)
> > + master
> > +$ git checkout master
>
> I am not so sure about this advice. Don't you want to see how
> the detached HEAD and 'master' (or any other branches) are
> related before doing this? You might even want to create a
> "fix-up" branch that is rooted at the detached HEAD if the
> change you are making is to fix minor details of the submodule
> to suit what superproject wants (i.e. "little feature that is
> applicable to the submodule as a standalone project, meant to
> be pushed back to the submodule upstream").
right, changed it to two examples, one about "git checkout master", and
the other about "git checkout -b fix-up"
> > +$ git push
> > +$ cd ..
> > +$ git add a
>
> Before doing this "git add", it would be educational to have the
> user do
>
> $ git diff
>
> which would say that now the submodule is being updated.
added.
> > +$ git commit -m "Updated submodule a."
> > +$ git push
> > +-------------------------------------------------
> > +
> > +NOTE: This means that you have to run `git submodule update` after `git pull`
> > +if you want to update the subprojects, too.
>
> I do not quite understand this note. I do understand the part
> after "that you have to", but I do not know how the above
> example relates to that --- iow, the above example does not
> seem to "mean" such thing to me.
>
> Also "submodule" is used consistently in the rest of the
> document but this sentence talks about "subproject".
yes, it was illogical to use a 'note' here as it's not related. i've
just added a separte sentence about this without the 'this means'.
> > +Problems with submodules
> > +------------------------
>
> The list is good, but are they Problems or pitfalls to watch out
> for?
the later :) title changed.
> > +Always publish the submodule change before publishing the change to the
> > +superproject that references it. If you forget to publish the submodule change,
> > +others won't be able to clone the repository:
>
> The same caution applies not to rewind branches in submodule
> beyond commits that were ever recorded in any superproject.
i've added a paragraph about this issue.
> > +-------------------------------------------------
> > +$ echo i added another line to this file >> a.txt
> > +$ git commit -a -m "doing it wrong this time"
>
> It is not clear in which repository you are supposed to try this
> command in the example sequence, as we crossed the section
> boundary. I am _guessing_ that the above two commands are to be
> run inside ~/git/cloned-2/a after redoing ~/git/cloned-2 the
> same way as you did ~/git/cloned, but you may want to make it
> clear.
right, i forgot the 'cd ~/git/super/a'. provided the repos are
symmetric, i think it would just make the situation unnecessary
complicated to clone a third repo.
> > +$ git submodule update
> > +error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
> > +Did you forget to 'git add'?
>
> I sense there is a bug in "git submodule update" here. I do not
> have time to look at what it's doing right now, but this is a
> symptom of running:
>
> $ git checkout 261dfac35...
>
> without checking if that is a valid commit object name, and git
> checkout cannot decide if the request is about detaching the
> head at commit 261dfac35 or checking the path 261dfac35 out of
> the current index. Porcelains should check with "cat-file -t"
> first.
hm yes. i think as long as this behaviour is not changed, it would not
be good to remove the "Did you forget to 'git add'?" part from the
example
> > +Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
> > +-------------------------------------------------
> > +
> > +It's not safe to run `git submodule update` if you've made changes within a
> > +submodule. They will be silently overwritten:
>
> You want to distinguish two cases here. Local uncommitted
> changes, and committed changes. The latter case is switched
> away without too much noise, which is what you are demonstrating
> here. I _think_ local uncommitted changes will not be
> overwritten at all, unless "submodule update" does "reset
> --hard", which I suspect it doesn't.
i've just checked that it does a git checkout, so uncommitted changes
are preserved. i've updated this part to mention this fact.
i've also added the suggestions by skimo.
VMiklos
Documentation/user-manual.txt | 175 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ecb2bf9..ce0cf38 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3155,6 +3155,181 @@ a tree which you are in the process of working on.
If you blow the index away entirely, you generally haven't lost any
information as long as you have the name of the tree that it described.
+[[submodules]]
+Submodules
+==========
+
+This tutorial explains how to create and publish a repository with submodules
+using the gitlink:git-submodule[1] command.
+
+Submodules maintain their own identity; the submodule support just stores the
+submodule repository location and commit ID, so other developers who clone the
+superproject can easily clone all the submodules at the same revision.
+
+To see how submodule support works, create (for example) four example
+repository that can be used later as a submodule:
+
+-------------------------------------------------
+$ mkdir ~/git
+$ cd ~/git
+$ for i in a b c d
+do
+ mkdir $i
+ cd $i
+ git init
+ echo "module $i" > $i.txt
+ git add $i.txt
+ git commit -m "Initial commit, submodule $mod"
+ cd ..
+done
+-------------------------------------------------
+
+Now create the superproject and add all the submodules:
+
+-------------------------------------------------
+$ mkdir super
+$ cd super
+$ git init
+$ echo hi > super.txt
+$ git add super.txt
+$ git commit -m "Initial commit of empty superproject"
+$ for i in a b c d
+do
+ git submodule add ~/git/$i
+done
+-------------------------------------------------
+
+See what files `git submodule` created:
+
+-------------------------------------------------
+$ ls -a
+. .. .git .gitmodules a b c d super.txt
+-------------------------------------------------
+
+The `git submodule add` command does a couple of things:
+
+- It clones the submodule under the current directory and by default checks out
+ the master branch.
+- It adds the submodule's clone path to the `.gitmodules` file and adds this
+ file to the index, ready to be committed.
+- It adds the submodule's current commit ID to the index, ready to be
+ committed.
+
+Commit the superproject:
+
+-------------------------------------------------
+$ git commit -m "Add submodules a, b, c, d."
+-------------------------------------------------
+
+Now clone the superproject:
+
+-------------------------------------------------
+$ cd ..
+$ git clone super cloned
+$ cd cloned
+-------------------------------------------------
+
+The submodule directories are there, but they're empty:
+
+-------------------------------------------------
+$ ls -a a
+. ..
+$ git submodule status
+-d266b9873ad50488163457f025db7cdd9683d88b a
+-e81d457da15309b4fef4249aba9b50187999670d b
+-c1536a972b9affea0f16e0680ba87332dc059146 c
+-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
+-------------------------------------------------
+
+Pulling down the submodules is a two-step process. First run `git submodule
+init` to add the submodule repository URLs to `.git/config`:
+
+-------------------------------------------------
+$ git submodule init
+-------------------------------------------------
+
+Now use `git submodule update` to clone the repositories and check out the
+commits specified in the superproject:
+
+-------------------------------------------------
+$ git submodule update
+$ cd a
+$ ls -a
+. .. .git a.txt
+-------------------------------------------------
+
+One major difference between `git submodule update` and `git submodule add` is
+that `git submodule update` checks out a specific commit, rather than the tip
+of a branch. It's like checking out a tag: the head is detached, so you're not
+working on a branch.
+
+-------------------------------------------------
+$ git branch
+* (no branch)
+ master
+-------------------------------------------------
+
+If you want to make a change within a submodule, you should first check out a
+branch, make your changes, publish the change within the submodule, and then
+update the superproject to reference the new commit:
+
+-------------------------------------------------
+$ git branch
+* (no branch)
+ master
+$ git checkout master
+$ echo "adding a line again" >> a.txt
+$ git commit -a -m "Updated the submodule from within the superproject."
+$ git push
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a."
+$ git push
+-------------------------------------------------
+
+NOTE: This means that you have to run `git submodule update` after `git pull`
+if you want to update the subprojects, too.
+
+Problems with submodules
+------------------------
+
+Always publish the submodule change before publishing the change to the
+superproject that references it. If you forget to publish the submodule change,
+others won't be able to clone the repository:
+
+-------------------------------------------------
+$ echo i added another line to this file >> a.txt
+$ git commit -a -m "doing it wrong this time"
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a again."
+$ git push
+$ cd ~/git/cloned
+$ git pull
+$ git submodule update
+error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
+Did you forget to 'git add'?
+Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
+-------------------------------------------------
+
+It's not safe to run `git submodule update` if you've made changes within a
+submodule. They will be silently overwritten:
+
+-------------------------------------------------
+$ cat a.txt
+module a
+$ echo line added from private2 >> a.txt
+$ git commit -a -m "line added inside private2"
+$ cd ..
+$ git submodule update
+Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
+$ cd a
+$ cat a.txt
+module a
+-------------------------------------------------
+
+NOTE: The changes are still visible in the submodule's reflog.
+
[[low-level-operations]]
Low-level git operations
========================
--
1.5.3.1.1.g1e61-dirty
^ 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