* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 19:43 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103193826.GB19483@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> a little more readable, or even:
>
> stop_progress_msg(&progress, p->next ? NULL : "done\n");
Yeah, this one looks neat.
> But I almost wonder if it is worth factoring out the concept of a
> "progress group", where you would call it like:
>
> progress = progress_group_start("Checking objects in pack", nr_packs);
> for (p = packed_git; p; p = p->next) {
> progress_group_next(progress, p->num_objects);
> for (j = 0; j < num; j++) {
> fsck_sha1(p, j);
> display_progress(progress, j+1);
> }
> }
> stop_progress(&progress);
Hmm, once you do this kind of thing I would expect two (or more) progress
bars to be shown, something like:
$ git fsck --progress
checking packs: 3 of 7 (42% done)
checking objects in pack: 12405 of 332340 (4% done)
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 19:38 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1320310234-11243-1-git-send-email-pclouds@gmail.com>
On Thu, Nov 03, 2011 at 03:50:34PM +0700, Nguyen Thai Ngoc Duy wrote:
> 2011/11/3 Jeff King <peff@peff.net>:
> > We're actually leaking some memory here, since stop_progress will also
> > free() the progress object and any associated resources. It's not a lot,
> > but it's kind of ugly.
>
> Fixed by always calling stop_progress_msg() but make sure no newline
> is printed (actually "done\n" is not)
Thanks, that sounds reasonable, and the output looks good.
> > Or perhaps we could even come up with a total object count
> > before starting. I guess it would involve mapping each pack index
> > simultaneously, though by my reading of the code, I think we do that
> > anyway (the opened index is cached in the pack object).
>
> I think this way is better because we can count two numbers at a
> time, nr. packs and nr. objects of current pack. Total object
> (I assume you mean of all packs) may be less informative.
Yeah, I meant all of the packs. It's a little more accurate as a
progress meter, because you don't otherwise know what's in each of the
packs. For example, if I see that we are halfway through "pack 1/2",
does that mean we are a quarter of the way done? Not really. Pack 2/2
may be much smaller or much bigger. Finishing pack 1 may make us 99%
done, or it may make us 10% done.
Showing all of the objects in a flat list gives a more accurate
representation (though it's still not entirely accurate; even one
gigantic blob may dwarf the earlier objects. But it's the best we can
do).
In practice, though, I think people tend to have one really big pack and
some small ones. And the packs are sorted in recency order, so we'll
quickly go through the early little ones, and then spend all of our time
on the big old one. Unless they have .keep files.
So I don't really care that much. But it would also make the newline
stuff go away.
> + for (i = 1, p = packed_git; p; p = p->next, i++) {
> + if (show_progress) {
> + char buf[32];
> + snprintf(buf, sizeof(buf), "Verifying pack %d/%d",
> + i, nr_packs);
> + if (open_pack_index(p))
> + continue;
> + progress = start_progress(buf, p->num_objects);
> + }
> /* verify gives error messages itself */
> + verify_pack(p, progress);
>
> + if (p->next)
> + stop_progress_msg(&progress, NULL);
> + }
> + stop_progress(&progress);
You start the progress in the loop, but stop the final one outside the
loop. Which means that if there are no packs, we'll call stop_progress
even though we didn't start one. I think the progress code will handle
the NULL fine, but it took me a minute to convince myself it's right.
I would find this:
if (p->next)
stop_progress_msg(&progress, NULL);
else
stop_progress(&progress);
a little more readable, or even:
stop_progress_msg(&progress, p->next ? NULL : "done\n");
But I almost wonder if it is worth factoring out the concept of a
"progress group", where you would call it like:
progress = progress_group_start("Checking objects in pack", nr_packs);
for (p = packed_git; p; p = p->next) {
progress_group_next(progress, p->num_objects);
for (j = 0; j < num; j++) {
fsck_sha1(p, j);
display_progress(progress, j+1);
}
}
stop_progress(&progress);
and progress_set_next would take care of formatting the %d/%d counter,
and would not output a newline before writing the new description line.
> + snprintf(buf, sizeof(buf), "Checking objects on pack %d/%d",
> + i, nr_packs);
s/on/in/
-Peff
^ permalink raw reply
* Re: Folder level Acces in git
From: Eugene Sajine @ 2011-11-03 19:28 UTC (permalink / raw)
To: redhat1981; +Cc: git
In-Reply-To: <1320300655224-6958047.post@n2.nabble.com>
On Thu, Nov 3, 2011 at 2:10 AM, redhat1981 <redhat1981@gmail.com> wrote:
> Hi,
>
> I am using Gitosis, Adding the gitosis conf file
>
> [group testabc]
> writable = testabc
> members = shrii Abhijeet premkumar
> add cgit = yes
> gitweb = yes
>
>
> [group testabc-readonly]
> readonly = testabc
> members = Ganesh Shweta
> add cgit = yes
> gitweb = yes
>
> Inside the repository, testabc let us say there are folders folder1, folder
> 2 etc, I want some users to have read/write, read or no access to the
> folder1 or folder2, Is this possible in Git, I have done it in SVN, Please
> help!!
>
> redhat1981@gmail.com
>
Are you sure that the way your have organized the repository is
actually correct? If you need to manage the access on folder level why
don't you simply split up the project into several
repositories/projects which each team is going to work with
independently?
This seems to me to be much simpler and cleaner solution then any
other alternative.
Thanks,
Eugene
^ permalink raw reply
* Re: error from 'git push' on v1.7.8-rc0
From: Junio C Hamano @ 2011-11-03 19:15 UTC (permalink / raw)
To: Stefan Näwe; +Cc: gitlist
In-Reply-To: <7vmxcdf2x7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Stefan Näwe <stefan.naewe@gmail.com> writes:
>
>> I get errors from git push when trying to delete a (remote) branch:
>>
>> $ ./bin-wrappers/git versiongit version 1.7.8.rc0
>> $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
>> 0000000000000000000000000000000000000000fatal: bad object
>> 0000000000000000000000000000000000000000remote: warning: Allowing
>> deletion of corrupt ref.
>
> Thanks. I think the operation does _not_ error out and fail to delete, but
> I agree that the "fatal:" message should be squelched.
-- >8 --
Subject: receive-pack: do not expect object 0{40} to exist
When pushing to delete a ref, it uses 0{40} as an object name to signal
that the request is a deletion. We shouldn't trigger "deletion of a
corrupt ref" warning in such a case, which was designed to notice that a
ref points at an object that is truly missing from the repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/receive-pack.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 261b610..7ec68a1 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -634,7 +634,7 @@ static int command_singleton_iterator(void *cb_data, unsigned char sha1[20])
struct command **cmd_list = cb_data;
struct command *cmd = *cmd_list;
- if (!cmd)
+ if (!cmd || is_null_sha1(cmd->new_sha1))
return -1; /* end of list */
*cmd_list = NULL; /* this returns only one */
hashcpy(sha1, cmd->new_sha1);
@@ -659,11 +659,16 @@ static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20])
struct command **cmd_list = cb_data;
struct command *cmd = *cmd_list;
- if (!cmd)
- return -1; /* end of list */
- *cmd_list = cmd->next;
- hashcpy(sha1, cmd->new_sha1);
- return 0;
+ while (cmd) {
+ if (!is_null_sha1(cmd->new_sha1)) {
+ hashcpy(sha1, cmd->new_sha1);
+ *cmd_list = cmd->next;
+ return 0;
+ }
+ cmd = cmd->next;
+ }
+ *cmd_list = NULL;
+ return -1; /* end of list */
}
static void execute_commands(struct command *commands, const char *unpacker_error)
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-03 19:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7vvcr1f38j.fsf@alter.siamese.dyndns.org>
On Thu, Nov 3, 2011 at 11:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Ahh, sorry for the noise. I realize that we already have a winner, namely,
> the proposal outlined in your message I was responding to.
No, no, don't consider my "put in the merge message" a winner at all.
I personally dislike it, and don't really think it's a wonderful thing
at all. I really does have real downsides:
- internal signatures really *are* a disaster for maintenance. You
can never fix them if they need fixing (and "need fixing" may well be
"you want to re-sign things after a repository format change")
- they are ugly as heck, and you really don't want to see them in
99.999% of all cases.
So putting those things iin the merge commit message may have some
upsides, but it has tons of downsides too.
I think your refs/audit/ idea should be given real thought, because
maybe that's the right idea.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-03 19:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7v62j1gitn.fsf@alter.siamese.dyndns.org>
On Thu, Nov 3, 2011 at 11:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It is not "Whatever".
>
> $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0
> fatal: Couldn't find remote ref v3.0
>
> I do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it
> is not the naming but fetching tags without saying "git fetch tag v3.0"
> (which IIRC was your invention long time ago).
Ahh. Yeah, and not DWIM'ing tags is probably ok. I'd completely
forgotten about the special "tag" shortcut.
Which probably means it was a bad ui decision to begin with. But once
more, the UI is clearly designed for fetching the tags into your own
tag-space (ie it does "refs/tags/<tag>:refs/tags/<tag>") rather than
fetching the tag just for verification.
> If we changed this "git fetch $there v3.0" to fetch tag, it would help the
> final step in your illustration, and I do not think it would be a huge
> regression---the only case it becomes fuzzy is when they have v3.0 branch
> at the same time, but the owner of such a repository is already playing
> with fire.
Yeah, extending DWIM for remote repos to do the same thing it does for
local repositories is probably the right thing regardless of any other
issues.
We already have the "tag and branch with the same name" issue for
local repositories, and we have perfectly good disambiguation rules
for when disambiguation is necessary. Making the DWIM rules be the
same for a remote case sounds sane.
That said, I don't think it's a big deal either. I was just confused
by the expansion being different, but having to have the refs/tags/
there isn't a dealbreaker by any means.
>> Quite frankly, I think that's a git bug, but it's a git bug because
>> "git fetch" was designed to get the commit to merge. Fair enough.
>
> And because FETCH_HEAD started as (and probably still is) an internal
> implementation detail of communication between fetch and merge inside
> pull.
Well, I certainly don't consider it to be just "an implementation
detail" personally. I use FETCH_HEAD all the time (the same way I use
ORIG_HEAD and just plain HEAD). It's very useful for "fetch and check
what they have", when you want to look at something but you don't want
all the remote tags and crud. So I consider it a honest-to-goodness
real user feature.
>So I do not have any issue in changing it to store tags unpeeled there.
In fact, storing the peeled was really surprising to me, especially
since it actually *says* "tag" in the .git/FETCH_HEAD file. So the
.git/FETCH_HEAD file really currently ends up being actively wrogn and
misleading for tags we fetch: it looks something like
<sha-of-commit> tag '<tagname>' of <reponame>
and says it is a tag, but the SHA1 is of the peeled commit. That's
just crazy, and actually made me think the other end (Rusty, in this
case) had done something wrong initially (ie I quite reasonably - I
thought - blamed it on Rusty using a non-signed tag).
>> WTF?
>
> This is not WTF but "fetching a history to store the tip of it in your
> refs/ namespace causes tags pointing into the history line followed
> automatically", and it exactly is what you want to happen if rusty asked
> you to fetch his for-linus branch (which the tag may point at) instead.
Well, yes and no. But mostly no.
If I just fetch his for-linus branch, I don't get (and I don't want)
his tags. It's only because I fetched it into my ref-space.
And I only fetched it into my ref-space, because otherwise the crazy
git peeling happened if I don't do that.
So I didn't want those other tags, and I really normally wouldn't have
gotten them. Only because I had to do that odd work-around to avoid
the peeling did I get it, because then the totally unrelated logic of
"ok, get the tags too" triggered.
So it's a WTF, because this work-around ends up having the special
side effects - and they make sense when you *really* fetch his branch
and make it part of your name-space, but not when you only did the
"part of my namespace" as a workaround for another git issue.
Obviously, you can use "-n" (--no-tags) to fetch the tag, and that
actually fixes the issue, but that is it's own kind of WTF too: in
order to fetch just *one* tag, you have to specify that you don't want
tags? Not exactly a greatly intuitive use case ;)
Anyway, the one-line rpatch I sent basically avoids all these WTF
moments, by just making "git fetch <repo> <tagname>" work (apart from
the DWIMmery on the tag-name, but that's a totally independent small
detail that doesn't really matter)
>> We got three other
>> tags too that we didn't even ask for!
>
> We could change the rule to read "fetching a history to store the tip of it
> in your refs/heads namespace causes autofollow". I am not sure if that is
> what we really want, though.
No, I think the current "follow tags" rule is fine. It's just that it
didn't really mesh well with "damn, I have to work around this other
git issue".
> We could update three things:
>
> - DWIM $name in "git fetch $there $name" to refs/tags/$name when it makes
> sense;
> - FETCH_HEAD stores unpeeled object names; and
> - "git pull" learns --verify option.
Yes. I think that would indeed solve everything.
> Then
>
> $ git pull --verify rusty rusty@rustcorp.com.au-v3.1-8068-g5087a50
>
> could integrate the history leading to that tag to your current branch
> while running verify-tag on it.
Agreed. The only remaining issue then would be how that "yes, I
verified the tag" part would be actually saved for posterity. My
suggestion would be to to just punt that question, and let the user
decide, by simply:
- start the editor by default with "--verify"
- output the "gpg --verify" result into the end of the commit file,
along with the tag content (which has the original pgp signature, of
course).
- let the user decide what part of it he wants to use.
In particular, the "gpg --verify" result may well be something that
the user wants to *act* on - maybe the key didn't exist in the key
ring, or maybe it does exist but doesn't have quite enough trust and
gpg complains about that etc etc. But that's all something that "start
the editor and show the user what is up" would let the user decide on.
> For this, disabling the tag-auto-following is not necessary, as you are
> not storing the retrieved tag anywhere.
Exactly,
>> That said, I do think that the "signature in the pull request" should
>> also "just work", and I'm not entirely sure which one is better.
>
> I do not think it is necessarily either/or choice.
No, I think we can do both, and it actually ends up being just a
matter of convenience which one a particular project ends up using (or
even use both depending on preferences of particular sub-lieutenants
within the project).
> I wonder if an approach like the following, in addition to the three
> things I listed above, may give us a workable solution:
>
> * "git fetch linus v3.0" called by "git pull --verify linus v3.0" fetches
> the v3.0 unpeeled into FETCH_HEAD, GPG verifies it, creates
> refs/audit/$u, before running "git merge". $u is derived from v3.0
> (given tag), the identity of the GPG signer, and perhaps timestamp to
> make it both identifiable and unique under refs/audit/ hierarchy.
So far so good, but see above: it may turn out that the user will
*re-verify* the key after having done some gpg action. So..
> * You "git push origin". This causes refs/audit/* refs that point at
> commits in the transferred history to auto-follow, just like the
> current "git fetch $there $src:$dst" causes refs/tags/* auto-follow.
> The refs/audit/* hierarchy in your public repository will be populated
> by lieutenant signatures.
So I don't think auto-follow is good here.
I could *easily* see various companies using this for their own
internal audit, without really wanting to expose things outside of the
company. So auto-following sounds like the wrong approach. Make it an
explicit "expose audit checks" thing.
> * (Optional) You may have signed "git tag -s 'Linux v3.2' v3.2 master"
> before you push origin out, or you may have not. Currently, you do have
> to "git push origin v3.2" separately if you did. The above auto-follow
> could be extended to push refs/tags/* hierarchy to eliminate this step
> as well.
So far I haven't really had any issues with having to do a "git push
--tags" to push things out.
That said, maybe the auto-push could just be a per-repo option, and
then you can have it both ways.
> Note that because of the way "upload-pack" protocol is structured, the
> first response from "upload-pack" after it gets connection is the
> advertisement of refs, and there is no way for "fetch-pack" to ask for
> customized refs advertisement to it. So for this to work without incurring
> undue overhead for normal users, we would need to exclude refs/audit/*
> from the normal ref advertisement (i.e. "ls-remote" does not see it) so
> that "git fetch" by casual users will not have to wait for megabytes of
> ref advertisements before issuing its first "want" request.
I think that would be a good thing, and make it much more palatable.
After all, th elikelihood is that *nobody* will ever care about the
audit cases at all. They are very much a "..but what if xyz happens"
kind of safety net for the extreme badness, not anything you'd expect
to use.
Linus
^ permalink raw reply
* Re: error from 'git push' on v1.7.8-rc0
From: Junio C Hamano @ 2011-11-03 18:59 UTC (permalink / raw)
To: Stefan Näwe; +Cc: gitlist, Junio C Hamano
In-Reply-To: <CAJzBP5Q1_zX+H0jeBZNB81KLYAbtJWhUuHA3rf8CuW-_OSFXbg@mail.gmail.com>
Stefan Näwe <stefan.naewe@gmail.com> writes:
> I get errors from git push when trying to delete a (remote) branch:
>
> $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
> 0000000000000000000000000000000000000000fatal: bad object
> 0000000000000000000000000000000000000000remote: warning: Allowing
> deletion of corrupt ref.
Thanks. I think the operation does _not_ error out and fail to delete, but
I agree that the "fatal:" message should be squelched.
^ permalink raw reply
* Re: [PATCH v3 2/7] invalidate_ref_cache(): take the submodule as parameter
From: Junio C Hamano @ 2011-11-03 18:57 UTC (permalink / raw)
To: Michael Haggerty
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Heiko Voigt, Johan Herland, Julian Phillips
In-Reply-To: <4EB26BA0.9030609@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Sorry I didn't respond to this earlier.
>
> The public API convention (which predates my changes) is that "char
> *submodule" arguments either point at the relative path to the submodule
> or are NULL to denote the main module. But since these are stored
> internally in a name[FLEX_ARRAY] field, I have been using "" internally
> to denote the main module. I believe that everything is done correctly,
> but I admit that the use of different conventions internally and
> externally is a potential source of programming errors.
Yes, it would have been better if the original also used "". After all,
that would make it more consistent---"sub/" means the repository goverend
by "sub/.git", and "" would mean the repository governed by ".git".
Is it hard to change to do so now, given that we won't be rushing this for
the upcoming release and we have plenty of time?
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7v62j1gitn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> BUT.
Ahh, sorry for the noise. I realize that we already have a winner, namely,
the proposal outlined in your message I was responding to.
It just didn't click to me that you were replacing "signed material from
pull request copied into the merge" with "contents of signed tag copied
into the merge".
So forget everything I said in the later parts of my response that talks
about refs/audit/*, and the other message except for gpgsig header being a
stronger form of existing committer line.
^ permalink raw reply
* [PATCH] completion: add --interactive option to git svn dcommit
From: Frédéric Heitzmann @ 2011-11-03 18:33 UTC (permalink / raw)
To: git, gitster; +Cc: normalperson, Frederic Heitzmann
From: Frederic Heitzmann <frederic.heitzmann@gmail.com>
see afd7f1e for more details on git svn dcommit --interactive
Signed-off-by: Frederic Heitzmann <frederic.heitzmann@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 98af8f5..d919baa 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2508,7 +2508,7 @@ _git_svn ()
__gitcomp "
--merge --strategy= --verbose --dry-run
--fetch-all --no-rebase --commit-url
- --revision $cmt_opts $fc_opts
+ --revision --interactive $cmt_opts $fc_opts
"
;;
set-tree,--*)
--
1.7.7.rc2.4.g5ec82.dirty
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> But on the other hand, in many ways, publishing your commit to the outside
>> world, not necessarily for getting pulled into the final destination
>> (i.e. your tree) but merely for other people to try it out, is the point
>> of no return (aka "don't rewind or rebase once you publish"). "pushing
>> out" might be less special than "please pull", but it still is special.
>
> So I really think that signing the top commit itself is fundamentally wrong.
It merely is a stronger form of the "committer" line in the commit
object. A random repository at Github anybody can create repositories at
can serve you a random commit with any random name on "committer" line,
and the new gpgsig header is a way to let the committer certify it
genuinely is from the committer.
I do not think for that purpose, in-commit signature is fundamentally
wrong. I was hoping it would be more useful than it turned out to be, but
I agree that it just is not suitable as a vehicle to convey "I made that
commit some time ago, and now I want you to pull it for such and such
reasons" in a larger workflow.
The "now I want you to pull it for such and such reasons" part is the pull
request, and if we are to protect them with GPG signatures, and perhaps
copy the signed part in the resulting merge, don't we have a reasonable
solution, without all the downsides the signed tag approach would cause if
we wanted to allow third party auditors to have access to the signatures
for independent auditing purposes (described in a separate message)?
Perhaps what is causing the problem is the desire to allow third party
auditors finer grained audit trail, but after having heard that $DAYJOB
folks went through each and every commit after known release points with
fine-toothed comb, I am not brave/rude/blunt enough to dismiss it as
unimportant.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> rusty@rustcorp.com.au-v3.1-8068-g5087a50
> fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50
>
> oops. Ok, so his tag naming is *really* akward. Whatever.
It is not "Whatever".
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0
fatal: Couldn't find remote ref v3.0
I do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it
is not the naming but fetching tags without saying "git fetch tag v3.0"
(which IIRC was your invention long time ago).
If we changed this "git fetch $there v3.0" to fetch tag, it would help the
final step in your illustration, and I do not think it would be a huge
regression---the only case it becomes fuzzy is when they have v3.0 branch
at the same time, but the owner of such a repository is already playing
with fire.
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50
> From git://github.com/rustyrussell/linux
> * tag
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> FETCH_HEAD
>
> Ahh, success!
>
> Oops. Nope. It turns out that git will *peel* the tag when you fetch
> it, so FETCH_HEAD actually doesn't contain the tag object at all, but
> the commit object that the tag pointed to. MAJOR FAIL.
>
> Quite frankly, I think that's a git bug, but it's a git bug because
> "git fetch" was designed to get the commit to merge. Fair enough.
And because FETCH_HEAD started as (and probably still is) an internal
implementation detail of communication between fetch and merge inside
pull. So I do not have any issue in changing it to store tags unpeeled
there.
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50:refs/tags/rusty
> From git://github.com/rustyrussell/linux
> * [new tag]
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> rusty
> * [new tag]
> rusty@rustcorp.com.au-v3.1-2-gb1e4d20 ->
> rusty@rustcorp.com.au-v3.1-2-gb1e4d20
> * [new tag]
> rusty@rustcorp.com.au-v3.1-4896-g0acf000 ->
> rusty@rustcorp.com.au-v3.1-4896-g0acf000
> * [new tag]
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 ->
> rusty@rustcorp.com.au-v3.1-8068-g5087a50
>
> WTF?
This is not WTF but "fetching a history to store the tip of it in your
refs/ namespace causes tags pointing into the history line followed
automatically", and it exactly is what you want to happen if rusty asked
you to fetch his for-linus branch (which the tag may point at) instead.
> We got three other
> tags too that we didn't even ask for!
We could change the rule to read "fetching a history to store the tip of it
in your refs/heads namespace causes autofollow". I am not sure if that is
what we really want, though.
> Again - not a fundamental design mistake in the data structures, and
> it actually made sense from a "signed tags are important release
> points" standpoint, but it makes it *really* inconvenient to use
> signed tags for signature verification.
We could update three things:
- DWIM $name in "git fetch $there $name" to refs/tags/$name when it makes
sense;
- FETCH_HEAD stores unpeeled object names; and
- "git pull" learns --verify option.
Then
$ git pull --verify rusty rusty@rustcorp.com.au-v3.1-8068-g5087a50
could integrate the history leading to that tag to your current branch
while running verify-tag on it.
For this, disabling the tag-auto-following is not necessary, as you are
not storing the retrieved tag anywhere.
That is a longwinded way to say I agree what you said below.
> So signed tags are not mis-designed from a conceptual standpoint -
> they just work really really awkwardly right now for what the kernel
> would like to do with them.
>
> With a few UI fixes, I think the signed tag thing would "just work".
>
> That said, I do think that the "signature in the pull request" should
> also "just work", and I'm not entirely sure which one is better.
I do not think it is necessarily either/or choice.
Either way does not solve anything other than validating the last hop
between the last lieutenant to the integrator without having a way to give
the verification material to third parties.
Your earlier "pull request signature could be copied into the message of
the merge that integrates the pulled history" solves 90% of the "third
party validation" issue.
With the signed tags approach, you could push out these signed tags you
get from lieutenants, but there are quite a few things that need to happen
for it to be usable:
- You or your lieutenants do not want to keep these tags in your working
repository, to be listed in "git tag -l". They are ephemeral to you and
your lieutenant, even though they have to be permanent for third
party auditors.
- Normal users of your project do not want to see them in "git tag -l"
either.
- Responses to "git fetch" and "git ls-remote" produced by "git
upload-pack" do need to (optionally) include them to allow third party
auditors to ask for them.
I wonder if an approach like the following, in addition to the three
things I listed above, may give us a workable solution:
* "git fetch linus v3.0" called by "git pull --verify linus v3.0" fetches
the v3.0 unpeeled into FETCH_HEAD, GPG verifies it, creates
refs/audit/$u, before running "git merge". $u is derived from v3.0
(given tag), the identity of the GPG signer, and perhaps timestamp to
make it both identifiable and unique under refs/audit/ hierarchy.
* You "git push origin". This causes refs/audit/* refs that point at
commits in the transferred history to auto-follow, just like the
current "git fetch $there $src:$dst" causes refs/tags/* auto-follow.
The refs/audit/* hierarchy in your public repository will be populated
by lieutenant signatures.
* (Optional) You may have signed "git tag -s 'Linux v3.2' v3.2 master"
before you push origin out, or you may have not. Currently, you do have
to "git push origin v3.2" separately if you did. The above auto-follow
could be extended to push refs/tags/* hierarchy to eliminate this step
as well.
Note that because of the way "upload-pack" protocol is structured, the
first response from "upload-pack" after it gets connection is the
advertisement of refs, and there is no way for "fetch-pack" to ask for
customized refs advertisement to it. So for this to work without incurring
undue overhead for normal users, we would need to exclude refs/audit/*
from the normal ref advertisement (i.e. "ls-remote" does not see it) so
that "git fetch" by casual users will not have to wait for megabytes of
ref advertisements before issuing its first "want" request. Probably we
can change "upload-pack" to advertise only refs/heads/*, refs/tags/*, and
HEAD by default, and a protocol extension could be added to ask for other
hierarchies for specialized needs like third party auditors.
BUT.
This does not allow third party auditors to audit how sub-subsystem
histories came into your lieutenants' history unless you also fetch from
your lieutenants in "auditor" mode to retrieve their refs/audit/* refs to
be propagated to your public repository, which all of us involved in this
thread know you wouldn't bother if it is an additional manual step (and I
personally do not think I would bother if I were you).
So the audit trail will end at one level unless we have even more complex
arrangements. The auditors know the history up to some point in the past
came from you (your last signed tag at release time, which some people may
feel a bit too sparse for auditing purposes when a security incident like
that one happens in between releases), and they know subhistories of what
you merged came from your direct lieutenants (the refs/audit/* tags the
above change allowed you to forward automatically when you published), but
they have to take the word of your direct lieutenants at face value.
I do not know if that is acceptable for $DAYJOB types, though.
^ permalink raw reply
* Re: Folder level Acces in git
From: Jens Lehmann @ 2011-11-03 18:13 UTC (permalink / raw)
To: redhat1981; +Cc: Magnus Bäck, git
In-Reply-To: <20111103071701.GA22412@jpl.local>
Am 03.11.2011 08:17, schrieb Magnus Bäck:
> On Thursday, November 03, 2011 at 07:10 CET,
> redhat1981 <redhat1981@gmail.com> wrote:
>> Inside the repository, testabc let us say there are folders folder1,
>> folder 2 etc, I want some users to have read/write, read or no access
>> to the folder1 or folder2, Is this possible in Git, I have done it in
>> SVN, Please help!!
>
> Given Git's nature, you can't have read access restrictions on a sub-git
> level (i.e. file/directory level). For basically the same reason, you
> can never prevent users from making (local) commits that modify certain
> paths (but you can encourage people to have local hooks to enforce such
> policies). What you *can* do is install a server-side update hook that
> rejects attempts to push commits that modify certain paths. If you're
> willing to trade Gitosis for Gitolite, you get that feature for free.
Directory read access control can be achieved by putting the directory
content into a submodule. You can then control who is allowed to clone
from the repo for that submodule separately from the superproject,
thereby disallowing a group of people to see (let alone modify) what is
in there.
http://progit.org/book/ch6-6.html
^ permalink raw reply
* Re: error from 'git push' on v1.7.8-rc0
From: Stefan Naewe @ 2011-11-03 17:26 UTC (permalink / raw)
To: git
In-Reply-To: <CAJzBP5Q1LaUBL_wHFfaY-cLatd_=oez9j+=60z3kxwg_47GN_Q@mail.gmail.com>
Stefan Näwe <stefan.naewe <at> gmail.com> writes:
>
> On Thu, Nov 3, 2011 at 12:43 PM, Stefan Näwe <stefan.naewe <at> gmail.com>
wrote:
> > I get errors from git push when trying to delete a (remote) branch:
> >
> > $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> > $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
> $ ./bin-wrappers/git push -q . :refs/heads/nogo
>
> (re-wrapped)
>
> $ ./bin-wrappers/git push -q . :refs/heads/nogo
> fatal: bad object 0000000000000000000000000000000000000000
> fatal: bad object 0000000000000000000000000000000000000000
> remote: warning: Allowing deletion of corrupt ref.
I think the problem lies actually in 'rev-list':
$ git rev-list --verify-objects 0000000000000000000000000000000000000000 \
--not --all
fatal: bad object 0000000000000000000000000000000000000000
Regards,
Stefan
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Andreas Schwab @ 2011-11-03 17:00 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: Kirill Likhodedov, git
In-Reply-To: <CANiMyiF=C_uBXf3kV8ix=CY9Mi=cxHU-J3dn5UyJ87gu3Sm0dg@mail.gmail.com>
Hong-Ming Su <halleyinvent@gmail.com> writes:
> /d/workspace/git/work1 (master)
> $ git remote add origin ../depot
$ git branch --set-upstream master origin/master
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Thomas Rast @ 2011-11-03 16:28 UTC (permalink / raw)
To: Reuben Thomas; +Cc: git
In-Reply-To: <CAOnWdoj1eUipRd8M=jsAPdDTNcgEbT7adWR78iU5Oac9DvODkQ@mail.gmail.com>
Reuben Thomas wrote:
> If I run
>
> git svn dcommit COMMIT
>
> with COMMIT being an unambiguous, but partial revision string, it
> behaves like git svn dcommit, i.e. commits everything.
In what git version? How do I reproduce? I just ran a simple test
and can't:
svnadmin create svnrepo
svn co file://$(pwd)/svnrepo svnwt
cd svnwt
echo a > a
svn add a
svn ci -m'do a'
cd ..
git svn clone file://$(pwd)/svnrepo gitwt
cd gitwt
echo b > a
git add a
git commit -mb
echo c>a
git add a
git commit -mc
git log --oneline
git svn dcommit 1b4c4e1
where 1b4c4e1 was the abbreviated hash of the parent commit (i.e., the
commit 'b'). As expected, it commits everything *up to* 1b4c4e1 from
a detached HEAD, not affecting the current branch.
Note that this is different from what you describe:
> (If I remember to copy and paste the whole nine yards of the
> revision string, it works as expected, i.e. commits just that
> revision.)
It was never designed to commit "just that revision".
By "it" I mean 5eec27e (git-svn: let 'dcommit $rev' work on $rev
instead of HEAD, 2009-05-29), which changed it to the current
semantics and went into 1.6.4. Before that, 'git svn dcommit <foo>'
did something weird and you should avoid giving it arguments.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: How to find a commit that introduces (not removes) a string?
From: Vijay Lakshminarayanan @ 2011-11-03 16:13 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> Hi all,
>
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
This appears to work:
$ for ref in `git log -SWORD --pretty=format:"%h"` ; do
git log -1 -p $ref | grep WORD | grep -E '^[+]' > /dev/null ;
if [ $? -eq 0 ]; then
echo $ref;
fi ;
done
substitute WORD for what you're looking for. Note that it is repeated
twice.
> Thanks!
>
> PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
>
> [1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
--
Cheers
~vijay
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 16:10 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: git
In-Reply-To: <F802D297-95A0-4B1E-894D-9681E0EEF3AD@jetbrains.com>
Thank for your hints. I get "git push" work. The "git pull" need argument.
/d/workspace/git
$ ls
depot work1 work2
/d/workspace/git
$ git clone --bare work1 depot
Cloning into bare repository depot...
done.
/d/workspace/git/work1 (master)
$ git push
fatal: No destination configured to push to.
/d/workspace/git/work1 (master)
$ git pull
fatal: No remote repository specified. Please, specify either a URL or a
remote name from which new revisions should be fetched.
/d/workspace/git/work1 (master)
$ git remote add origin ../depot
/d/workspace/git/work1 (master)
$ git push
Everything up-to-date
/d/workspace/git/work1 (master)
$ git pull
From ../depot
* [new branch] master -> origin/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.
If you often merge with the same branch, you may want to
use something like the following in your configuration file:
[branch "master"]
remote = <nickname>
merge = <remote-ref>
[remote "<nickname>"]
url = <url>
fetch = <refspec>
/d/workspace/git/work1 (master)
$ git pull origin master:master
Already up-to-date.
2011/11/4 Kirill Likhodedov <Kirill.Likhodedov@jetbrains.com>:
>
>
> 03.11.2011, в 17:59, Hong-Ming Su:
>
>> I create a repo X with git init. After several commit in X, I clone a
>> bare repo Y from X.
>> I try to continue work in X, and push to/pull from Y. The command git
>> push and git pull fails. I see the error message but I do not know
>> which git command can fix that problem.
>> Then I clone Z from Y. git push/pull works in Z.
>> How to make "git push/pull" the same in X as in Z?
>>
>
>
> By cloning Y from X you made X to be a parent of Y while you need vice versa.
> To fix this add Y as a remote to X and set up tracking for you master branch.
>
> By the way, in such cases you'd better write commands you've executed, and the error report you've got.
> " I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
>
> ----------------------------------
> Kirill Likhodedov
> JetBrains, Inc
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Joshua Jensen @ 2011-11-03 16:05 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4EA9B0B5.6060005@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 10/27/2011 1:27 PM
> We had a submodule that we deleted and then added back into the
> repository at the same location as the former submodule. When running
> fast-export, the newly 'added' files for the merge commit are listed
> and then are followed with a:
>
> M ... path/to/submodule/file
> D path/to/submodule
>
> On fast-import, the resultant repository becomes corrupt due to the
> Delete instruction above occurring AFTER the file adds/modifications.
> The new repository does not match the old repository where the
> fast-export was performed.
>
> I am not familiar with the fast-export code. Can anyone help out?
Okay, I looked into this further, and I came up with a patch that works
for me. Nevertheless, I do not understand exactly what is going on
here, so I would like to defer to someone else's patch to fix the issue.
-Josh
---
builtin/fast-export.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 9836e6b..1abc470 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -161,6 +161,14 @@ static int depth_first(const void *a_, const void *b_)
name_a = a->one ? a->one->path : a->two->path;
name_b = b->one ? b->one->path : b->two->path;
+ /*
+ * Move 'D'elete entries first.
+ */
+ if (a->status == 'D')
+ return -1;
+ else if (b->status == 'D')
+ return 1;
+
len_a = strlen(name_a);
len_b = strlen(name_b);
len = (len_a < len_b) ? len_a : len_b;
--
^ permalink raw reply related
* Re: How to find a commit that introduces (not removes) a string?
From: Neal Kreitzinger @ 2011-11-03 15:56 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
On 11/3/2011 4:50 AM, Sebastian Schuberth wrote:
> Hi all,
>
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
>
> Thanks!
>
> PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
>
> [1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
>
If you are using linux, here is git diff command I use to find leftover
debug statements. I imagine the -S option will work the same in git
log. I pipe the results into grep to filter the results to show only
the additions. (I'm using git 1.7.1)
$ git diff --unified=0 -S"DEBUG" <commit> <commit> -- <path> | grep -e
"diff --" -e "+" | grep -v -e "@@" -e "+++"
maybe you will find this helpful.
v/r,
neal
^ permalink raw reply
* Re: git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Frans Klaver @ 2011-11-03 15:56 UTC (permalink / raw)
To: Reuben Thomas; +Cc: git
In-Reply-To: <CAOnWdoj1eUipRd8M=jsAPdDTNcgEbT7adWR78iU5Oac9DvODkQ@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 4:12 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> If I run
>
> git svn dcommit COMMIT
>
> with COMMIT being an unambiguous, but partial revision string, it
> behaves like git svn dcommit, i.e. commits everything. (If I remember
> to copy and paste the whole nine yards of the revision string, it
> works as expected, i.e. commits just that revision.)
>
> I'd expect it to work like other git commands, and understand partial
> revision strings, or at least bail out saying it was an invalid
> revision.
Sounds like git-svn skips the rev-parse, or doesn't verify. Which
version of git is this?
Workaround would probably be something like
dcommit.sh:
#!/bin/sh
COMMIT=$1
THINGY=$(git rev-parse --verify $COMMIT) || exit $?
git svn dcommit THINGY
$ dcommit.sh COMMIT
Meh. Better fix git-svn.
Cheers,
Frans
^ permalink raw reply
* git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Reuben Thomas @ 2011-11-03 15:12 UTC (permalink / raw)
To: git
If I run
git svn dcommit COMMIT
with COMMIT being an unambiguous, but partial revision string, it
behaves like git svn dcommit, i.e. commits everything. (If I remember
to copy and paste the whole nine yards of the revision string, it
works as expected, i.e. commits just that revision.)
I'd expect it to work like other git commands, and understand partial
revision strings, or at least bail out saying it was an invalid
revision.
--
http://rrt.sc3d.org
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Kirill Likhodedov @ 2011-11-03 16:09 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
03.11.2011, в 17:59, Hong-Ming Su:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
>
By cloning Y from X you made X to be a parent of Y while you need vice versa.
To fix this add Y as a remote to X and set up tracking for you master branch.
By the way, in such cases you'd better write commands you've executed, and the error report you've got.
" I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
----------------------------------
Kirill Likhodedov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Frans Klaver @ 2011-11-03 15:07 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 3:59 PM, Hong-Ming Su <halleyinvent@gmail.com> wrote:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
Care to tell us which commands you use and which errors you get? It
will give clues about how to help.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
Same here.
Cheers,
Frans
^ permalink raw reply
* How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 14:59 UTC (permalink / raw)
To: git
Hi,
I create a repo X with git init. After several commit in X, I clone a
bare repo Y from X.
I try to continue work in X, and push to/pull from Y. The command git
push and git pull fails. I see the error message but I do not know
which git command can fix that problem.
Then I clone Z from Y. git push/pull works in Z.
How to make "git push/pull" the same in X as in Z?
Thanks,
Hong-Ming
^ 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