* 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: [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: [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: [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: [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
* [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
* [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
* 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
* 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: 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] [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: 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
* [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: 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
* [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: [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
* 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: [EGIT PATCH] Change to simplified icon.
From: Robin Rosenberg @ 2007-09-19 18:19 UTC (permalink / raw)
To: Ben Konrath; +Cc: git
In-Reply-To: <20070918222416.GB11990@toast.toronto.redhat.com>
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?
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: State of Perforce importing.
From: David Brown @ 2007-09-19 18:25 UTC (permalink / raw)
To: Reece Dunn; +Cc: Simon Hausmann, Git
In-Reply-To: <3f4fd2640709191123j64b53878vc96d785c13c3bca2@mail.gmail.com>
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.
David
^ permalink raw reply
* Re: State of Perforce importing.
From: Reece Dunn @ 2007-09-19 18:23 UTC (permalink / raw)
To: Simon Hausmann, Git
In-Reply-To: <20070919171243.GA23902@old.davidb.org>
On 19/09/2007, David Brown <git@davidb.org> wrote:
> On Wed, Sep 19, 2007 at 08:19:11AM +0200, Simon Hausmann wrote:
>
> >> An additional problem:
> >>
> >> - git-p4 doesn't preserve the execute permission bit from Perforce.
> >
> >Hmm, can you paste the output of
> >
> > p4 fstat //path/in/depot/to/file/that/is/imported/incorrectly
> >
> >? I'm interested in the type of the file that p4 reports.
>
> headType kxtext
>
> so the problem is that the git-p4 is only looking for an 'x' at the start.
> According to 'p4 help filetypes', we need to use execute for any of:
>
> cxtext, kxtext, uxbinary, and the others that start with 'x'.
>
> 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.
- Reece
^ permalink raw reply
* [PATCH] User Manual: add a chapter for submodules
From: Miklos Vajna @ 2007-09-19 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181405120.6203@juice.ott.cti.com>
Signed-off-by: Michael Smith <msmith@cbnco.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Tue, Sep 18, 2007 at 02:12:17PM -0400, Michael Smith <msmith@cbnco.com> wrote:
> On Tue, 18 Sep 2007, Miklos Vajna wrote:
>
> > Michael, i think the wiki version is better as my example does not
> > contain any extra to the wiki version. is it ok if i would send a patch
> > to include your work in the official docs?
>
> Thanks, that would be great.
here it is. this version is a bit shorter than the wiki one, but i think it
does not contain less useful info
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
* Re: State of Perforce importing.
From: David Brown @ 2007-09-19 17:12 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Git
In-Reply-To: <200709190819.12188.simon@lst.de>
On Wed, Sep 19, 2007 at 08:19:11AM +0200, Simon Hausmann wrote:
>> An additional problem:
>>
>> - git-p4 doesn't preserve the execute permission bit from Perforce.
>
>Hmm, can you paste the output of
>
> p4 fstat //path/in/depot/to/file/that/is/imported/incorrectly
>
>? I'm interested in the type of the file that p4 reports.
headType kxtext
so the problem is that the git-p4 is only looking for an 'x' at the start.
According to 'p4 help filetypes', we need to use execute for any of:
cxtext, kxtext, uxbinary, and the others that start with 'x'.
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.
David
^ permalink raw reply
* Re: Repository backups
From: Johannes Schindelin @ 2007-09-19 15:27 UTC (permalink / raw)
To: Jason Sewall; +Cc: git
In-Reply-To: <31e9dd080709190814t6ef8b725w8a8320685e70578b@mail.gmail.com>
Hi,
On Wed, 19 Sep 2007, Jason Sewall wrote:
> I'd like to build a modest safety net for my various git repositories
> in case of catastrophic failure. Currently, everything is backed up on
> machines in the same building. I'm not expecting the Computer Science
> building to get hit by terrorists and we're in a seismically stable
> place, but there *is* construction nearby...
>
> Anyway, my university offers a "mass storage" tape-based service that
> is supposedly very safe. We are encouraged to give them single big
> files for backups.
>
> The temptation to just make bundles of all branch heads is great but
> probably not what I really want - things like reflogs don't get handed
> off with those, if I understand correctly.
>
> Is there any argument against just making a tar of a bare clone of the
> repo?
If you make a bare clone, you lose reflogs, too.
So I would backup the complete .git/ directory instead.
Hth,
Dscho
^ permalink raw reply
* Repository backups
From: Jason Sewall @ 2007-09-19 15:14 UTC (permalink / raw)
To: git
I'd like to build a modest safety net for my various git repositories
in case of catastrophic failure. Currently, everything is backed up on
machines in the same building. I'm not expecting the Computer Science
building to get hit by terrorists and we're in a seismically stable
place, but there *is* construction nearby...
Anyway, my university offers a "mass storage" tape-based service that
is supposedly very safe. We are encouraged to give them single big
files for backups.
The temptation to just make bundles of all branch heads is great but
probably not what I really want - things like reflogs don't get handed
off with those, if I understand correctly.
Is there any argument against just making a tar of a bare clone of the
repo? Any other ideas? I'm reluctant to actually clone into the tape
(SAM-FS, which I know nothing about) because of the number of files it
would create and the lack of git tools on the machines with access to
this machine.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Pierre Habouzit @ 2007-09-19 13:36 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20070919144604.7deca4f7.froese@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
On Wed, Sep 19, 2007 at 12:46:04PM +0000, Edgar Toernig wrote:
> Pierre Habouzit wrote:
> >
> > +void strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
> > +{
> > + int len;
> > +
> > + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> > + if (len < 0) {
> > + len = 0;
> > + }
> > + if (len > strbuf_avail(sb)) {
> > + strbuf_grow(sb, len);
> > + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> > + if (len > strbuf_avail(sb)) {
> > + die("this should not happen, your snprintf is broken");
> > + }
> > + }
> > + strbuf_setlen(sb, sb->len + len);
> > +}
>
> The second vsnprintf won't work as the first one consumed all args
> from va_list ap. You need to va_copy the ap. But iirc va_copy poses
> compatibility issues. Unless va_copy is made available somehow,
> I would suggest to let the caller know that the buffer was too small
> (but isn't any more) and it has to call the function again:
That's what I thought, and then nfvasprintf in trace.c suffers from
the same issue, as I copied the code from there.
> do {
> va_start(ap, fmt);
> again = strbuf_addvf(sb, fmt, ap);
> va_end(ap);
> } while (again);
in fact doing it twice is enough but either way I don't like to impose
that to the caller :/ I mean it's totally stupid to have to do that on a
strbuf. of course we could provide a macro doing that ...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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