* [PATCH] git-reset: Let -q hush "locally modified" messages
From: Stephan Beyer @ 2008-07-25 20:49 UTC (permalink / raw)
To: Carlos Rica, Johannes Schindelin; +Cc: git, Stephan Beyer
git reset -q makes reset more quiet, but "locally modified" messages are
still shown. This patch makes them disappear, too.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
I don't know if this was actually a bug or a feature.
I considered this a bug, so here's a patch.
Regards,
Stephan
builtin-reset.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 4d246c3..c24c219 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -85,7 +85,7 @@ static void print_new_head_line(struct commit *commit)
printf("\n");
}
-static int update_index_refresh(int fd, struct lock_file *index_lock)
+static int update_index_refresh(int fd, struct lock_file *index_lock, int flags)
{
int result;
@@ -96,7 +96,8 @@ static int update_index_refresh(int fd, struct lock_file *index_lock)
if (read_cache() < 0)
return error("Could not read index");
- result = refresh_cache(REFRESH_SAY_CHANGED) ? 1 : 0;
+
+ result = refresh_cache(flags) ? 1 : 0;
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(index_lock))
return error ("Could not refresh index");
@@ -128,7 +129,7 @@ static void update_index_from_diff(struct diff_queue_struct *q,
}
static int read_from_tree(const char *prefix, const char **argv,
- unsigned char *tree_sha1)
+ unsigned char *tree_sha1, int refresh_flags)
{
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
int index_fd, index_was_discarded = 0;
@@ -152,7 +153,7 @@ static int read_from_tree(const char *prefix, const char **argv,
if (!index_was_discarded)
/* The index is still clobbered from do_diff_cache() */
discard_cache();
- return update_index_refresh(index_fd, lock);
+ return update_index_refresh(index_fd, lock, refresh_flags);
}
static void prepend_reflog_action(const char *action, char *buf, size_t size)
@@ -246,7 +247,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
else if (reset_type != NONE)
die("Cannot do %s reset with paths.",
reset_type_names[reset_type]);
- return read_from_tree(prefix, argv + i, sha1);
+ return read_from_tree(prefix, argv + i, sha1,
+ quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
}
if (reset_type == NONE)
reset_type = MIXED; /* by default */
@@ -286,7 +288,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
case SOFT: /* Nothing else to do. */
break;
case MIXED: /* Report what has not been updated. */
- update_index_refresh(0, NULL);
+ update_index_refresh(0, NULL,
+ quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
break;
}
--
1.6.0.rc0.49.g3d2ce
^ permalink raw reply related
* Re: [PATCH] bash completion: Add completion for 'git help'
From: Junio C Hamano @ 2008-07-25 21:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Lee Marlow, git
In-Reply-To: <20080725204051.GB23202@spearce.org>
Thanks for an Ack, but personally I do not think the completion of "all
commands" is worth it.
I've been busy with day-job for the past few days, and haven't had chance
to push things out today, but FYI here is what I already have on 'master'
privately, relative to what have already been pushed out.
Documentation: clarify how to disable elements in core.whitespace (Junio C Hamano)
Makefile: fix shell quoting (Junio C Hamano)
tests: propagate $(TAR) down from the toplevel Makefile (Junio C Hamano)
index-pack.c: correctly initialize appended objects (Björn Steinbrink)
send-email: find body-encoding correctly (Peter Valdemar Mørch)
document that git-tag can tag more than heads (Jonathan Nieder)
perl/Makefile: update NO_PERL_MAKEMAKER section (Brandon Casey)
bash: offer only paths after '--' for 'git checkout' (SZEDER Gábor)
checkout: mention '--' in the docs (SZEDER Gábor)
git-checkout: improve error messages, detect ambiguities. (Pierre Habouzit)
update test case to protect am --skip behaviour (Olivier Marin)
Teach fsck and prune about the new location of temporary objects (Brandon Casey)
git-checkout: fix command line parsing. (Pierre Habouzit)
At this point immediately before -rc1, I am giving much higher precedence
to real fixes than clean-ups, "use parse-opt", or new features. Please do
not get alarmed if your non-fix patches are left unresponded for a while.
BTW, has anybody taken a look at this one?
Subject: BUG: fetch incorrect interpretation of globing patterns in refspecs
Date: Thu, 24 Jul 2008 09:07:21 +0200
Message-ID: <71295b5a0807240007k246973abj1897895d0d67bb6c@mail.gmail.com>
If not, I think I probably need to take a look at this, reproducing and
possibly fixing, before applying non-fix patches.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-25 21:05 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <20080725140142.GB2925@dpotapov.dyndns.org>
On 25. juli. 2008, at 16.01, Dmitry Potapov wrote:
> On Fri, Jul 25, 2008 at 02:30:16PM +0200, Eyvind Bernhardsen wrote:
>>
>> Fair enough. Did you read the rest of my email to see when I think
>> Git should mess with content? I've thought about it, and being able
>> to do stuff like this in .gitattributes would work for me:
>>
>> * eol=auto
>> *.bat eol=crlf
>> Makefile eol=lf
>> bin/magic-binary eol=none
>>
>> I.e. "detect line endings and do CRLF->LF conversion on all files
>> except *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do
>> nothing)".
>
> I suppose "* eol=auto" means to convert CRLF->LF on checkin and
> LF->native on checkout?
That's the idea, yes, with "native" being configurable.
> Also, perhaps, it should be also possible to explicitly specify:
> *.txt eol=native
> which is the same as 'auto' but without guessing whether it is text
> or not.
Yes! Good catch, that needs to be possible.
>> ...but "core.autocrlf" is not versioned and applies to _all_
>> repositories, and anyone who doesn't have the correct setting can
>> mess
>> the repository up.
>
> I think the real issue here is not as much about being or not being
> versioned, but about forcing and not forcing anything on users.
The reason I want versioning is to fix the problem of enforcing
normalised line endings in repositories with checked-in CRLFs; I'm not
sure how to solve it any other way, but I'm open to suggestions.
> If we had core.autocrlf=input as default then clueless users will not
> checkin files with the incorrect ending. But there is an objection to
> that -- you penalize those who always have good endings. And even the
> fact that is merely default value that you can easily change to false
> does not convince everyone.
That is an excellent argument for why setting "autocrlf=true" by
default on Windows was a bad idea. Thanks! :)
> The same can be said about your
> * eol=auto
> It forces conversion on everyone, even on those who do not need it.
> Of course, you can say those projects that do not have the problem
> with
> clueless users putting text files with incorrect end-of-lines will not
> have lines like that in their .gitattribute. Yet, if I participate in
> that project, why do I have to pay the price for this conversion just
> because someone stupid can mess up line-endings?
It's about correctness: if the repository isn't supposed to have CRs
in any text files, that needs to be enforced. You might not be
stupid, but that doesn't mean you won't ever take a file that was
created on Windows and commit it to the repository on Linux. If the
tool used to create the file was CR-damaged, there goes the
repository's LF-only policy.
As you say, the reason I want the setting to be per-repository is that
I don't think the cost is worthwhile for every repository. The case
where it _is_ worthwhile is when the repository will be shared between
Windows users and Linux users, and the Windows users want CRLFs in
their working directories. I think it's worthwhile to actually make
Git work right in that case.
As a side note, there's a lot of complaining about the cost of
enforcing LF-only input, but I can't remember seeing any actual
numbers. Is it really that bad?
>> There's also no way of saying "this file should
>> have LF line endings, even with autocrlf=true".
>
> Actually, there is
>
> *.sh crlf=input
>
> i.e. I want my shell files to have LF even I normally use CRLF for
> all other files (on Windows).
Won't they still be converted to CRLF on checkout when autocrlf=true
on Windows?
>> One problem is that the autocrlf setting mixes "I want LF only in my
>> repositories" and "I like to have CRLFs in my working directory" into
>> one config variable. Instead, I'd like to have a config setting that
>> specifies which line ending form I prefer: "when a text file is
>> marked
>> eol=auto, convert LFs to CRLFs on checkout".
>
> Following your style above, I believe it should be defined as
> native-eol=crlf
Yes, that sounds right.
> but there are people who do not want to pay any price for conversion.
> Currently, "core.autocrlf=false" means to do nothing about end-of-
> lines,
> and even to ignore setting in .gitattributes. Should it be possible to
> disable *any* conversion on checkin and checkout? Should this be that
> value be the default, which most users use?
Well, there's no reason why Git repositories used only on Windows
machines shouldn't store CRLFs, so why should all msysgit users pay
the cost on every checkin _and_ checkout?
This is the reason the setting needs to be a per-repository policy and
not a user configuration; users should not be able to configure away
correctness, but they shouldn't be penalised unnecessarily for it,
either.
--
Eyvind Bernhardsen
^ permalink raw reply
* Re: git-scm.com
From: Sverre Rabbelier @ 2008-07-25 21:20 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
On Fri, Jul 25, 2008 at 19:35, Scott Chacon <schacon@gmail.com> wrote:
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com. I had meant
> to discuss this with Petr before posting it to you all, but I
> published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion,
> as some have already accused me of.
I had a looksie at the site and I think the documentation section [0]
could use some TLC. It might be because it's getting late, but there's
not really any 'eye catchers', no "CLICK ME!" link for someone
browsing around looking for Documentation. In order to find what you
want you have to read -a lot- of the page, which I think is a sign
that the page would do well with some TLC ;).
Now I'll admit that the git.or.cz version [1] is a lot worse, but with
this being an attempt to make it a lot more newbie friendly...
[0] http://git-scm.com/documentation
[1] http://git.or.cz/gitwiki/GitDocumentation
PS: I think you forgot the </shameless plug> when you did put up your
own e-book in the books section but did not put "Git Magic" there ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Junio C Hamano @ 2008-07-25 21:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Carlos Rica, Johannes Schindelin, git
In-Reply-To: <1217018948-32475-1-git-send-email-s-beyer@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
> git reset -q makes reset more quiet, but "locally modified" messages are
> still shown. This patch makes them disappear, too.
Files being "locally modified" is not and error, so I think it is in line
with the spirit of what -q is meant to do.
It is an interface change, though.
^ permalink raw reply
* Re: git-scm.com
From: Johan Herland @ 2008-07-25 21:36 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
On Friday 25 July 2008, Scott Chacon wrote:
> Hey all,
>
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com. I had meant
> to discuss this with Petr before posting it to you all, but I
> published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion,
> as some have already accused me of.
>
> Anyhow, I'm discussing with Petr about where we want to go from here -
> what changes he'd like to make, etc, but I obviously value your
> opinion as well, so please let me know what you think. The content
> has barely changed, it's really just a usability overhaul. I want to
> make sure that whatever someone is looking for (especially someone
> new), they can find in a few clicks and a few seconds.
Thanks for the update. Looks good.
Minor niggle: On the download page, in the Binaries table, Cygwin is listed
before msysGit. I'm under the impression that msysGit is what we really
want to be pushing on Windows (it's faster, smaller, and less strange to
Windows-people (i.e. less Unix-y)), so you might want to switch the order
around.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [StGit PATCH] Test that we can add a new file to a non-topmost patch with refresh -p
From: Catalin Marinas @ 2008-07-25 21:37 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Jon Smirl
In-Reply-To: <20080722071438.GA16807@diana.vm.bytemark.co.uk>
2008/7/22 Karl Hasselström <kha@treskal.com>:
> On 2008-07-21 23:01:17 +0100, Catalin Marinas wrote:
>
>> I don't think we should spend time on fixing the current code as you
>> already have a new implementation. Maybe we could add a simple test
>> and refuse refreshing other than the topmost patch in case of files
>> added to the index.
>
> Yes, I guess that's OK. Hmm, how do we check that cheaply?
In the stable branch, we already call git.check_status() in the
refresh implementation, so it's pretty cheap to test.
--
Catalin
^ permalink raw reply
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Stephan Beyer @ 2008-07-25 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, Johannes Schindelin, git
In-Reply-To: <7vwsj9r722.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
>
> > git reset -q makes reset more quiet, but "locally modified" messages are
> > still shown. This patch makes them disappear, too.
>
> Files being "locally modified" is not and error, so I think it is in line
> with the spirit of what -q is meant to do.
>
> It is an interface change, though.
Yes, as "needs update" -> "locally modified" was.
However, scripts, that rely on filenames when doing -q (whyever),
will break.
So should I stick to "git reset -q foo >/dev/null" if I want it quiet,
or is there some chance of inclusion?
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-25 21:46 UTC (permalink / raw)
To: git
In-Reply-To: <bd6139dc0807251420x32e65e73o8db5d77c8b841947@mail.gmail.com>
I mean to have the new documentation I'm beginning be the
'eye-catcher' on that page eventually. Not because it's done by me,
but because it will be open and I want to encourage people to
contribute to it (we must make it perfect, after all) :) However, the
big thing is that I couldn't think of a _single_ resource that I would
want to point people at. I tried to split everything up
categorically, but I don't know what you're looking for being there
exactly. Thanks for the feedback, though, I'll see what I can do.
As for my own plug, I feel kinda bad about that, but I have gotten a
lot of feedback that it's a useful resource and I thought by
separating it out into a 'books' section, I had cleanly distinguished
between the corporate sellouts and everyone else :) I have Git Magic
in the Tutorials section, including a nice plug for it and a link to
it's source on Github - if it were an e-book (had a pdf version and a
cover) I would happily put it over there. I would like, however, to
keep the downloadable resources seperate from the free online
resources (though now that I think about it, I should probably put
"Git from the Bottom Up" pdf up there somewhere...). I want people to
know they have to shell out money for those greedy bastards projects,
though. There will be an O'Reilly book soon, and I'll put that up,
too. If you have other resources that you think are really good, let
me know so I can add them.
Scott
On Fri, Jul 25, 2008 at 2:20 PM, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Fri, Jul 25, 2008 at 19:35, Scott Chacon <schacon@gmail.com> wrote:
>> A followup on the post I did a few days ago about Git documentation.
>> I forked Petr's git.or.cz site and put up a version that I think is a
>> bit more accessible and newbie-friendly at git-scm.com. I had meant
>> to discuss this with Petr before posting it to you all, but I
>> published a blog post that got a bit more attention than I expected,
>> and I didn't want you all to think I didn't care about your opinion,
>> as some have already accused me of.
>
> I had a looksie at the site and I think the documentation section [0]
> could use some TLC. It might be because it's getting late, but there's
> not really any 'eye catchers', no "CLICK ME!" link for someone
> browsing around looking for Documentation. In order to find what you
> want you have to read -a lot- of the page, which I think is a sign
> that the page would do well with some TLC ;).
> Now I'll admit that the git.or.cz version [1] is a lot worse, but with
> this being an attempt to make it a lot more newbie friendly...
>
> [0] http://git-scm.com/documentation
> [1] http://git.or.cz/gitwiki/GitDocumentation
>
> PS: I think you forgot the </shameless plug> when you did put up your
> own e-book in the books section but did not put "Git Magic" there ;).
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: [StGit PATCH] Fixed default install location
From: Catalin Marinas @ 2008-07-25 21:46 UTC (permalink / raw)
To: Daniel White; +Cc: git
In-Reply-To: <20080724202031.55dec8e8@whitehouse.id.au>
2008/7/24 Daniel White <daniel@whitehouse.id.au>:
> 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.
I also use "python setup.py bdist_rpm" when releasing, I think it will
get confused by a different prefix.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Propagate -u/--upload-pack option of "git clone" to transport.
From: Junio C Hamano @ 2008-07-25 21:48 UTC (permalink / raw)
To: Steve Haslam; +Cc: git, Daniel Barkalow
In-Reply-To: <1217008311-27916-1-git-send-email-shaslam@lastminute.com>
Looks correct; thanks.
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-25 21:49 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200807252336.13555.johan@herland.net>
Actually, that's directly from git.or.cz - I thought about removing
the Cygwin one, but perhaps swapping the order would be better. Any
thoughts?
Scott
On Fri, Jul 25, 2008 at 2:36 PM, Johan Herland <johan@herland.net> wrote:
> On Friday 25 July 2008, Scott Chacon wrote:
>> Hey all,
>
> Thanks for the update. Looks good.
>
> Minor niggle: On the download page, in the Binaries table, Cygwin is listed
> before msysGit. I'm under the impression that msysGit is what we really
> want to be pushing on Windows (it's faster, smaller, and less strange to
> Windows-people (i.e. less Unix-y)), so you might want to switch the order
> around.
>
>
> Have fun!
>
> ...Johan
>
> --
> Johan Herland, <johan@herland.net>
> www.herland.net
>
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-25 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <7vr69hsss1.fsf@gitster.siamese.dyndns.org>
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>> On Thu, 24 Jul 2008, Marek Zawirski wrote:
>>>> Junio C Hamano wrote:
>>>
>>>>> I am not sure how and where, but I think j/egit should also be
>>>>> mentioned and/or asked about.
>>>>
>>>> There is no separate mailing list for j/egit, we just used private mails
>>>> for some discussions/less important notifications.
[cut]
>
> Sorry for causing confusion in the discussion, but I was not talking about
> "mailing list on e/jgit".
>
> What I meant was that we might want to have a few more questions about
> e/jgit as an independent entity in the survey, as it is a completely
> different re-implementation of the same git theme.
There are two questions about egit/jgit planned for the survey:
16. Which porcelains / interfaces / implementations do you use?
(zero or more: multiple choice)
- core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
27. Which of the following features do you use?
(zero or more: multiple choice)
- Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
...
What question about egit/jgit would you like to have in the survey?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-25 21:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <200807252352.09751.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 25 Jul 2008, Junio C Hamano wrote:
> >
> > What I meant was that we might want to have a few more questions about
> > e/jgit as an independent entity in the survey, as it is a completely
> > different re-implementation of the same git theme.
>
> There are two questions about egit/jgit planned for the survey:
>
> 16. Which porcelains / interfaces / implementations do you use?
> (zero or more: multiple choice)
> - core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
> Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
pg should come out of this list in this version of the survey.
It never had a large user base and all of those users should have
moved away to something else by now.
Cogito has also been deprecated, and maybe should be removed from
the list, but it did have a larger user base so maybe we keep it
on this survey and we remove it from the next?
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
> ...
>
> What question about egit/jgit would you like to have in the survey?
I'm not certain what else I would want to ask that is egit/jgit
specific.
--
Shawn.
^ permalink raw reply
* Re: git-scm.com
From: Stephan Beyer @ 2008-07-25 22:02 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
Just a very short note: I like it ;-)
Amusing picture.
You perhaps should switch the page encoding to utf-8, since many
names of contributors are broken without.
I've just taken a view at the XHTML. You have:
<?xml version="1.0" encoding="iso-8859-1" ?>
But:
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
And the HTTP server does not set an encoding, as it seems, which is ok.
So please change the first line to
<?xml version="1.0" encoding="UTF-8"?>
Thanks,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Shawn O. Pearce @ 2008-07-25 22:05 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: Murphy, John, git
In-Reply-To: <20080724132853.GA25313@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> wrote:
> At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
> >
> > I presume this was just an oversight when git- commands were removed
> > from the bin directory.
>
> Looks like it. The following patch fixes it for me. Does it work for
> you on Windows?
Thanks.
This patch is obviously correct on any platform except Mac OS X.
On Mac OS X it gets confusing because [info nameofexecutable] is
a wrapper .app which loads its own main script. That main script
needs to use the gitk location it receives from git-gui, and not
the location it computes from gitexecdir. So I'm following up
your patch with this:
diff --git a/macosx/AppMain.tcl b/macosx/AppMain.tcl
index 41ca08e..ddbe633 100644
--- a/macosx/AppMain.tcl
+++ b/macosx/AppMain.tcl
@@ -7,7 +7,7 @@ if {[string first -psn [lindex $argv 0]] == 0} {
}
if {[file tail [lindex $argv 0]] eq {gitk}} {
- set argv0 [file join $gitexecdir gitk]
+ set argv0 [lindex $argv 0]
set AppMain_source $argv0
} else {
set argv0 [file join $gitexecdir [file tail [lindex $argv 0]]]
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Junio C Hamano @ 2008-07-25 22:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Carlos Rica, Johannes Schindelin, git
In-Reply-To: <20080725213853.GD13539@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
> Junio C Hamano wrote:
> ...
>> Files being "locally modified" is not and error, so I think it is in line
>> with the spirit of what -q is meant to do.
>>
>> It is an interface change, though.
>
> Yes, as "needs update" -> "locally modified" was.
>
> However, scripts, that rely on filenames when doing -q (whyever),
> will break.
I was not worried about scripts. "reset" is a Porcelain, and it is Ok for
the scripts to use it and rely on what it does (e.g. "git reset HEAD^"
will move the HEAD one commit back and match your index to it), but they
should not be depending on its output to be parsable. Perhaps it is Ok
for them to detect if there is any change by observing if it spits out
anything, but that is about it. So the earlier change to use "locall
modified" does not really matter in that sense, but squelching the output
altogether is a change with bigger impact. With your patch, we declare
that the scripts should not assume anything about its output.
I was more worried about expectation from human users. We used to get a
reminder of the paths that are different from the HEAD/index, even with
the "-q" option, in the form of human-readable list of paths. Your patch
changes that.
Having said all that (the only reason I said the above is not because I
think this particular interface change is a big deal, but because I wanted
to explain what kind of interface change I do and do _not_ care about when
we talk about Porcelain), when the user explicitly gives "-q" to the
command, I think it is Ok to assume that the user does not want to hear
anything back. I do not see any fundamental problem with your patch in
that sense.
It still is an interface change, though ;-)
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-25 22:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <20080725215707.GC23202@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> On Fri, 25 Jul 2008, Junio C Hamano wrote:
>> >
>> > What I meant was that we might want to have a few more questions about
>> > e/jgit as an independent entity in the survey, as it is a completely
>> > different re-implementation of the same git theme.
>>
>> There are two questions about egit/jgit planned for the survey:
>>
>> 16. Which porcelains / interfaces / implementations do you use?
>> (zero or more: multiple choice)
>> - core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
>> Pyrite, Easy Git, IsiSetup, _jgit_, my own scripts, other(*)
>
> pg should come out of this list in this version of the survey.
> It never had a large user base and all of those users should have
> moved away to something else by now.
>
> Cogito has also been deprecated, and maybe should be removed from
> the list, but it did have a larger user base so maybe we keep it
> on this survey and we remove it from the next?
>
>> 27. Which of the following features do you use?
>> (zero or more: multiple choice)
>> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
>> ...
>>
>> What question about egit/jgit would you like to have in the survey?
>
> I'm not certain what else I would want to ask that is egit/jgit
> specific.
If you do not have any specific questions you would want to see answers
to, then my point was moot, which is fine.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-25 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <7vabg5r4vy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >> 27. Which of the following features do you use?
> >> (zero or more: multiple choice)
> >> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
> >> ...
> >>
> >> What question about egit/jgit would you like to have in the survey?
> >
> > I'm not certain what else I would want to ask that is egit/jgit
> > specific.
>
> If you do not have any specific questions you would want to see answers
> to, then my point was moot, which is fine.
Actually I'd like the editor integration to be broken out (if
it isn't already) so we can see which editors (and thus which
integrations) are popular among users. I think it would help all
of the integration authors, as well as make it clear to end-users
where we have integration available/under development, in case they
were not aware of it previously.
--
Shawn.
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-25 22:15 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080725220217.GE13539@leksak.fem-net>
Thanks - we're working on validating the pages now. This should be
fixed shortly.
Scott
On Fri, Jul 25, 2008 at 3:02 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
> Hi,
>
> Just a very short note: I like it ;-)
> Amusing picture.
>
> You perhaps should switch the page encoding to utf-8, since many
> names of contributors are broken without.
> I've just taken a view at the XHTML. You have:
> <?xml version="1.0" encoding="iso-8859-1" ?>
> But:
> <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
>
> And the HTTP server does not set an encoding, as it seems, which is ok.
> So please change the first line to
> <?xml version="1.0" encoding="UTF-8"?>
>
> Thanks,
> Stephan
>
> --
> Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
>
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Petr Baudis @ 2008-07-25 22:15 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jakub Narebski, Junio C Hamano, Johannes Schindelin,
Marek Zawirski, git
In-Reply-To: <20080725215707.GC23202@spearce.org>
On Fri, Jul 25, 2008 at 04:57:07PM -0500, Shawn O. Pearce wrote:
> Cogito has also been deprecated, and maybe should be removed from
> the list, but it did have a larger user base so maybe we keep it
> on this survey and we remove it from the next?
Even recently, I've found a lot of people still using Cogito. I would
keep it in the survey in this round and in next years, decide based on
the share it gets this time.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: statistics
From: Kevin Ballard @ 2008-07-25 22:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Rene Herman, git
In-Reply-To: <4889B912.9040006@viscovery.net>
On Jul 25, 2008, at 4:29 AM, Johannes Sixt wrote:
> Rene Herman schrieb:
>> Hi.
>>
>> Is there a (non-depressing) way of getting "which files did not
>> change
>> since <rev>" out of git?
>
> What is "non-depressing"?
>
> Try this if you are using bash:
>
> comm -13 <(git diff --name-only your-rev-here) <(git ls-files)
Neat, I never knew about comm before. I probably would have come up
with something like
cat <(git ls-tree -r $REV) <(git ls-tree -r HEAD) | sort | uniq -d
| cut -f 2 | sort
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-25 23:47 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
I think counting merges in "The Authors of Git" statistics give quite
skewed numbers. If you are generating it with "shortlog", you probably
would want to give --no-merges to the command line as well. Also it
appears that you are not using .mailmap to avoid counting the same person
as different people.
I find a tabular list like this list easier to read if it were sorted like
this:
A D G
B E H
C F
i.e. not like this:
A B C
D E F
G H
^ permalink raw reply
* Re: [PATCH 5/6] archive: allow --exec and --remote without equal sign
From: Junio C Hamano @ 2008-07-26 0:28 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <1216982486-5887-5-git-send-email-rene.scharfe@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Allow "--remote repo" and "--exec cmd" in addition to "--remote=repo" and
> "--exec=cmd" to make their usage consistent with parameters handled by
> parse_options().
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> builtin-archive.c | 20 +++++++++++++++++---
> 1 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-archive.c b/builtin-archive.c
> index 4dd2716..22445ac 100644
> --- a/builtin-archive.c
> +++ b/builtin-archive.c
> @@ -15,7 +15,7 @@ static int run_remote_archiver(const char *remote, int argc,
> int fd[2], i, len, rv;
> struct child_process *conn;
> const char *exec = "git-upload-archive";
> - int exec_at = 0;
> + int exec_at = 0, exec_value_at = 0;
>
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> @@ -24,7 +24,14 @@ static int run_remote_archiver(const char *remote, int argc,
> die("multiple --exec specified");
> exec = arg + 7;
> exec_at = i;
> - break;
Interesting... With this "break", we would have never triggered the
multiple --exec error, wouldn't we?
The patch itself looked fine. Thanks.
^ permalink raw reply
* Re: [PATCH 5/6] archive: allow --exec and --remote without equal sign
From: Junio C Hamano @ 2008-07-26 0:31 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <1216982486-5887-6-git-send-email-rene.scharfe@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Convert git archive to parse_options(). The parameters --remote and --exec
> are still handled by their special parser. Define them anyway in order for
> them to show up in the usage notice.
>
> Note: in a command like "git archive --prefix --remote=a/ HEAD", the string
> "--remote=a/" will be interpreted as a remote option, not a prefix, because
> that special parser sees it first. If one needs such a strange prefix, it
> needs to be specified like this: "git archive --prefix=--remote=a/ HEAD"
> (with an equal sign).
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> archive.c | 110 +++++++++++++++++++++++++++++++++++++-----------------------
> 1 files changed, 68 insertions(+), 42 deletions(-)
Hmph, somewhat dubious.
The real point of parse-options was to make the code smaller, easier to
maintain and command line handling more consistent. At least this patch
seems to fail on the two out of three counts.
All of the other patches made obvious sense to me and are queued for -rc1
but I'd like to backburner this one.
^ 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