* 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 can occur when the script is sourced on systems with "set, -u."
From: Shawn O. Pearce @ 2009-01-13 16:45 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CBD17.3000207@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>
> Third in a series of patches that make bash completions more robust to
> different interactive shell configurations and editors.
>
> [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 can occur when the script is sourced on systems with "set
> -u."
Aside from the message format... OK. The message really should
have looked like this from an mbox point of view:
From: Ted Pavlic <ted@tedpavlic.com>
To: git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>
Bcc:
Subject: [PATCH 3/3] bash-completion: Add internal function documentation
Slightly document the internal functions of the bash
completion package, so callers are more easily able to
determine the expected arguments.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Third in a series to improve the bash completion package,
so it sucks less.
contrib/completion/git-completion.bash | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash
See how the stuff that doesn't matter to the commit message itself
goes after the "---" line? And how the subject is a niceshort, one
line summary of the module impacted and the change? These show up in
gitk and git shortlog, and thus in the "What's changed in git.git"
newsletters Junio publishes. Its important that the subject be
really short and sweet. You can put more detail above the "---"
line, and it will be included in the commit when Junio applies it.
This is all based on the formatting at the time of commit.
Anything up to the first "\n\n" in a commit message goes into the
email subject line. The rest goes into the email body, but above the
"---" line. You can then edit the buffer before sending to insert
non-commit message text after the "---" and before the diff stat.
You can include my Ack'd by line below your Signed-off-by when you
resend it.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Shawn O. Pearce @ 2009-01-13 16:46 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CC3E7.8060805@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>> Your commit message leaves a lot to be desired. I would instead
>> have written something like this:
>
> I agree completely. Sorry about that. stg fired off vim to edit the
> commit message, and I just wasn't thinking.
>
> Would you like me to modify the commit message and resubmit?
You probably should, to be nice to Junio. Its far easier for the
maintainer to save off well formatted messages to an mbox and run
"git am" than it is to stitch it together from different emails
and/or hand edit messages to make them work.
--
Shawn.
^ permalink raw reply
* [PATCH] git-rebase: Update --whitespace documentation
From: Todd Zullinger @ 2009-01-13 17:01 UTC (permalink / raw)
To: git
The parameters accepted by the --whitespace option of "git apply" have
changed over time, and the documentation for "git rebase" was out of
sync. Remove the specific parameter list from the "git rebase"
documentation and simply point to the "git apply" documentation for
details, as is already done in the "git am" documentation.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Documentation/git-rebase.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..dec2b2c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -241,7 +241,7 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
---whitespace=<nowarn|warn|error|error-all|strip>::
+--whitespace=<option>::
This flag is passed to the 'git-apply' program
(see linkgit:git-apply[1]) that applies the patch.
--
1.6.1
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That men do not learn very much from the lessons of history is the
most important of all the lessons of history.
-- Aldous Huxley Collected Essays, 1959
^ permalink raw reply related
* Re: gitignore excludes too much
From: Michael J Gruber @ 2009-01-13 17:36 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901131429020.23531@fbirervta.pbzchgretzou.qr>
Jan Engelhardt venit, vidit, dixit 01/13/09 14:30:
> Hi,
>
>
> I noticed that having "*.d" in .gitignore ignores files that would start
> with a dot, such as ".main.o.d". This is against Unix shell behavior;
> but maybe it's a feature rather than a bug?
> In case of latter, please fix :-)
git uses fnmatch with the last option (flags) being either 0 (for most
purposes) or FNM_PATHNAME (leading /), but never with FNM_PERIOD.
Think "sh with dotglob set" ;)
Since dotfiles tend to be the ones which are not tracked this behaviour
is the more practical one (compared to using FNM_PERIOD and forcing the
typical user to write two patterns).
Cheers,
Michael
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Michael J Gruber @ 2009-01-13 17:51 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T150220-345@post.gmane.org>
Vladimir Pouzanov venit, vidit, dixit 01/13/09 16:03:
> Also just tried on linux box (git 1.6.0.4, perl 5.8.8). Got all the revisions
> but git segfaulted at the end:
> ...
> r21 = e839272549fd746cf45542a7aa6cb151ae3813da (trunk)
> Checked out HEAD:
> http://qsb-mac.googlecode.com/svn/trunk r21
> Segmentation fault
I'm getting
...
r21 = e839272549fd746cf45542a7aa6cb151ae3813da (git-svn)
Checked out HEAD:
http://qsb-mac.googlecode.com/svn/trunk r21
This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
not matter because you don't have branches. What's your svn version?
Michael
^ permalink raw reply
* Re: [PATCH] Fix Documentation typos surrounding the word 'handful'.
From: Jon Loeliger @ 2009-01-13 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vsknnbltu.fsf@gitster.siamese.dyndns.org>
On Tue, 2009-01-13 at 01:24 -0800, Junio C Hamano wrote:
> Thanks, applied with fix from Markus and Sam.
Thanks, Junio, for fixinf my lameness... :-)
jdl
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Boyd Stephen Smith Jr. @ 2009-01-13 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901131204420.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Tuesday 13 January 2009, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote about 'Re: git/webdav is refusing to
authenticate properly.':
>Oh, and FWIW: trying to ridicule the way Git does it completely misses
> the fact that you are using such a ridiculously weak authentication
> scheme anyway that you could just as well open the window and shout your
> password out loud.
Using DIGEST auth would help, although it is still quite vulnerable, but I
couldn't convince git to use that either.
I'm pretty sure even PLAIN auth is acceptable (security-wise) if used over
SSL/TLS. It would be really nice for contributors behind oppressive firewalls
if they could push via https and not have their passwords exposed to the
local BOFH. (Who else sets up an oppressive firewall?)
SVN supported it. It would be nice to add it to the list of git features.
Still, it's just not important enough to me right now to make the time to
throw together a PATCH/RFC.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Davide Libenzi @ 2009-01-13 18:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git, Thomas Rast
In-Reply-To: <200901130152.24401.jnareb@gmail.com>
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> Is this core algorithm available as some exported function in libxdiff?
> I mean would it be easy to replace default line tokenizer (per-line
> pre-processing) and post-processing to better deal with word diff?
In libxdiff, no. I hadn't thought to export the raw Meyer algo, and nobody
ever asked before.
> The other side would be to generate per-paragraph diffs (with empty
> line being separator)...
In Git I guess you can use it to generate other kind of diffs. I don't see
any problems with that. Just requires more memory WRT a line based one.
- Davide
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 19:01 UTC (permalink / raw)
To: git
In-Reply-To: <496CD49D.1070201@drmicha.warpmail.net>
Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
> svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
> another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
> not matter because you don't have branches. What's your svn version?
svn, version 1.5.5 (r34862) on OSX (where perl fails with error) and
svn, version 1.5.0 (Release Candidate
5) on Linux
(where perl segfaults somewhere in apr).
^ permalink raw reply
* Re: [PATCH 3/6] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Johannes Sixt @ 2009-01-13 19:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, Steve Haslam
In-Reply-To: <1231595452-27698-3-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> index db67c31..bbedcfe 100644
> --- a/builtin-receive-pack.c
> +++ b/builtin-receive-pack.c
> @@ -579,6 +579,9 @@ int cmd_receive_pack(int argc, const char **argv, const
> char *prefix) int i;
> char *dir = NULL;
>
> + if (argv[0] && *argv[0])
> + git_extract_argv0_path(argv[0]);
> +
This is not necessary because receive-pack is meanwhile a builtin.
> diff --git a/upload-pack.c b/upload-pack.c
> index e5adbc0..c469a60 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -616,6 +616,9 @@ int main(int argc, char **argv)
> int i;
> int strict = 0;
>
> + if (argv[0] && *argv[0])
> + git_extract_argv0_path(argv[0]);
> +
> for (i = 1; i < argc; i++) {
> char *arg = argv[i];
This hunk should be merged into 4/6.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/6] Refactor git_set_argv0_path() to git_extract_argv0_path()
From: Johannes Sixt @ 2009-01-13 19:37 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, Steve Haslam
In-Reply-To: <1231595452-27698-2-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> @@ -63,9 +63,19 @@ const char *system_path(const char *path)
> return path;
> }
>
> -void git_set_argv0_path(const char *path)
> +const char *git_extract_argv0_path(const char *argv0)
> {
> - argv0_path = path;
Please insert the 'if (argv0 && *argv0)' here to simplify the call sites.
Or you could introduce this check later in 4/6 because the call site in
this patch (main() of git.c) is simpler if it keeps the check.
> + const char *slash = argv0 + strlen(argv0);
> +
> + while (argv0 <= slash && !is_dir_sep(*slash))
> + slash--;
> +
> + if (slash >= argv0) {
> + argv0_path = xstrndup(argv0, slash - argv0);
> + return slash + 1;
> + }
> +
> + return argv0;
> }
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/6] Move computation of absolute paths from Makefile to runtime and compute prefix on the fly if RUNTIME_PREFIX set
From: Johannes Sixt @ 2009-01-13 19:43 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <1231595452-27698-1-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> This is the first commit of a series that adds support for
> relocatable binaries (called RUNTIME_PREFIX). Such binaries can be
> moved together with the system configuration files to a different
> directory, as long as the relative paths from the binary to the
> configuration files is preserved. This functionality is essential
> on Windows where we deliver git binaries with an installer that
> allows to freely choose the installation location. The commit
> series implements RUNTIME_PREFIX only on Windows. Adding support
> on Unix should not be too hard, though.
This series looks sane, and my comments on 2/6 and 3/6 certainly do not
indicate any showstoppers. I've just started using it; so far there are no
problems.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Junio C Hamano @ 2009-01-13 19:43 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496CC3E7.8060805@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
>> Your commit message leaves a lot to be desired. I would instead
>> have written something like this:
>
> I agree completely. Sorry about that. stg fired off vim to edit the
> commit message, and I just wasn't thinking.
>
> Would you like me to modify the commit message and resubmit?
Luckily or unluckily, you need to do that anyway, as your patches are
whitespace damaged.
Please don't send "format=flowed".
^ permalink raw reply
* [PATCH next] git-notes: fix printing of multi-line notes
From: Tor Arne Vestbø @ 2009-01-13 19:57 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, junio
The line length was read from the same position every time,
causing mangled output when printing notes with multiple lines.
Also, adding new-line manually for each line ensures that we
get a new-line between commits, matching git-log for commits
without notes.
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
---
This approach uses a msg pointer, but I started out with just using
msg + msgoffset all over the place, so if that's a preferred way
to do things I'm happy to provide an alternate patch.
Also, I'm guessing this printing should go into pretty.c at some
point, so you can reference the notes as part of a custom pretty
format. If so, this code could be converted to use helpers such
as get_one_line().
This is my first patch to Git, so sorry if I messed something up :)
notes.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/notes.c b/notes.c
index ad43a2e..bd73784 100644
--- a/notes.c
+++ b/notes.c
@@ -110,8 +110,8 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
{
static const char *utf8 = "utf-8";
unsigned char *sha1;
- char *msg;
- unsigned long msgoffset, msglen;
+ char *msg, *msg_p;
+ unsigned long linelen, msglen;
enum object_type type;
if (!initialized) {
@@ -148,12 +148,13 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
strbuf_addstr(sb, "\nNotes:\n");
- for (msgoffset = 0; msgoffset < msglen;) {
- int linelen = strchrnul(msg, '\n') - msg;
+ for (msg_p = msg; msg_p < msg + msglen; msg_p += linelen + 1) {
+ linelen = strchrnul(msg_p, '\n') - msg_p;
strbuf_addstr(sb, " ");
- strbuf_add(sb, msg + msgoffset, linelen);
- msgoffset += linelen;
+ strbuf_add(sb, msg_p, linelen);
+ strbuf_addch(sb, '\n');
}
+
free(msg);
}
--
1.6.0.2.GIT
^ permalink raw reply related
* egit problem with sym linked eclipse project dirs
From: Stephen Bannasch @ 2009-01-13 20:00 UTC (permalink / raw)
To: git; +Cc: Scott Cytacki
To hack around Eclipse's problem with projects in nested directories
I clone a repo and then create a new top-level dir that just has
symbolic links to all the project directories.
However when I Team/Share with git using egit the resources become
untracked when displayed in Eclipse -- they still are tracked however
when I check from the command line.
---- more details ----
using v0.4.0.200901041117 of egit
I've got a large dir structure in a git repo in which there are many
eclipse projects at different levels of the tree.
However Eclipse doesn't work with projects at different levels in a
nested dir structure (bad Eclipse) -- see: Eclipse bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973
When we work with these projects with svn we checkout each one
individually into it's own dir to create the flat hierarchy Eclipse
needs. Updating all these separate projects takes forever -- at
least compared to using Git.
I created a Ruby script to create a new dir named 'workspace' at the
top level of a checkout with symbolic links to all the enclosed
directories that have a .project file inside them.
http://svn.concord.org/svn/projects/trunk/common/flatten_projects.rb
or here in the git mirror:
http://gitorious.org/projects/otrunk-examples/repos/mainline/blobs/raw/5c5ca6ff830f4ad3e4d427df92c1a5dff64831b5/flatten_projects.rb
(warning: repos are public but very big)
The result is a dir: workspace/ that emulates the flat project space
that Eclipse needs:
http://gist.github.com/4658 (a bunch of these are legacy projects)
Then I open Eclipse, switch to a new Workspace, select the
newly-created 'workspace' dir and import the projects to work on.
This works fine for Eclipse. The projects build and reference each other.
But when I then turn on the team/sharing/git for each project ...
The operation completes -- the git decorator appears showing [Git @ master] ...
but the files are all untracked.
Screenshots showing the sequence after importing just 7 projects:
apple-support, framework, frameworkview, otrunk, swing, thirdparty-jars
share projects:
http://skitch.com/stepheneb/bbnqf/skitched-20090113-144412
select git:
http://img.skitch.com/20090113-peu5y38a1yqm4kfqasf6hh9r9t.png
iterate through each project:
http://img.skitch.com/20090113-k6wf8xgs2bc4ehy9siscdyteqr.png
http://img.skitch.com/20090113-jughm7eatnuum43gfuedmctrw5.png
showing untracked files on master branch:
http://skitch.com/stepheneb/bbnqc/skitched-20090113-144646
However from the command line git shows the appropriate untracked
files after an Eclipse build:
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# java/core/apple-support/bin/
# java/core/framework/lib/
# java/core/frameworkview/lib/
# java/core/swing/lib/
# java/otrunk/otrunk/lib/
# java/thirdparty/phet-simulations-java/simulations/cck/cck
# rails/portal/portal
# workspace/
^ permalink raw reply
* 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 can occur when the script is sourced on systems with "set, -u."
From: Boyd Stephen Smith Jr. @ 2009-01-13 20:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git, Junio C Hamano
In-Reply-To: <20090113164518.GS10179@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
>See [...] how the subject is a niceshort, one
>line summary of the module impacted and the change?
My rule for this is absolutely no more than 80 characters. Generally, you
wouldn't want more than 60 or so, since it is used as the Subject: header and
generally has some prefix added.
As shown says, details can go in the rest of the commit message. If you are
using more than 60-80 characters even without details, you might think about
splitting the patch.
>This is all based on the formatting at the time of commit.
>Anything up to the first "\n\n" in a commit message goes into the
>email subject line.
IIRC, multiple "-m" options to "git commit" will be separated by "\n\n", so
that's one way to do it if you don't like your $EDITOR for some reason.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* 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 can occur when the script is sourced on systems with "set, -u."
From: Adeodato Simó @ 2009-01-13 20:10 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Shawn O. Pearce, Ted Pavlic, git, Junio C Hamano
In-Reply-To: <200901131403.16012.bss@iguanasuicide.net>
* Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
> On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
> >See [...] how the subject is a niceshort, one
> >line summary of the module impacted and the change?
> My rule for this is absolutely no more than 80 characters.
My rule for *all* of the commit message is "absolutely no more than 76
characters". With more than 76, `git log` wraps in a 80-column terminal.
Just my 2¢,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-13 20:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git
In-Reply-To: <200901130039.48340.jnareb@gmail.com>
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> Asheesh Laroia wrote:
>> On Mon, 12 Jan 2009, Jakub Narebski wrote:
>>
>>> But I have to run
>>>
>>> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>>>
>>> first. Is there any way to automate this?
>>
>> Check out 'gstm' or 'autossh'.
>
> I don't know about gSTM (Gnome SSH Tunnel Manager), but autossh
> does only provide reconnect in the case the gateway host closes
> connection. I still have to run it, perhaps from startup script.
Yeah, gSTM is pretty manual in that regard. autossh from a startup script
makes sense.
-- Asheesh.
--
Q: How many marketing people does it take to change a light bulb?
A: I'll have to get back to you on that.
^ permalink raw reply
* Re: [PATCH/RFC v7 0/5] git checkout: optimise away lots of lstat() calls
From: Junio C Hamano @ 2009-01-13 20:17 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Pete Harlan, Linus Torvalds
In-Reply-To: <1231849748-8244-1-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Junio, I hope it is possible to use patches 1/5, 2/5 and 3/5 from this
> version instead of 1/3, 2/3 and 3/3 from version 6, for the possible
> future in origin/pu? See also a) above. Thanks in advance!
>
> In general, are we allowed to redesign the patch-series while the
> patches is inside origin/pu?
You won't be too far off if you thought of 'pu' branch nothing more than
my bookmarks into the list archive. They are interesting enough to keep
an eye on their evolution but not yet stable enough to go into initial
round of wider testing and incremental development which starts to happen
when they hit 'next'.
So yes, while you are not yet confident that the series does not need
major redesign, please keep sending replacements (not incremental
updates), making it clear that you still have reservations and I'll keep
them in 'pu', until the initial barrage of "Oh, I think this way is
better", "The previous review comments were valuable, and this round
contains all of them" is over and things seem to stabilize into a testable
shape.
Personally I felt your v5 and later ones were already 'next' material, and
the only reason why the series haven't landed on 'next' was because you
kept sending updates before I sat down in the evening and said "Ok, this
looks good---let's merge it to 'next'". Instead I ended up saying "Hmph,
I thought it looked good already but the author seems not satisfied yet;
there is another round of update to replace the previous one. Let's queue
it in 'pu', as it may be updated again, and I have to also look at series
from other people.' ;-)
^ permalink raw reply
* Commit messages
From: Teemu Likonen @ 2009-01-13 20:24 UTC (permalink / raw)
To: Adeodato Simó
Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <20090113201024.GA20129@chistera.yi.org>
Adeodato Simó (2009-01-13 21:10 +0100) wrote:
> * Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
>
>> My rule for this is absolutely no more than 80 characters.
>
> My rule for *all* of the commit message is "absolutely no more than 76
> characters". With more than 76, `git log` wraps in a 80-column terminal.
Here's my rule:
(add-to-list 'auto-mode-alist
'("/\\.git/\\(COMMIT\\|TAG\\)_EDITMSG\\'" .
vcs-message-mode))
(define-derived-mode vcs-message-mode text-mode "VCS-message"
"Major mode for editing commit and tag messages."
(auto-fill-mode 1)
(set (make-local-variable 'tab-stop-list)
(number-sequence 4 100 4))
(setq indent-tabs-mode nil
fill-column 72
truncate-lines t))
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Kyle Moffett @ 2009-01-13 20:26 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Linus Torvalds, Sam Ravnborg, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <200901112239.20306.borntraeger@de.ibm.com>
On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> In my opinion we should really avoid subtree merges in the future as a curtesy
> to people who do the uncool work of testing, problem tracking and bisecting.
> </rant>
As an alternative, you can relatively easily rewrite the following
independent histories:
A -- B -- C
X -- Y -- Z
To look like this:
A -- B -- C -- X' -- Y' -- Z'
Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...
Assuming the following:
"master" branch points to commit C
"child" branch points to commit Z
"${KIDSTART}" is the SHA1 id of commit X
echo "${KIDSTART} $(git rev-parse --verify master)" >>.git/info/grafts
git filter-branch --index-filter 'git read-tree master && git
read-tree --prefix="sub/dir/" "${GIT_COMMIT}"' -- master..child
The one downside is then somebody actually has to *test* those commits
when doing a bisect, even though they did not materially change
anything. The upside is that there isn't any "what the hell just
happened?" when you *do* end up in the newly-created branch.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Björn Steinbrink @ 2009-01-13 20:39 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T185918-397@post.gmane.org>
On 2009.01.13 19:01:28 +0000, Vladimir Pouzanov wrote:
> Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> > This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
> > svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
> > another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
> > not matter because you don't have branches. What's your svn version?
>
> svn, version 1.5.5 (r34862) on OSX (where perl fails with error) and
> svn, version 1.5.0 (Release Candidate
> 5) on Linux
> (where perl segfaults somewhere in apr).
Is that Linux box using Gentoo? If so, try emerging subversion with -dso
in your build flags.
Cloning the svn repo you mentioned works fine with
git-svn version 1.6.1.40.g8ea6a (svn 1.5.1)
(On debian sid)
Björn
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 20:46 UTC (permalink / raw)
To: git
In-Reply-To: <20090113203922.GD30404@atjola.homenet>
Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
> Is that Linux box using Gentoo? If so, try emerging subversion with -dso
> in your build flags.
Yeah, that's gentoo. Will try rebuilding svn now. Any hints about OSX
perl problem?
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Jay Soffian @ 2009-01-13 21:12 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T204616-845@post.gmane.org>
On Tue, Jan 13, 2009 at 3:46 PM, Vladimir Pouzanov <farcaller@gmail.com> wrote:
> Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
>> Is that Linux box using Gentoo? If so, try emerging subversion with -dso
>> in your build flags.
>
> Yeah, that's gentoo. Will try rebuilding svn now. Any hints about OSX
> perl problem?
Your original email doesn't appear to provide the complete error
message. I'm on OS X 10.5.6 (Intel), git 1.6.1.77.g81ea1, system perl
(/usr/bin/perl - 5.8.8) and I'm able to clone okay:
$ which git
/opt/git/bin/git
$ git version
git version 1.6.1.77.g81ea1
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
...
Checked out HEAD:
http://qsb-mac.googlecode.com/svn/trunk r21
j.
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <76718490901131312j28f8283bi94f55000e70c532e@mail.gmail.com>
Jay Soffian <jaysoffian <at> gmail.com> writes:
> Your original email doesn't appear to provide the complete error
> message. I'm on OS X 10.5.6 (Intel), git 1.6.1.77.g81ea1, system perl
> (/usr/bin/perl - 5.8.8) and I'm able to clone okay:
$ git version
git version 1.6.1
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
Initialized empty Git repository in /Users/farcaller/temp/qsb-mac/.git/
r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.m
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_01.txt
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_02.txt
A externals/BSJSONAdditions/Example/version.plist
A externals/BSJSONAdditions/Example/main.m
A externals/BSJSONAdditions/Example/Unit Tests/Test
Files/json_test_valid_03.txt
A externals/BSJSONAdditions/NSArray+BSJSONAdditions.m
A externals/BSJSONAdditions/BSJSON.h
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.h
Temp file with moniker ' at /opt/local/lib/perl5/site_perl/5.8.8/Git.pm line
1011.
Git, subversion and perl are from macports:
$ port info perl5
perl5 @5.8.8, Revision 2 (lang)
$ port info git-core
git-core @1.6.1 (devel)
Variants: bash_completion, doc, gitweb, svn
$ port info subversion
subversion @1.5.5 (devel)
Variants: bash_completion, (-)darwin_7, mac_os_x_server_mod_dav_svn,
mod_dav_svn, no_bdb, no_neon, tools, unicode_path, (-)universal
^ 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