* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Jeff King @ 2008-07-24 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
I agree there are a lot of issues. I am just thinking of the person who
said they had a >100G repository. But I am also not volunteering to do
it, so I will let somebody who really cares about it try to defend the
idea.
-Peff
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Geoff Russell
In-Reply-To: <alpine.DEB.1.00.0807241506340.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
>
> > > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > When GIT_DIR is not set, cwd is used to determine where .git is. If
> > > > core.worktree is set, setup_git_directory() needs to jump back to
> > > > the original cwd in order to calculate worktree, this leads to
> > > > incorrect .git location later in setup_work_tree().
> > >
> > > I do not understand. core.worktree is either absolute, in which case
> > > there is no problem. Or it is relative to where the config lives, no?
> >
> > The problem is GIT_DIR is not absolute in this case. So cwd must stay
> > where git dir is until it is absolute-ized by setup_work_tree().
>
>
> I do not see GIT_DIR being set in your test case at all.
>
> I do not see how get_git_work_tree() ro get_relative_cwd() should ever be
> allowed to chdir().
>
> _If_ they were (which I strongly doubt), they should chdir() back
> themselves.
>
> I now wasted easily 30 minutes just trying to make sense of your patch and
> your response. And I am still puzzled.
>
> Your commit message was of no help.
Alright, let's look at the code.
1. cwd is moved to toplevel working directory by setup_git_directory_gently()
2. setup_git_env() by default will set git_dir variable as ".git" as
part of check_repository_format_gently()
3. now in setup_git_directory() finds out core.worktree, it chdir()
to get relative prefix
4. setup_work_tree() sees that git_dir is not absolute path, it makes
git_dir absolute
If in step 3, it does not chdir(), step 4 will be right. In this case,
step 3 does chdir() and not going back, access to git repository will
fail as Geoff Russell discovered.
--
Duy
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 18:42 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080724175714.GZ2925@dpotapov.dyndns.org>
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> >
> > Is there some channel that I have forgot about?
>
> If the start of this survey can be timed to release 1.6.0 then the
> announce about Git 1.6.0 release may also contain reference to that
> survey, and because release announcements are usually widely distributed
> by online magazines such as LinuxToday and LWN, anyone who is interested
> in Git will learn about this survey too.
You can send a story to LWN with two weeks notice; IIRC Git user's
Survey 2007 was announced in LWN around the middle of its duration.
I don't know about LinuxToday / Linux.com.
IIRC tentative date for 1.6.0 release is around August 10. It is
quite a bit of time from now. On the other hand that mean lot
of time to prepare questions, and to put survey on the web.
P.S. <tongue in cheek> are there enough of us to Digg / Mixx / Reddit
Git User's Survey 2008 announcement? ;-P </tongue in cheek>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
On 7/25/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 Jul 2008, Jeff King wrote:
>
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
>
> - security issues (you'd need to open the git protocol to give you
> something else than a ref, _including_ refs that were deleted)
>
> - performance issues (the server would have to do a lot more, faking
> commits, or in the alternative serving a gazillion more sessions if the
> client does the reconstruction)
>
> ... and I am sure there are tons more issues.
Widen checkout won't work and probably more.
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724171519.GA21043@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Wed, Jul 23, 2008 at 09:55:35PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
>
> The commit message is a bit lacking...what config are we interested in?
core.sparsecheckout, but I will probably stay away from config.
--
Duy
^ permalink raw reply
* Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724171952.GB21043@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Wed, Jul 23, 2008 at 09:57:18PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > + if (option_sparse_prefix) {
> > + git_config_set("core.sparsecheckout", option_sparse_prefix);
> > + set_sparse_prefix(option_sparse_prefix);
> > + }
> > +
>
>
> As a user, I would expect "sparse clone" to also be sparse on the
> fetching. That is, to not even bother fetching tree objects that we are
> not going to check out. But that is a whole other can of worms from
> local sparseness, so I think it is worth saving for a different series.
>
> So instead I would suggest that this be mentioned in the documentation
> for --path, but there doesn't seem to be any.
Thanks. Will mention it when I write documentation for this.
--
Duy
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Lachele Foley (Lists) @ 2008-07-24 18:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jon Loeliger, git
In-Reply-To: <200807242018.27663.jnareb@gmail.com>
>> > 01. What country are you in?
>> > 02. What is your preferred non-programming language?
>> > (or) What is the language you want computer communicate with you?
>>
>> How about: What is your preferred natural language?
>
> Perhaps it is a better formulation. I am not native English speaker.
> (But so would be some people who would answer this survey).
According to Wikipedia
(http://en.wikipedia.org/wiki/Natural_language), "natural language"
could include, for example, bee dances. "...a language that is
spoken, written, or signed by animals for general-purpose
communication..." And, it might also exclude constructed languages
like Esperanto and Klingon. How about:
02. What language do you prefer to use when communicating with people?
In case there are, for example, any Klingons, sentient machines, etc.,
in the audience, the sentence does not assume the answerer is human...
:-) It's a tricky question to write.
I'm a total newbie here, by the way.
01. USA
02. Probably best I stick to English, but I'm willing to negotiate.
06. Not sure yet.
09. Last month. I think.
--
:-) Lachele
Lachele Foley
CCRC/UGA
^ permalink raw reply
* git reset musings
From: Sverre Rabbelier @ 2008-07-24 18:51 UTC (permalink / raw)
To: Git Mailinglist
Heya,
After doing "git reset" you always get a whole bunch of lines saying
"foo: locally modified". Now I have a "OMG?!" reaction to that every
so often, where for a brief moment I think something went wrong. A bit
silly surely, but I suspect that some other users (especially those
new to git) have had similar reactions. Maybe it would be worth
letting the user know what's going on? E.g., before suddenly spitting
out an un-asked-for status report, let the user know that a status
report is following? Why not just do a 'git status' instead of this
we-hacked-up-a-quick-status-listing thing?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Sverre Rabbelier @ 2008-07-24 18:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git
In-Reply-To: <fcaeb9bf0807241145y16bb5f94q9f7e3c09c3184782@mail.gmail.com>
On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
Something went wrong replying here possibly? Or is it just me who is
receiving empty messages? (At least the 3rd empty mail I see.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Petr Baudis @ 2008-07-24 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
Hi,
On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Jeff King wrote:
>
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
>
> - security issues (you'd need to open the git protocol to give you
> something else than a ref, _including_ refs that were deleted)
>
> - performance issues (the server would have to do a lot more, faking
> commits, or in the alternative serving a gazillion more sessions if the
> client does the reconstruction)
I don't follow how these two issues arise, if the server will do the
pruning for you. It will just skip entering some tree objects when doing
object traversal; why opening the git protocol or faking commits? This
would be a simple extra capability in the protocol.
One question is what to do with delta chains including unwanted
objects, but I think that given the objects' associativity for delta
chains, this shouldn't be huge practical issues and it could be
affordable in principle to include even unwanted objects.
> ... and I am sure there are tons more issues.
I do agree on this. :-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Jeff King @ 2008-07-24 18:58 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807241145y16bb5f94q9f7e3c09c3184782@mail.gmail.com>
On Fri, Jul 25, 2008 at 01:45:58AM +0700, Nguyen Thai Ngoc Duy wrote:
> > The commit message is a bit lacking...what config are we interested in?
>
> core.sparsecheckout, but I will probably stay away from config.
Right, I kind of guessed that from reading the rest of the series. But
that sort of "why" really should go into the commit message.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 18:59 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Schindelin, git
In-Reply-To: <32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com>
On 7/24/08, Avery Pennarun <apenwarr@gmail.com> wrote:
> On 7/24/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > OK. I am lost here. I do not know how putting sparse prefix and index
> > together could fix "it" (I think you meant the index guarding).
>
> [snip]
>
> The information required to do a checkout is in the index. And
> "sparse checkout" is all about checking out :)
That was better Dscho's questions ;) Thanks for the enlightenment.
--
Duy
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-24 19:01 UTC (permalink / raw)
To: Petr Baudis
Cc: Johannes Schindelin, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <20080724185332.GQ32184@machine.or.cz>
On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> I don't follow how these two issues arise, if the server will do the
> pruning for you. It will just skip entering some tree objects when doing
> object traversal; why opening the git protocol or faking commits? This
> would be a simple extra capability in the protocol.
Wouldn't that be as simple as passing a pathspec to git-rev-list? Not
a lot of overhead there I reckon.
> One question is what to do with delta chains including unwanted
> objects, but I think that given the objects' associativity for delta
> chains, this shouldn't be huge practical issues and it could be
> affordable in principle to include even unwanted objects.
Just keep them? What we're doing here is trying to optimize in the
case that someone has a sparse checkout, nothing bad will happen if
they get too many info surely? (Save for them not getting as much
improvement as would have been possible would the pack have been
created differently.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 19:03 UTC (permalink / raw)
To: sverre; +Cc: Jeff King, git
In-Reply-To: <bd6139dc0807241153v5055e922p69a176b5b706f98e@mail.gmail.com>
On 7/25/08, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> >
>
> Something went wrong replying here possibly? Or is it just me who is
> receiving empty messages? (At least the 3rd empty mail I see.)
I blame gmail MTA or my name's having non-ascii chars in it. Combining
those two, it produces base64-encoded messages, which are usually
refused by vger.
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Nguyen Thai Ngoc Duy @ 2008-07-24 19:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080724185844.GC21186@sigill.intra.peff.net>
On 7/25/08, Jeff King <peff@peff.net> wrote:
> On Fri, Jul 25, 2008 at 01:45:58AM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > > The commit message is a bit lacking...what config are we interested in?
> >
> > core.sparsecheckout, but I will probably stay away from config.
>
>
> Right, I kind of guessed that from reading the rest of the series. But
> that sort of "why" really should go into the commit message.
There was "why" in the commit before but I wanted to make the first
two patches independent to this series. Turns out bad, I think :)
--
Duy
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Sverre Rabbelier @ 2008-07-24 19:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git
In-Reply-To: <fcaeb9bf0807241203yd57e675j964594c501ce59a2@mail.gmail.com>
On Thu, Jul 24, 2008 at 9:03 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 7/25/08, Sverre Rabbelier <alturin@gmail.com> wrote:
>> On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> >
>>
>> Something went wrong replying here possibly? Or is it just me who is
>> receiving empty messages? (At least the 3rd empty mail I see.)
>
> I blame gmail MTA or my name's having non-ascii chars in it. Combining
> those two, it produces base64-encoded messages, which are usually
> refused by vger.
Curiously enough, in the first mail there -are- non-asci characters in
your name, in the 'empty' mail there are non, instead the 'letter
decorations' were removed.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Jay Soffian @ 2008-07-24 19:16 UTC (permalink / raw)
To: sverre; +Cc: Nguyen Thai Ngoc Duy, Jeff King, git
In-Reply-To: <bd6139dc0807241153v5055e922p69a176b5b706f98e@mail.gmail.com>
On Thu, Jul 24, 2008 at 2:53 PM, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 24, 2008 at 8:45 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>
>
> Something went wrong replying here possibly? Or is it just me who is
> receiving empty messages? (At least the 3rd empty mail I see.)
Here's what's going on.
1. Gmail will often send messages as base64 encoded, inline. i.e.:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline
2. Majordomo is dumb dumb dumb and adds the standard list footer to
the message. It should probably either not add the footer to such
messages, or it should do it correctly by base64 decoding them, adding
the footer, then re-encoding. Anyway, what it sends out is:
[... prior base64 encoded lines elided ...]
b3V0LCBidXQgSSB3aWxsIHByb2JhYmx5IHN0YXkgYXdheSBmcm9tIGNvbmZpZy4KCi0tIApEdXkK
--
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
3. Gmail is dumb dumb dumb and cannot decode such "corrupted"
messages. They display as completely blank. If you go to gmane you can
see the message is fine. (I think gmane strips the majordomo added
footer.)
I've filed a bug against gmail multiple times about this. No idea if
they'll ever fix it.
I also sent an email to git-owner@vger.kernel.org (which I think was
/dev/null'ed) offering to patch Majordomo, but got no reply.
I wonder if such a mailing list footer is useful in the first place.
Perhaps it could just be disabled.
Anyway, my offer to "fix" majordomo still stands. Perhaps someone
knows who I should contact at vger.kernel.org to find out whether
they're willing to accept a patch.
j.
^ permalink raw reply
* Re: [StGit PATCH] Fixed default install location
From: Karl Hasselström @ 2008-07-24 19:45 UTC (permalink / raw)
To: Daniel White; +Cc: Catalin Marinas, git
In-Reply-To: <20080724202031.55dec8e8@whitehouse.id.au>
On 2008-07-24 20:20:31 +1000, Daniel White wrote:
> Originally broken by addition of Debian package support.
>
> Signed-off-by: Daniel White <daniel@whitehouse.id.au>
> ---
>
> The default installation direction is actually /usr at present
> despite what 'INSTALL' says.
>
> The 'debian/rules' makefile specifies the prefix as /usr so doesn't
> seem to depend on this. I've tested the resulting debian package and
> everything is still installed correctly under /usr.
Looks correct to me; I'll queue it up in kha/stable. Catalin, do you
have any issues with it?
Those extra comments should have been part of the commit message,
though. I'll fix that.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-24 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4l37vz7.fsf@gitster.siamese.dyndns.org>
On Donnerstag, 24. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > It also fixes 'make install' of git-gui as well (sigh!) by not exporting
> > gitexecdir - assuming that Shawn applies the git-gui patch.
>
> Yeah, this seems to break the install quite badly without git-gui patch.
If you squash this in, we don't need the git-gui patch.
-- Hannes
diff --git a/Makefile b/Makefile
index aab23a2..904150e 100644
--- a/Makefile
+++ b/Makefile
@@ -1344,7 +1344,7 @@ install: all
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
$(MAKE) -C gitk-git install
- $(MAKE) -C git-gui install
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' install
endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
$(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
^ permalink raw reply related
* git rebase to move a batch of patches onto the current branch
From: Avery Pennarun @ 2008-07-24 19:57 UTC (permalink / raw)
To: Git Mailing List
Hi,
I often find myself being on a branch and wanting to do the equivalent
of a series of cherry-picks from another branch into the current one.
Unfortunately, "git cherry-pick" only does one patch at a time (which
is very tedious), and "git rebase", which is much less tedious to use,
seems to specializing in applying your current branch on top of
another branch, not the other way around.
Currently I do something like this:
git checkout -b tmp branch_with_interesting_stuff~5
git rebase --onto mybranch branch_with_interesting_stuff~15
git branch -d mybranch
git branch -m tmp mybranch
But it seems a little complex when what I *really* want to type is
something like:
git cherry-pick
branch_with_interesting_stuff~15..branch_with_interesting_stuff~5
and have it give me a rebase-style UI in case of conflicts, etc. And
of course, even more bonus points if I can get "rebase -i"
functionality.
Am I missing an obvious syntax option here or is this not something
normal people want to do?
I see that the second option to rebase sounds almost right:
If <branch> is specified, git-rebase will perform an automatic git
checkout <branch> before doing anything else. Otherwise it remains
on the current branch.
So I could perhaps do this:
git rebase --onto mybranch branch_with_interesting_stuff~15 \
branch_with_interesting_stuff
But it sounds like that would rewrite branch_with_interesting_stuff
instead of mybranch.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Michele Ballabio @ 2008-07-24 20:07 UTC (permalink / raw)
To: Olivier Marin; +Cc: git, gitster
In-Reply-To: <4888AAB2.5050007@free.fr>
On Thursday 24 July 2008, Olivier Marin wrote:
> Michele Ballabio a écrit :
> >
> > + const struct option options[] = {
> > + OPT_STRING(0, "template", &template_dir, "dir",
> > + "directory from which templates will be used"),
>
> Perhaps "path", "path to the template repository" to stay consistent with clone.
Ok.
> > + OPT_BOOLEAN(0, "bare", &bare, "set up a bare repo"),
>
> s/set up/setup/ and s/repo/repository/?
I think "set up a bare repository" will be fine.
> > + { OPTION_CALLBACK, 0, "shared", &shared_repository,
> > + "type", "type of shared repository",
>
> What about "permissions", "setup a shared repository"?
Ok, but with s/setup/set up/.
> > + PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
>
> Are you sure the default value is really used here?
Yes. Perhaps I don't understand your question. Can you explain what you mean?
> Also, perhaps we can play it safer by avoiding changing "share_repository"
> directly.
>
> $ git init -> shared_repository == PERM_UMASK
> $ git init --shared --no-shared -> shared_repository == 0
>
> It works because PERM_UMASK == 0, but it is a side effect. Don't you think?
Would you like this better, with PARSE_OPT_NONEG?
+ { OPTION_CALLBACK, 0, "shared", &shared_repository,
+ "permissions", "set up a shared repository",
+ PARSE_OPT_OPTARG | PARSE_OPT_NONEG, parse_opt_shared_cb, PERM_GROUP },
Or do you prefer changing the callback like this:
+static int parse_opt_shared_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ *(int *)(opt->value) = unset ? PERM_UMASK : git_config_perm("arg", arg);
+ return 0;
+}
> > + OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
>
> OPT__QUIET(&quiet),
>
> if (quiet)
> flags |= INIT_DB_QUIET;
>
> to use the same quiet option everywhere?
I thought about it and decided against ;)
And it's one line vs four (counting "int quiet = 0;"). But I see your point.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Jakub Narebski @ 2008-07-24 20:01 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0807240358l6584c063u85179196bd6db30a@mail.gmail.com>
On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/24/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > Second, I think you can simply special case .git* files (.gitignore,
> > .gitattributes, .gitmodules), and always check them out for all
> > intermediate directories (unless configured otherwise, of course).
> > So for example if you have the following directory structure:
> >
> > A/.gitignore
> > A/a
> > A/B1/.gitignore
> > A/B1/b
> > A/B2/.gitignore
> > A/B2/c
> >
> > and you are checking out only subdirectory 'B1' (and all files in it;
> > if subdirectories are checked out recursively it depends on
> > configuration), and if for example there is .gitignore in every
> > directory, then checked out tree would look like this:
> >
> > A/.gitignore
> > A/B1/.gitignore
> > A/B1/b
> >
> > The ability to do this is one of advantages of 'sparse' checkout over
> > 'subtree' checkout.
>
> Or teach git to use index version of those files. Or collect all those
> files, combine them and put the result to .git/info/exclude (and
> similar places). Anyway well organized repos won't have this problem.
>
> Checking some files out as read-only (like this case) may be
> interesting. Though I do not how much complicated it can be.
I think teaching git to use index version of .git* files (.gitignore,
.gitattributes, .gitmodules) would be much more work than adding
default rule that .git* files in leading directories are by default
checked out, just like leading directories are checked out. This
would limit modifying git code, I think, and chances for errors.
Having "leading" directories and files read-only would be a good idea,
I think.
I don't understand the sentence "well organized repos won't have this
problem". I think well organized repos _would_ have this problem,
because of maintained and distributed top-level .gitignore and
.gitattributes.
P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 7/9] builtin-checkout-index.c: use parse_options()
From: Michele Ballabio @ 2008-07-24 20:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807241543190.8986@racer>
On Thursday 24 July 2008, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Michele Ballabio wrote:
>
> > + { OPTION_CALLBACK, 'f', "force", &state, NULL,
> > + "force overwrite of existing files",
> > + PARSE_OPT_NOARG, parse_state_force_cb, 0 },
>
> I wonder if this could not be written as
>
> OPT_BOOLEAN('f', "force", &state.force,
> "force overwrite of existing files"),
I did it that way because 'force' is a bitfield.
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Alex Riesen @ 2008-07-24 20:13 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807241257j7820a591if8ca01c66bbcd6b2@mail.gmail.com>
Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:
> I often find myself being on a branch and wanting to do the equivalent
> of a series of cherry-picks from another branch into the current one.
> Unfortunately, "git cherry-pick" only does one patch at a time (which
> is very tedious), and "git rebase", which is much less tedious to use,
> seems to specializing in applying your current branch on top of
> another branch, not the other way around.
Try this:
$ type gcp3
gcp3 is a function
gcp3 ()
{
git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
}
^ permalink raw reply
* [PATCH] Do not use ctime if file mode is not used
From: Alex Riesen @ 2008-07-24 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vr69lihkt.fsf@gitster.siamese.dyndns.org>
On some file systems, the only part of inode information we need
(executable) cannot be used, so ctime can be ignored as well. Change
time is updated when file attributes were changed (or it is written
to, but in this case, mtime is updated as well).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:
> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than
> > deemed it excessive.
>
> Why is it excessive? My initial reaction was "what does trustable
> filemode nor trust_executable_bit has anything to do with ctime". Please
> explain.
You know, you have a good point... (and I'm sometimes really stupid)
Of course it depends on the underlying filesystem!
The updated patch is untested yet, but should be obviously correct.
BTW, any idea how to check if all callers of ce_match_stat_basic have
read the configuration? It is not that essential to have
trust_executable_bit set correctly, though. In worst case an index
entry will be marked not up-to-date.
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index a50a851..f2fa0d9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -181,7 +181,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
}
if (ce->ce_mtime != (unsigned int) st->st_mtime)
changed |= MTIME_CHANGED;
- if (ce->ce_ctime != (unsigned int) st->st_ctime)
+ if (trust_executable_bit && ce->ce_ctime != (unsigned int) st->st_ctime)
changed |= CTIME_CHANGED;
if (ce->ce_uid != (unsigned int) st->st_uid ||
--
1.6.0.rc0.70.g5aae9
^ 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