* [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-16 23:21 UTC (permalink / raw)
To: git; +Cc: Jonathan del Strother
Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
Documentation/gitattributes.txt | 2 ++
diff.c | 6 ++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 6f3551d..c1f13e2 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -315,6 +315,8 @@ patterns are available:
- `java` suitable for source code in the Java language.
+- `objc` suitable for source code in the Objective-C language.
+
- `pascal` suitable for source code in the Pascal/Delphi language.
- `php` suitable for source code in the PHP language.
diff --git a/diff.c b/diff.c
index 998dcaa..6ed8322 100644
--- a/diff.c
+++ b/diff.c
@@ -1403,6 +1403,12 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
+ { "objc", "^[\t ]*\\([-+][\t ]*([\t ]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$" // Objective-C methods
+ "\\|"
+ "^[\t ]*\\(\\([\t ]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[\t ]*([^;]*\\)$" // C functions
+ "\\|"
+ "^@\\(implementation\\|interface\\|protocol\\).*" // Objective-C class/protocol definitions
+ },
{ "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
"destructor\\|interface\\|implementation\\|"
"initialization\\|finalization\\)[ \t]*.*\\)$"
--
1.6.0.2
^ permalink raw reply related
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Boyd Lynn Gerber @ 2008-09-16 23:25 UTC (permalink / raw)
To: Brandon Casey
Cc: Arjen Laarhoven, git, Mike Ralphson, Johannes Sixt, Jeff King,
Junio C Hamano
In-Reply-To: <W_emvcr7ijntBMNCDV17_XHXotGkm1Bn-9Bw-ZixcXmFyBWlDj5vYg@cipher.nrlssc.navy.mil>
Hello,
On Tue, 16 Sep 2008, Brandon Casey wrote:
> Arjen Laarhoven wrote:
>> The standard libc regex library on OSX does not support alternation
>> in POSIX Basic Regular Expression mode. This breaks the diff.funcname
>> functionality on OSX.
>>
>> To fix this, we use the GNU regex library which is already present in
>> the compat/ diretory for the MinGW port. However, simply adding compat/
>> to the COMPAT_CFLAGS variable causes a conflict between the system
>> fnmatch.h and the one present in compat/. To remedy this, move the
>> regex and fnmatch functionality to their own subdirectories in compat/
>> so they can be included seperately.
>
> I wonder if this is the right fix? Right now the GNU regex library is
> necessary for Darwin, FreeBSD and AIX. I can add IRIX6.5 and Solaris 7
> to that list. Have newer Solaris's been tested yet? (Jeff?) I wonder if
> the new test which triggers this flaw has been tested on the other
> non-GNU platforms in the Makefile which have not been updated. Boyd
> Lynn Gerber and his 12 platforms comes to mind.
>
> It seems POSIX only mentions alternation under Extended Regular Expressions.
> Likewise for the vertical-line character '|'.
Someone forwarded me this email and asked if I had tested it. I have not.
Where is the easiest place to get it to test with the various platforms?
I will check it out on 3-5 of them. I now have 1.6.0.2 on 5 platforms
running and working. I have not had the time to get it on the other's
yet.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Submitting patches from unsubscribed authors?
From: Jonathan del Strother @ 2008-09-16 23:24 UTC (permalink / raw)
To: Git Mailing List
Is it possible to submit a patch to the mailing list, from an author
that isn't subscribed? Last time I submitted a patch I went via my
throwaway email address, and so that was used as the commit author.
It looks like "git am" is always going to just use the email address
used to post to the mailing list as the email address, but I'm sure in
the past that my patches have appeared under my real email. Was that
just manual intervention by the maintainer?
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Dmitry Potapov @ 2008-09-16 23:20 UTC (permalink / raw)
To: mtk.manpages; +Cc: git, michael.kerrisk
In-Reply-To: <cfd18e0f0809161505g4c04bd88vaf4fd7c40f67b243@mail.gmail.com>
On Wed, Sep 17, 2008 at 2:05 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
>
> I'm currently trying to import an svn repository, along with its tags,
> into git, and everything seems okay except that after the import I
> expect to have the following structure to my checked out repository:
>
> [root-dir]
> .git
> <checked-out-files>
>
> But instead I end up with
>
> [root-dir]
> .git
> man-pages <-- name of my svn project
> <checked-out-files>
>
> I've tried out a few different command-line flag settings but so far I
> haven't managed to get the desired layout. I guess that I'm missing
> something trivial, but I haven't worked out what it is so far.
>
> The commands I'm using to do the import are:
>
> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
Probably, you want to run:
$ git svn init file:///home/mtk/man-pages-rep/ -t tags -T
trunk/man-pages -b branches
Dmitry
^ permalink raw reply
* Re: Grafts workflow for a "shallow" repository...?
From: Dmitry Potapov @ 2008-09-16 23:12 UTC (permalink / raw)
To: sverre
Cc: Björn Steinbrink, Michael J Gruber, Junio C Hamano,
Shawn O. Pearce, Martin Langhoff, Git Mailing List
In-Reply-To: <bd6139dc0809161502t121c5aa5la53784bb8ff273a2@mail.gmail.com>
On Wed, Sep 17, 2008 at 12:02:25AM +0200, Sverre Rabbelier wrote:
> On Tue, Sep 16, 2008 at 15:50, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> > Maybe instead of providing "pre-shallowed" repos to clone from, that
> > should have been an RFE to support shallow clones starting at a given
> > commit in the DAG? I have no idea whether that's feasible though.
>
> Would it be like grafts, only the graft is set up by the fetcher,
> instead of the host?
No, the idea is to have it in the $GIT_DIR/shallow format, which differs
from grafts in that it cannot add new parents. So, it can only truncate
history, while grafts adding new parents can modify history in different
ways.
> (E.g., the graft is created on clone, instead of
> -before- the clone, by means of the --depth parameter?) Which means
> the mentioned security risk is not there (what with the fetcher
> setting it up himself).
The important difference between grafts and shallow is that the latter
does not allow you to add new parents. So, you cannot modify history but
only truncate existing one. So I am not sure about what security risk
you are talking about. Obviously, that git blame will attribute all
changes that were done before to the earliest downloaded commit. Other
than that, I don't think that you can fake anything here. All downloaded
history will be correct and that can be verified based on SHA-1.
Also, I believe that the default mode should be to ignore this shallow
file on server unless the user specified the corresponding option to
make a shallow copy.
BTW, the current implementation of shallow copy has some limitations.
See Documentation/technical/shallow.txt for details.
Dmitry
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Jakub Narebski @ 2008-09-16 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Miklos Vajna
In-Reply-To: <7vhc8h7xgj.fsf@gitster.siamese.dyndns.org>
Dnia wtorek 16. września 2008 02:20, Junio C Hamano napisał:
> Junio C Hamano <gitster@pobox.com> writes:
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>>> The merge says
>>>
>>> Trying simple merge with 5b3e4bb1c2d88d6967fb575729fbfc86df5eaec9
>>> Simple merge did not work, trying automatic merge.
>>> Auto-merging foo
>>> ERROR: Merge conflict in foo
>>> fatal: merge program failed
>>> Automated merge did not work.
>>> Should not be doing an Octopus.
>>> Merge with strategy octopus failed.
>> ...
>> Read the second from the last line of what you were told by git. Run "git
>> reset --hard" after that, perhaps.
The problem, as far as I understand it, is not that octopus merge fails.
The problem is that it fails halfway, and it leaves working are in
inconsistent state: git-status output with its "unmerged" suggests that
we are in the middle of the merge, but we are not.
> By the way, there are three failure modes in Octopus.
>
> (0) your index (not work tree) is dirty; this is not limited to octopus
> merge but any merge will be refused;
IIRC the idea of stashing away changes, doing merge, and then unstashing
was shot down as encouraging bad workflows, and more often than not
leading only to mess in workdir and index.
> (1) while it merges other heads one-by-one, it gets conflicts on an
> earlier one, before it even attempts to merge all of them. Recording
> the heads that it so far attempted to merge in MERGE_HEAD is wrong
> (the result won't be an Octopus the end user wanted to carete), and
> recording all the heads the user gave in MERGE_HEAD is even more
> wrong (it hasn't even looked at the later heads yet, so there is no
> way for the index or work tree to contain anything from them).
>
> The above is hitting this case.
IMVHO the correct solution would be to rollback changes to the state
before attempting a merge. I'd rather 'octopus' did its thing as
transaction; contrary to ordinary merges if merge fails it doesn't
mean necessary that it is in the state of resolvable conflict, state
we can stop at. Perhaps (if it is still a shell script, doing git-stash
at beginning, and either dropping or popping the stash at the end;
or just saving old index if it is built-in).
BTW. does it mean that "git merge a b" might be not the same as
"git merge b a"?
> (2) it gets conflicts while merging the _last_ head. It records
> MERGE_HEAD and allows you to record the resolved result.
>
> I think originally we treated (1) and (2) the same way, because an Octopus
> is to record the most trivial merge with more than 2 legs, and a rough
> definition of "the most trivial" is "tracks of totally independent works;
> you could merge them one by one and _in any order_, and the result won't
> matter because they are logically independent. However if they are _so_
> independent, why not record them as merged in one step (i.e. octopus),
> instead of insisting on recording in what order you merged them".
>
> Obviously, if you get a conflict during Octopus creation, they were not
> tracks of totally independent works, and that is where the "Should not" in
> the message comes from.
>
> We later relaxed it to allow a conflict at the last step, not because
> recording an Octopus with nontrivial merge is particuarly a good idea we
> should encourage, but because there simply weren't reason not to.
Well, octopus merge could simply fail when merge is nontrivial (not
limited to being tree-level merge only).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [JGIT PATCH 2/2] Add support for ~/.ssh/config BatchMode
From: Shawn O. Pearce @ 2008-09-16 22:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200809170046.31859.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> tisdagen den 16 september 2008 17.44.29 skrev Shawn O. Pearce:
> > Connections created through batch processes (e.g. those started by
> > cron) don't have a terminal to interact with a user through. A
> > common way to disable password prompting with OpenSSH is to setup
> > a Host block in ~/.ssh/config with "BatchMode yes" enabled, thus
> > telling the client not to prompt for passphases or passwords.
>
> That did not work when any of the identities in ~/.ssh matched. Though
> I specifically told jgit to use an identity that should not work, it found another
> that did. During setup all identities are loaded and made available to JSch.
Yes, that's a known bug.
> That bug is not related to this code (so I pushed it) other than it made it tricky
> to test. OpenSSH only tries the identity I tell it to, or default if not told.
I have a plan on how to fix it. I just didn't find the time today
to actually implement it. I'll put an issue on the issue tracker
with my thoughts on how IdentityFile can be implemented correctly.
If I don't get to it this week maybe someone else can, it looks
pretty simple on the surface.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 2/2] Add support for ~/.ssh/config BatchMode
From: Robin Rosenberg @ 2008-09-16 22:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1221579869-27835-2-git-send-email-spearce@spearce.org>
tisdagen den 16 september 2008 17.44.29 skrev Shawn O. Pearce:
> Connections created through batch processes (e.g. those started by
> cron) don't have a terminal to interact with a user through. A
> common way to disable password prompting with OpenSSH is to setup
> a Host block in ~/.ssh/config with "BatchMode yes" enabled, thus
> telling the client not to prompt for passphases or passwords.
That did not work when any of the identities in ~/.ssh matched. Though
I specifically told jgit to use an identity that should not work, it found another
that did. During setup all identities are loaded and made available to JSch.
That bug is not related to this code (so I pushed it) other than it made it tricky
to test. OpenSSH only tries the identity I tell it to, or default if not told.
-- robin
^ permalink raw reply
* Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-16 22:05 UTC (permalink / raw)
To: git; +Cc: michael.kerrisk
Hello,
I'm currently trying to import an svn repository, along with its tags,
into git, and everything seems okay except that after the import I
expect to have the following structure to my checked out repository:
[root-dir]
.git
<checked-out-files>
But instead I end up with
[root-dir]
.git
man-pages <-- name of my svn project
<checked-out-files>
I've tried out a few different command-line flag settings but so far I
haven't managed to get the desired layout. I guess that I'm missing
something trivial, but I haven't worked out what it is so far.
The commands I'm using to do the import are:
$ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
$ git svn fetch
The svn tags are getting imported okay, since:
git branch -a | head
tags/man-pages-2.00
tags/man-pages-2.01
...
tags/man-pages-3.08
tags/man-pages-3.09
trunk
The following commands show the layout of my svn repo, which is pretty
much standard:
$ svn list file:///home/mtk/man-pages-rep
branches/
tags/
trunk/
$ svn list file:///home/mtk/man-pages-rep/trunk
man-pages/
$ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
Changes
Changes.old
Makefile
README
man-pages-3.09.Announce
...
man7/
man8/
scripts/
$ svn list file:///home/mtk/man-pages-rep/tags
man-pages-2.00/
man-pages-2.01/
...
man-pages-3.08/
man-pages-3.09/
What 'git svn init' command do I need to get the layout that I want
for my imported git repo?
Cheers,
Michael
^ permalink raw reply
* Re: [GIT-GUI PATCH] call prepare-commit-msg hook
From: Joshua Williams @ 2008-09-16 22:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jay Blakeborough, Bill Lohse
In-Reply-To: <48D02144.8030409@qlogic.com>
Small change. Still need to load MERGE_MSG and SQUASH_MSG
if there's no prepare-commit-msg hook. We now process the hook
first and if it's not there, load MERGE_MSG or SQUASH_MSG.
Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
---
git-gui/git-gui.sh | 64
++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 10d8a44..8d06cd1 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1131,6 +1131,7 @@ proc rescan {after {honor_trustmtime 1}} {
|| [string trim [$ui_comm get 0.0 end]] eq {})} {
if {[string match amend* $commit_type]} {
} elseif {[load_message GITGUI_MSG]} {
+ } elseif {[run_prepare_commit_msg_hook]} {
} elseif {[load_message MERGE_MSG]} {
} elseif {[load_message SQUASH_MSG]} {
}
@@ -1230,6 +1231,69 @@ proc load_message {file} {
return 0
}
+proc run_prepare_commit_msg_hook {} {
+ global pch_error
+
+ # prepare-commit-msg requires PREPARE_COMMIT_MSG exist. From git-gui
+ # it will be .git/MERGE_MSG (merge), .git/SQUASH_MSG (squash), or an
+ # empty file but existant file.
+
+ set fd_pcm [open [gitdir PREPARE_COMMIT_MSG] a]
+
+ if {[file isfile [gitdir MERGE_MSG]]} {
+ set pcm_source "merge"
+ set fd_mm [open [gitdir MERGE_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_mm]
+ close $fd_mm
+ } elseif {[file isfile [gitdir SQUASH_MSG]]} {
+ set pcm_source "squash"
+ set fd_sm [open [gitdir SQUASH_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_sm]
+ close $fd_sm
+ } else {
+ set pcm_source ""
+ }
+
+ close $fd_pcm
+
+ set fd_ph [githook_read prepare-commit-msg \
+ [gitdir PREPARE_COMMIT_MSG] $pcm_source]
+ if {$fd_ph eq {}} {
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return 0;
+ }
+
+ ui_status [mc "Calling prepare-commit-msg hook..."]
+ set pch_error {}
+
+ fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+ fileevent $fd_ph readable \
+ [list prepare_commit_msg_hook_wait $fd_ph]
+
+ return 1;
+}
+
+proc prepare_commit_msg_hook_wait {fd_ph} {
+ global pch_error
+
+ append pch_error [read $fd_ph]
+ fconfigure $fd_ph -blocking 1
+ if {[eof $fd_ph]} {
+ if {[catch {close $fd_ph}]} {
+ ui_status [mc "Commit declined by prepare-commit-msg hook."]
+ hook_failed_popup prepare-commit-msg $pch_error
+ exit 1
+ } else {
+ load_message PREPARE_COMMIT_MSG
+ }
+ set pch_error {}
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return
+ }
+ fconfigure $fd_ph -blocking 0
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+}
+
proc read_diff_index {fd after} {
global buf_rdi
^ permalink raw reply related
* Re: Grafts workflow for a "shallow" repository...?
From: Sverre Rabbelier @ 2008-09-16 22:02 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Michael J Gruber, Junio C Hamano, Shawn O. Pearce,
Martin Langhoff, Git Mailing List
In-Reply-To: <20080916135022.GA19466@atjola.homenet>
On Tue, Sep 16, 2008 at 15:50, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Maybe instead of providing "pre-shallowed" repos to clone from, that
> should have been an RFE to support shallow clones starting at a given
> commit in the DAG? I have no idea whether that's feasible though.
Would it be like grafts, only the graft is set up by the fetcher,
instead of the host? (E.g., the graft is created on clone, instead of
-before- the clone, by means of the --depth parameter?) Which means
the mentioned security risk is not there (what with the fetcher
setting it up himself).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Robin Rosenberg @ 2008-09-16 21:13 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Sergio Callegari, Johannes Sixt, git
In-Reply-To: <32541b130809160904v7acc73cfm4856c33d40555e94@mail.gmail.com>
tisdagen den 16 september 2008 18.04.44 skrev Avery Pennarun:
> unzipping from /dev/stdin seems to work if stdin is seekable, otherwise not.
>
> unzip /dev/stdin <filename.zip # works
> cat filename.zip | unzip /dev/stdin # doesn't work
Try a cousin of zip for extraction:
cat filename.zip | jar x # works
> Have fun,
Always.
-- robin
^ permalink raw reply
* [GIT-GUI PATCH] call prepare-commit-msg hook
From: Joshua Williams @ 2008-09-16 21:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jay Blakeborough, Bill Lohse
This patch adds support to git-gui for calling out to the
prepare-commit-msg hook.
Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
---
git-gui/git-gui.sh | 66
++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 10d8a44..1e269de 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1131,8 +1131,7 @@ proc rescan {after {honor_trustmtime 1}} {
|| [string trim [$ui_comm get 0.0 end]] eq {})} {
if {[string match amend* $commit_type]} {
} elseif {[load_message GITGUI_MSG]} {
- } elseif {[load_message MERGE_MSG]} {
- } elseif {[load_message SQUASH_MSG]} {
+ } elseif {[run_prepare_commit_msg_hook]} {
}
$ui_comm edit reset
$ui_comm edit modified false
@@ -1230,6 +1229,69 @@ proc load_message {file} {
return 0
}
+proc run_prepare_commit_msg_hook {} {
+ global pch_error
+
+ # prepare-commit-msg requires PREPARE_COMMIT_MSG exist. From git-gui
+ # it will be .git/MERGE_MSG (merge), .git/SQUASH_MSG (squash), or an
+ # empty file but existant file.
+
+ set fd_pcm [open [gitdir PREPARE_COMMIT_MSG] a]
+
+ if {[file isfile [gitdir MERGE_MSG]]} {
+ set pcm_source "merge"
+ set fd_mm [open [gitdir MERGE_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_mm]
+ close $fd_mm
+ } elseif {[file isfile [gitdir SQUASH_MSG]]} {
+ set pcm_source "squash"
+ set fd_sm [open [gitdir SQUASH_MSG] r]
+ puts -nonewline $fd_pcm [read $fd_sm]
+ close $fd_sm
+ } else {
+ set pcm_source ""
+ }
+
+ close $fd_pcm
+
+ set fd_ph [githook_read prepare-commit-msg \
+ [gitdir PREPARE_COMMIT_MSG] $pcm_source]
+ if {$fd_ph eq {}} {
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return 0;
+ }
+
+ ui_status [mc "Calling prepare-commit-msg hook..."]
+ set pch_error {}
+
+ fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+ fileevent $fd_ph readable \
+ [list prepare_commit_msg_hook_wait $fd_ph]
+
+ return 1;
+}
+
+proc prepare_commit_msg_hook_wait {fd_ph} {
+ global pch_error
+
+ append pch_error [read $fd_ph]
+ fconfigure $fd_ph -blocking 1
+ if {[eof $fd_ph]} {
+ if {[catch {close $fd_ph}]} {
+ ui_status [mc "Commit declined by prepare-commit-msg hook."]
+ hook_failed_popup prepare-commit-msg $pch_error
+ exit 1
+ } else {
+ load_message PREPARE_COMMIT_MSG
+ }
+ set pch_error {}
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+ return
+ }
+ fconfigure $fd_ph -blocking 0
+ catch {file delete [gitdir PREPARE_COMMIT_MSG]}
+}
+
proc read_diff_index {fd after} {
global buf_rdi
^ permalink raw reply related
* Re: upload-pack packfile caching
From: Nicolas Pitre @ 2008-09-16 20:59 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0809161052h43b1be7dh9b322c8ec7d49add@mail.gmail.com>
On Tue, 16 Sep 2008, Scott Chacon wrote:
> I was wondering if it would be of general interest to have upload-pack
> take an option to cache packfiles. Unless I am mistaken, every clone
> on a git server will recreate the same packfile until something new is
> pushed into it, correct? I thought it might be a good idea to pass an
> option to have it cache the packfile that is created if
> create_full_pack is set and re-use it until the repository is updated.
> If I patched upload-pack to do this, would there be any interest in
> it?
Well, if you do that there are a few things to be careful about.
First, having a server process able to write files is a security hazard.
If you want to create a pack cache then it is best if created manually
by the repository owner. You don't want someone cloning a repository
actually messing with such cache.
Secondly, the dynamic creation of a pack currently take into account the
capabilities of the client so not to produce a pack with features that
the client does not support. So in order not to have to cache pack with
many feature combinations, this cache should probably only take effect
if pack capabilities of the server are also supported by the client.
Now, the _only_ advantage of a cached pack file is in avoiding execution
of rev-list. Otherwise creation of a pack for streaming is almost
identical to straight copying of data from disk due to pack data reuse.
The rev-list can be made faster by having the pack-objects process do
the object listing itself instead of piping the output from rev-list
into it ('git repack' does that but 'git-upload-pack' doesn't). And I
believe that rev-list could be made much much faster with pack v4.
That been said...
What you could have is a simple file with 2 SHA1s: the first
corresponding to the output of 'git for-each-ref' and the second one
corresponding to the list of all objects reachable from those refs.
For example:
1) git for-each-ref --format="%(objectname)" --sort=objectname | sha1sum
2) git for-each-ref --format="%(objectname)" | \
xargs git rev-list --objects | cut -c -40 | sort | sha1sum
So, if you do the above in a freshly cloned repository, you'll find that
the SHA1 in 2) corresponds to this:
3) git show-index < .git/objects/pack/pack-*.idx | cut -f2 -d' ' | sha1sum
which means that all objects reachable from all refs are found in the
only pack you have.
Now, if the SHA1 in 2) is computed over the binary representation of all
those object names, you'll find out that it corresponds to the actual
pack name in the .git/objects/pack/ directory.
So what upload-pack could do is look for a special file with those 2
SHA1s, and if it exists then see if the first SHA1 matches the list of
values for all refs, if so then the name of the pack to send out
corresponds to the second SHA1. If that pack is found in the repository
then you just have to stream it out.
Creating that file is then just a matter of doing the equivalent of the
above commands and repacking your repository
into a single pack.
Nicolas
^ permalink raw reply
* [JGIT PATCH 2/2] More aggressively clear flags during RevWalk.reset
From: Shawn O. Pearce @ 2008-09-16 19:34 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1221593677-24481-1-git-send-email-spearce@spearce.org>
We cannot rely upon SEEN to tell us if the commit has flags we
must clear, as some forms of RevWalk usage can get flags put in
places that don't have a clear SEEN trail leading to them. To
ensure we have correctly reset the graph we need to follow down
any chain which has any flag we are not going to retain across
the reset, making the correct test ~retain (and not just SEEN).
This fixes an issue I identified in an application that makes
heavy use of the same RevWalk instance, constantly resetting
it and executing down different parts of the same DAG instance.
Some executions still had UNINTERESTING colored on commits,
even though they should have been cleared by the prior reset.
The clear failed as there was not a SEEN path leading into the
previously UNINTERESTING (but now interesting) commit. This
missing SEEN path occurred because markUninteresting() runs
RevComit.carryFlags(), pushing the UNINTERESTING flag as far
down the DAG as we have parsed. Not all of those DAG nodes
may get visited in a traversal (so they lack SEEN), but they
must get reset in order to reuse the same DAG instance.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/revwalk/RevWalk.java | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
index 5cd7f71..d7e4c58 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
@@ -887,10 +887,11 @@ public final void resetRetain(final RevFlag... retainFlags) {
protected void reset(int retainFlags) {
finishDelayedFreeFlags();
retainFlags |= PARSED;
+ final int clearFlags = ~retainFlags;
final FIFORevQueue q = new FIFORevQueue();
for (final RevCommit c : roots) {
- if ((c.flags & SEEN) == 0)
+ if ((c.flags & clearFlags) == 0)
continue;
c.flags &= retainFlags;
c.reset();
@@ -901,10 +902,13 @@ protected void reset(int retainFlags) {
final RevCommit c = q.next();
if (c == null)
break;
+ if (c.parents == null)
+ continue;
for (final RevCommit p : c.parents) {
- if ((p.flags & SEEN) == 0)
+ if ((p.flags & clearFlags) == 0)
continue;
p.flags &= retainFlags;
+ p.reset();
q.add(p);
}
}
--
1.6.0.2.389.g421e0
^ permalink raw reply related
* [JGIT PATCH 1/2] Paper bag fix RevWalk.reset after inMergeBase is used
From: Shawn O. Pearce @ 2008-09-16 19:34 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
We need to remove delayedFreeFlags from carryFlags anytime we
mark those delayedFreeFlags as actually freeFlags. In other
words we do not want to continue carrying a flag which we have
now freed and will recycle for a different use in the future,
one which may not want to be carried automatically onto parent
commits during revision traversal.
I had the boolean expression incorrect (call it a typo). The
correct way to remove set b from a is "a &= ~b" not "a &= b".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/revwalk/RevWalk.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
index 079432c..5cd7f71 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
@@ -824,7 +824,7 @@ void freeFlag(final int mask) {
private void finishDelayedFreeFlags() {
if (delayFreeFlags != 0) {
freeFlags |= delayFreeFlags;
- carryFlags &= delayFreeFlags;
+ carryFlags &= ~delayFreeFlags;
delayFreeFlags = 0;
}
}
--
1.6.0.2.389.g421e0
^ permalink raw reply related
* Re: Management of opendocument (openoffice.org) files in git
From: Stephen R. van den Berg @ 2008-09-16 19:28 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Sergio Callegari, Johannes Sixt, git
In-Reply-To: <32541b130809160904v7acc73cfm4856c33d40555e94@mail.gmail.com>
Avery Pennarun wrote:
>On Tue, Sep 16, 2008 at 3:41 AM, Sergio Callegari
><sergio.callegari@gmail.com> wrote:
>> Johannes Sixt wrote:
>IIRC zip files keep their index at the end of the file, which means
>zipping in a pipeline is efficient (you can write all the blocks
>first, then drop the final index at the end) but unzipping that way is
>really hard.
Well, the index *is* at the end, yes, however, almost all (if not all) the
information in the index is present directly in front of the files as
well, so unzipping from stdin is possible without seeks (though the
standard unzip doesn't support that (yet) because it tries to verify
integrity and speed up lists using the index at the end).
--
Sincerely,
Stephen R. van den Berg.
Human beings were created by water to transport it uphill.
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-16 19:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809160759w5c9be510t3b33d5d983bff5a7@mail.gmail.com>
On 2008-09-16 15:59:31 +0100, Catalin Marinas wrote:
> 2008/9/16 Karl Hasselström <kha@treskal.com>:
>
> > iw is the index+worktree object. The idea is that you provide one
> > if your branch is checked out, and not if not. Operations that
> > have no need of index+worktree, like pop, and push in case
> > automatic merging succeeds, will just work anyway, while
> > operations that need index+worktree, such as a conflicting push,
> > will cause the whole transaction to abort.
>
> Ah, that's the difference. I thought that even if iw isn't passed,
> it uses the default one.
It wouldn't be clean of it to do that -- it would be accessing
non-local state it had no business knowing about. I try hard to avoid
that kind of thing.
> > ( Oh, and note that what I just said talks about the "patch stack
> > log", meaning that I'm talking about the code in
> > kha/experimental. The code in kha/safe doesn't look quite the
> > same -- in particular, there's no obvious place to place code
> > that ignores the conflicting push. Unless you really don't want
> > your sink changes to depend on the stack log stuff (e.g. because
> > you doubt you'll be merging it anytime soon), I suggest we do
> > this: I'll prepare, and ask you to pull, a "stacklog" branch,
> > and once you've pulled it we won't rebase it anymore. You can
> > merge it directly to your master or publish it as a separate
> > development branch, whichever you feel is best. )
>
> I think we could merge your experimental branch into master. I gave
> it a try and seems OK. The only issue I had was that I had an older
> version of Git and it failed in really weird ways (stg pop still
> busy-looping after 4 minutes and in another case it failed with
> broken pipe). Once I pulled the latest Git, it was fine but we
> should try to be compatible at least with the Git version in the
> Debian testing distribution. It might be the patch at the top with
> diff-ing several trees at once but I haven't checked.
There are two patches that depend on new git versions. One needs git
1.5.6, which is in testing so I'll be pushing that to you; the other
needs Junio's master branch, and i won't even consider asking you to
take it until it's in a released git.
I hope to push it out to you tonight or tomorrow, but I have a small
pet patch I'd like to finish first, so I might be late.
> BTW, I ran some benchmarks on stable/master/kha-experimental
> branches with 300 patches from the 2.6.27-rc5-mm1 kernel. See
> attached for the results. Since performance was my worry with the
> stack log stuff, it turns out that there isn't a big difference with
> real patches. I think pushing can be made even faster by trying a
> git-apply first and taking the diff from the saved blobs in the log.
When benchmarking recent StGits, you'll want to try goto as well,
since push and pop are not yet new-infrastructure-ized (meaning
they're getting slowdowns from the stack log, but no speedups (if any)
from the new infrastructure).
> > On 2008-09-15 17:44:38 +0100, Catalin Marinas wrote:
> >
> > > + if options.conflict:
> > > + iw = stack.repository.default_iw
> > > + else:
> > > + iw = None
> >
> > As I said above, this doesn't (or at least isn't supposed to)
> > work.
>
> It should work since the trans.run() command without iw is
> equivalent to trans.run(iw=None).
But passing iw = None means telling the transaction that you have no
index+worktree, so it won't touch them. You'll get no detection of
dirty tree, or checkout of result tree in the end. Which is not what
you indended, IIUC.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Grafts workflow for a
From: Sergio @ 2008-09-16 19:12 UTC (permalink / raw)
To: git
In-Reply-To: <20080916052425.GA14644@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> Martin Langhoff <martin.langhoff <at> gmail.com> wrote:
> > Here is my attempt at a "let's publish a shallow repository for branch
> > of moodle". Let me show you what I did...
> ...
> > # 1.7 was a significant release, anything earlier than that
> > # is just not interesting -- even for pickaxe/annotate purposes
> > # so add a graft point right at the branching point.
> ...
> > Is this kind of workflow (or a variation of it) supported? For this to
> > work, we should communicate the grafts in some push operations and
> > read them in clone ops - and perhaps in fetch too.
>
> Currently the grafts file isn't transferred over any transport
> protocol as it is considered to be local only to the repository.
>
> For one thing, grafts are a security risk. Any user can graft
> anything in at any position and log/blame operations will honor
> the graft, rather than what is stored in the signed commit chain.
> Its a low risk, but it allows a peer to lie to you and give you
> something other than what you asked for.
>
Would it make sense to differentiate two types of grafts, just like we
differentiate two kind of tags?
Then there could be "annotated grafts objects" that could be optionally signed
and that would get transferred on clones, fetches, pushes, etc.
Sergio
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Jeff King @ 2008-09-16 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Avery Pennarun, Thomas Rast
In-Reply-To: <7vhc8g6nqt.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 16, 2008 at 09:48:10AM -0700, Junio C Hamano wrote:
> Ok, how about this patch? I do not have an access to the box with
> AsciiDoc 8 handy right now, so I cannot test this myself, but there must
> be somebody on the list who can give a quick test to this.
No, using this patch and your test procedure, +old and +new are
identically broken with my version of asciidoc (8.2.7). Both contain
<sub> tags.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Jeff King @ 2008-09-16 19:08 UTC (permalink / raw)
To: Brandon Casey
Cc: Arjen Laarhoven, git, Mike Ralphson, Johannes Sixt,
Junio C Hamano
In-Reply-To: <W_emvcr7ijntBMNCDV17_XHXotGkm1Bn-9Bw-ZixcXmFyBWlDj5vYg@cipher.nrlssc.navy.mil>
On Tue, Sep 16, 2008 at 12:49:20PM -0500, Brandon Casey wrote:
> I wonder if this is the right fix? Right now the GNU regex library is
> necessary for Darwin, FreeBSD and AIX. I can add IRIX6.5 and Solaris 7
> to that list. Have newer Solaris's been tested yet? (Jeff?) I wonder if
I haven't tested; getting tests running under Solaris is on my long-term
todo. I'll try to look later today or tomorrow to see how this
particular one behaves.
-Peff
^ permalink raw reply
* Re: [EGIT] Checking out signed tags fails
From: Jonas Fonseca @ 2008-09-16 18:48 UTC (permalink / raw)
To: Jonas Flodén; +Cc: git
In-Reply-To: <gaoaif$2up$1@ger.gmane.org>
On Tue, Sep 16, 2008 at 14:58, Jonas Flodén <jonas.floden@gmail.com> wrote:
> When trying to check-out a signed tag I get the following Error:
> Unable to switch branches
>
> Reason:
> Mapping commit: refs/tags/v1.3.1.1
>
> And in details:
> Object XXX is not a commit.
>
> The object ID shown is actually the id for the tag object and not the
> tagged commit.
>
> This was tested with the latest master. It seemed commit 1f460e2 (Tests
> and fixes for dereferencing tags in Repository.resolve(), 2008-09-12)
> would fix it, but it didn't.
The fixes are only for the code path where reference expressions needs
to be resolved. From what I understand, the problem you have
encountered is due to resolve() falling back to using resolveSimple()
which doesn't dereference any tags. Perhaps EGit could postfix ^{} or
^{commit} to the tag name before calling mapCommit(), or whatever it
uses?
--
Jonas Fonseca
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Junio C Hamano @ 2008-09-16 18:09 UTC (permalink / raw)
To: Brandon Casey
Cc: Arjen Laarhoven, git, Mike Ralphson, Johannes Sixt, Jeff King
In-Reply-To: <W_emvcr7ijntBMNCDV17_XHXotGkm1Bn-9Bw-ZixcXmFyBWlDj5vYg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> It's too late to change diff.*.funcname now, but an alternative fix
> which would probably not require every other platform to use GNU regex,
> is to introduce a new funcname option which would allow extended regular
> expression syntax and to convert the internal regular expressions to
> that format.
That's a very sensible approach, I would agree.
^ permalink raw reply
* upload-pack packfile caching
From: Scott Chacon @ 2008-09-16 17:52 UTC (permalink / raw)
To: git list
I was wondering if it would be of general interest to have upload-pack
take an option to cache packfiles. Unless I am mistaken, every clone
on a git server will recreate the same packfile until something new is
pushed into it, correct? I thought it might be a good idea to pass an
option to have it cache the packfile that is created if
create_full_pack is set and re-use it until the repository is updated.
If I patched upload-pack to do this, would there be any interest in
it?
Scott
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Brandon Casey @ 2008-09-16 17:49 UTC (permalink / raw)
To: Arjen Laarhoven
Cc: git, Mike Ralphson, Johannes Sixt, Jeff King, Junio C Hamano
In-Reply-To: <20080907184537.GA4148@regex.yaph.org>
Arjen Laarhoven wrote:
> The standard libc regex library on OSX does not support alternation
> in POSIX Basic Regular Expression mode. This breaks the diff.funcname
> functionality on OSX.
>
> To fix this, we use the GNU regex library which is already present in
> the compat/ diretory for the MinGW port. However, simply adding compat/
> to the COMPAT_CFLAGS variable causes a conflict between the system
> fnmatch.h and the one present in compat/. To remedy this, move the
> regex and fnmatch functionality to their own subdirectories in compat/
> so they can be included seperately.
I wonder if this is the right fix? Right now the GNU regex library is
necessary for Darwin, FreeBSD and AIX. I can add IRIX6.5 and Solaris 7
to that list. Have newer Solaris's been tested yet? (Jeff?) I wonder if
the new test which triggers this flaw has been tested on the other
non-GNU platforms in the Makefile which have not been updated. Boyd
Lynn Gerber and his 12 platforms comes to mind.
It seems POSIX only mentions alternation under Extended Regular Expressions.
Likewise for the vertical-line character '|'.
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_04_07
A look at compat/regex/regex.c: line 4723 shows that the default mode is
RE_SYNTAX_POSIX_BASIC.
>From the description in regex.h this mode includes "...bits common to both
basic and extended POSIX regex syntax". It seems this mode allows backslashed
versions of the extended regular expression operators ?, +, and |.
Other platforms which adhere more strictly to the POSIX spec do not interpret
the backslashed Ext-RE operators in Basic Regular Expression mode. Similar
to GNU RE_SYNTAX_POSIX_MINIMAL_BASIC.
If I'm interpreting things correctly, then all non-GNU platforms may need the
compat regex library.
On a related note: Is there any reason why extended regular expressions
were not used by default? Wouldn't they have looked prettier (fewer backslashes)?
It's too late to change diff.*.funcname now, but an alternative fix which would
probably not require every other platform to use GNU regex, is to introduce a
new funcname option which would allow extended regular expression syntax and to
convert the internal regular expressions to that format.
-brandon
^ 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