* git-stash.sh: don't default to refs/stash if invalid ref supplied
From: Brandon Casey @ 2008-09-26 15:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
commit da65e7c133cd316c9076fbb6b0aeee7bc42a6db8
Author: Brandon Casey <casey@nrlssc.navy.mil>
Date: Tue Sep 23 18:57:09 2008 -0500
git-stash.sh: don't default to refs/stash if invalid ref supplied
<snip>
e.g. 'git stash apply stash@{1}' would fall back to
'git stash apply stash@{0}'
heh, you fixed my spelling "mistake" :), but it wasn't a mistake. Originally
I had:
e.g. 'git stash apply stahs@{1}' would fall back to
'git stash apply stash@{0}'
intending to show that a simple spelling mistake could cause the wrong thing
to be done. The example in the commit message could actually still happen if
there was only a single stash entry. I guess I should have used 'foobar@{1}'. :)
-brandon
^ permalink raw reply
* Re: Internal, corporate, shared hosting solutions
From: Shawn O. Pearce @ 2008-09-26 15:39 UTC (permalink / raw)
To: Tom Lanyon; +Cc: git
In-Reply-To: <8B29890D-C03B-4ECE-9BEF-0A8E8EF7233E@netspot.com.au>
Tom Lanyon <tom@netspot.com.au> wrote:
> We have some pretty basic requirements:
> - authentication and authorisation; some repos are only readable/
> writable by specific people
> - accessible; many dev servers are on private subnets, ideally we need
> to be able to proxy git access
> - not too much messing with unix user accounts on the central git host
> (because they're tied to LDAP, for example)
Use git over ssh, but use gitosis on the server side:
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Have each developer supply their own SSH public key, install it
into the gitosis database, and they can only read/write repos
they have access to in the admin database.
Secure, fast, yea, you can actually pick two out of two. :)
--
Shawn.
^ permalink raw reply
* Internal, corporate, shared hosting solutions
From: Tom Lanyon @ 2008-09-26 15:13 UTC (permalink / raw)
To: git
Hi list,
I'm struggling. There's been a recent adoption of git here by our
development staff, which is great. However, from an administrative
point of view, I'm having trouble finding a solution to provide some
kind of easy, shared, secure and accessible hosting solution to our
developers.
So that these repositories can be centrally tracked and backed up, we
require a central git host for all of our projects from all our
development teams.
We have some pretty basic requirements:
- authentication and authorisation; some repos are only readable/
writable by specific people
- accessible; many dev servers are on private subnets, ideally we
need to be able to proxy git access
- not too much messing with unix user accounts on the central git
host (because they're tied to LDAP, for example)
Accessibility is easily addressed by providing access to the git
repositories via WebDAV with which we can proxy HTTP traffic.
Similarly, HTTP gives us great authentication and authorisation;
fantastic, problem solved. Not so fast. We need git built with
USE_CURL_MULTI to support push over HTTP, which requires curl >=
7.16.0. The most recent RedHat Enterprise Linux has 7.15.5 so we'd
need to build many custom packages and compatibility packages for any
servers needing git access and this is plainly not acceptable from an
administrative standpoint. Additionally, git over WebDAV is incredibly
slow. Pushing git's git repostory to a new, empty repository over
gigabit ethernet was ridiculously slow (I didn't bother to do it again
and time it).
Looking at the git native protocol or git-over-ssh, then. We can
tunnel these if need be, so forget about the accessibility issue.
Authentication becomes a problem here; the git daemon doesn't have
enough security controls to grant groupA r/w access to repoX, read
access to repoY and no access to anything else. Is SSH a solution for
my problems? Can we provide shared repositories to certain groups of
people, while limiting access to others and is this going to require
accounts for each developer on the server (the git-shell seems to not
be flexible enough for this)?
Am I thinking about this conceptually wrong or am I missing something
simple?
Thanks,
Tom
--
Tom Lanyon
^ permalink raw reply
* Re: [PATCH] Fix memleak and the implementation of remove_file in builtin-rm.c
From: Shawn O. Pearce @ 2008-09-26 15:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080925202237.GB18315@blimp.localhost>
Alex Riesen <raa.lkml@gmail.com> wrote:
> It is the same as in merge-recursive, but they're so small so unless
> we get a special file with such random routines there is no much point
> exporting it. Actually, we do seem to have such a file: dir.c. It is
> already plagued by file_exists kind of things, why not remove_path...
Yea. I'm thinking remove_path should migrate to dir.c. Hell,
we already have rm -rf as remove_dir_recursively() in dir.c.
remove_path is its long-lost soul mate. I'm not applying this
builtin-rm fix, and am hoping you'll rewrite it around a move
of remove_path to dir.c... ;-)
> diff --git a/builtin-rm.c b/builtin-rm.c
> index fdac34f..910a34d 100644
> --- a/builtin-rm.c
> +++ b/builtin-rm.c
> @@ -31,22 +31,18 @@ static void add_list(const char *name)
>
> static int remove_file(const char *name)
> {
--
Shawn.
^ permalink raw reply
* Re: git-stash.sh: don't default to refs/stash if invalid ref supplied
From: Shawn O. Pearce @ 2008-09-26 15:25 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <rM3bh5QWZGeYnjwx4dCYZ179UgQYlxany_gu84OcX6FVMMOkKmGKWg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> wrote:
> commit da65e7c133cd316c9076fbb6b0aeee7bc42a6db8
> Author: Brandon Casey <casey@nrlssc.navy.mil>
> Date: Tue Sep 23 18:57:09 2008 -0500
>
> git-stash.sh: don't default to refs/stash if invalid ref supplied
>
> <snip>
>
> e.g. 'git stash apply stash@{1}' would fall back to
> 'git stash apply stash@{0}'
>
> heh, you fixed my spelling "mistake" :), but it wasn't a mistake. Originally
> I had:
Heh. I geuss my spleling meter was working overtime yesterday? ;-)
> e.g. 'git stash apply stahs@{1}' would fall back to
> 'git stash apply stash@{0}'
>
> intending to show that a simple spelling mistake could cause the wrong thing
> to be done. The example in the commit message could actually still happen if
> there was only a single stash entry. I guess I should have used 'foobar@{1}'. :)
Yea, reading it now I see why you had the typo in the message.
But yesterday it just looked like a typo to me. Dammit. That's
the last time I cleanup a typo before applying a patch!
;-)
--
Shawn.
^ permalink raw reply
* [PATCH] builtin-commit: avoid always using reduce_heads()
From: Miklos Vajna @ 2008-09-26 15:20 UTC (permalink / raw)
To: SZEDER Gabor; +Cc: spearce, jnareb, Johannes.Schindelin, git
In-Reply-To: <20080926151517.GV23137@genesis.frugalware.org>
In case git merge --no-ff is used with --no-commit or we have a
conflict, write info about if fast forwards are allowed or not to
$GIT_DIR/MERGE_MODE.
Based on this info, don't run reduce_heads() in case fast-forwards are
denied, to avoid turning a 'merge --no-ff' to a non-merge commit.
Test case by SZEDER Gabor <szeder@ira.uka.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Sep 26, 2008 at 05:15:17PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> I'll send a patch that does this in a bit.
Here it is.
builtin-commit.c | 16 +++++++++++++++-
builtin-merge.c | 9 +++++++++
t/t7600-merge.sh | 9 +++++++++
3 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 55e1087..aac5cb4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -937,6 +937,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char commit_sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
+ struct stat statbuf;
+ int allow_fast_forward = 1;
git_config(git_commit_config, NULL);
@@ -988,7 +990,18 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = "commit";
pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
}
- parents = reduce_heads(parents);
+ strbuf_reset(&sb);
+ if (!stat(git_path("MERGE_MODE"), &statbuf)) {
+ if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
+ die("could not read MERGE_MODE: %s", strerror(errno));
+ printf("debug, contents of buf: '%s'\n",sb.buf);
+ if (!strcmp(sb.buf, "deny_fast_forward")) {
+ printf("debug, deny fast forward\n");
+ allow_fast_forward = 0;
+ }
+ }
+ if (allow_fast_forward)
+ parents = reduce_heads(parents);
/* Finally, get the commit message */
strbuf_init(&sb, 0);
@@ -1040,6 +1053,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unlink(git_path("MERGE_HEAD"));
unlink(git_path("MERGE_MSG"));
+ unlink(git_path("MERGE_MODE"));
unlink(git_path("SQUASH_MSG"));
if (commit_index_files())
diff --git a/builtin-merge.c b/builtin-merge.c
index 5c65a58..973b167 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -1210,6 +1210,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
merge_msg.len)
die("Could not write to %s", git_path("MERGE_MSG"));
close(fd);
+ fd = open(git_path("MERGE_MODE"), O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("Could open %s for writing", git_path("MERGE_MODE"));
+ strbuf_reset(&buf);
+ if (!allow_fast_forward)
+ strbuf_addf(&buf, "deny_fast_forward");
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die("Could not write to %s", git_path("MERGE_MODE"));
+ close(fd);
}
if (merge_was_ok) {
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9516f54..98cfc53 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -511,4 +511,13 @@ test_expect_success 'in-index merge' '
test_debug 'gitk --all'
+test_expect_success 'merge --no-ff --no-commit && commit' '
+ git reset --hard c0 &&
+ git merge --no-ff --no-commit c1 &&
+ EDITOR=: git commit &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-26 15:15 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20080926010312.GE6816@neumann>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Fri, Sep 26, 2008 at 03:03:12AM +0200, SZEDER Gábor <szeder@ira.uka.de> wrote:
> * FAIL 18: Hand committing of a redundant merge removes dups
>
>
> git rev-parse second master >expect &&
> test_must_fail git merge second master &&
> git checkout master g &&
> EDITOR=: git commit -a &&
> git cat-file commit HEAD | sed -n -e "s/^parent //p"
> -e "/^$/q" >actual &&
> test_cmp expect actual
>
>
>
> * failed 1 among 18 test(s)
> make: *** [t7502-commit.sh] Error 1
OK, here is the scenario.
The basic problemis that if it's git-commit that creates the merge
commit and not git-merge, then git-commit does not "know" that git-merge
was invoked using --no-ff.
--no-ff means that if reduce_heads() removes a parent, that will be a
problem, since the resulting commit will no longer be a merge commit.
I think we can't avoid storing this info in a MERGE_MODE file, because
we have to add HEAD to the list of parents in case --no-ff is used, but
we should not do so in case it's reachable from existing heads and
--no-ff is not used.
I'll send a patch that does this in a bit.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Johannes Sixt @ 2008-09-26 15:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Gustaf Hendeby, git
In-Reply-To: <20080926143119.GX3669@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> My situation is this: I fire up git-gui, and because I have some stale
>> .git/GITGUI_MSG file, the commit message box is not empty. Aspell begins
>> its work, and git-gui correctly marks spelling mistakes in the first line.
>> Even if I type new text, delete old text, or change the whole text by
>> clicking "Amend", no new spelling mistakes are marked for the whole session.
>
> Hmm. Sounds to me like aspell crashes and dies after a while.
>
> When aspell terminates on its own git-gui doesn't try to restart it.
> I've never seen it abort on my Mac, or my Linux systems. Or even
> on Windows when I was using the Cygwin version of aspell.
No, it does not abort. It's still running, but sitting there idly.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Remove empty directories in recursive merge
From: Shawn O. Pearce @ 2008-09-26 15:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080925203329.GC3959@blimp.localhost>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Alex Riesen, Thu, Sep 25, 2008 22:12:45 +0200:
> > The code was actually supposed to do that, but was accidentally broken.
> > Noticed by Anders Melchiorsen.
> >
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
>
> Shawn, the change is intentionally based on Junios master,
Actually I think this is 'maint' worthy. It applies clean there.
I'm trying to slate it for maint.
> so people can just apply it. But if you wish, I can rebase it on top
> of Miklos' patches.
Its small. I can manage to merge it over myself. Thanks.
--
Shawn.
^ permalink raw reply
* RE: [QGit] Some suggestion
From: Li Frank-B20596 @ 2008-09-26 14:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550809260337o1523995ele3333c0de9295393@mail.gmail.com>
Option 1:
Telling user just filted is better than nothing. Is it possible
add tool button tip.
When mouse over 'Rev list [Felted]", show what filtering.
Best regards
Frank Li
-----Original Message-----
From: Marco Costalba [mailto:mcostalba@gmail.com]
Sent: Friday, September 26, 2008 6:38 PM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: [QGit] Some suggestion
On Fri, Sep 26, 2008 at 7:43 AM, Li Frank-B20596
<Frank.Li@freescale.com> wrote:
>
> I have some suggestions.
> Option 1: Change "Rev List" to "Rev List Filtered"
This is the more correct but we don't have the space to write on what
files it is filtering
> Option 2: Change "Short Log" to "Short Log Filter On
> <Lib/blame.tcl>"
This is less correct because short log has nothing to do with filtering,
but here there is more space...
> Option 3: Add bar between tab and list, show current filter
> information
>
Too complicated and space wasteful IMO.
Marco
^ permalink raw reply
* Re: No "pull" in git gui?
From: Shawn O. Pearce @ 2008-09-26 14:49 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git
In-Reply-To: <588192970809260737i46ce0c30y191e29156bbf6396@mail.gmail.com>
Steve Hoelzer <shoelzer@gmail.com> wrote:
> Why isn't there a pull command in git gui's remote menu?
I got lazy and didn't write support for it. Before today nobody has
really asked me why it was missing so it seemed to be unimportant.
> Am I supposed to fetch and then merge?
Yes, that works.
> Is that preferred over pull for some reason?
I find it easier to teach new Git users "fetch + merge" rather
than pull. It helps to reinforce the idea of having your own
local state that differs from the state on the upstream repository.
I consider pull to be more of a power-user feature. But many in the
Git community disagree with me and find teaching pull is easier, with
fetch+merge being power user features.
So patches to add pull to git-gui would be accepted, but they won't
be getting written by me anytime soon. I've got too much other
stuff going on to write a feature that isn't very interesting to me.
--
Shawn.
^ permalink raw reply
* Re: No "pull" in git gui?
From: Andreas Ericsson @ 2008-09-26 14:47 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git
In-Reply-To: <588192970809260737i46ce0c30y191e29156bbf6396@mail.gmail.com>
Steve Hoelzer wrote:
> Why isn't there a pull command in git gui's remote menu? Am I supposed
> to fetch and then merge? Is that preferred over pull for some reason?
>
Yes, it is. Blind "git pull" without knowing what you're going to
fetch is not recommended, because it tends to create tons and tons
of "useless" merges, where all commits are on one branch and there's
no clear distinction between them. Such merges are useless because
you'd be better off with a linearized history (bisection turns out
slightly easier, fe).
"git pull" is primarily intended for
* people like Linus, who merge in a lot of other people's code.
* bleeding-edge *users* that just want the latest and greatest.
* "vcs = cvs" users, that never care about history
For all other workflows I've ever encountered, doing "git pull"
blindly always ends up being worse than
* developing on topic-branches and merging those when ready.
* doing 'git pull --rebase', to linearize a series of small
fixes before pushing them back up.
* 'git fetch' + manually inspect new code + 'git merge'.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC PATCH (GIT-GUI)] git-gui: Add more integration options to citool.
From: Shawn O. Pearce @ 2008-09-26 14:45 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200809261419.41392.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> On Wednesday 24 September 2008 20:52:01 Shawn O. Pearce wrote:
> >
> > --8<--
> > git-gui: Hide commit related UI during citool --nocommit
>
> I believe that the 'Sign Off' button should better be controlled by the nocommitmsg
> option; otherwise this looks good to me. But I'm not the best thinker at the
> moment (had a cold).
Since I've already pushed that patch in both git-gui.git and git.git
how is this as a followup?
--8<--
git-gui: Show/hide "Sign Off" based on nocommitmsg option
If citool --nocommit is invoked we hide the Sign Off features, as
the commit message area is not editable. But we really want the
selection tied to the message area's editing ability.
Suggested-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 4085e8f..09ce410 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2413,7 +2413,7 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
.mbar.commit add separator
- if {![is_enabled nocommit]} {
+ if {![is_enabled nocommitmsg]} {
.mbar.commit add command -label [mc "Sign Off"] \
-command do_signoff \
-accelerator $M1T-S
@@ -2743,7 +2743,7 @@ pack .vpane.lower.commarea.buttons.incall -side top -fill x
lappend disable_on_lock \
{.vpane.lower.commarea.buttons.incall conf -state}
-if {![is_enabled nocommit]} {
+if {![is_enabled nocommitmsg]} {
button .vpane.lower.commarea.buttons.signoff -text [mc "Sign Off"] \
-command do_signoff
pack .vpane.lower.commarea.buttons.signoff -side top -fill x
--
1.6.0.2.508.g2bf53a
--
Shawn.
^ permalink raw reply related
* No "pull" in git gui?
From: Steve Hoelzer @ 2008-09-26 14:37 UTC (permalink / raw)
To: git
Why isn't there a pull command in git gui's remote menu? Am I supposed
to fetch and then merge? Is that preferred over pull for some reason?
Steve
^ permalink raw reply
* Re: mysterious error message
From: Shawn O. Pearce @ 2008-09-26 14:37 UTC (permalink / raw)
To: tom sgouros; +Cc: Johannes Schindelin, git
In-Reply-To: <30988.1222439568@as220.org>
tom sgouros <tomfool@as220.org> wrote:
> > On Thu, 25 Sep 2008, Tom Sgouros wrote:
> > > I receive the following error message when I try to do a 'git push':
> > >
> > > tomfool@toms-box:hpl$ git push
> > > updating 'refs/heads/master'
> > > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > > Also local refs/remotes/origin/master
> > > Generating pack...
> > > Done counting 10 objects.
> > > Deltifying 10 objects...
> > > error: pack-objects died with strange error
> > > unpack eof before pack header was fully read
> > > ng refs/heads/master n/a (unpacker error)
> > > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > > tomfool@toms-box:hpl$
> >
> > I got this message when I tried to push a project with submodules to a
> > server which had submodule-ignorant git installed. Maybe it's that?
>
> I'm not sure which versions are submodule-ignorant, but it's version
> 1.5.3.6 on the pusher and version 1.5.4.5 on the server. I installed
> git via the fink package manager. Could there be some other
> incompatibility?
This change came after 1.5.3.6 and I think its what you are
tripping over:
commit 481f0ee60eef2c34b891e5d04b7e6e5a955eedf4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Nov 11 23:35:23 2007 +0000
Fix rev-list when showing objects involving submodules
rev-list aborting because it cannot mark a submodule commit
as uninteresting should cause pack-objects to abort too since
the list of objects wasn't completely produced.
That fix is in 1.5.3.7 or later.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/5] git-gui: Support for "Locators" - address templates
From: Shawn O. Pearce @ 2008-09-26 14:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: pasky, git
In-Reply-To: <alpine.LNX.1.00.0809251705260.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Thu, 25 Sep 2008, pasky@suse.cz wrote:
>
> > This patch allows "locators" to be configured and used in the GUI,
> > basically as URL templates the input string is subsituted into.
>
> Can this be set up to use the "url.<base>.insteadOf" configuration? Part
> of my goal with that feature was to make it easy for me to reference
> projects on my work's central repository store. That is, put in your
> ~/gitconfig:
>
> [url "git://repo.or.cz/"]
> insteadOf = repo:
>
> And "git clone repo:alt-git" works.
That's a good idea.
When I saw the locator patch come by I thought a bit about the
insteadOf idea, but didn't make it far enough to open an email
discussion about it.
Pasky?
--
Shawn.
^ permalink raw reply
* Re: mysterious error message
From: tom sgouros @ 2008-09-26 14:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0809261400400.13830@pacific.mpi-cbg.de.mpi-cbg.de>
> Hi,
>
> On Thu, 25 Sep 2008, Tom Sgouros wrote:
>
> > I receive the following error message when I try to do a 'git push':
> >
> > tomfool@toms-box:hpl$ git push
> > updating 'refs/heads/master'
> > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > Also local refs/remotes/origin/master
> > Generating pack...
> > Done counting 10 objects.
> > Deltifying 10 objects...
> > error: pack-objects died with strange error
> > unpack eof before pack header was fully read
> > ng refs/heads/master n/a (unpacker error)
> > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > tomfool@toms-box:hpl$
>
> I got this message when I tried to push a project with submodules to a
> server which had submodule-ignorant git installed. Maybe it's that?
I'm not sure which versions are submodule-ignorant, but it's version
1.5.3.6 on the pusher and version 1.5.4.5 on the server. I installed
git via the fink package manager. Could there be some other
incompatibility?
Thanks,
-tom
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Shawn O. Pearce @ 2008-09-26 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Gustaf Hendeby, git
In-Reply-To: <48DCAC08.9060004@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
>
> My situation is this: I fire up git-gui, and because I have some stale
> .git/GITGUI_MSG file, the commit message box is not empty. Aspell begins
> its work, and git-gui correctly marks spelling mistakes in the first line.
> Even if I type new text, delete old text, or change the whole text by
> clicking "Amend", no new spelling mistakes are marked for the whole session.
Hmm. Sounds to me like aspell crashes and dies after a while.
When aspell terminates on its own git-gui doesn't try to restart it.
I've never seen it abort on my Mac, or my Linux systems. Or even
on Windows when I was using the Cygwin version of aspell.
--
Shawn.
^ permalink raw reply
* Re: mysterious error message
From: tom sgouros @ 2008-09-26 14:29 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20080926082003.GA6772@strlen.de>
> Hello,
>
> On Thu, Sep 25, 2008 at 05:33:38PM -0400, Tom Sgouros wrote:
> > I receive the following error message when I try to do a 'git push':
> >
> > tomfool@toms-box:hpl$ git push
> > updating 'refs/heads/master'
> > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > Also local refs/remotes/origin/master
> > Generating pack...
> > Done counting 10 objects.
> > Deltifying 10 objects...
> > error: pack-objects died with strange error
> > unpack eof before pack header was fully read
> > ng refs/heads/master n/a (unpacker error)
> > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > tomfool@toms-box:hpl$
> >
> > I haven't been able to interpret this message, and haven't found it in
> > the documentation, and google has let me down, too. Can anyone tell me
> > what is causing it?
> I think it's a problem on the pushing side. Maybe out of disk space (in
> $GIT_DIR or $TMP_DIR)? Does git repack work?
>
I did have a disk space issue on the pushing side, but have cleared it
up. Is there something that needs to be reset, do you think?
Yes, git repack seems to work fine. "Counting 215 objects, Deltifying
215 objects." But I still get the same error message afterwards.
Thanks,
-tom
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Shawn O. Pearce @ 2008-09-26 14:28 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Johannes Sixt, git
In-Reply-To: <48DCA5F3.4090009@isy.liu.se>
Gustaf Hendeby <hendeby@isy.liu.se> wrote:
> >> }
> >> - set s_version [string range $s_version 5 end]
> >> + set s_version [string range [string trim $s_version] 5 end]
> >
> > A strange indentation you have here.
>
> Yep, sorry about that, seems I had a nonstandard tab-width setting. Too
> bad not all projects can decide on the same tab width. :( Will resend
> if there are no other comments to this, and at the same time fix the
> spelling in the commit message...
I fixed the indentation, but didn't notice the spelling error in
the commit message. Anyway, its too late, I have already pushed
this fix out to my maint and master branches in git-gui. I'm not
going to rewind 'em.
--
Shawn.
^ permalink raw reply
* Re: mysterious error message
From: Shawn O. Pearce @ 2008-09-26 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tom Sgouros, git
In-Reply-To: <alpine.DEB.1.00.0809261400400.13830@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 25 Sep 2008, Tom Sgouros wrote:
>
> > I receive the following error message when I try to do a 'git push':
> >
> > tomfool@toms-box:hpl$ git push
> > updating 'refs/heads/master'
> > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > Also local refs/remotes/origin/master
> > Generating pack...
> > Done counting 10 objects.
> > Deltifying 10 objects...
> > error: pack-objects died with strange error
> > unpack eof before pack header was fully read
> > ng refs/heads/master n/a (unpacker error)
> > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > tomfool@toms-box:hpl$
>
> I got this message when I tried to push a project with submodules to a
> server which had submodule-ignorant git installed. Maybe it's that?
Almost.
I think its that there are submodules in the local side and they are
being pushed to the remote peer, but the git binary on the client
that is being used to execute git-push doesn't know about submodules.
"error: pack-objects died with strange error":
This was pack-objects aborting when it saw a subtree entry and it
couldn't trace down that path in order to include it into the pack.
"unpack eof before pack header was fully read":
This is the server side aborting because its gotten the command
set from the git-push client, but pack-objects never even got to
create the pack header, since it couldn't generate the full list
of objects it needed to include.
Tom, try upgrading to a Git implementation on the client. It seems
to me that this repository must have been moved here by means outside
of Git (NFS mount?), or the client got downgraded (wrong $PATH?)
--
Shawn.
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Alex Riesen @ 2008-09-26 13:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <200809260931.21883.jnareb@gmail.com>
2008/9/26 Jakub Narebski <jnareb@gmail.com>:
> On Fri, 26 Sep 2008, Alex Riesen wrote:
>> Jakub Narebski, Fri, Sep 26, 2008 01:15:58 +0200:
>> >
>> > Well, in gitweb we could use '-z' option for git-diff-tree and git-ls-tree,
>> > but it has its disadvantages, like having to do actual parsing record after
>> > record instead of simplys splitting outout on end of line ("\n") characters.
>> >
>>
>> How about simply splitting output on end of line ("\0" NUL) characters?
>> The "\n" NL you refer to is just as EOR as NUL.
>
> Doesn't work for "git diff-tree -z [...]" output. When there is rename
> or copy detected, NUL is used as separator between fields (beetween
> source and destination unquoted filename), not only between records:
>
> git diff-tree
> .... <src qfilename> TAB <dst qfilename> LF
>
> git diff-tree -z
> .... <src filename> NUL <dst filename> NUL
>
You still have the marker (Rnnn) from pre-<src filename> record and
can treat the next record correspondingly. Still a split, just a bit more
careful handling of the resulting list/array.
^ permalink raw reply
* Re: On Sponsor Notices
From: A.J. Rossini @ 2008-09-26 13:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080924225120.GL10544@machine.or.cz>
Petr -
I should have been clear! What I meant to say was that it would be
nice to have things like our Novartis sponsorship in the README of
projects which are particular to the repository structure and client
which we (well, you :-), developed, and make them available, but I'd
not be certain I'd like to have such acknowledgement entered into the
git development proper (I'd prefer to think that the changes would
have been made anyway, we just accelerated them -- however for the
direct project code (non-general), that clearly should have in a
README (not license) sponsored by Novartis, as it's technically
pre-competitive (we'd love to hire people who in addition to quant and
science skills, know how to use it for statistical/mathematical
modeling, and/or improve it).
(BTW, if anyone is interested in the possibility of a similar summer
project in Basel, working for a certain large multinational Pharma
company, doing open source work, possibly around git or other
"information management projects", please let me know -- we can take
on undergrads and grad students who know programming, mathematics, and
statistics, or just one of those disciplines -- it's not too bad, just
ask Petr).
On Thu, Sep 25, 2008 at 12:51 AM, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> to follow up a little on the "This patch has been sponsored by
> Novartis" messages - I have been on a summer internship at Novartis busy
> deploying Git and these patches (still quite a few more to come, mostly
> for gitweb) have been one of the main outputs of that work.
>
> However, I'm not sure if acknowledging the Novartis-originated patches
> in the log message like this is the best practice and we will understand
> if the maintainers will decide to strip these notices when applying the
> patches. Usually, this kind of acknowledgement is made by using
> "sponsored" email addresses, however mine will probably stop working
> shortly after I leave and the only way to read it is, shall we say,
> utmostly inconvenient. ;-) Now, Shawn has proposed 'Sponsored-by:' line
> at the header footer, which is also an interesting possibility.
>
> --
> Petr "Pasky" Baudis
> People who take cold baths never have rheumatism, but they have
> cold baths.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
best,
-tony
blindglobe@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).
Drink Coffee: Do stupid things faster with more energy!
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Mike Ralphson @ 2008-09-26 13:24 UTC (permalink / raw)
To: Shawn O. Pearce, Jeff King; +Cc: git
In-Reply-To: <20080924154632.GR3669@spearce.org>
2008/9/24 Shawn O. Pearce <spearce@spearce.org>:
> My tree is being published here:
>
> git: git://repo.or.cz/git/spearce.git
> repo.or.cz/srv/git/git/spearce.git
> http://repo.or.cz/r/git/spearce.git
>
> gitweb: http://repo.or.cz/w/git/spearce.git
>
> The usual maint/master/next/pu stuff applies. I'm basically just
> picking up from where Junio left off.
>
> I would appreciate it if anyone who normally tracks Junio's "next"
> or "master" branch for their production work can switch over to my
> next (or master) branch for the next few weeks. Something about
> many eyeballs and fewer bugs.
Now there are new commits in this tree, Gitbuild
[http://repo.or.cz/w/git/gitbuild.git] has spearce/master,
spearce/maint and spearce/next branches and I'm currently running my
automated AIX test builds on these branches and pushing the relevant
tags along.
Jeff, if you want to switch your BSD builds to Shawn's tree too, I
made and pushed a tiny change to the gitbuild.sh script to allow for
the spearce/{branch} format becoming spearce_{branch} in the tag
names.
Cheers, Mike
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Brad King @ 2008-09-26 12:15 UTC (permalink / raw)
To: Mikael Magnusson
Cc: Wincent Colaiuta, Linus Torvalds, Paul Mackerras,
Git Mailing List
In-Reply-To: <237967ef0809260121w1c7cc516tceb3be2cbebb85bc@mail.gmail.com>
Mikael Magnusson wrote:
> 2008/9/26 Wincent Colaiuta <win@wincent.com>:
>> It's a shame that tcl/tk regular expressions don't appear to support
>> anchoring matches against word boundaries (ie. "\b").
>
> \y appears to achieve this;
>
> % regexp {abc\y} 'abc'
> 1
> % regexp {abc\y} 'abcd'
> 0
> % regexp {\yabc\y} 'uabc,d'
> 0
> % regexp {\yabc\y} 'u+abc,d'
> 1
>
> I have tcl/tk 8.5 so I cannot promise that isn't a new addition, I didn't
> look it up anywhere, but it's \y in some other implementations too, so I
> tried it.
It goes back at least as far as tcl/tk 8.2:
http://www.tcl.tk/man/tcl8.2.3/TclCmd/re_syntax.htm#M54
-Brad
^ 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