* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190519mbe9ddaava3c15de94a0cd14f@mail.gmail.com>
And... I instantly have to apologise.. With wonderful irony,
Googlemail folded the helpful bit of your reply leaving just the
(apparently) unhelpful bit.
(Crawls under nearest rock).
2009/10/19 Howard Miller <howard@e-learndesign.co.uk>:
> Mmm....
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
>
> On the other hand if you can't be bothered making a helpful reply
> rather than a rude one perhaps simply not writing anything at all
> would, at the very least, leave us absolutely no worse off. Just the
> opinion of someone not to be taken seriously.... of course!
>
> Howard
>
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> first, if you want to be taken seriously, you might want to avoid to
>> top-post.
>>
>> Second, do diligent research (e.g. on the 'mob' user).
>>
>> On Mon, 19 Oct 2009, Howard Miller wrote:
>>
>>> I'm quite interested in this too but I can't see what that patch does at
>>> all. I'm unsure what the 'mob' account is but a search suggests it's
>>> something to do with anonymous access, which doesn't seem to make any
>>> sense.
>>
>> If this trivial script (_not_ a patch! This should be obvious at first
>> sight) does not make any sense to you, I fear you will not be able to use
>> hooks to do what you want to do.
>>
>>> Can you explain?
>>
>> Yes.
>>
>> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
>> that exists. IOW a user of repo.or.cz can decide to let random people to
>> push commits by creating the 'mob' branch and adding the 'mob' user to the
>> pushers.
>>
>> The first part of the hook (as you can see from the pretty helpful error
>> messages it outputs) is about denying to push to anything but the mob
>> branch.
>>
>> The second part is much more interesting in the context of this thread
>> (and I would expect anyone capable of reading shell scripts to see that
>> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
>> See line 16ff.
>>
>> So the point is: the update hook gets a "$2" = 0000... in case a branch is
>> about to be created, and the hook can prevent that by exiting with a
>> non-zero exit code.
>>
>> Hth,
>> Dscho
>>
>>
>
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 12:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191353080.4985@pacific.mpi-cbg.de>
Mmm....
Thanks for the helpful reply Johannes. Perhaps you should do diligent
research into mail software that folds quoted text for you. There's a
company called Google you might have heard of. Just a thought.
On the other hand if you can't be bothered making a helpful reply
rather than a rude one perhaps simply not writing anything at all
would, at the very least, leave us absolutely no worse off. Just the
opinion of someone not to be taken seriously.... of course!
Howard
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> first, if you want to be taken seriously, you might want to avoid to
> top-post.
>
> Second, do diligent research (e.g. on the 'mob' user).
>
> On Mon, 19 Oct 2009, Howard Miller wrote:
>
>> I'm quite interested in this too but I can't see what that patch does at
>> all. I'm unsure what the 'mob' account is but a search suggests it's
>> something to do with anonymous access, which doesn't seem to make any
>> sense.
>
> If this trivial script (_not_ a patch! This should be obvious at first
> sight) does not make any sense to you, I fear you will not be able to use
> hooks to do what you want to do.
>
>> Can you explain?
>
> Yes.
>
> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
> that exists. IOW a user of repo.or.cz can decide to let random people to
> push commits by creating the 'mob' branch and adding the 'mob' user to the
> pushers.
>
> The first part of the hook (as you can see from the pretty helpful error
> messages it outputs) is about denying to push to anything but the mob
> branch.
>
> The second part is much more interesting in the context of this thread
> (and I would expect anyone capable of reading shell scripts to see that
> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
> See line 16ff.
>
> So the point is: the update hook gets a "$2" = 0000... in case a branch is
> about to be created, and the hook can prevent that by exiting with a
> non-zero exit code.
>
> Hth,
> Dscho
>
>
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 12:00 UTC (permalink / raw)
To: Howard Miller; +Cc: Mohit Aron, git
In-Reply-To: <26ae428a0910190308t3233debdjfc0c8beedb9c0ac6@mail.gmail.com>
Hi,
first, if you want to be taken seriously, you might want to avoid to
top-post.
Second, do diligent research (e.g. on the 'mob' user).
On Mon, 19 Oct 2009, Howard Miller wrote:
> I'm quite interested in this too but I can't see what that patch does at
> all. I'm unsure what the 'mob' account is but a search suggests it's
> something to do with anonymous access, which doesn't seem to make any
> sense.
If this trivial script (_not_ a patch! This should be obvious at first
sight) does not make any sense to you, I fear you will not be able to use
hooks to do what you want to do.
> Can you explain?
Yes.
The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
that exists. IOW a user of repo.or.cz can decide to let random people to
push commits by creating the 'mob' branch and adding the 'mob' user to the
pushers.
The first part of the hook (as you can see from the pretty helpful error
messages it outputs) is about denying to push to anything but the mob
branch.
The second part is much more interesting in the context of this thread
(and I would expect anyone capable of reading shell scripts to see that
readily), because it denies the 'mob' user to _create_ the 'mob' branch.
See line 16ff.
So the point is: the update hook gets a "$2" = 0000... in case a branch is
about to be created, and the hook can prevent that by exiting with a
non-zero exit code.
Hth,
Dscho
^ permalink raw reply
* Re: Unapplied patches reminder
From: Rolf Bjarne Kvinge @ 2009-10-19 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vzl7ogtxs.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On Mon, 19 Oct 2009 01:31:59 +0200, Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, I saw these patches and thought what they try to do were
>> sensible, but I don't them in your tree. I didn't see much discussion
>> on most of them, either.
>>
>> Because I don't read C very well, I may have listed some patches
>> here that you may have discarded because the code was no good, and
>> if so I apologize for wasting your time, but I thought at least
>> some of them should be salvaged.
>> ...
>> From: "Rolf Bjarne Kvinge" <RKvinge@novell.com>
>> Subject: git rev-list --pretty=raw strips empty lines
>> Date: Tue, 06 Oct 2009 14:33:37 +0200
>> Message-ID: <op.u1do6bq5k71drc@linux.lacasa>
>>
>> It seems like the --pretty=raw format strips off empty newlines from
>> the beginning of log messages, while I'd expect the raw format to
>> not do any transformations (just as the documentation says: "The
>> 'raw' format shows the entire commit exactly as stored in the commit
>> object").
>>
>> The below changes works for me, not sure if I'm right about this
>> though (my first time here ;-)
>
> I do not recall seeing this one; most likely it was lost in the noise,
> especially because it did not look like a patch submission, without having
> anything resembling a commit log message.
>
> I think the change itself is an uncontroversial one, even though this
> really changes the behaviour.
My specific need is to be able to get out the exact same log message as I committed, another way of getting the same result would be to implement --pretty=xml (along the lines of subversions 'svn log --xml'). This would prevent behavioural changes. And yes, I'm willing to implement it if you agree it's a good idea.
Regarding the previous patch I just found that it's not complete - git would still print lines with only whitespace as empty lines (i.e. stripping off the whitespace). I'm attaching a revised patch that fixes this issue, but since I found the resulting code slightly ugly, I also found an easier approach: in pretty_print_commit (pretty.c) just print the commit message buffer and return.
Rolf
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: 0001-pretty.c-Don-t-do-any-transformations-when-using-the.patch --]
[-- Type: application/octet-stream, Size: 0 bytes --]
[-- Attachment #3: 0001-pretty.c-special-case-raw-format.patch --]
[-- Type: application/octet-stream, Size: 874 bytes --]
From 4fa9e4c1c133fbe3423c979efd5722dd7bd5d530 Mon Sep 17 00:00:00 2001
From: Rolf Bjarne Kvinge <RKvinge@novell.com>
Date: Mon, 19 Oct 2009 13:31:17 +0200
Subject: [PATCH] pretty.c: Don't do any transformations when using the 'raw' format.
When formatting commits with the 'raw' format, print the commit exactly as
stored.
Signed-off-by: Rolf Bjarne Kvinge <RKvinge@novell.com>
---
pretty.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index f5983f8..96dac9a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -915,6 +915,11 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
return;
}
+ if (fmt == CMIT_FMT_RAW) {
+ strbuf_add(sb, msg, strlen (msg));
+ return;
+ }
+
reencoded = reencode_commit_message(commit, &encoding);
if (reencoded) {
msg = reencoded;
--
1.6.5.rc2.17.gdbc1b.dirty
^ permalink raw reply related
* Re: Potentially dangerous behavior of git gc
From: Miklos Vajna @ 2009-10-19 11:21 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T095725-840@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari <sergio.callegari@gmail.com> wrote:
> With this when the alternate info of A is finally updated, A is broken, missing
> many references and not having a head anymore.
>
> Would it be better to have git gc not to take dangerous actions on potentially
> problematic repos?
Such repos are usually created using git clone -s. See the NOTE of the
manpage under the -s option, probably you want to use git repack -a
after git clone.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Sergio Callegari @ 2009-10-19 10:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Johannes Sixt wrote:
> Sergio Callegari schrieb:
>
>> Is there a means to have fsck to a truly full check on the sanity of a repo?
>>
>
> git fsck --full
>
> RTFM, please.
>
>
Right... sorry for the noise, I mismatched --strict for --full in a script.
BTW, the short help for fsck at --full only says "consider objects in
alternate repositories".
My apologize.
Sergio
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Howard Miller @ 2009-10-19 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mohit Aron, git
In-Reply-To: <alpine.DEB.1.00.0910191155310.4985@pacific.mpi-cbg.de>
Hi,
I'm quite interested in this too but I can't see what that patch does
at all. I'm unsure what the 'mob' account is but a search suggests
it's something to do with anonymous access, which doesn't seem to make
any sense.
Can you explain?
Thanks!
2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 19 Oct 2009, Mohit Aron wrote:
>
>> I'm setting up a shared repository and I'd like to prevent users from
>> creating branches in it (they can of course create local branches in
>> their own clone of this repository). How can I accomplish this ? I
>> looked at 'git help config' and it seems I need something similar to the
>> parameter receive.denyDeletes - this prevents deletion of branches.
>
> The easiest way to accomplish things is to look who had the same problem
> and solved it:
>
> http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
>
> Hth,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Which dates 'git log --since= --after=' compare?
From: Daniel @ 2009-10-19 10:01 UTC (permalink / raw)
To: git
Hi,
I can see that 'git log --since= --after=' compares commit's dates,
not author's dates.How can I limit commits by Author's date?
$ git log --format="%aD %cD"
Mon, 5 Oct 2009 14:54:57 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 11:11:35 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Mon, 21 Sep 2009 10:14:41 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 14:23:30 +0200 Thu, 8 Oct 2009 10:31:40 +0200
Wed, 16 Sep 2009 10:27:39 +0200 Thu, 8 Oct 2009 10:31:38 +0200
Wed, 16 Sep 2009 09:15:32 +0200 Thu, 8 Oct 2009 10:30:31 +0200
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
$ git log --format="%aD %cD" --since=2009-09-01 --until=2009-10-01
Wed, 16 Sep 2009 08:02:23 +0200 Wed, 16 Sep 2009 09:02:29 +0200
--
Daniel
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Schindelin @ 2009-10-19 10:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio Callegari, git
In-Reply-To: <4ADC2D45.3020803@viscovery.net>
Hi,
On Mon, 19 Oct 2009, Johannes Sixt wrote:
> Sergio Callegari schrieb:
> > Is there a means to have fsck to a truly full check on the sanity of a
> > repo?
>
> git fsck --full
>
> RTFM, please.
Now, now.
If you were to test a new filesystem, say, wonderfulfs, and wanted to
check its integrity, would you not just run "fsck-wonderfulfs" if that
exists, rather than reading the fantamagastic manual? Would you not
expect that it Does The Right Thing? Would you not expect that it
follows the Law Of Minimal Surprise?
So FWIW I can see where Sergio is coming from.
Ciao,
Dscho
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Johannes Schindelin @ 2009-10-19 9:57 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
Hi,
On Mon, 19 Oct 2009, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to the
> parameter receive.denyDeletes - this prevents deletion of branches.
The easiest way to accomplish things is to look who had the same problem
and solved it:
http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
Hth,
Dscho
^ permalink raw reply
* Re: Moving git
From: rhlee @ 2009-10-19 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <20091016184251.GG19511@inocybe.localdomain>
Thanks, I've been looking for something like EPEL for a long time.
--
View this message in context: http://n2.nabble.com/Moving-git-tp3836198p3848039.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johan Herland @ 2009-10-19 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7vhbtv6c76.fsf@alter.siamese.dyndns.org>
On Monday 19 October 2009, Junio C Hamano wrote:
> * jh/notes (2009-10-09) 22 commits.
> - fast-import: Proper notes tree manipulation using the notes API
> - Refactor notes concatenation into a flexible interface for combining notes
> - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> - Notes API: get_note(): Return the note annotating the given object
> - Notes API: add_note(): Add note objects to the internal notes tree structure
> - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> - Add selftests verifying concatenation of multiple notes for the same commit
> - Refactor notes code to concatenate multiple notes annotating the same object
> - Add selftests verifying that we can parse notes trees with various fanouts
> - Teach the notes lookup code to parse notes trees with various fanout schemes
> - Teach notes code to free its internal data structures on request
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note string
> - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
> (this branch uses sr/gfi-options.)
Nope. This branch does not use sr/gfi-options. The jh/cvs-helper branch
does, though.
> Is this good for 'next' now?
Not all of it.
I suspect the first 14 patches are stable and 'next'-worthy, although
it would be nice if Dscho had the time to ACK them.
The last patch (#22) needs some major rework based on Shawn's comments
(I'm working on that, although I currently have less time than I hoped
for), and that rework might ripple into patches #15 through #21.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Sixt @ 2009-10-19 9:11 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T094924-194@post.gmane.org>
Sergio Callegari schrieb:
> Is there a means to have fsck to a truly full check on the sanity of a repo?
git fsck --full
RTFM, please.
-- Hannes
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Björn Steinbrink @ 2009-10-19 8:51 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On 2009.10.19 01:32:24 -0700, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
You could write a pre-receive or update hook (depending on whether you
want the whole push to fail, or just the branch head creation, see
githooks(5)).
If a ref is created, the old value is 40 0 (just zeros, forty of them).
And if the refname starts with refs/heads/, then a branch head is being
created. And in that case, you could refuse the push.
Björn
^ permalink raw reply
* Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit
From: Junio C Hamano @ 2009-10-19 8:50 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <499EF2B6.7060103@hvoigt.net>
Heiko Voigt <git-list@hvoigt.net> writes:
> It sometimes happens that you move to a new machine and forget to setup your
> name and email address. To find this out after 10 commits can be quite
> frustrating.
Doesn't env_hint[] kick in in fmt_ident() in such a case, though?
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-19 8:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vws2snwum.fsf@alter.siamese.dyndns.org>
On 2009.10.18 15:47:13 -0700, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:
> > 1) No uncommitted changes => No problem
> > 2) Uncommitted changes merge cleanly => No problem
> > 3) Uncommitted changes causes conflicts =>
> > - User can resolve
> > - User can start over (git update --retry)
> > - User can give up (git update --abort)
>
> By "--abort", if you meant to discard the local change, that is only
> suitable for people who would say "what I was doing was minor anyway, and
> I'll redo them based on the updated upstream", and may not be so useful, I
> think. The user may want to pretend that he did not even start "update"
> (i.e. not pulled while he was still working on something) at this point,
> and if you meant by "give up" (aka --abort) to "reset --hard @{1} &&
> unstash", I think it makes quite a lot of sense. Then the user has an
> option to fork a topic at that point:
>
> git update --abort
> git checkout -b topic
> work on more with committing
> git checkout master
> git update
Yes, I meant the latter. The former would just be "git reset --hard" and
is pointless to be rewrapped in "git update --abort". Maybe "abort" is
the wrong word there? I'm not a native speaker and basically took that
from "git rebase", which returns you to your (unchanged) branch head,
i.e. the state you were in before you started the rebase.
> But then this starts to look more like an enhanced failure recovery mode
> for "git pull" command.
Yeah, I notice that, also while working on my "proof-of-concept"
implementation. Currently, I simply suggest "git pull" to the user when
the update is not a fast-forward one.
I'm probably influenced by a latent hatred for "git pull"... Explaining
that it is fetch+merge/rebase and uses defaults from the config which
are automagically setup is probably something my fingers can do on
their own by now. Confusion about "git pull" probably beats
misunderstandings about HEAD.
If it wasn't so inconvenient for people that actually commit, I'd even
dare to suggest:
git update
- FF update only, using branch.<name>.{remote,merge}
- suggests "git update --merge" or "git update --rebase" if non-ff
git update --merge
- Does a merge
git update --rebase
- Does a rebase
And "git pull" would stop using branch.<name>.{remote,merge} and require
command line arguments.
That would at least raise awareness that "git update --merge" is doing a
merge, unlike "git pull", which many new users simply treat as magic,
not realizing what actually happens (and thus they create butt-ugly
criss-cross merge histories). Of course, I can't tell whether being
aware that a merge happens actually makes the user realize that they
shouldn't update/pull/merge 50 times a day.
But passing --merge all the time seems just too inconvenient. And having
a config option to make --merge or --rebase the default would probably
end up with --merge as the "default default", ultimately turning "git
update" into "git pull".
Anyway, I'm probably getting quite far off the track here.
> In addition, I think that you would internally implement the "save" step
> with "stash" (which would be a sane thing to do), but then you would need
> to worry about the case where the user was in the middle of a merge (or
> "revert", "cherry-pick", "checkout -m") that did not complete. "git pull"
> fails upfront, says why and tells users what to do. "git update" should
> do the same.
Yup, got the same check in my PoC
> > I do see problems with a "stash around merge" thing ("stash" around
> > rebase seems easier, as that could just create a commit and reset later,
> > but I'm not exactly sure that such smartness is a good idea). As soon as
> > the merge has conflicts, you need to know that you have to unstash after
> > committing the merge, but what I have in mind is fast-forward only (or
> > possibly reset, when upstream was rewritten). Primarily for users that
> > don't commit at all, but just look at things [*1*].
>
> Ok. If you have a clean way to guarantee that "update" users won't
> commit, I think the above would sort of make sense and my earlier worries
> about (1) a user who wish he did not fetch and (2) a user who was doing
> something more complex and had conflicts already would go away.
Currently it's just:
test -z "$(git rev-list -1 $upstream..)"
As a "is a fast-forward" check, suggesting the user to use "git pull"
instead of "git update", if it is not. Maybe I should use "git
merge-base" there instead? Is that better? Not sure whether history
simplication might break the rev-list based test...
> If the sole target audience is "minor changes only, never committing"
> people, then I would even rescind my earlier suggestion on --abort; it
> should mean "remove the minor changes and get pristine copy of the
> upstream---the user will redo the minor changes to adjust to the updated
> upstream from scratch", to keep the end user experience simpler and
> clearer.
Hmhm... If the user can't resolve the conflict, but still keep those
changes, he might want to ask someone else for help. And then he might
want to present his changes to that other person, so I think allowing
the user to go back to the old commit with his changes on top is better.
Maybe "git update --drop" could do the "drop the user's changes", if the
user wants to do so. No support for going back is what's bad about "svn
update" (and, I guess, "git checkout --merge").
> I am undecided if it is a good thing to divide the userbase into two
> classes, "update" people and "work-commit-fetch-merge-resolve" people.
I expect that there are already two userbases. Developers in one
userbase and users that just want the latest code in the other. And
these users might have some uncommitted stuff (either self-made or
possibly found somewhere, or maybe a bit of both).
I just wonder what's easier/better: to cater to each one or trying to
unify them by trying to educate the one that actually doesn't care.
Björn
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Sitaram Chamarty @ 2009-10-19 8:43 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On Mon, Oct 19, 2009 at 2:02 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
> Hello,
>
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
That was the main reason I wrote gitolite
(http://github.com/sitaramc/gitolite), though now it does a heck of a
lot more than just that.
Scroll down a bit on that page for the README.
People have said pretty nice things about it on #git, and (subject to
being in India time zone and the day job and all) I make sure I help
out as much as I can. Email or #git, both are fine.
Being somewhat familiar with ssh and authkeys is good. Otherwise,
*please* be sure to read
http://sitaramc.github.com/0-installing/9-gitolite-basics.html for
background
^ permalink raw reply
* denying branch creation in a shared repository
From: Mohit Aron @ 2009-10-19 8:32 UTC (permalink / raw)
To: git
Hello,
I'm setting up a shared repository and I'd like to prevent users from
creating branches in it (they can of course create local branches in
their own clone of this repository). How can I accomplish this ? I
looked at 'git help config' and it seems I need something similar to
the parameter receive.denyDeletes - this prevents deletion of
branches.
- Mohit
^ permalink raw reply
* Re: Re: Unapplied patches reminder
From: Heiko Voigt @ 2009-10-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <7vbpk4i8ii.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 04:31:49PM -0700, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> > ...
> > From: Heiko Voigt <hvoigt@hvoigt.net>
> > Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> > Date: Wed, 23 Sep 2009 20:30:28 +0200
> > Message-ID: <20090923183023.GA85456@book.hvoigt.net>
> >
> > This is useful if you are using the testsuite with local changes that
> > include activated default hooks suitable for your teams installation.
>
> This may be useful when Heiko or somebody actually has changes that needs
> this fix, but otherwise was an unnecessary code churn during pre-release
> code freeze. I am reasonably sure that Heiko will include it in a series
> that requires this one.
>
> In other words, I am not against it per-se, but I would prefer to see
> patches that actually depends on this change at the same time. Otherwise
> this "is supposed to be no-op, and promises it will help in the future",
> and needs extra mental effort to validate the latter claim.
Well, currently we do not have any activated hooks. They are all sample.
And because the use scenarios for git are so diverse we will probably
never have any default hook activated.
But I imagine that if you are creating a default installation for any
team you will activate some. For an example take this patch:
http://thread.gmane.org/gmane.comp.version-control.git/110874
it is not in master because it was to specific but I have such a hook
activated. It does not allow you to commit on master which breaks the
testsuite.
So in my opinion we should not run the testsuite with hooks even though
the current defaults are all deactivated.
I am afraid that I will never be able to persuade everyone on the list
to not commit on master... ;)
cheers Heiko
P.S.: Just thinking of previous hooks, I might make it an option like
hooks.doNotCommitOnMaster. But still the hooks would be
deactivated.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091019064955.GB1457@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yep. I got comments from JSixt, but I never got around to re-rolling.
> Here it is, though still only lightly tested by me (happily, I have not
> had to touch CVS for a few years).
>
> -- >8 --
> Subject: [PATCH] cvsimport: fix relative argument filenames
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] describe: load refnames before calling describe()
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <4AD9F138.3080405@lsrfire.ath.cx>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] rebase -i: fix reword when using a terminal editor
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Björn Gustavsson
In-Reply-To: <1255674753-13949-1-git-send-email-bebarino@gmail.com>
Thanks, applied.
^ permalink raw reply
* Potentially dangerous behavior of git gc
From: Sergio Callegari @ 2009-10-19 8:04 UTC (permalink / raw)
To: git
Hi,
I encountered an issue with git gc.
Consider the following scenario. Repo A is using repo B as an alternate object
database through the .git/objects/info/alternates mechanism. B is at
/some_path/B. A has some references, including HEAD that are pointing at
objects that are in fact in the object database of B.
For some reasons, paths are modified on the machine, so that B gets moved at
/some_new_path/B.
Obviously A cannot find its objects anymore and its alternate info should be
updated.
Suppose that now one runs git gc on A.
Correctly git gc complains about the broken alternate link.
And then complains again as it cannot find some objects.
However, rather than trying to preserve the repo integrity, it then _removes_
all the references pointing to non existing objects.
With this when the alternate info of A is finally updated, A is broken, missing
many references and not having a head anymore.
Would it be better to have git gc not to take dangerous actions on potentially
problematic repos?
Thanks
Sergio
^ permalink raw reply
* What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: git
What's cooking in git.git (Oct 2009, #03; Mon, 19)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
--------------------------------------------------
[Graduated to "master"]
* jp/maint-send-email-fold (2009-10-08) 1 commit.
+ git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
* pv/maint-add-p-no-exclude (2009-10-10) 1 commit.
(merged to 'next' on 2009-10-11 at 0ff2e96)
+ git-add--interactive: never skip files included in index
* dk/blame-el (2009-09-29) 1 commit.
+ git-blame.el: Change how blame information is shown.
* jn/gitweb-patch (2009-10-09) 1 commit.
+ gitweb: Do not show 'patch' link for merge commits
* mr/instaweb-cgid (2009-09-26) 1 commit.
(merged to 'next' on 2009-10-11 at 99bcfaf)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit.
+ Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree).
* bg/rebase-reword (2009-10-07) 2 commits.
+ rebase-i: fix reword when using a terminal editor
+ Teach 'rebase -i' the command "reword"
* jp/fetch-tag-match (2009-09-17) 1 commit.
+ fetch: Speed up fetch by rewriting find_non_local_tags
* jn/gitweb-show-size (2009-09-07) 1 commit.
+ gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-10-11 at 7f34fb3)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
--------------------------------------------------
[New Topics]
* ak/bisect-reset-to-switch (2009-10-13) 1 commit.
- bisect reset: Allow resetting to any commit, not just a branch
* fc/doc-fast-forward (2009-10-11) 1 commit.
- user-manual: use 'fast-forward'
* gb/maint-gitweb-esc-param (2009-10-13) 1 commit.
(merged to 'next' on 2009-10-14 at 105f997)
+ gitweb: fix esc_param
(this branch is used by sb/gitweb-link-author.)
* jc/maint-1.6.3-graft-trailing-space (2009-10-14) 1 commit.
- info/grafts: allow trailing whitespaces at the end of line
* jc/strbuf-nested-expand (2009-10-18) 5 commits
- Teach --wrap to only indent without wrapping
- Add %[wrap(width,in1,in2)<<any-string>>%] implementation
- strbuf_nested_expand(): allow expansion to interrupt in the middle
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch uses js/log-rewrap.)
* jk/maint-cvsimport-pathname (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-19 at 77824f2)
+ cvsimport: fix relative argument filenames
* jn/show-normalized-refs (2009-10-12) 3 commits.
- check-ref-format: simplify --print implementation
- git check-ref-format --print
- Add tests for git check-ref-format
* sb/gitweb-link-author (2009-10-14) 1 commit.
- gitweb: linkify author/committer names with search
(this branch uses gb/maint-gitweb-esc-param.)
* jc/checkout-auto-track (2009-10-18) 3 commits
- git checkout --nodwim
- DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
- check_filename(): make verify_filename() callable without dying
--------------------------------------------------
[Stalled]
* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged in 1.6.5. If people want to replace this with improvements it
would be a good time to do so.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ejected from 'next' as fast-import folks still seem to be discussing with
how to proceed.
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits.
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper.
--------------------------------------------------
[Cooking]
* tr/stash-format (2009-10-16) 5 commits
. stash list: drop the default limit of 10 stashes
. stash list: use new %g formats instead of sed
. Introduce new pretty formats %g[sdD] for reflog information
. reflog-walk: refactor the branch@{num} formatting
. Refactor pretty_print_commit arguments into a struct
Expecting a re-roll.
* ks/precompute-completion (2009-10-05) 1 commit.
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
* sp/smart-http (2009-10-14) 17 commits
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions
* ef/msys-imap (2009-10-13) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
Is this good to go yet?
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* js/log-rewrap (2008-11-10) 2 commits
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch is used by jc/strbuf-nested-expand.)
* js/diff-verbose-submodule (2009-10-14) 4 commits.
- add tests for git diff --submodule-summary
- fix output for deleted submodules in git diff --submodule-summary
- fix indentation depth for git diff --submodule-summary
- Add the --submodule-summary option to the diff option family
There was an attempted re-roll and it looked very promising with a minor
fix-up, but I ran out of time to pick it up and unilaterally tweaking it.
Waiting for a response.
* jc/fix-tree-walk (2009-09-14) 10 commits.
- read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
This includes the fix to aggressive mode of three-way merge used by the
resolve strategy.
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Is this good for 'next' now?
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* ne/rev-cache (2009-09-07) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
This seems to break at least t6001 when merged to 'pu'.
* jg/log-format-body-indent (2009-09-19) 1 commit.
. git-log --format: Add %B tag with %B(x) option
Ejected from 'pu' as this is merely a short-hand for %[wrap(0,x,x)%b%].
^ permalink raw reply
* git fsck not identifying corrupted packs
From: Sergio Callegari @ 2009-10-19 7:56 UTC (permalink / raw)
To: git
Hi,
I have a pack that contains a corrupted object.
It is an old corrupted repo that I have conserved.
As expected, git gc cries out loud about it.
It indicates an inflate error (data stream error with incorrect data check),
and then the impossibility to read an object from a certain offset in the pack.
However, git fsck does not complain at all about the repo.
I guess that for speed reasons, git fsck does not try to inflate the objects.
Is there a means to have fsck to a truly full check on the sanity of a repo?
This both on git 1.6.5.1 and 1.6.4.2.
Thanks
Sergio Callegari
^ 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