* mergetool ignore
From: Caleb Cushing @ 2009-01-16 20:19 UTC (permalink / raw)
To: git
is there any way to tell git to ignore merging certain files? I've got
files that have the same name in each directory. but I can't merge
them with an editor... it'd be easier to be able to ignore them with
git mergetool... and handle them manually.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* [PATCH] githooks.txt: add missing word
From: Stephan Beyer @ 2009-01-16 20:36 UTC (permalink / raw)
To: git; +Cc: gitster, Stephan Beyer
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Documentation/githooks.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index e4d61d5..1fd512b 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -90,7 +90,7 @@ This hook is invoked by 'git-commit' right after preparing the
default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file
-that the commit log message. The second is the source of the commit
+that contains the commit log message. The second is the source of the commit
message, and can be: `message` (if a `-m` or `-F` option was
given); `template` (if a `-t` option was given or the
configuration option `commit.template` is set); `merge` (if the
--
1.6.1.160.gecdb
^ permalink raw reply related
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Schindelin @ 2009-01-16 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, SZEDER Gábor, git
In-Reply-To: <7vr63386rc.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 16 Jan 2009, Junio C Hamano wrote:
> Dscho, what performance issues do you have in mind, by the way?
Back when I tried to fix the worktree issue (still the subject of some of
my nightmares), I set the GIT_DIR (IIRC) to the absolute path, just to
make sure that it works in all cases, even when the work tree is far away
from the GIT_DIR (think DOS drives, blech).
I could be mistaken, but I think it was there that somebody did some
timing and found that lstats on hundreds of absolute paths were
substantially slower than on relative paths.
Now, think of git-gc in a large number of bare repositories, such as
repo.or.cz. It does matter there.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Johannes Schindelin @ 2009-01-16 20:58 UTC (permalink / raw)
To: Stephan Beyer
Cc: git, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <20090116172521.GD28177@leksak.fem-net>
Hi,
On Fri, 16 Jan 2009, Stephan Beyer wrote:
> Dscho wrote:
>
> > Lots of improvements possible (I agree; _after_ this patch):
> [...]
>
> > - use an strbuf for the index file
>
> Is that useful in some way?
> Currently it would only adds code to generate strbufs at the caller
> side. And in the case the caller has a strbuf for the index file, it
> can simply use the .buf member.
Of course I meant the buffer into which "GIT_INDEX_FILE=..." is written,
which is fixed size ATM.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] run_hook(): allow more than 9 hook arguments
From: Johannes Schindelin @ 2009-01-16 21:05 UTC (permalink / raw)
To: Stephan Beyer
Cc: git, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <1232133002-21725-5-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 16 Jan 2009, Stephan Beyer wrote:
> This is accomplished using the ALLOC_GROW macro.
>
> 5 cells are initially allocated for the argv array, allowing
> four actual arguments without reallocating memory.
>
> Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
> ---
>
> I was a little unsure if it looks better to
> initialize i = 0, alloc = 0
> and do:
> ALLOC_GROW(argv, i + 1, alloc);
> argv[i++] = git_path("hooks/%s", name);
> instead of the xmalloc().
>
> Do some people care about details like that?
Actually, you need to do it before setting argv[0], and I think it
would look better to let ALLOC_GROW() handle the allocation: less
opportunity for bugs to lurk.
Besides that, ALLOC_GROW() will allocate 16 entries initially,
plenty enough for anyone, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-16 21:06 UTC (permalink / raw)
To: Stephan Beyer
Cc: Sverre Rabbelier, Johan Herland, git, Jay Soffian,
Wincent Colaiuta, Junio C Hamano, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <20090116172640.GE28177@leksak.fem-net>
Hi,
On Fri, 16 Jan 2009, Stephan Beyer wrote:
> Of course, "pause" could be renamed to "halt", "stop" or whatever you
> like. But I think everyone likes something different.
Both 's' and 'p' shortcuts are already taken, unfortunately.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-16 21:09 UTC (permalink / raw)
To: Thomas Rast
Cc: Santi Béjar, Junio C Hamano, Boyd Stephen Smith Jr.,
Teemu Likonen, git
In-Reply-To: <200901162004.32557.trast@student.ethz.ch>
Hi,
On Fri, 16 Jan 2009, Thomas Rast wrote:
> The tip commit has some tweaks to the builtin regexes that aren't in any
> mailed version yet; I'll resend RSN.
Note that I applied the "better" fix for the @@ -2 +1,0 @@ issue, but
haven't sent out a redone series.
Thomas, could you pick up the patches from my 'my-next' branch and
maintain an "official" topic branch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-commit.c: do not remove COMMIT_EDITMSG
From: Johannes Schindelin @ 2009-01-16 21:15 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, krh, gitster
In-Reply-To: <1232134805-19597-1-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 16 Jan 2009, Stephan Beyer wrote:
> This patch just removes the removal of COMMIT_EDITMSG.
LOL. Let's hope we will not need a patch removing the remove of the
removal.
Ciao,
Dscho
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Jon Loeliger @ 2009-01-16 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: George Spelvin, Git List
In-Reply-To: <7vr634ow3r.fsf@gitster.siamese.dyndns.org>
On Thu, 2009-01-15 at 17:52 -0800, Junio C Hamano wrote:
> "George Spelvin" <linux@horizon.com> writes:
>
> By the way, congratulations for getting a name. Can we fix one entry in
> our .mailmap file?
Hmmm....
http://en.wikipedia.org/wiki/George_Spelvin
George Spelvin, Georgette Spelvin, and Georgina Spelvin are the
traditional pseudonyms used in programs in American theater by
actors who don't want to be credited or whose names would
otherwise appear twice because they are playing more than one
role in a production.
jdl
^ permalink raw reply
* [PATCH] Documentation: let asciidoc align related options
From: Markus Heidelberg @ 2009-01-16 21:42 UTC (permalink / raw)
To: gitster; +Cc: git
Command line options can share the same paragraph of description, if
they are related or synonymous. In these cases they should be written
among each other, so that asciidoc can format them itself.
This also fixes the description of the -t option in git-mergetool.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
I'm not quite sure about the options in git-diff-files, maybe
there is a better solution. But at least I think, additional
words between the options should be avoided, because they add
confusion.
Documentation/git-diff-files.txt | 5 ++++-
Documentation/git-mergetool.txt | 6 ++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index 5c8c1d9..c526141 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -21,7 +21,10 @@ OPTIONS
-------
include::diff-options.txt[]
--1 -2 -3 or --base --ours --theirs, and -0::
+-1 --base::
+-2 --ours::
+-3 --theirs::
+-0::
Diff against the "base" version, "our branch" or "their
branch" respectively. With these options, diffs for
merged entries are not shown.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 4c0ffec..5d3c632 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -22,7 +22,8 @@ with merge conflicts.
OPTIONS
-------
--t or --tool=<tool>::
+-t <tool>::
+--tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
@@ -60,7 +61,8 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, 'git-mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.
--y or --no-prompt::
+-y::
+--no-prompt::
Don't prompt before each invocation of the merge resolution
program.
--
1.6.1.35.g0c23
^ permalink raw reply related
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Shawn O. Pearce @ 2009-01-16 22:12 UTC (permalink / raw)
To: Markus Heidelberg, Junio C Hamano; +Cc: git
In-Reply-To: <200901162254.58300.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> I've just accidently read in the completion file itself, that
> Shawn is the maintainer, so I give it a third try. The first two
> haven't been sent to him.
Sorry, I must have missed the other two attempts. :-)
> contrib/completion/git-completion.bash | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 049ded0..6623344 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1384,7 +1384,7 @@ _git_config ()
>
> _git_remote ()
> {
> - local subcommands="add rm show prune update"
> + local subcommands="add rename rm show prune update"
> local subcommand="$(__git_find_subcommand "$subcommands")"
> if [ -z "$subcommand" ]; then
> __gitcomp "$subcommands"
> @@ -1392,7 +1392,7 @@ _git_remote ()
> fi
>
> case "$subcommand" in
> - rm|show|prune)
> + rename|rm|show|prune)
> __gitcomp "$(__git_remotes)"
> ;;
> update)
> --
> 1.6.1.35.g0c23
>
--
Shawn.
^ permalink raw reply
* I've added Dulwich to the Git Wiki
From: Johannes Schindelin @ 2009-01-16 22:42 UTC (permalink / raw)
To: jelmer, git
Hi people,
just got aware of the Dulwich project, which purports to be a pure Python
Git engine. I added it here:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-762f9c85c62c555dbb88129a127431ddeeb56191
Jelmer, is there a chance you can export the Bazaar repository into a
public Git repository? The Bazaar web-frontend does not even allow me to
download a snapshot.
BTW I find it a bit distressing that more and more projects crop up doing
substantial and valuable work around Git, but without even bothering to
mention it on this list. There might have been a good chance, too, to
avoid having _three_ Python libraries for exactly the same task.
Ciao,
Dscho
P.S.: In related news, it seems that dotGit -- which _is_ linked on the
Git Wiki, at least -- progresses rather nicely, which is pretty awesome,
given that we have _two_ failed GSoC projects under our belt which wanted
to do the same. However, dotGit could do with some more visibility on
this list, too, methinks.
^ permalink raw reply
* Re: I've added Dulwich to the Git Wiki
From: Jelmer Vernooij @ 2009-01-16 23:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901162329340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
Hi Johannes,
On Fri, 2009-01-16 at 23:42 +0100, Johannes Schindelin wrote:
> just got aware of the Dulwich project, which purports to be a pure Python
> Git engine. I added it here:
>
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-762f9c85c62c555dbb88129a127431ddeeb56191
Thanks! I wasn't actually aware of that wiki page.
> Jelmer, is there a chance you can export the Bazaar repository into a
> public Git repository? The Bazaar web-frontend does not even allow me to
> download a snapshot.
See:
git://git.samba.org/jelmer/dulwich.git
And gitweb: http://git.samba.org/?p=jelmer/dulwich.git;a=summary
> BTW I find it a bit distressing that more and more projects crop up doing
> substantial and valuable work around Git, but without even bothering to
> mention it on this list. There might have been a good chance, too, to
> avoid having _three_ Python libraries for exactly the same task.
I wasn't aware of PyGit (and its homepage doesn't seem to work), but
Python-Git is just a wrapper around the git command line tools, it
doesn't parse/write the file formats itself.
Cheers,
Jelmer
--
Jelmer Vernooij <jelmer@samba.org> - http://samba.org/~jelmer/
Jabber: jelmer@jabber.fsfe.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 315 bytes --]
^ permalink raw reply
* Re: I've added Dulwich to the Git Wiki
From: Adeodato Simó @ 2009-01-16 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jelmer, git
In-Reply-To: <alpine.DEB.1.00.0901162329340.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Fri, 16 Jan 2009 23:42:38 +0100]:
> Hi people,
> just got aware of the Dulwich project, which purports to be a pure Python
> Git engine.
Interesting.
> Jelmer, is there a chance you can export the Bazaar repository into a
> public Git repository? The Bazaar web-frontend does not even allow me to
> download a snapshot.
Unfortunately, the Dulwich repository contains Git repositories within,
so the resulting repository is not valid. I guess one could drop those
when converting.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Radiohead - House Of Cards
^ permalink raw reply
* Re: I've added Dulwich to the Git Wiki
From: Johannes Schindelin @ 2009-01-16 23:30 UTC (permalink / raw)
To: Jelmer Vernooij; +Cc: git
In-Reply-To: <1232146991.24098.13.camel@ganieda.vernstok.nl>
Hi,
On Sat, 17 Jan 2009, Jelmer Vernooij wrote:
> See:
>
> git://git.samba.org/jelmer/dulwich.git
>
> And gitweb: http://git.samba.org/?p=jelmer/dulwich.git;a=summary
For higher visibility, I also added these to the Wiki.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-checkout(1) mention fate of extraneous files
From: jidanni @ 2009-01-17 0:36 UTC (permalink / raw)
To: git
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-checkout.txt | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 9cd5151..bce31c7 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -14,12 +14,13 @@ SYNOPSIS
DESCRIPTION
-----------
-When <paths> are not given, this command switches branches by
-updating the index and working tree to reflect the specified
-branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>. Using -b will cause <new_branch> to
-be created; in this case you can use the --track or --no-track
-options, which will be passed to `git branch`.
+When <paths> are not given, this command switches branches by updating
+the index and working tree to reflect the specified branch, <branch>,
+and updating HEAD to be <branch> or, if specified, <new_branch>. (No
+extraneous files present are deleted, use linkgit:git-clean[1] for a
+pristine checkout.) Using -b will cause <new_branch> to be created; in
+this case you can use the --track or --no-track options, which will be
+passed to `git branch`.
As a convenience, --track will default to create a branch whose
name is constructed from the specified branch name by stripping
--
1.6.0.6
^ permalink raw reply related
* git add --patch bug with split+edit?
From: Hannu Koivisto @ 2009-01-17 1:37 UTC (permalink / raw)
To: git
Greetings,
If I have a hunk that adds three lines, I can edit the hunk and
remove the last line but I can't split it in two, stage the first
part, edit the second part and remove the last line. An example:
mkdir gittest
cd gittest
git init
echo "baz\nbaz" > baz
git add baz
git commit -m baz baz
rm baz
echo "sur\nbaz\nbaz\njee\njee" > baz
git add --patch
Now say 's RET y RET e RET' and remove the second "+jee" line using
your editor. The output for me looks like this:
--8<-----------------------------------------------------------------
diff --git a/baz b/baz
index 1f55335..48a5f83 100644
--- a/baz
+++ b/baz
@@ -1,2 +1,5 @@
+sur
baz
baz
+jee
+jee
Stage this hunk [y/n/a/d/s/e/?]? s
Split into 2 hunks.
@@ -1,2 +1,3 @@
+sur
baz
baz
Stage this hunk [y/n/a/d/j/J/e/?]? y
@@ -1,2 +2,4 @@
baz
baz
+jee
+jee
Stage this hunk [y/n/a/d/K/e/?]? e
Waiting for Emacs...
error: patch failed: baz:1
error: baz: patch does not apply
Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]?
--8<-----------------------------------------------------------------
What I also didn't expect is that if I answer 'n' to that last
question, I get...
@@ -1,2 +1,3 @@
+sur
baz
baz
Stage this hunk [y/n/a/d/j/J/e/?]?
...which is the first part of the splitted hunk that I already
staged. If I answer 'd', git status and git diff indicate that
"+sur" is nevertheless staged.
Now, if instead of splitting the hunk and editing it, I edit the
entire...
@@ -1,2 +1,5 @@
+sur
baz
baz
+jee
+jee
...hunk and remove the last "+jee" line, I get no error.
I'm using git 1.6.1 on Linux.
--
Hannu
^ permalink raw reply related
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that
From: Jeff King @ 2009-01-17 1:40 UTC (permalink / raw)
To: Baz
Cc: markus.heidelberg, Adeodato Simó, Boyd Stephen Smith Jr.,
Shawn O. Pearce, Ted Pavlic, git, Junio C Hamano
In-Reply-To: <2faad3050901160706y297a98d4r35340e4811ca3d2b@mail.gmail.com>
On Fri, Jan 16, 2009 at 03:06:34PM +0000, Baz wrote:
> > At the beginning I tried to fulfil this limit, but often it's not easy.
> > So should it be adjusted to a slightly higher value in the documentation
> > or even split into a recommended limit (e.g. 50) and a recommended
> > absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
>
> The 50 character limit is for the first line, try "git log
> --pretty=oneline" and it should be obvious why.
I'm not sure it makes sense to make a workflow recommendation that the
git project itself does not follow. Of 14590 non-merge commits in
git.git, 6940 (nearly 50%) have subject lines longer than 50
characters.
In practice, is this a problem for people using git.git?
Personally, I find --pretty=oneline unreadable because so much of the
screen real estate is wasted on random characters that I don't care
about. I find --pretty=tformat:'%h %s' much nicer (yes, --abbrev-commit
works, too, but I find the '...' a pointless waste of space).
For reference, here are the percentiles of subject lines in git.git
longer than X:
X | %
50 | 48%
60 | 24%
65 | 14%
70 | 8%
So it seems that quite a large chunk are between 50 and 65 characters.
Which still leaves room for "Subject: " or 8 characters of hash at the
beginning.
> perl -ne '$lim = (50,0,72)[($.>3?3:$.)-1];
Ugh. Would a little whitespace have killed you? ;P
> (I wish I'd had something like this when one of the devs here pushed a
> commit with a 346-line message,
> just listing what files he was changing...doh)
Well, yes. That's just insane.
-Peff
^ permalink raw reply
* Re: git add --patch bug with split+edit?
From: Jeff King @ 2009-01-17 2:33 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <833afihfvc.fsf@kalahari.s2.org>
On Sat, Jan 17, 2009 at 03:37:43AM +0200, Hannu Koivisto wrote:
> echo "sur\nbaz\nbaz\njee\njee" > baz
> git add --patch
>
> Now say 's RET y RET e RET' and remove the second "+jee" line using
> your editor. The output for me looks like this:
> [...]
> error: patch failed: baz:1
> error: baz: patch does not apply
> Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]?
Actually, you do not even need to change the patch at all for this to
fail. The hunk that you edit looks like this:
@@ -1,2 +2,4 @@
baz
baz
+jee
+jee
which doesn't make sense. I think the hunk header should actually be:
@@ -1,2 +1,4 @@
But I don't think that is the problem, since git-apply should be
recounting the hunk information (and in a simple test, it doesn't fix
it).
Hm. OK, I see. The "does this diff apply" check feeds _both_ parts of
the split patch to git-apply. But of course the second part will never
correctly apply, because its context overlaps with the first part, but
doesn't take it into account.
Doing the check with _just_ the edited patch would work. But that
doesn't take into account that your edited patch will potentially fail
to apply in the long run, depending on whether or not you accept the
other half of the split patch. And we can't know that yet, because the
user may not have told us (they could have skipped the first half, and
then come back to it later after the edit step).
So in general, I think splitting and editing the same hunk is inherently
dangerous and is going to lead to these sorts of problems. And because
editing provides a superset of the functionality, I think you should
just edit and either allow the first part of the hunk to be applied or
not depending on your preference.
But maybe there is some better way of resolving the conflict. I don't
see one, but I'm tired and didn't think too hard on it. :)
-Peff
^ permalink raw reply
* Re: I've added Dulwich to the Git Wiki
From: David Aguilar @ 2009-01-17 2:37 UTC (permalink / raw)
To: Jelmer Vernooij; +Cc: Johannes Schindelin, git
In-Reply-To: <1232146991.24098.13.camel@ganieda.vernstok.nl>
On Fri, Jan 16, 2009 at 3:03 PM, Jelmer Vernooij <jelmer@samba.org> wrote:
>>
>> BTW I find it a bit distressing that more and more projects crop up doing
>> substantial and valuable work around Git, but without even bothering to
>> mention it on this list. There might have been a good chance, too, to
>> avoid having _three_ Python libraries for exactly the same task.
> I wasn't aware of PyGit (and its homepage doesn't seem to work), but
> Python-Git is just a wrapper around the git command line tools, it
> doesn't parse/write the file formats itself.
>
> Cheers,
>
> Jelmer
>
> --
> Jelmer Vernooij <jelmer@samba.org> - http://samba.org/~jelmer/
> Jabber: jelmer@jabber.fsfe.org
>
Hello
This sounds like a great project.
I've talked with the authors of GitPython in the past and I believe
the reason it was never mentioned here was that they were probably too
shy or intimidated (you guys are pretty hardcore ;-) ).
Anyways, as you said, GitPython is purely a wrapper around git
commands. BTW, git is bloody fast so it's actually not that bad and
works pretty well.
GitPython's license is the New BSD license and thus it can't use git
code nor could it use libgit2. I think the best route for a useful
Python module would be to wrap something like libgit2 which aims to be
a true library for git. If that's the goals for Dulwich then all the
better. If not (and it instead aims to be a pure-Python
implementation) then that's cool too, but for performance reasons I
think the community would best be served by pursuing a core git
library with various language bindings built on top of it.
In any case, this sounds like a neat development and it does seem like
the goals are slightly different then the existing GitPython module.
GitPython was basically a port of the Ruby Grit library, which also
just wraps git commands. I'll keep my eye on this and see if there's
anywhere I can help.
--
David
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Hannu Koivisto @ 2009-01-17 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: George Spelvin, git
In-Reply-To: <7vr634ow3r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "George Spelvin" <linux@horizon.com> writes:
>
>> Could someone fix this some day?
>
> As far as I know you are the first to ask for this, so perhaps people never
> considered this was something to "fix"....
I for one have faced that problem and considered it something that
would be nice to have fixed. Then again, I consider the default
behaviour (when you pass no path) a bigger usability problem.
>> While you're at it, an option to search the entire git tree rather than
>> the current subdirectory would also be useful. I was thinking about
>> a flag like -r (for "root"),...
It turns out that this "entire git tree" is practically my only use
case when using normal (find and) grep and when I first tried git
grep, I actually expected it to do just that with no path specified.
Why? Because of the way at least git diff and git log work. I
thought that just like with them, "git grep foo" would search the
entire git tree and I would have to say "git grep foo ." to limit to
the current directory and its subdirectories. git-grep(1)'s "Look
for specified patterns in the working tree files..." at least
didn't seem to disagree with my expectation so I was a bit puzzled.
So I'd rather see git grep behave in a way consistent with git log
and git diff (I realize that would change current behaviour instead
of extending it).
--
Hannu
^ permalink raw reply
* [PATCH 1/3] http-push: append slash if possible for directories
From: Ray Chuan @ 2009-01-17 2:53 UTC (permalink / raw)
To: git
the lock_remote currently sends MKCOL requests to leading directories
to make sure they exist; however, it doesn't put a forward slash '/'
behind the path, so if the path is a directory, the server sends a 301
redirect.
by appending a '/' we can save the server this additional step.
in addition, it seems that curl doesn't re-send the authentication
credentials when it follows a 301 redirect, so skipping (unnecessary)
redirects can also be seen as a workaround for this issue. (i'm using
7.16.3)
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/http-push.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
index 7c64609..25b655d 100644
--- a/src/git-1.6.1/http-push.c
+++ b/src/git-1.6.1/http-push.c
@@ -1189,6 +1189,7 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
struct strbuf in_buffer = STRBUF_INIT;
char *url;
char *ep;
+ char ep_old;
char timeout_header[25];
struct remote_lock *lock = NULL;
struct curl_slist *dav_headers = NULL;
@@ -1198,9 +1199,18 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
sprintf(url, "%s%s", remote->url, path);
/* Make sure leading directories exist for the remote ref */
- ep = strchr(url + strlen(remote->url) + 1, '/');
- while (ep) {
- *ep = 0;
+ ep = url + strlen(remote->url) + 1;
+ int has_fs = 0;
+ while (1) {
+ ep = strchr(ep + 1, '/');
+ if(ep) {
+ ep++;
+ ep_old=*ep;
+ *ep = 0;
+ has_fs = 1;
+ } else {
+ break;
+ }
slot = get_active_slot();
slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
@@ -1222,8 +1232,9 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
free(url);
return NULL;
}
- *ep = '/';
- ep = strchr(ep + 1, '/');
+ if(has_fs) {
+ *ep = ep_old;
+ }
}
strbuf_addf(&out_buffer.buf, LOCK_REQUEST, git_default_email);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE
From: Ray Chuan @ 2009-01-17 2:59 UTC (permalink / raw)
To: git
since 753bc911f489748a837ecb5ea4b5216220b24845, the opaquelocktocken
URI isn't used, so it doesn't make sense to PUT then MOVE.
currently, git PUTs to
/repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
on some platforms, ':' isn't allowed in filenames so this fails
(assuming the server doesn't recognize it as opaquelocktoken scheme).
in fact, i don't think this is the correct implementation of the
scheme; 'opaquelocktoken: ' should come in front of the path.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/http-push.c | 45 +--------------------------------------------
1 files changed, 1 insertions(+), 44 deletions(-)
diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
index a646a49..838ff6f 100644
--- a/src/git-1.6.1/http-push.c
+++ b/src/git-1.6.1/http-push.c
@@ -31,7 +31,6 @@ enum XML_Status {
/* DAV methods */
#define DAV_LOCK "LOCK"
#define DAV_MKCOL "MKCOL"
-#define DAV_MOVE "MOVE"
#define DAV_PROPFIND "PROPFIND"
#define DAV_PUT "PUT"
#define DAV_UNLOCK "UNLOCK"
@@ -104,7 +103,6 @@ enum transfer_state {
NEED_PUSH,
RUN_MKCOL,
RUN_PUT,
- RUN_MOVE,
ABORTED,
COMPLETE,
};
@@ -528,11 +526,6 @@ static void start_put(struct transfer_request *request)
posn += 2;
*(posn++) = '/';
strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -557,32 +550,6 @@ static void start_put(struct transfer_request *request)
}
}
-static void start_move(struct transfer_request *request)
-{
- struct active_request_slot *slot;
- struct curl_slist *dav_headers = NULL;
-
- slot = get_active_slot();
- slot->callback_func = process_response;
- slot->callback_data = request;
- curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1); /* undo PUT setup */
- curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_MOVE);
- dav_headers = curl_slist_append(dav_headers, request->dest);
- dav_headers = curl_slist_append(dav_headers, "Overwrite: T");
- curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
- curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
- curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
-
- if (start_active_slot(slot)) {
- request->slot = slot;
- request->state = RUN_MOVE;
- } else {
- request->state = ABORTED;
- free(request->url);
- request->url = NULL;
- }
-}
-
static int refresh_lock(struct remote_lock *lock)
{
struct active_request_slot *slot;
@@ -705,23 +672,13 @@ static void finish_request(struct
transfer_request *request)
}
} else if (request->state == RUN_PUT) {
if (request->curl_result == CURLE_OK) {
- start_move(request);
- } else {
- fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
- sha1_to_hex(request->obj->sha1),
- request->curl_result, request->http_code);
- request->state = ABORTED;
- aborted = 1;
- }
- } else if (request->state == RUN_MOVE) {
- if (request->curl_result == CURLE_OK) {
if (push_verbosely)
fprintf(stderr, " sent %s\n",
sha1_to_hex(request->obj->sha1));
request->obj->flags |= REMOTE;
release_request(request);
} else {
- fprintf(stderr, "MOVE %s failed, aborting (%d/%ld)\n",
+ fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
sha1_to_hex(request->obj->sha1),
request->curl_result, request->http_code);
request->state = ABORTED;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/3] http-push: update tests
From: Ray Chuan @ 2009-01-17 2:59 UTC (permalink / raw)
To: git
note: the test needs to chmod the test_repo.git folder so that
apache/mod_dav can create .DAV folders in it for locking.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/t/t5540-http-push.sh | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/git-1.6.1/t/t5540-http-push.sh
b/src/git-1.6.1/t/t5540-http-push.sh
index da95886..730b9cb 100755
--- a/src/git-1.6.1/t/t5540-http-push.sh
+++ b/src/git-1.6.1/t/t5540-http-push.sh
@@ -51,17 +51,16 @@ test_expect_success 'clone remote repository' '
git clone $HTTPD_URL/test_repo.git test_repo_clone
'
-test_expect_failure 'push to remote repository' '
+test_expect_success 'push to remote repository' '
cd "$ROOT_PATH"/test_repo_clone &&
: >path2 &&
git add path2 &&
test_tick &&
git commit -m path2 &&
- git push &&
- [ -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/refs/heads/master" ]
+ git push origin master
'
-test_expect_failure 'create and delete remote branch' '
+test_expect_success 'create and delete remote branch' '
cd "$ROOT_PATH"/test_repo_clone &&
git checkout -b dev &&
: >path3 &&
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 5/5] run_hook(): allow more than 9 hook arguments
From: Stephan Beyer @ 2009-01-17 3:02 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232133002-21725-4-git-send-email-s-beyer@gmx.net>
This is done using the ALLOC_GROW macro.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Ok, Dscho :-)
The interdiff based on [PATCH 5/5] is...
--- a/run-command.c
+++ b/run-command.c
@@ -350,14 +350,14 @@ int run_hook(const char *index_file, const char *name, ...)
char index[PATH_MAX];
va_list args;
int ret;
- size_t i = 1, alloc = 5;
+ size_t i = 0, alloc = 0;
if (access(git_path("hooks/%s", name), X_OK) < 0)
return 0;
va_start(args, name);
- argv = xmalloc(alloc * sizeof(const char *));
- argv[0] = git_path("hooks/%s", name);
+ ALLOC_GROW(argv, i + 1, alloc);
+ argv[i++] = git_path("hooks/%s", name);
while (argv[i-1]) {
ALLOC_GROW(argv, i + 1, alloc);
argv[i++] = va_arg(args, const char *);
Documentation/technical/api-run-command.txt | 2 +-
run-command.c | 18 +++++++++---------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index 13e7b63..2efe7a4 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -58,7 +58,7 @@ Functions
The first argument is a pathname to an index file, or NULL
if the hook uses the default index file or no index is needed.
The second argument is the name of the hook.
- The further arguments (up to 9) correspond to the hook arguments.
+ The further arguments correspond to the hook arguments.
The last argument has to be NULL to terminate the arguments list.
If the hook does not exist or is not executable, the return
value will be zero.
diff --git a/run-command.c b/run-command.c
index fc54c07..d2f1262 100644
--- a/run-command.c
+++ b/run-command.c
@@ -346,23 +346,22 @@ int finish_async(struct async *async)
int run_hook(const char *index_file, const char *name, ...)
{
struct child_process hook;
- const char *argv[10], *env[2];
+ const char **argv, *env[2];
char index[PATH_MAX];
va_list args;
int ret;
- int i;
+ size_t i = 0, alloc = 0;
if (access(git_path("hooks/%s", name), X_OK) < 0)
return 0;
va_start(args, name);
- argv[0] = git_path("hooks/%s", name);
- i = 0;
- do {
- if (++i >= ARRAY_SIZE(argv))
- die("run_hook(): too many arguments");
- argv[i] = va_arg(args, const char *);
- } while (argv[i]);
+ ALLOC_GROW(argv, i + 1, alloc);
+ argv[i++] = git_path("hooks/%s", name);
+ while (argv[i-1]) {
+ ALLOC_GROW(argv, i + 1, alloc);
+ argv[i++] = va_arg(args, const char *);
+ }
va_end(args);
memset(&hook, 0, sizeof(hook));
@@ -377,6 +376,7 @@ int run_hook(const char *index_file, const char *name, ...)
}
ret = start_command(&hook);
+ free(argv);
if (ret) {
warning("Could not spawn %s", argv[0]);
return ret;
--
1.6.1.160.gecdb
^ 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