* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-27 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <7vps2e5x4y.fsf@assigned-by-dhcp.cox.net>
On Thu, 26 Jul 2007, Junio C Hamano wrote:
>
> If you mean the offset associated with fd, we actually do.
Ahh, for some reason I thought we didn't (probably because the user likely
doesn't care at all), but right you are..
> The original HP-UX error is confusing, as we ask pread() to
> transfer 428 bytes and it returns 0 (not returning -1 with
> EINTR). Return value of zero is understandable, if the starting
> position is at or after the EOF, but the offset is 123601 and
> 56k objects packed from git.git repository should be longer than
> that, so that also sounds implausible.
Yeah. It is suspicious.
If somebody could run git under gdb on HP-UX (preferably compiled
statically), and just disassemble the pread() thing, it would be
interesting.
PA-RISC assembly is *almost* entirely unreadable, but it might show
whether hpux-11.11 actually has a pread() system call or whether it is
doing the "emulate with lseek" and maybe obviously buggily at that..
It really isn't that complex a system call. So I'm surprised at bugs
there, and that makes me worry that there is something in git that
triggers this.
Linus
^ permalink raw reply
* Re: git-gui problem with version number.
From: Shawn O. Pearce @ 2007-07-27 5:36 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85y7h25sg6.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > David Kastrup <dak@gnu.org> wrote:
> >> Hi, git-gui does not get along with the creativeness in git
> >> versioning:
> >
> > What version of git-gui? gitgui-0.7.5-67-g91464df and later have
> > fixes to handle all of the fun cases in git versioning. Like the
> > one you have here.
> >
> >> git-gui
> >> Error in startup script: expected version number but got "1.5.3.rc2.4.g726f9-dirty"
> >> while executing
> >> "package vcompare $_git_version $vr"
>
> The one coming with the mentioned version number. I suspect that this
> may be a matter of the Perl libraries being used: I experience this on
> an Ubuntu Dapper, but not on other (newer) systems compiled from the
> same source.
Ah. Junio hasn't pulled those version numbering fixes from me yet.
Because I haven't asked him to pull in a while. That explains that.
There's no Perl involved in git-gui, except for the Perl in an
underlying Git command it might invoke. So perhaps you were
talking about Tcl above?
Anyway, you can setup a build with the most recent 'stable
development' version of git-gui:
git checkout -b with-new-gitgui
git pull -s subtree git://repo.or.cz/git-gui.git
That's really all Junio does. Although I think he does actually try
to test it briefly before pushing a final release out to the public.
Just to make sure Git hasn't broken anything really obvious in
git-gui. ;-)
--
Shawn.
^ permalink raw reply
* Re: gitk screenshots of complex history
From: Shawn O. Pearce @ 2007-07-27 5:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707262219210.3442@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 27 Jul 2007, Shawn O. Pearce wrote:
> >
> > I just compared my own history to Linus' linux-2.6 history.
> > The kernel team can't hold a candle to this mess.
>
> Rather on purpose, I might add. I've actually been fairly anal about
> having people maintain clean histories, to the point where I refuse to
> pull from trees that don't do a good enough job.
For 4 of our internal repositories I've taken that policy up now
myself, and nobody is allowed to create releases from them except me.
This has helped. A lot. So does sensible use of `git rebase -i`.
You and Junio have really sold me on the value of having someone
play a very strict gatekeeper role. I get better work product from
my coworkers this way too. They know someone else is looking at
what they are doing and try harder.
But it doesn't help the really old history, nor does it help
the repository these images came from. I don't own/control that
development. I just provide git help as much as I can.
--
Shawn.
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-27 5:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070727044634.GG20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>> Hi, git-gui does not get along with the creativeness in git
>> versioning:
>
> What version of git-gui? gitgui-0.7.5-67-g91464df and later have
> fixes to handle all of the fun cases in git versioning. Like the
> one you have here.
>
>> git-gui
>> Error in startup script: expected version number but got "1.5.3.rc2.4.g726f9-dirty"
>> while executing
>> "package vcompare $_git_version $vr"
The one coming with the mentioned version number. I suspect that this
may be a matter of the Perl libraries being used: I experience this on
an Ubuntu Dapper, but not on other (newer) systems compiled from the
same source.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-27 5:22 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200707270133.25221.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> (
> I don't know which mail is the best to reply to and I probably missed
> something in the thread, so bear with me if I'm repeating anything.
> )
>
> David. Reconsider "tracking" all directories and what that would
> give, compared to explicitly tracking specific ones and the requires
> magic entries.
It would be quite a nuisance for a patch-based workflow, since patches
don't talk about the creation and deletion of directories.
The "track only when entered approach" has the advantage that
directories that were only created to accommodate patches will be
removed again when becoming empty.
Of course, once doing "git-add top-level" will level the difference.
> Say we have a config setting that tells git never to remove empty
> trees.
Why wouldn't I have tree/zap removed when doing git-rm tree?
> Linus patches could be a start for representing trees in the
> index. As an optimization the index could prune trees from the index
> if they contain things as long as the index *effectively* remembers
> all trees.
But it doesn't. If you do git-add tree, optimizing the dir entry away
since tree/zap exists, then subsequently do git-rm tree/zap, of course
there is nothing to do except remove tree/zap, and the tree is gone.
One can't start tracking trees explicitly only when they become empty,
because one can't know whether to track them then.
> Using the patches again we could add empty directories to the index
> and remove them. No directory would be removed automatically, except
> maybe by a merge.
I currently have the problem that
rm -rf *
unzip some-archive
git-add some-archive
git-commit -a -m whatever
git-checkout something else
leaves empty directory skeletons lying around.
> We would probably have only a few empty directories and new
> unexpected ones would only pop up when we remove all blobs from
> one. Git status could tell us about them so we will not forget
> them.
I don't want a source management system to tell me whenever it is
going to annoy me.
> It could even tell us about "new" empty directories, which is
> probably the most important thing you'd want to know.
>
> Forgetting to untrack an empty directory would not be a big deal.
>
> Whether to retain empty trees or not should be a repository policy,
> but an all or nothing setting.
With that approach idea the workflow
"Apply a patch creating something/hello"
"Undo the patch creating something/hello"
will leave something lying around. For somebody managing hundreds of
directories, that would be a nuisance.
I don't say that a "track all parents automatically" approach would
not have its merits: it would likely prevent some mistakes and be
easily understandable to most users. But for managing a patch
workflow, it would appear to get in the way.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: gitk screenshots of complex history
From: Linus Torvalds @ 2007-07-27 5:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070727041300.GD20052@spearce.org>
On Fri, 27 Jul 2007, Shawn O. Pearce wrote:
>
> I just compared my own history to Linus' linux-2.6 history.
> The kernel team can't hold a candle to this mess.
Rather on purpose, I might add. I've actually been fairly anal about
having people maintain clean histories, to the point where I refuse to
pull from trees that don't do a good enough job.
Linus
^ permalink raw reply
* Re: [PATCH] git-gui wording suggestions
From: Junio C Hamano @ 2007-07-27 5:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Stimming, Brett Schwarz, git, Paul Mackerras
In-Reply-To: <20070727044009.GF20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Christian Stimming <stimming@tuhh.de> wrote:
>> Unifiy wording to say "to stage" instead of "to add" always.
> ...
>> With this patch I'd propose to talk every only about "stage" instead
>> of "add". IMHO that's just the logical conclusion of the above wording
>> decision. What do you think?
>
> Yes, I agree. This is a necessary change, the current wording is
> very confusing.
Looking at the expressions used in the application from the
point of view of translating the words to (or expressing the
concept in) another language helps finding more appropriate
wording even in the original language.
"Add" is a simple and nice word, but it is too broad, so "to
stage" is an improvement. The translated message for "to stage"
for Japanese we will probably end up choosing would translate
back to English as "Schedule for commit".
^ permalink raw reply
* Re: bug: update hook failure doesn't prevent local deletion of a branch
From: Junio C Hamano @ 2007-07-27 5:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, Andy Parkins, Git Mailing List
In-Reply-To: <20070727042606.GE20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We should make our repository state reflect the user's internal
> mental view of what just happened, especially here, because the
> user's mental view is probably correct.
Fair enough. At least if we correct git-push so that when it
exits with failure it would not touch the local refs, I would
think that would make what happens to match user's mental model
much better. The user would be _told_ that it failed, and then
can fetch back if he cares where the remote heads are too
deeply.
^ permalink raw reply
* Re: [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Junio C Hamano @ 2007-07-27 4:53 UTC (permalink / raw)
To: Bradford Smith; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <7vfy3a5uzv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> "Bradford Smith" <bradford.carl.smith@gmail.com> writes:
>
>> FWIW, I have successfully run 'make test' and also verified that it
>> behaves as I expect with my ~/.gitconfig symlink (in conjunction with
>> the my other patch for resolving symlinks).
>
> Existing "make test" testsuite is not an appropriate thing to
> say this patch is safe, as we do not have much symlinking in the
> test git repository there. Care to add a new test or two?
How about this? On top of your "lockfile to keep symlink" and
"set-multivar to use lockfile protocol" patches.
---
t/t1300-repo-config.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1c43cc3..187ca2d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -595,4 +595,19 @@ echo >>result
test_expect_success '--null --get-regexp' 'cmp result expect'
+test_expect_success 'symlinked configuration' '
+
+ ln -s notyet myconfig &&
+ GIT_CONFIG=myconfig git config test.frotz nitfol &&
+ test -h myconfig &&
+ test -f notyet &&
+ test "z$(GIT_CONFIG=notyet git config test.frotz)" = znitfol &&
+ GIT_CONFIG=myconfig git config test.xyzzy rezrov &&
+ test -h myconfig &&
+ test -f notyet &&
+ test "z$(GIT_CONFIG=notyet git config test.frotz)" = znitfol &&
+ test "z$(GIT_CONFIG=notyet git config test.xyzzy)" = zrezrov
+
+'
+
test_done
^ permalink raw reply related
* Re: git-gui problem with version number.
From: Shawn O. Pearce @ 2007-07-27 4:46 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86odhzpg2l.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> wrote:
> Hi, git-gui does not get along with the creativeness in git
> versioning:
What version of git-gui? gitgui-0.7.5-67-g91464df and later have
fixes to handle all of the fun cases in git versioning. Like the
one you have here.
> git-gui
> Error in startup script: expected version number but got "1.5.3.rc2.4.g726f9-dirty"
> while executing
> "package vcompare $_git_version $vr"
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui wording suggestions
From: Shawn O. Pearce @ 2007-07-27 4:40 UTC (permalink / raw)
To: Christian Stimming; +Cc: Brett Schwarz, git, Paul Mackerras, Junio C Hamano
In-Reply-To: <20070726111902.xqkxcdlsbo8w4c8k@webmail.tu-harburg.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Unifiy wording to say "to stage" instead of "to add" always.
...
> With this patch I'd propose to talk every only about "stage" instead
> of "add". IMHO that's just the logical conclusion of the above wording
> decision. What do you think?
Yes, I agree. This is a necessary change, the current wording is
very confusing. I would apply this earlier than the other i18n
stuff, but this patch is written based upon the current i18n work.
:-|
> diff --git a/git-gui.sh b/git-gui.sh
> index 3536d38..fd8b4b4 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -1824,12 +1824,12 @@ if {[is_enabled multicommit] || [is_enabled
> singlecommit]} {
> lappend disable_on_lock \
> [list .mbar.commit entryconf [.mbar.commit index last] -state]
>
> - .mbar.commit add command -label [mc "Add To Commit"] \
> + .mbar.commit add command -label [mc "Stage To Commit"] \
> -command do_add_selection
> lappend disable_on_lock \
> [list .mbar.commit entryconf [.mbar.commit index last] -state]
...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Junio C Hamano @ 2007-07-27 4:30 UTC (permalink / raw)
To: Bradford Smith; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <f158199e0707261148r29419a39h7d83fc7bd0ea7df1@mail.gmail.com>
"Bradford Smith" <bradford.carl.smith@gmail.com> writes:
> FWIW, I have successfully run 'make test' and also verified that it
> behaves as I expect with my ~/.gitconfig symlink (in conjunction with
> the my other patch for resolving symlinks).
Existing "make test" testsuite is not an appropriate thing to
say this patch is safe, as we do not have much symlinking in the
test git repository there. Care to add a new test or two?
^ permalink raw reply
* Re: bug: update hook failure doesn't prevent local deletion of a branch
From: Shawn O. Pearce @ 2007-07-27 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Andy Parkins, Git Mailing List
In-Reply-To: <7vk5sm5vrd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > Summary: when using git-push to delete a remote branch, and that deletion is
> > disallowed by the update hook, the local tracking branch _is_ deleted.
>
> Yes, a few months ago with b516968f, "send-pack" started to
> pretend that it turned around and fetched immediately after it
> attempted to push.
>
> There are two problems with it. One is this exact problem Andy
> reported.
...
> I think this is correctable without major changes.
> If the remote end refused to update only one of the refs, and
> send-pack as a whole fails, we could refrain from updating
> anything local.
Reasonable. Probably pretty simple too.
> But another more fundamental issue is that post-update hook on
> the receiving end could do anything it pleases (for example, it
> could try to rebase what was pushed), and at the protocol level
> there is no way to say "you tried to push this SHA-1 but we
> replaced it with this other SHA-1 instead".
You keep raising this argument against the "git-push updates local
refs" feature. Its not just the post-update hook that could alter
the ref. Another user could just push behind you (and I mean right
behind you) and either force an update, delete the ref entirely, or
just fast-forward it. (Its entirely possible that the other user
does have the commit you just pushed, because you had previously
supplied it to them.) So its actually possible for the ref to have
changed again before you even see the successful update message on
your console.
I don't think it really matters. Based on the output you see from
git-push on screen you have good reason to believe that the ref
you just pushed to is now at the commit SHA-1 displayed. For that
reason alone I think it is correct to update the corresponding
tracking branch, because an immediate git-fetch just wastes the
user's time and will (usually) fetch the SHA-1 just pushed.
We should make our repository state reflect the user's internal
mental view of what just happened, especially here, because the
user's mental view is probably correct.
--
Shawn.
^ permalink raw reply
* Re: bug: update hook failure doesn't prevent local deletion of a branch
From: Junio C Hamano @ 2007-07-27 4:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Andy Parkins, Git Mailing List
In-Reply-To: <200707251250.08166.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I wanted to delete a branch (let's call it "deleted-branch") from my public
> repository. I ran this:
>
> $ git push origin :deleted-branch
> deleting 'refs/heads/deleted-branch'
> Also local refs/remotes/up/deleted-branch
> *** Update hook: aborting
> error: hooks/update exited with error code 1
> error: hook declined to update refs/heads/deleted-branch
> ng refs/heads/deleted-branch hook declined
> error: failed to push to '/path/to/git/repo.git'
> ...
> Summary: when using git-push to delete a remote branch, and that deletion is
> disallowed by the update hook, the local tracking branch _is_ deleted.
Yes, a few months ago with b516968f, "send-pack" started to
pretend that it turned around and fetched immediately after it
attempted to push.
There are two problems with it. One is this exact problem Andy
reported. Newer receive-pack reports the status (if an update
of the ref was successful), and the sender _could_ try to detect
a failure and refrain from making the local side update (but if
the receive-pack running on the other end is old enough there is
no indication of an error); the code does not bother to do this
correctly. I think this is correctable without major changes.
If the remote end refused to update only one of the refs, and
send-pack as a whole fails, we could refrain from updating
anything local.
But another more fundamental issue is that post-update hook on
the receiving end could do anything it pleases (for example, it
could try to rebase what was pushed), and at the protocol level
there is no way to say "you tried to push this SHA-1 but we
replaced it with this other SHA-1 instead".
^ permalink raw reply
* gitk screenshots of complex history
From: Shawn O. Pearce @ 2007-07-27 4:13 UTC (permalink / raw)
To: git
I've mentioned both on list and on #git that one of my production
repositories has a few weird points in time. Some folks have asked
to see at least screenshots of the line part of the gitk output,
as apparently they've never seen ugly history in Git. Lucky them.
The images are rather large so I have posted them on my website
with a bit longer explanation of each:
http://www.spearce.org/2007/07/difficult-gitk-graphs.html
I just compared my own history to Linus' linux-2.6 history.
The kernel team can't hold a candle to this mess. Remember,
this is *with* me involved in the project on a daily basis. Me.
Someone who knows Git fairly well...
OK, no more screenshots from *that* repository! I don't ever want
to run `gitk --all` there again. Ever.
PS: The really interesting data (subject lines, authors, dates)
has all been redacted from the images. I can't publish that stuff.
--
Shawn.
^ permalink raw reply
* [PATCH] Make verify-tag a builtin.
From: Carlos Rica @ 2007-07-27 4:07 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
This replaces "git-verify-tag.sh" with "builtin-verify-tag.c".
Testing relies on the "git tag -v" tests calling this command.
A temporary file is needed when calling to gpg, because git is
already creating detached signatures (gpg option -b) to sign tags
(instead of leaving gpg to add the signature to the file by itself),
and those signatures need to be supplied in a separate file to be
verified by gpg.
The program uses git_mkstemp to create that temporary file needed by
gpg, instead of the previously used "$GIT_DIR/.tmp-vtag", in order to
allow the command to be used in read-only repositories, and also
prevent other instances of git to read or remove the same file.
Signal SIGPIPE is ignored because the program sometimes was
terminated because that signal when writing the input for gpg.
The command now can receive many tag names to be verified.
Documentation is also updated here to reflect this new behaviour.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
This resend is addressing the questions commented in:
http://thread.gmane.org/gmane.comp.version-control.git/53376
Function verify_tag is designed to be easily reused in the
upcoming "builtin-tag.c", although it is declared static now.
Documentation/git-verify-tag.txt | 4 +-
Makefile | 3 +-
builtin-verify-tag.c | 111 ++++++++++++++++++++
builtin.h | 1 +
.../examples/git-verify-tag.sh | 0
git.c | 1 +
6 files changed, 117 insertions(+), 3 deletions(-)
create mode 100644 builtin-verify-tag.c
rename git-verify-tag.sh => contrib/examples/git-verify-tag.sh (100%)
diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt
index 48d17fd..ac7fb19 100644
--- a/Documentation/git-verify-tag.txt
+++ b/Documentation/git-verify-tag.txt
@@ -3,11 +3,11 @@ git-verify-tag(1)
NAME
----
-git-verify-tag - Check the GPG signature of tag
+git-verify-tag - Check the GPG signature of tags
SYNOPSIS
--------
-'git-verify-tag' <tag>
+'git-verify-tag' <tag>...
DESCRIPTION
-----------
diff --git a/Makefile b/Makefile
index 73b487f..c6ed79f 100644
--- a/Makefile
+++ b/Makefile
@@ -206,7 +206,7 @@ SCRIPT_SH = \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
git-sh-setup.sh \
- git-tag.sh git-verify-tag.sh \
+ git-tag.sh \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
@@ -367,6 +367,7 @@ BUILTIN_OBJS = \
builtin-update-ref.o \
builtin-upload-archive.o \
builtin-verify-pack.o \
+ builtin-verify-tag.o \
builtin-write-tree.o \
builtin-show-ref.o \
builtin-pack-refs.o
diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
new file mode 100644
index 0000000..11b971e
--- /dev/null
+++ b/builtin-verify-tag.c
@@ -0,0 +1,111 @@
+/*
+ * Builtin "git verify-tag"
+ *
+ * Copyright (c) 2007 Carlos Rica <jasampler@gmail.com>
+ *
+ * Based on git-verify-tag.sh
+ */
+#include "cache.h"
+#include "builtin.h"
+#include "tag.h"
+#include "run-command.h"
+#include <signal.h>
+
+static const char builtin_verify_tag_usage[] =
+ "git-verify-tag [-v|--verbose] <tag>...";
+
+#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
+
+static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
+{
+ struct child_process gpg;
+ const char *args_gpg[] = {"gpg", "--verify", "FILE", "-", NULL};
+ char path[PATH_MAX], *eol;
+ size_t len;
+ int fd, ret;
+
+ fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
+ if (fd < 0)
+ return error("could not create temporary file '%s': %s",
+ path, strerror(errno));
+ if (write_in_full(fd, buf, size) < 0)
+ return error("failed writing temporary file '%s': %s",
+ path, strerror(errno));
+ close(fd);
+
+ /* find the length without signature */
+ len = 0;
+ while (len < size && prefixcmp(buf + len, PGP_SIGNATURE "\n")) {
+ eol = memchr(buf + len, '\n', size - len);
+ len += eol ? eol - (buf + len) + 1 : size - len;
+ }
+ if (verbose)
+ write_in_full(1, buf, len);
+
+ memset(&gpg, 0, sizeof(gpg));
+ gpg.argv = args_gpg;
+ gpg.in = -1;
+ gpg.out = 1;
+ args_gpg[2] = path;
+ if (start_command(&gpg))
+ return error("could not run gpg.");
+
+ write_in_full(gpg.in, buf, len);
+ close(gpg.in);
+ gpg.close_in = 0;
+ ret = finish_command(&gpg);
+
+ unlink(path);
+ free(path);
+
+ return ret;
+}
+
+static int verify_tag(const char *name, int verbose)
+{
+ enum object_type type;
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ int ret;
+
+ if (get_sha1(name, sha1))
+ return error("tag '%s' not found.", name);
+
+ type = sha1_object_info(sha1, NULL);
+ if (type != OBJ_TAG)
+ return error("%s: cannot verify a non-tag object of type %s.",
+ name, typename(type));
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return error("%s: unable to read file.", name);
+
+ ret = run_gpg_verify(buf, size, verbose);
+
+ free(buf);
+ return ret;
+}
+
+int cmd_verify_tag(int argc, const char **argv, const char *prefix)
+{
+ int i = 1, verbose = 0, had_error = 0;
+
+ git_config(git_default_config);
+
+ if (argc == 1)
+ usage(builtin_verify_tag_usage);
+
+ if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
+ verbose = 1;
+ i++;
+ }
+
+ /* sometimes the program was terminated because this signal
+ * was received in the process of writing the gpg input: */
+ signal(SIGPIPE, SIG_IGN);
+ while (i < argc)
+ if (verify_tag(argv[i++], verbose))
+ had_error = 1;
+ return had_error;
+}
diff --git a/builtin.h b/builtin.h
index 4cc228d..cb860a0 100644
--- a/builtin.h
+++ b/builtin.h
@@ -76,6 +76,7 @@ extern int cmd_update_index(int argc, const char **argv, const char *prefix);
extern int cmd_update_ref(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);
+extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
extern int cmd_version(int argc, const char **argv, const char *prefix);
extern int cmd_whatchanged(int argc, const char **argv, const char *prefix);
extern int cmd_write_tree(int argc, const char **argv, const char *prefix);
diff --git a/git-verify-tag.sh b/contrib/examples/git-verify-tag.sh
similarity index 100%
rename from git-verify-tag.sh
rename to contrib/examples/git-verify-tag.sh
diff --git a/git.c b/git.c
index a647f9c..1dfe120 100644
--- a/git.c
+++ b/git.c
@@ -368,6 +368,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
+ { "verify-tag", cmd_verify_tag, RUN_SETUP },
{ "version", cmd_version },
{ "whatchanged", cmd_whatchanged, RUN_SETUP | USE_PAGER },
{ "write-tree", cmd_write_tree, RUN_SETUP },
--
1.5.0
^ permalink raw reply related
* Re: index-pack died on pread
From: Junio C Hamano @ 2007-07-27 3:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707260911040.3442@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I'm not saying that's great programming, but the "git_pread()" that git
> will use in the absense of a real pread() is actually even *less* of a
> POSIX pread, since it doesn't even try to save/restore the old position
> (it knows that git doesn't care).
If you mean the offset associated with fd, we actually do.
The original HP-UX error is confusing, as we ask pread() to
transfer 428 bytes and it returns 0 (not returning -1 with
EINTR). Return value of zero is understandable, if the starting
position is at or after the EOF, but the offset is 123601 and
56k objects packed from git.git repository should be longer than
that, so that also sounds implausible.
^ permalink raw reply
* Re: incremental fast-import
From: Shawn O. Pearce @ 2007-07-27 0:51 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707262242460.14017@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> I seem to be missing something though. I can't seem to get it to work
> when run in an incremental manner.
>
> I have a saved stream of fast-import commands. Every time I run this
> through fast import I get the exact same marks file out. This is good.
>
> However if I feed it in in two chunks, then nearly all of the SHA1s
> generated in the second run are different to those produced in a single
> pass. In addition I get a pair of "warning: Not updating
> refs/heads/BUG_101_BRANCH (new tip <some sha1> does not contain <other
> sha1>)" messages. This is not so good.
>
> I'm using the --import-marks and --export-marks options. Is there
> something else I need to do to be able to run fast-import in an
> incremental manner?
I'm guessing you didn't restart the branches at the start of the
second import. You need to do something like this to get the import
going again:
commit refs/heads/BUG_101_BRANCH
from refs/heads/BUG_101_BRANCH^0
...
or because you imported the marks you can use a mark:
commit refs/heads/BUG_101_BRANCH
from :18981
...
where 18981 was the last revision on BUG_101_BRANCH that the frontend
had imported during the last run.
fast-import doesn't assume the local branches already exist.
It actually assumes its importing from scratch every time. The
frontend tool needs to restart the branch if that is what it wants.
In other words, by splitting the file in half you actually also
split the history in half, and got two root commits, one of which
was in the middle of your history. :-(
--
Shawn.
^ permalink raw reply
* Re: Empty directories...
From: Robin Rosenberg @ 2007-07-26 23:33 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85lkdezi08.fsf@lola.goethe.zz>
(
I don't know which mail is the best to reply to and I probably missed
something in the thread, so bear with me if I'm repeating anything.
)
David. Reconsider "tracking" all directories and what that would give,
compared to explicitly tracking specific ones and the requires magic entries.
Say we have a config setting that tells git never to remove empty trees. Linus
patches could be a start for representing trees in the index. As an
optimization the index could prune trees from the index if they contain
things as long as the index *effectively* remembers all trees.
Using the patches again we could add empty directories to the index and remove
them. No directory would be removed automatically, except maybe by a merge.
We would probably have only a few empty directories and new unexpected ones
would only pop up when we remove all blobs from one. Git status could tell us
about them so we will not forget them. It could even tell us about "new" empty
directories, which is probably the most important thing you'd want to know.
Forgetting to untrack an empty directory would not be a big deal.
Whether to retain empty trees or not should be a repository policy, but an all
or nothing setting.
-- robin
^ permalink raw reply
* git-gui: i18n introductory document (2nd draft)
From: Junio C Hamano @ 2007-07-26 23:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Christian Stimming, Irina Riesen,
Paolo Ciarrocchi, Xudong Guan, Nanako Shiraishi, git
In-Reply-To: <7vir87adzo.fsf@assigned-by-dhcp.cox.net>
This short note is to help a translation contributor to help us
localizing git-gui message files by covering the basics.
I have tried to address issues raised in Christian's comments on
the first draft that was circulated privately. There are a few
remaining issues I could not decide myself, which are marked
with NEEDSWORK in the text.
---
diff --git a/po/README b/po/README
new file mode 100644
index 0000000..974cce4
--- /dev/null
+++ b/po/README
@@ -0,0 +1,203 @@
+Localizing git-gui for your language
+====================================
+
+This short note is to help you, who reads and writes English and your
+own language, help us getting git-gui localized for more languages. It
+does not try to be a comprehensive manual of GNU gettext, which is the
+i18n framework we use, but tries to help you get started by covering the
+basics and how it is used in this project.
+
+1. Getting started.
+
+You would first need to have a working "git". Your distribution may
+have it as "git-core" package (do not get "GNU Interactive Tools" --
+that is a different "git"). You would also need GNU gettext toolchain
+to test the resulting translation out. It also is a good idea to have
+specialized so-called "po file editors" (e.g. emacs po-mode, KBabel,
+poedit, GTranslator). Please install them.
+
+You would then need to clone the git-gui internationalization project
+repository, so that you can work on it:
+
+ $ git clone mob@repo.or.cz:/srv/git/git-gui/git-gui-i18n.git/
+ $ cd git-gui-i18n.git
+ $ git checkout --track -b mob origin/mob
+ $ git config remote.origin.push mob
+
+The "git checkout" command creates a 'mob' branch from upstream's
+corresponding branch and makes it your current branch. You will be
+working on this branch.
+
+The "git config" command records in your repository configuration file
+that you would push "mob" branch to the upstream when you say "git
+push".
+
+
+2. Starting a new language.
+
+In the git-gui-i18n.git directory is a po/ subdirectory. It has a
+handful files whose names end with ".po". Is there a file that has
+messages in your language?
+
+If you do not know what your language should be named, you need to find
+it. This currently follows ISO 639-1 two letter codes:
+
+ http://www.loc.gov/standards/iso639-2/php/code_list.php
+
+For example, if you are preparing a translation for Afrikaans, the
+language code is "af". If there already is a translation for your
+language, you do not have to perform any step in this section, but keep
+reading, because we are covering the basics.
+
+If you did not find your language, you would need to start one yourself.
+Copy po/git-gui.pot file to po/af.po (replace "af" with the code for
+your language). Edit the first several lines to match existing *.po
+files to make it clear this is a translation table for git-gui project,
+and you are the primary translator. The result of your editing would
+look something like this:
+
+ # Translation of git-gui to Afrikaans
+ # Copyright (C) 2007 Shawn Pearce
+ # This file is distributed under the same license as the git-gui package.
+ # YOUR NAME <YOUR@E-MAIL.ADDRESS>, 2007.
+ #
+ #, fuzzy
+ msgid ""
+ msgstr ""
+ "Project-Id-Version: git-gui\n"
+ "Report-Msgid-Bugs-To: \n"
+ "POT-Creation-Date: 2007-07-24 22:19+0300\n"
+ "PO-Revision-Date: 2007-07-25 18:00+0900\n"
+ "Last-Translator: YOUR NAME <YOUR@E-MAIL.ADDRESS>\n"
+ "Language-Team: Afrikaans\n"
+ "MIME-Version: 1.0\n"
+ "Content-Type: text/plain; charset=UTF-8\n"
+ "Content-Transfer-Encoding: 8bit\n"
+
+You will find many pairs of a "msgid" line followed by a "msgstr" line.
+These pairs define how messages in git-gui application are translated to
+your language. Your primarily job is to fill in the empty double quote
+pairs on msgstr lines with the translation of the strings on their
+matching msgid lines. A few tips:
+
+ - Control characters, such as newlines, are written in backslash
+ sequence similar to string literals in the C programming language.
+ When the string given on a msgid line has such a backslash sequence,
+ you would typically want to have corresponding ones in the string on
+ your msgstr line.
+
+ - Often the messages being translated are format strings given to
+ "printf()"-like functions. Make sure "%s", "%d", and "%%" in your
+ translated messages match the original.
+
+ When you have to change the order of words, you can add "<number>$"
+ between '%' and the conversion ('s', 'd', etc.) to say "<number>-th
+ parameter to the format string is used at this point". For example,
+ if the original message is like this:
+
+ "Length is %d, Weight is %d"
+
+ and if for whatever reason your translation needs to say weight first
+ and then length, you can say something like:
+
+ "WEIGHT IS %2$d, LENGTH IS %1$d"
+
+ [NEEDSWORK: this whole "parameter permutation" part needs to be
+ verified if it works with Tcl at all]
+
+ - A long message can be split across multiple lines by ending the
+ string with a double quote, and starting another string on the next
+ line with another double quote. They will be concatenated in the
+ result. For example:
+
+ #: lib/remote_branch_delete.tcl:189
+ #, tcl-format
+ msgid ""
+ "One or more of the merge tests failed because you have not fetched the "
+ "necessary commits. Try fetching from %s first."
+ msgstr ""
+ "HERE YOU WILL WRITE YOUR TRANSLATION OF THE ABOVE LONG "
+ "MESSAGE IN YOUR LANGUAGE."
+
+You can test your translation by running "make install", which would
+create po/af.msg file and installs the result, and then running the
+resulting git-gui under your locale:
+
+ $ make install
+ $ LANG=af git-gui
+
+There is a trick to test your translation without first installing, if
+you prefer. First, create this symbolic link in the source tree:
+
+ $ ln -s ../po lib/msgs
+
+After setting up such a symbolic link, you can:
+
+ $ make
+ $ LANG=af ./git-gui
+
+[NEEDSWORK: this symlink trick needs to be verified if it works.]
+
+When you are satisfied with your translation, commit your changes, and
+push it back to the 'mob' branch:
+
+ $ edit po/af.po
+ ... be sure to update Last-Translator: and
+ ... PO-Revision-Date: lines.
+ $ git add po/af.po
+ $ git commit -m 'Started Afrikaans translation.'
+ $ git push
+
+
+3. Updating your translation.
+
+There may already be a translation for your language, and you may want
+to contribute an update. This may be because you would want to improve
+the translation of existing messages, or because the git-gui software
+itself was updated and there are new messages that need translation.
+
+In any case, make sure you are up-to-date before starting your work:
+
+ $ git pull
+
+In the former case, you will edit po/af.po (again, replace "af" with
+your language code), and after testing and updating the Last-Translator:
+and PO-Revision-Date: lines, "add/commit/push" as in the previous
+section.
+
+By comparing "POT-Creation-Date:" line in po/git-gui.pot file and
+po/af.po file, you can tell if there are new messages that need to be
+translated. You would need the GNU gettext package to perform this
+step.
+
+ $ msgmerge -U po/af.po po/git-gui.pot
+
+[NEEDSWORK: who is responsible for updating po/git-gui.pot file by
+running xgettext? IIRC, Christian recommended against running it
+nilly-willy because it can become a source of unnecessary merge
+conflicts. Perhaps we should mention something like "
+
+The po/git-gui.pot file is updated by the internationalization
+coordinator from time to time. You _could_ update it yourself, but
+translators are discouraged from doing so because we would want all
+language teams to be working off of the same version of git-gui.pot.
+
+" here?]
+
+This updates po/af.po (again, replace "af" with your language
+code) so that it contains msgid lines (i.e. the original) that
+your translation did not have before. There are a few things to
+watch out for:
+
+ - The original text in English of an older message you already
+ translated might have been changed. You will notice a comment line
+ that begins with "#, fuzzy" in front of such a message. msgmerge
+ tool made its best effort to match your old translation with the
+ message from the updated software, but you may find cases that it
+ matched your old translated message to a new msgid and the pairing
+ does not make any sense -- you would need to fix them, and then
+ remove the "#, fuzzy" line from the message.
+
+ - New messages added to the software will have msgstr lines
+ with empty strings. You would need to translate them.
+
^ permalink raw reply related
* Re: [PATCH 3/5] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-26 22:31 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Johannes Schindelin, git
In-Reply-To: <20070726220949.GA4420@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I try to take a closer look at your changes tomorrow evening. Here
> are just two short things I saw while taking a short look at the
> patch.
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> +const char *get_git_work_tree(void)
>> +{
>> + static int initialized = 0;
>> + if (!initialized) {
>> + work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
>> + if (!work_tree) {
>> + work_tree = git_work_tree_cfg;
>> + if (work_tree && !is_absolute_path(work_tree))
>> + work_tree = git_path(work_tree);
>
> A tab is missing here.
I think xstrdup() is missing here, too.
^ permalink raw reply
* Re: [PATCH] gitk: let you easily specify lines of context in diff view
From: Paul Mackerras @ 2007-07-26 12:34 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11854367692095-git-send-email-prohaska@zib.de>
Steffen Prohaska writes:
> More lines of context sometimes help to better understand a diff.
> This patch introduces a text field above the box displaying the
> blobdiffs. You can type in the number of lines of context that
> you wish to view.
Nice idea! I suggest you use a spinbox instead of an entry though,
since that has up and down buttons, and allows you to restrict the
value to an integer.
> * I don't know how to update the view after entering a new value.
You can put a trace on the associated variable and specify a function
to be called when the variable's value changes. Grep for "trace add
variable" in gitk to see how it's done.
Paul.
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Matthias Lederhofer @ 2007-07-26 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707260729150.14781@racer.site>
I try to take a closer look at your changes tomorrow evening. Here
are just two short things I saw while taking a short look at the
patch.
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> +const char *get_git_work_tree(void)
> +{
> + static int initialized = 0;
> + if (!initialized) {
> + work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
> + if (!work_tree) {
> + work_tree = git_work_tree_cfg;
> + if (work_tree && !is_absolute_path(work_tree))
> + work_tree = git_path(work_tree);
A tab is missing here.
> - fprintf(stderr, "No directory given for --work-tree.\n" );
> + error("No directory given for --work-tree.\n");
There should probably be no '\n' at the end when the 'error' function
is used. There are two other calls to fprintf(stderr, <error message>)
next to the one you changed, why did you change this one but not the
other ones?
^ permalink raw reply
* incremental fast-import
From: Julian Phillips @ 2007-07-26 21:47 UTC (permalink / raw)
To: Shawn O. Pearce, git
Sorry to be going on about fast-import again ...
I seem to be missing something though. I can't seem to get it to work
when run in an incremental manner.
I have a saved stream of fast-import commands. Every time I run this
through fast import I get the exact same marks file out. This is good.
However if I feed it in in two chunks, then nearly all of the SHA1s
generated in the second run are different to those produced in a single
pass. In addition I get a pair of "warning: Not updating
refs/heads/BUG_101_BRANCH (new tip <some sha1> does not contain <other
sha1>)" messages. This is not so good.
I'm using the --import-marks and --export-marks options. Is there
something else I need to do to be able to run fast-import in an
incremental manner?
--
Julian
---
A fool must now and then be right by chance.
^ permalink raw reply
* Re: Windows support
From: Jakub Narebski @ 2007-07-26 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <f329bf540707260018u21ad8e16h75cc9c3351fe0fc2@mail.gmail.com>
Han-Wen Nienhuys wrote:
> 2007/7/26, Shawn O. Pearce <spearce@spearce.org>:
>> Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>>> I would suggest to making a clear
>>> decision of what are recommended languages, and move everything else
>>> to contrib/ .. Currently, C and bash seem the most reasonable choice,
>>> but you could decide for perl, but then the consequence should be that
>>> the bash scripts are translated into perl. Having both bash and perl
>>> serves no purpose, and will lead to duplication of library code to
>>> interact with the git binary.
>>
>> Sure, but there's some stuff that shell is good at, and other stuff
>> that Perl is good at. Forcing everything into one mold while we
>> prototype new features is really limiting.
>
> I'm not contradicting that, but merely suggesting that they go into
> contrib/ and are not recommended as standard git commands, and don't
> need to be packaged for windows.
They can be not packaged for windows, but for example git-send-email
(which is written in Perl) is IMHO important enough to be in git proper
and not delegated to contrib/; but it is packaged in separate RPM,
git-email. Same with git-svn package...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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