* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-11-03 23:02 UTC (permalink / raw)
To: Stefan Naewe, Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20111102200947.GA5628@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Normally I would say to implement in favor of the no-netrc case, as it
> is probably more common (and will hopefully be more so after the auth
> helpers are finished). But the problem is that the penalties are
> different. On the one hand, we have the extra http round-trip. Which is
> annoying, but mostly invisible to the user. But on the other, we have
> git prompting the user unnecessarily, which is just awful.
Ok, so are we in agreement that Stefan's patch $gmane/184617 is the right
fix at least for the time being?
This will be a minor regression if left unfixed, so I'd like to have a
minimum fix in before I tag -rc1 over the weekend.
Could any one of you guys please care to package it up with a readable
commit log message with a sign-off?
^ permalink raw reply
* What's cooking in git.git (Nov 2011, #01; Thu, 3)
From: Junio C Hamano @ 2011-11-03 22:16 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
--------------------------------------------------
[New Topics]
* jc/stream-to-pack (2011-11-03) 4 commits
- Bulk check-in
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. I think this
codepath to move data from worktree to repository needs to become aware of
streaming, just like the checkout codepath that goes the other way, which
was done in the previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* vr/msvc (2011-10-31) 3 commits
- MSVC: Remove unneeded header stubs
- Compile fix for MSVC: Include <io.h>
- Compile fix for MSVC: Do not include sys/resources.h
It seems this needs to be rehashed with msysgit folks.
* mf/curl-select-fdset (2011-11-02) 2 commits
- http.c: Use timeout suggested by curl instead of fixed 50ms timeout
- http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
* na/strtoimax (2011-11-02) 2 commits
- Support sizes >=2G in various config options accepting 'g' sizes.
- Add strtoimax() compatibility function.
--------------------------------------------------
[Graduated to "master"]
* dm/pack-objects-update (2011-10-20) 4 commits
(merged to 'next' on 2011-10-27 at fa52898)
+ pack-objects: don't traverse objects unnecessarily
+ pack-objects: rewrite add_descendants_to_write_order() iteratively
+ pack-objects: use unsigned int for counter and offset values
+ pack-objects: mark add_to_write_order() as inline
* ef/mingw-upload-archive (2011-10-30) 3 commits
(merged to 'next' on 2011-10-30 at 5267fa3)
+ upload-archive: use start_command instead of fork
+ compat/win32/poll.c: upgrade from upstream
+ mingw: move poll out of sys-folder
* jk/git-tricks (2011-10-21) 3 commits
(merged to 'next' on 2011-10-23 at 7c9bf71)
+ completion: match ctags symbol names in grep patterns
+ contrib: add git-jump script
+ contrib: add diff highlight script
* nd/pretty-commit-log-message (2011-10-23) 2 commits
(merged to 'next' on 2011-10-27 at 4b61df7)
+ pretty.c: use original commit message if reencoding fails
+ pretty.c: free get_header() return value
* ss/blame-textconv-fake-working-tree (2011-10-28) 2 commits
(merged to 'next' on 2011-10-30 at 9588bc1)
+ (squash) test for previous
+ blame.c: Properly initialize strbuf after calling, textconv_object()
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
Will keep in 'next' during this cycle.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
Will keep in 'next' during this cycle.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
Will keep in 'next' during this cycle.
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
Will keep in 'next' during this cycle.
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' until an Ack or two from completion folks.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
--------------------------------------------------
[Discarded]
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
. gitweb: add a feature to show side-by-side diff
. gitweb: change format_diff_line() to remove leading SP from $diff_class
jn/gitweb-side-by-side-diff replaces this.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vwrbhdixe.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 01:56:13PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So you would agree that we are better summing the objects for all packs
> > and showing one big progress bar?
>
> If it can be done without sacrificing the clarity of the code, compared to
> the "we will do new and smaller ones first so in practice it does not
> matter" approach taken by the patch in question, I would not mind it, but
> to be honest, I do not deeply care either way.
I looked briefly at doing this. It's a little annoying with the
verify_packs code, because you have to pass around the "how far are we
into the progress" counter separately. But I confess I don't care that
much either way, either. With the two minor fixups I sent in my original
review, I think Duy's patch would be OK by me.
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 20:56 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103202954.GC19483@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So you would agree that we are better summing the objects for all packs
> and showing one big progress bar?
If it can be done without sacrificing the clarity of the code, compared to
the "we will do new and smaller ones first so in practice it does not
matter" approach taken by the patch in question, I would not mind it, but
to be honest, I do not deeply care either way.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7v8vnxeyrp.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 01:28:42PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> 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)
> >
> > I don't think we can do multiple lines portably, though, because the
> > progress code just uses "\r" to return to the beginning of the line.
>
> It was meant to be a tongue-in-cheek comment. I personally hate those
> "Installing n of N packages / Installation of package n p% done" progress
> meters when we know the weight of each of these N packages varies.
OK, I missed your sarcasm. You're too understated. ;)
So you would agree that we are better summing the objects for all packs
and showing one big progress bar?
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103195147.GA21318@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> 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)
>
> I don't think we can do multiple lines portably, though, because the
> progress code just uses "\r" to return to the beginning of the line.
It was meant to be a tongue-in-cheek comment. I personally hate those
"Installing n of N packages / Installation of package n p% done" progress
meters when we know the weight of each of these N packages varies.
I also agree with your "how would you know which one is throughput and
which one is counts" comment, which would mean the particular abstraction
you mentioned is too premature even though it looks nice on the surface.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vd3d9f0u8.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 12:43:59PM -0700, Junio C Hamano wrote:
> > 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)
I don't think we can do multiple lines portably, though, because the
progress code just uses "\r" to return to the beginning of the line.
However, I do think it's a nice design even if the output is the same
right now, because the calling code is specifying more clearly to the
progress code what it actually means. Which means it is easier to
tweak the progress code later to make a prettier representation of that
meaning.
One downside (as with all abstractions :) ), is that it's hard to
deviate from the defaults. With the above, how would you specify if it
was a group of throughput measurements, not counts? Or that you wanted
to use start_progress_delay instead of start_progress on each one?
Or hey, if you really want to get crazy, why can't we check each pack in
parallel on a different CPU, and have all of the progress meters
displayed and moving simultaneously? :)
The last one is obviously a bit tongue in cheek. But it does raise an
interesting point: is seeing the per-pack meter actually useful (whether
parallel or not)? The user just wants to know that progress is being
made, and when it is done. And maybe that argues for just summing the
size of each pack and showing a single progress meter per task.
-Peff
^ permalink raw reply
* 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
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