* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Nicolas Pitre @ 2008-12-17 16:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jean-Luc Herren, jidanni, git
In-Reply-To: <20081217154407.GZ32487@spearce.org>
On Wed, 17 Dec 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > The fact is, fundamentally, we don't know how many bytes to push when
> > generating a pack to answer the clone request. Sometimes we _could_ but
> > not always. It is therefore better to be consistent and let people know
> > that there is simply no ETA.
>
> Hmm.
>
> What if on an initial clone (no "have" lines received) we sum up
> the sizes of the *.pack and all of the loose objects and sent
> that as an initial size estimate. Its going to be the upper bound
> of the final pack that we send. At worst it over-estimates on the
> size and download finishes faster.
It is a kludge. It makes the system imprecise for little benefit. Once
you start adding kludges like that into your system, people will always
ask for more kludges, and in the end your system isn't as reliable. We
all know about some other operating system which was designed like that.
I personally don't want to go there.
> Yea, a single stray binary of some *.mpg or *.iso accidentally
> added and then removed (and now unreachable) will vastly inflate
> the numbers. In which case the repository owner will be encouraged
> to prune when people won't clone his estimated 8 GiB download,
> which is actually only 1 MiB.
And I consider any system doing such thing completely stupid. Either
you consistently know the information or you don't. When you don't, it
is best to not create expectations for the user. And so far I think
that 99.9% of git users are just fine with the progress display we
currently provide.
Nicolas
^ permalink raw reply
* Re: [EGIT PATCH 1/2] Revert "Fix commit id in egit test T0001_ConnectProviderOperationTest"
From: Shawn O. Pearce @ 2008-12-17 16:09 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229472439-24104-2-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> This reverts commit 61133091d5f22398828b350ff772165e9945db8a.
>
> Bisect says this is the commit that failed, which is odd. Bad QA.
Hmmph. This revert fails here.
> diff --git a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
> index 0ce2d7f..aae1ef4 100644
> --- a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
> +++ b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
> @@ -99,8 +99,9 @@ assertTrue("tree missing", new File(gitDir,
> "objects/08/ccc3d91a14d337a45f355d3d63bd97fd5e4db9").exists());
> assertTrue("tree missing", new File(gitDir,
> "objects/9d/aeec817090098f05eeca858e3a552d78b0a346").exists());
> +
> assertTrue("commit missing", new File(gitDir,
> - "objects/09/6f1a84091b90b6d9fb12f95848da69496305c1").exists());
> + "objects/45/df73fd9abbc2c61620c036948b1157e4d21253").exists());
Debugging this test shows that the commit we created in the test
is actually:
--
$ git cat-file commit 4c1bc1435f93c9409c93db5239e111271a8ccf55
tree 9daeec817090098f05eeca858e3a552d78b0a346
author J. Git <j.git@egit.org> 60876086400 +0100
committer J. Git <j.git@egit.org> 60876086400 +0100
testNewUnsharedFile
Junit tests
--
Which has me starting to wonder, what the heck is different
between systems that is being reflected in this commit object?
The only thing I can think of is the timestamp we are creating by
the deprecated Date constructor call back on line 82. Perhaps
on different JVMs it is using different values for the hh:mm:ss
parts of the timestamp value?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Shawn O. Pearce @ 2008-12-17 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812142311360.25197@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> In dc871831(Only use GIT_CONFIG in "git config", not other programs),
> GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
> /etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
>
> You might want to hold off on that, as git-gui is supposed to be
> less tightly coupled to git.git than, say, git-svn.
>
> The commit removing support for GIT_CONFIG_LOCAL is from Mon Jun
> 30 03:37:47 2008 -0400...
Nah, that's in Git 1.6.0. This block of code is only useful on
Windows, where most people are probably running a more msysgit
style system than some random mashup of Git and git-gui versions.
Plus, wasn't there just some discussion about how this warning
is perhaps harmful to the user because it doesn't really help
her to resolve the problem?
I applied it anyway. Its quite unlikely anyone runs git-gui on
Windows with GIT_CONFIG_LOCAL in their environment.
--
Shawn.
^ permalink raw reply
* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Shawn O. Pearce @ 2008-12-17 15:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jean-Luc Herren, jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812160039180.30035@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 16 Dec 2008, Jean-Luc Herren wrote:
> > jidanni@jidanni.org wrote:
> > > JH> So maybe what you really want is an ETA display during the cloning
> > > JH> process? Sounds like a good idea to me.
>
> And then you'll end up being the unlucky bastard to be the first to
> clones the new latest revision of a repository, and ETA won't be
> available, and you'll complain about the fact that sometimes it is there
> and sometimes it is not.
>
> The fact is, fundamentally, we don't know how many bytes to push when
> generating a pack to answer the clone request. Sometimes we _could_ but
> not always. It is therefore better to be consistent and let people know
> that there is simply no ETA.
Hmm.
What if on an initial clone (no "have" lines received) we sum up
the sizes of the *.pack and all of the loose objects and sent
that as an initial size estimate. Its going to be the upper bound
of the final pack that we send. At worst it over-estimates on the
size and download finishes faster.
I'm willing to bet that most of the "big" repositories out there
don't have a lot of garbage in them. Linus' kernel repository
doesn't rewind, so he has 0 garbage. Anyone cloning from him would
get a reasonable estimate. Likewise with a Gentoo/KDE/WebKit/gcc
sort of giant tree most of that is in a huge historical pack.
That one pack file alone is completely reachable and dominates the
transfer size.
On smaller trees where people may have a lot of rebase garbage or
everything is loose the estimate will be quite a bit above what we
transfer, but how much so that it matters?
Yea, a single stray binary of some *.mpg or *.iso accidentally
added and then removed (and now unreachable) will vastly inflate
the numbers. In which case the repository owner will be encouraged
to prune when people won't clone his estimated 8 GiB download,
which is actually only 1 MiB.
--
Shawn.
^ permalink raw reply
* Re: Strange untracked file behaviour
From: Miklos Vajna @ 2008-12-17 14:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812170605300.14632@racer>
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
On Wed, Dec 17, 2008 at 06:09:16AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I just spent three hours narrowing it down to this test case (but now I
> have to catch 3 hours of sleep):
Thank you very much! :-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: fix description for enabling hooks
From: Miklos Vajna @ 2008-12-17 14:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <4948ADE8.2050804@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Wed, Dec 17, 2008 at 08:44:40AM +0100, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > This is true, but having the executable bit is necessary as well. I
> > think it would be better to just append this requirement instead of
> > replacing the old one with this.
>
> Markus's proposed new wording is correct because the .sample hooks *are*
> already executable.
I thought about the following situation: The user reads the
documentation while working in an older repo (initialized a few versions
ago). S/he sees that the .sample suffix is already missing, so s/he
assumes that the hook is already active. Which is not true, because the
+x bit is missing.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] doc/git-reset: add reference to git-stash
From: Miklos Vajna @ 2008-12-17 14:33 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200812170949.42753.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Wed, Dec 17, 2008 at 09:49:42AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> Miklos Vajna, 17.12.2008:
> > On Wed, Dec 17, 2008 at 03:59:36AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> > > ++
> > > +See also linkgit:git-stash[1].
> >
> > Manpages have a dedicated "SEE-ALSO" section. What about this?
>
> That's only appropriate if the commands are generally related to each
> other, which isn't true for git-reset and git-stash.
Ah, OK.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: Pete Wyckoff @ 2008-12-17 14:04 UTC (permalink / raw)
To: John Chapman; +Cc: Git Mailing List
In-Reply-To: <1229377952.18839.11.camel@therock.nsw.bigpond.net.au>
thestar@fussycoder.id.au wrote on Tue, 16 Dec 2008 08:52 +1100:
> On Mon, 2008-12-15 at 14:30 -0500, Pete Wyckoff wrote:
> Modifying the on_branch code is the right place to do what you want,
> however I was hoping that specifying your 'interesting' branches by
> regexp would be sufficient? All those places that do not get matched
> are effectively ignored and do not become part of the git repo.
[..]
> Do you need to use a client spec here, or is it possible to just use
> regexps? I'd like to try and avoid the need to parse the clientspec,
> that's all.
There is code to parse the client spec in git-p4, and I did hack it
to put the various depot contents in the git tree according to where
the spec says they go. Not a big hassle, and will do the same for
git-p4c if needed. (Not clean enough or tested with non-client-spec
configs to submit upstream for git-p4 though.)
> The script does try to import the full history, however it starts that
> history only at the most recent change, which is defined as a tag.
>
> Thus, if your main branch is 'trunk', then you should be able to
> manually import your changes, tag it as 'trunk/102388', to indicate
> that's p4's revision 102388 of trunk, and the script should then begin
> checking out changeset 102389. I haven't had a chance to test that
> theory yet, but it should work.
Okay, this is interesting. Would like to pursue that approach.
Except for the "manually import" part. Maybe bits of git-p4's
full-checkout model could be borrowed here? Anyway, will take a
look when you're ready.
-- Pete
^ permalink raw reply
* git clone rsync:// broken
From: demerphq @ 2008-12-17 13:45 UTC (permalink / raw)
To: git
Hi,
Summary:
There seems to be a problem with cloning via rsync in that a corrupted
packed-refs file is/maybe transmitted, and the HEAD file is not
correctly transfered.
Detail:
I've been encountering some problems getting things set up so people
can clone using rsync.
The object repository seems to transfer fine, in that the resulting
directory is the right size approximately, but the cloning fails with
the error message
warning: remote HEAD refers to nonexistent ref, unable to checkout
Inspecting the .git/HEAD file it points at refs/heads/master, which
doesn't exist as for historical reasons our master is called 'blead'.
Looking at the packed-refs file there was a duplicate incorrect entry
in the file. Which was remedied by executing
git pack-refs --all
on the source repository which improves the situation somewhat, as
after a clone fails we were able do a
git checkout -b blead origin/blead
and things seem ok. But the clone still fails as the HEAD is not correct.
If we use git://, http://, or ssh:// protocols to clone everything
transfers fine.
I checked in the #git channel and there were a number of comments by
people that helped me investigate:
because git transport via rsync seems to assume packed-refs is sorted
- which it maybe wasnt (cant check now anymore).
That caused the failure like "fatal: Duplicated ref, and SHA1s don't
match: refs/remotes/origin/p4/maint-5.10/perl"
The remaining problem is, that HEAD seems not get fetched at all
And I dont see how HEAD should get fetched in the transport.c code
The other dumb protocol aka http explicitly gets it
So i would bugreport this
For anyone wanting to try the repo is public at:
perl5.git.perl.org/perl, which works fine with http://, and git://,
but currently rsync:// is broken.
This isnt the official perl repository yet. We were planning to go
live with it tomorrow. Meaning if you do clone it please be aware that
we might replace the repository with a complete new version before it
goes live.
cheers,
Yves
ps: Im not on list, so please cc me in any replies.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Emily Ren @ 2008-12-17 13:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0812170447h7546cbf0v3151166668ad1248@mail.gmail.com>
Sverre, Johannes,
Thank you very much for sharing your good idea ! Yes, maintaining two
separate rep maybe best.
Johannes,
Does your second suggestion mean that I need to write a script and use
git hook to enable it ?
Thanks,
Emily
On Wed, Dec 17, 2008 at 8:47 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> [It is common not to top-post on this list :)]
>
> On Wed, Dec 17, 2008 at 13:35, Emily Ren <lingyan.ren@gmail.com> wrote:
>> As far as I know, gitosis can control someone readonly/writable to
>> some repo, it has no access control on branch/tag level. Am I right ?
>
> Ah, sorry, I meant to control access to different repo's for different groups.
>
>> I'll look at github and gitorious, are they free software ?
>
> IIRC gitorious is open source, but I just checked and I don't see any
> access control there; which leaves github, which is not free software
> I'm afraid.
>
> I think, as Johannes said, keeping two seperate repo's and using some
> form of access control on those would be best.
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Sverre Rabbelier @ 2008-12-17 12:47 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0812170435t32fce496q41f825c01ee7045c@mail.gmail.com>
[It is common not to top-post on this list :)]
On Wed, Dec 17, 2008 at 13:35, Emily Ren <lingyan.ren@gmail.com> wrote:
> As far as I know, gitosis can control someone readonly/writable to
> some repo, it has no access control on branch/tag level. Am I right ?
Ah, sorry, I meant to control access to different repo's for different groups.
> I'll look at github and gitorious, are they free software ?
IIRC gitorious is open source, but I just checked and I don't see any
access control there; which leaves github, which is not free software
I'm afraid.
I think, as Johannes said, keeping two seperate repo's and using some
form of access control on those would be best.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Emily Ren @ 2008-12-17 12:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0812170353y5d78f03ao1c0619c9bd68f309@mail.gmail.com>
Sverre,
Thank you for your information !
As far as I know, gitosis can control someone readonly/writable to
some repo, it has no access control on branch/tag level. Am I right ?
I'll look at github and gitorious, are they free software ?
Thanks,
Emily
On Wed, Dec 17, 2008 at 7:53 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 10:15, Emily Ren <lingyan.ren@gmail.com> wrote:
>> I want some group can pull these branches or tags from my repo, while
>> other's can't, Need I maintain two repositories ?
>
> I think gitosis should be able to do that? Otherwise you could look
> into hosting sites like github or gitorious, I think they have at
> least some form of access control, yes?
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <200812171316.21531.thomas.jarosch@intra2net.com>
Thnks!
In fact, the first line was enough!
git config --global color.diff auto
Mark
On Wed, Dec 17, 2008 at 2:15 PM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Wednesday, 17. December 2008 13:13:34 Mark Ryden wrote:
> [colors in diff]
>> What do you mean ?
>> where ? how ?
>
> This should do the trick:
>
> git config --global color.diff auto
> git config --global color.status auto
> git config --global color.branch auto
>
> Thomas
>
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Johannes Schindelin @ 2008-12-17 12:25 UTC (permalink / raw)
To: Emily Ren; +Cc: Junio C Hamano, git
In-Reply-To: <856bfe0e0812170115p73d72495ve81046127e68c281@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Emily Ren wrote:
> I want some group can pull these branches or tags from my repo, while
> other's can't, Need I maintain two repositories ?
Either that (that would be the easy method, and also the proper one, since
people would not even know what you hide), but you could patch
upload-pack so that it runs a hook with the rev-list arguments in
do_rev_list() in upload-pack.c, and die() if the hook returns non-zero.
Ciao,
Dscho
^ permalink raw reply
* Re: white spaces in a patch
From: Jeff King @ 2008-12-17 12:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Mark Ryden, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <200812171316.21531.thomas.jarosch@intra2net.com>
On Wed, Dec 17, 2008 at 01:15:56PM +0100, Thomas Jarosch wrote:
> This should do the trick:
>
> git config --global color.diff auto
> git config --global color.status auto
> git config --global color.branch auto
These days we have
git config --global color.ui auto
-Peff
^ permalink raw reply
* Re: Git Notes idea.
From: Petr Baudis @ 2008-12-17 12:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Govind Salinas, Jeff King, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812170003540.14632@racer>
On Wed, Dec 17, 2008 at 12:48:02AM +0100, Johannes Schindelin wrote:
> Again, do not limit your design by your expectations. People already talk
> about having cover letters for their patch series as notes, and Pasky
> seems to discuss tracking explicit renames with notes when he does not
> play Go, instead of maintaining repo.or.cz and git.or.cz.
I don't really play Go that much anymore! ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: white spaces in a patch
From: Sverre Rabbelier @ 2008-12-17 12:13 UTC (permalink / raw)
To: Mark Ryden; +Cc: Junio C Hamano, git
In-Reply-To: <dac45060812170344u368ffd7fx4e86253b4a13ffc7@mail.gmail.com>
On Wed, Dec 17, 2008 at 12:44, Mark Ryden <markryde@gmail.com> wrote:
> Any ideas ? does "git diff" does highlight for anyone ?
Do you have color on?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: white spaces in a patch
From: Sverre Rabbelier @ 2008-12-17 12:16 UTC (permalink / raw)
To: Mark Ryden; +Cc: Junio C Hamano, git
In-Reply-To: <dac45060812170413w7c8cffaifa1a0f3b649474e4@mail.gmail.com>
On Wed, Dec 17, 2008 at 13:13, Mark Ryden <markryde@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 2:13 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Do you have color on?
$ git config color.diff true
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: white spaces in a patch
From: Thomas Jarosch @ 2008-12-17 12:15 UTC (permalink / raw)
To: Mark Ryden; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <dac45060812170413w7c8cffaifa1a0f3b649474e4@mail.gmail.com>
On Wednesday, 17. December 2008 13:13:34 Mark Ryden wrote:
[colors in diff]
> What do you mean ?
> where ? how ?
This should do the trick:
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
Thomas
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0812170413j5ed2d9eak89df8517bc91c5fd@mail.gmail.com>
What do you mean ?
where ? how ?
Mark
On Wed, Dec 17, 2008 at 2:13 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 12:44, Mark Ryden <markryde@gmail.com> wrote:
>> Any ideas ? does "git diff" does highlight for anyone ?
>
> Do you have color on?
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Johannes Schindelin @ 2008-12-17 12:12 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812170103w1007cf4fs1e83e506c6dd909@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Emily Ren wrote:
> I created a repository, and I don't want somebody to pull some branch or
> tag from my repository with git protocol. How can I do ?
Yes, it is easy: do not push it into that repository.
If you already did, delete it in that repository.
Ciao,
Dscho
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0812171307460.28560@intel-tinevez-2-302>
Hello,
Thanks!
"git diff --check" indeed tells about trailing whitespace
Mark
On Wed, Dec 17, 2008 at 2:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 16 Dec 2008, Junio C Hamano wrote:
>
>> "Mark Ryden" <markryde@gmail.com> writes:
>>
>> > 2) Is there a way to get some messages about that there are white
>> > spaces when creating a git patch?
>>
>> Doesn't "git diff" highlight whitespace errors? That way, you can catch
>> errors before you make a commit that has them.
>
> Not to mention "git diff --check", which should catch them, too.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: white spaces in a patch
From: Johannes Schindelin @ 2008-12-17 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Ryden, git
In-Reply-To: <7vej07p84i.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 16 Dec 2008, Junio C Hamano wrote:
> "Mark Ryden" <markryde@gmail.com> writes:
>
> > 2) Is there a way to get some messages about that there are white
> > spaces when creating a git patch?
>
> Doesn't "git diff" highlight whitespace errors? That way, you can catch
> errors before you make a commit that has them.
Not to mention "git diff --check", which should catch them, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Sverre Rabbelier @ 2008-12-17 11:53 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0812170115p73d72495ve81046127e68c281@mail.gmail.com>
On Wed, Dec 17, 2008 at 10:15, Emily Ren <lingyan.ren@gmail.com> wrote:
> I want some group can pull these branches or tags from my repo, while
> other's can't, Need I maintain two repositories ?
I think gitosis should be able to do that? Otherwise you could look
into hosting sites like github or gitorious, I think they have at
least some form of access control, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] gitk: force focus to main window
From: Johannes Sixt @ 2008-12-17 11:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Johannes Schindelin
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On msysGit, the focus is first on the (Tk) console. This console is then
hidden, but keeps the focus. Work around that by forcing the focus onto
the gitk window.
This fixes issue 14.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
gitk-git/gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 1c8d98e..b3d8219 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10898,4 +10898,5 @@ if {[info exists permviews]} {
addviewmenu $n
}
}
+focus -force .
getcommits {}
--
1.6.1.rc3.980.ga0bb
^ permalink raw reply related
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