* 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
* Re: git rebase to move a batch of patches onto the current branch
From: Avery Pennarun @ 2008-07-24 20:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20080724201333.GA3760@blimp.local>
On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> 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
> }
But that'll give up when there are conflicts, right? git-rebase lets
me fix them in a nice way.
Avery
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Alex Riesen @ 2008-07-24 20:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145549.GA29067@laptop>
Nguyễn Thái Ngọc Duy, Wed, Jul 23, 2008 16:55:49 +0200:
>
> +static int no_external_grep;
> +
If you have used direct logic instead of negative, your patch would
have been simplier and the code would be easier to understand. I.e.:
+static int external_grep = 1;
> @@ -386,7 +388,7 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
> * we grep through the checked-out files. It tends to
> * be a lot more optimized
> */
> - if (!cached) {
> + if (!cached && !no_external_grep) {
+ if (!cached && external_grep) {
> @@ -544,6 +546,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> cached = 1;
> continue;
> }
> + if (!strcmp("--no-external-grep", arg)) {
> + no_external_grep = 1;
> + continue;
> + }
+ if (!strcmp("--no-external-grep", arg)) {
+ external_grep = 0;
+ continue;
+ }
BTW, how about a config option for this? And maybe --external-grep={yes|no}
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Alex Riesen @ 2008-07-24 20:30 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807241316x4f85bcdfw12857be575fb3289@mail.gmail.com>
Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > gcp3 ()
> > {
> > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > }
>
> But that'll give up when there are conflicts, right? git-rebase lets
> me fix them in a nice way.
>
No, it same as in rebase. You'll fix them and do "git am --resolved".
See manpage of git am.
^ permalink raw reply
* Re: [PATCH 7/9] builtin-checkout-index.c: use parse_options()
From: Sverre Rabbelier @ 2008-07-24 20:35 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <200807242208.37192.barra_cuda@katamail.com>
On Thu, Jul 24, 2008 at 10:08 PM, Michele Ballabio
<barra_cuda@katamail.com> wrote:
> 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.
I thought there is an OPT_BIT?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Avery Pennarun @ 2008-07-24 20:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20080724203049.GC3760@blimp.local>
On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
>
> > > gcp3 ()
> > > {
> > > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > > }
> >
> > But that'll give up when there are conflicts, right? git-rebase lets
> > me fix them in a nice way.
>
> No, it same as in rebase. You'll fix them and do "git am --resolved".
> See manpage of git am.
Hmm, cool.
So that command isn't too easy to come upon by accident. If I wanted
to submit a patch to make this process a bit more obvious, would it
make sense to simply have git-cherry-pick call that sequence when you
give it more than one commit?
Hmm, I suppose not, since git-am is a shellscript and cherry-pick is
currently a builtin, so it would be kind of a step backwards.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Robin Rosenberg @ 2008-07-24 20:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807241742220.8986@racer>
torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:
> However, I see Junio's point: on sane platforms you have to work hard to
> get CR-damaged files. And the regular sane platform user should not be
> punished for the brain/CR damage a certain monopolist has brought over
> this planet.
That wasn't hard at all :) Eclipse did it all by itself for JEE MANIFEST.MF files.
We got into some strange problems on windows with msysgit after that where git
(status) detected the files as changed, but no actual content change and refused
to change it's mind. I think we had actually fixed the files on Windows prior to that.
Only after converting the checkout to autocrlf=input did msysgit enter a sane state
again. I was not able to repeat the problem at the time.
Maybe I'll try again in a few weeks time.
-- robin
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 21:06 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080724180849.GA2925@dpotapov.dyndns.org>
On Thu, 24 July 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:49:41PM +0200, Jakub Narebski wrote:
>> On Wed, 23 Jul 2008, Dmitry Potapov wrote:
>>> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
>>>>
>>>> 02. What is your preferred non-programming language?
>>>> (or) What is the language you want computer communicate with you?
>>>
>>> IMHO, the later wording of the question is much better.
>>
>> First just satisfies demographic curiosity. Second is more question
>> about internationalization (i18n).
>
> I think demographic is largely covered by the first question about
> country. As to i18n, I don't think it is fully covered just by the
> question about one's language preference to communicate with computer
> (which is probably is more correctly to call localization). Possible
> questions related to i18n are:
> - Do you use file names with non-ASCII characters?
> - Do you use text files with non-ASCII characters?
> - Do you (or members of your team) use computers with different
> character sets and have to deal with non-ASCII characters?
>
> But I guess we do not want to have so many questions. So, maybe
> something simple instead:
> - Are you satisfied with support for non-ASCII characters in Git?
But only if it is free-form question:
xx. Are you satisfied with support for non-ASCII characters in Git?
Yes or No? If no, please explain what you had problems with.
(free form, or rather Yes/No + explanation for No)
If we decide to add more questions about translating Git, I think
we should also add the following:
xx. Which parts of Git would you like/do you need translated?
(zero or more: multiple choice)
- git-gui, gitk, manpages, user's manual, commands messages
>> Should "What version do you use now?" be multiple choice (using git
>> on more than one machine / operating system)?
>
> I think we already have another question about what OS one uses.
> So I believe it should be only version number here.
One can use Git on many different machines (for example at work, and
at home), or on multi-boot machine (with more than one operating
system). Each of those machines, and/or each of those operating
systems can use different version of Git. So that is why I think
this should be multiple choice, even if I guess that most people
would select only one answer.
>> What should be possible
>> choices for "How long do you use git?"? Perhaps.
>>
>> 10. How long do you use git?
>> (single choice)
>> - never/few days/few weeks/month/few months/year/few years/
>> from beginning/I wrote it(*)
>> + (*) just kidding ;-)
>
> I would rather use numbers like that:
>
> never
> less than month
> 1-3 months
> 3-6 months
> 6-12 months
> 1-2 year
> more than 2 years
> from the beginning
I think it is even better; I'm not sure if we shouldn't split sub-month
region, for example to provide for people who has heard of git for
first time, but played with it a little bit.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 21:08 UTC (permalink / raw)
To: Lachele Foley (Lists); +Cc: Jon Loeliger, git
In-Reply-To: <d028d8030807241150j4ce755aal53158c5c88db7078@mail.gmail.com>
On Thu, 24 Jul 2008, Lachele Foley wrote:
> 01. USA
> 02. Probably best I stick to English, but I'm willing to negotiate.
> 06. Not sure yet.
> 09. Last month. I think.
Errr... this email is _not_ a survey. It is an RFC, Request For
Comments, meant to come up with a good list of questions, and good list
of possible answers for single choice/multiple choice questions.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-24 21:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807232041570.8986@racer>
On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
[...]
> I deem it not, uhm, magical. By your reasoning there should be a
> way for
> Git to convert a file to UTF-8 when some entertaining person
> converted the
> working directory file to ISO-8859-15.
Um, what? This discussion is about figuring out when Git should mess
with the line endings a user is trying to commit. Why are you
bringing character encodings into it? Git does not (to my knowledge)
have any "utf8" setting that converts all files to UTF-8, and
certainly not one that is enabled by default on Windows.
Being able to mark a file with an "enforce crlf line endings on this
file" flag is useful _given that Git messes with line endings_, and a
"do not mess with line endings in this file" flag does not achieve the
same purpose. Okay?
If you want my personal opinion on autocrlf, I was happier when Git
left line endings alone so I didn't have to worry about the files I
commit being mangled (however reversibly).
I think "autocrlf=input" can make sense on a per-repository basis, but
I would have it somewhere versioned like .gitattributes, so that (a)
it is propagated when the repository is cloned, and (b) it is possible
to take an existing repository with checked-in CRLFs and do a one-time
conversion that also adds the "autocrlf=input" setting
to .gitattributes (or wherever the setting ends up going).
I don't use "autocrlf=true", even on Windows, so I don't have any
opinion on it other than thinking it should be a per-user setting
rather than per-repository (but with a per-platform default :). I
don't see how it could work unless the repository has normalised line
endings, though.
My background: I have a ton of repositories imported from CVS with a
sordid mix of CR and CRLF (occasionally in the same file!). Using
these repositories with "autocrlf=true" is a pain in the arse since
CRLFs in the repository cause spurious changes after a clean checkout,
merge troubles, etc. The code is supposed to build on Windows as well
as Unix, so I got bit by this when msysgit changed the default
autocrlf setting. [1]
My workaround is simply to set autocrlf=false; another solution might
be to filter-branch all CRLFs out of the repository, but then I'd be
messing with a lot of history, possibly breaking the files that
actually need CRLFs, and for no real upside. No thanks.
Okay, this turned into a longer rant than I intended; what I'm trying
to say is that I think autocrlf(=true) as it is currently implemented
is pretty useless, and that a setting that is versioned and cloneable
would be better. Phew!
--
Eyvind Bernhardsen
Footnote:
1. Your impression that people were rude when "autocrlf=true" was made
the default on msysgit might be related to the fact that nobody had
considered what would happen to existing repositories before making
the change? Steffen Prohaska wrote in response to one such complaint:
> Unfortunately, existing repositories that contain the wrong line
> endings
> suffer from the problems you described above. This can be handled
> either by switching off autocrlf, as you propose, or by cleaning up
> the
> line endings.
(http://groups.google.com/group/msysgit/browse_thread/thread/978a3435c1cb0c81/70bac514a8b438ef?lnk=gst#70bac514a8b438ef
)
Steffen went on to propose a patch to make autocrlf a sticky per-
repository setting, but I think you shot it down.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-24 22:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20080723141224.GA17648@leksak.fem-net>
> > How you use Git
I'd also like to see a question about what kind of content is tracked
using git.
[ ] Source code
[ ] Multimedia files
[ ] LaTeX documents
[ ] Office documents
[ ] Configuration files
[ ] Web content
[ ] the whole root filesystem ;-)
[ ] Other: _________________
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* git newbie - cloning / check out help
From: Donald Brady @ 2008-07-24 21:24 UTC (permalink / raw)
To: git
I am just ramping up on git and have the following scenario / issue:
I have a git repository on server A.
I clone it onto my machine B.
In my local copy/repository on machine B I clone a repository on some
third party server C.
I commit my changes into B and push them to A.
Now if I clone my repository from Server A onto my local machine
in a different location I see all the source as normal but only the top
level directory of C. Any source under that is not present.
What is the magic git incantation to make sure that I check out
not only the code from my repository but any repositories that
are cloned into it (recursive clone?)
Thanks
Donald
^ permalink raw reply
* [PATCH] Teach fsck and prune about the new location of temporary objects
From: Brandon Casey @ 2008-07-24 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Since 5723fe7e, temporary objects are now created in their final destination
directories, rather than in .git/objects/. Teach fsck to recognize and
ignore the temporary objects it encounters, and teach prune to remove them.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
builtin-fsck.c | 4 ++++
builtin-prune.c | 41 ++++++++++++++++++++++++-----------------
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 7326dc3..7a4a4f1 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -377,6 +377,10 @@ static void fsck_dir(int i, char *path)
if (de->d_name[0] != '.')
break;
continue;
+ case 14:
+ if (prefixcmp(de->d_name, "tmp_obj_"))
+ break;
+ continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
diff --git a/builtin-prune.c b/builtin-prune.c
index 7de4cab..947de8c 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -13,6 +13,22 @@ static const char * const prune_usage[] = {
static int show_only;
static unsigned long expire;
+static int prune_tmp_object(char *path, const char *filename)
+{
+ const char *fullpath = mkpath("%s/%s", path, filename);
+ if (expire) {
+ struct stat st;
+ if (lstat(fullpath, &st))
+ return error("Could not stat '%s'", fullpath);
+ if (st.st_mtime > expire)
+ return 0;
+ }
+ printf("Removing stale temporary file %s\n", fullpath);
+ if (!show_only)
+ unlink(fullpath);
+ return 0;
+}
+
static int prune_object(char *path, const char *filename, const unsigned char *sha1)
{
const char *fullpath = mkpath("%s/%s", path, filename);
@@ -53,6 +69,11 @@ static int prune_dir(int i, char *path)
if (de->d_name[0] != '.')
break;
continue;
+ case 14:
+ if (prefixcmp(de->d_name, "tmp_obj_"))
+ break;
+ prune_tmp_object(path, de->d_name);
+ continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
@@ -105,23 +126,9 @@ static void remove_temporary_files(void)
dirname);
return;
}
- while ((de = readdir(dir)) != NULL) {
- if (!prefixcmp(de->d_name, "tmp_")) {
- char name[PATH_MAX];
- int c = snprintf(name, PATH_MAX, "%s/%s",
- dirname, de->d_name);
- if (c < 0 || c >= PATH_MAX)
- continue;
- if (expire) {
- struct stat st;
- if (stat(name, &st) != 0 || st.st_mtime >= expire)
- continue;
- }
- printf("Removing stale temporary file %s\n", name);
- if (!show_only)
- unlink(name);
- }
- }
+ while ((de = readdir(dir)) != NULL)
+ if (!prefixcmp(de->d_name, "tmp_"))
+ prune_tmp_object(dirname, de->d_name);
closedir(dir);
}
--
1.6.0.rc0.55.g160ae.dirty
^ permalink raw reply related
* Re: git newbie - cloning / check out help
From: Petr Baudis @ 2008-07-24 23:15 UTC (permalink / raw)
To: Donald Brady; +Cc: git
In-Reply-To: <loom.20080724T211609-298@post.gmane.org>
Hi,
On Thu, Jul 24, 2008 at 09:24:34PM +0000, Donald Brady wrote:
> I am just ramping up on git and have the following scenario / issue:
>
> I have a git repository on server A.
>
> I clone it onto my machine B.
>
> In my local copy/repository on machine B I clone a repository on some
> third party server C.
>
> I commit my changes into B and push them to A.
>
> Now if I clone my repository from Server A onto my local machine
> in a different location I see all the source as normal but only the top
> level directory of C. Any source under that is not present.
>
> What is the magic git incantation to make sure that I check out
> not only the code from my repository but any repositories that
> are cloned into it (recursive clone?)
we call this functionality "submodules" and the quickstart howto is:
You have git repository on A
You clone it onto your machine B
git submodule add url directoryC
You commit your changes into B and push them to A
You do another clone of A and then within the clone
git submodule update --init
For further details, see git-submodule(1).
--
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 02/12] git-grep: support --no-external-grep
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080724202634.GB3760@blimp.local>
On 7/25/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Nguyen Thai Ngoc Duy, Wed, Jul 23, 2008 16:55:49 +0200:
>
> >
> > +static int no_external_grep;
> > +
>
>
> If you have used direct logic instead of negative, your patch would
> have been simplier and the code would be easier to understand. I.e.:
Point taken.
> + if (!strcmp("--no-external-grep", arg)) {
> + external_grep = 0;
> + continue;
> + }
>
> BTW, how about a config option for this? And maybe --external-grep={yes|no}
I don't need --external-grep=yes now, but that would be good for
testing external grep. About config option, is it really needed?
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <200807242201.23991.jnareb@gmail.com>
On 7/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> 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.
I wrote that with svn repos in mind. If those repos are to be
partially checked out, .svnignore would be in subdirectories rather
than at toplevel. Anyway that may not be true.
> P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0
>
> --
> Jakub Narebski
> Poland
>
--
Duy
^ 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