On Mon, Aug 6, 2012 at 11:03 PM, Jeff King wrote:
> On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
>> Anyone else? :)
>
> Sorry to gang up on you. :)
Heh. :b
> I still think your 2/2 is worth doing independently, though. It is silly
> that git-prune will not mention pruned object
On Sun, Aug 05, 2012 at 11:38:12AM +0200, Michael Haggerty wrote:
> I have some other crazy ideas for making the concept even more powerful:
>
> * Support remote alternate repositories. Local repository obtains
> missing objects from the remote as needed. This would probably be
> insanely ineff
On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
> On Mon, Aug 6, 2012 at 10:32 PM, Jeff King wrote:
> >
> > This seems like a band-aid. The real problem is that auto-gc can
> > interfere with the pack protocol, which it should not be allowed to do,
> > no matter what it produces.
>
On Mon, Aug 06, 2012 at 11:08:39AM +0800, mofaph wrote:
> I am using Git 1.7.11.4 now. I compile and then install it from the repo.
>
> $ git checkout v1.7.11.4
> $ make prefix=$HOME/opt/git/1.7.11.4 all doc info
> $ make prefix=$HOME/opt/git/1.7.11.4 install{,-doc,-html,-info}
>
> Recently, I f
On Mon, Aug 6, 2012 at 10:34 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> Ok, now a tested patch, on top of your 1/2
On Mon, Aug 6, 2012 at 10:32 PM, Jeff King wrote:
>
> This seems like a band-aid. The real problem is that auto-gc can
> interfere with the pack protocol, which it sho
Junio C Hamano writes:
> Note that this chooses to expose what comes out of the standard
> output of the subprocess to the standard error to be shown to the
> user sitting on the other end. This is in line with what we do to
> all of our hooks (Cf. cd83c74 (Redirect update hook stdout to
> stder
On Mon, Aug 06, 2012 at 10:01:49PM -0700, Brandon Casey wrote:
> This informational message can cause a problem if 'git prune' is spawned
> from an auto-gc during receive-pack. In this case, the informational
> message will be sent back over the wire to the git client and the client
> will try to
Thanks.
This patch may fix the immediate symptom, but I think the right fix
is to correct the way "gc" is invoked by receive-pack, so that
nothing "gc" writes to its standard output can leak to the standard
output of the receive-pack. After all, receive-pack is the one that
knows that its output
This informational message can cause a problem if 'git prune' is spawned
from an auto-gc during receive-pack. In this case, the informational
message will be sent back over the wire to the git client and the client
will try to interpret it as part of the pack protocol and will produce an
error.
S
When receive-pack triggers 'git gc --auto' and 'git prune' is called to
remove a stale temporary object, 'git prune' prints an informational
message to stdout about the file that it will remove. Since this message
is written to stdout, it is sent back over the transport channel to the git
client w
On Tue, Aug 07, 2012 at 12:03:26AM -0400, Jeff King wrote:
> > So which direction do you guys want to go? Use the "bidirectional
> > stdio with fseek()" for now, with the expectation that Tay's other
> > series will rewrite it to fd based one?
>
> I think so. The stdio fix is short and obviously
On Mon, Aug 06, 2012 at 08:43:02PM -0700, Junio C Hamano wrote:
> Ben Walton writes:
>
> > Now that git_terminal_prompt can cleanly interact with /dev/tty on
> > Solaris, enable HAVE_DEV_TTY so that this code path is used for
> > credential reading instead of relying on the crippled getpass().
>
Ben Walton writes:
> Now that git_terminal_prompt can cleanly interact with /dev/tty on
> Solaris, enable HAVE_DEV_TTY so that this code path is used for
> credential reading instead of relying on the crippled getpass().
>
> Signed-off-by: Ben Walton
> ---
>
> This is a follow up to Jeff's patch
Now that git_terminal_prompt can cleanly interact with /dev/tty on
Solaris, enable HAVE_DEV_TTY so that this code path is used for
credential reading instead of relying on the crippled getpass().
Signed-off-by: Ben Walton
---
This is a follow up to Jeff's patch that fixes git_terminal_prompt on
Excerpts from Jeff King's message of Mon Aug 06 20:35:41 -0400 2012:
> ---
> compat/terminal.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/compat/terminal.c b/compat/terminal.c
> index 6d16c8f..bbb038d 100644
> --- a/compat/terminal.c
> +++ b/compat/terminal.c
> @@ -59,6 +59,7 @@ ch
On Tue, Aug 7, 2012 at 8:35 AM, Jeff King wrote:
> Subject: [PATCH] terminal: seek when switching between reading and writing
>
> When a stdio stream is opened in update mode (e.g., "w+"),
> the C standard forbids switching between reading or writing
> without an intervening positioning function.
Steven Walter wrote:
> This fixes a bug where git finds the incorrect merge parent. Consider a
> repository with trunk, branch1 of trunk, and branch2 of branch1.
> Without this change, git interprets a merge of branch2 into trunk as a
> merge of branch1 into trunk.
Sam: your eyes would be much a
Steven Walter wrote:
> Consider the case where you have trunk, branchA of trunk, and branchB of
> branchA. trunk is merged back into branchB, and then branchB is
> reintegrated into trunk. The merge of branchB into trunk will have
> svn:mergeinfo property references to both branchA and branchB.
On Mon, Aug 06, 2012 at 08:23:18PM -0400, Jeff King wrote:
> This is all moot if we end up ripping stdio out of this code for other
> reasons, but it does give us another option for a fix.
And here is what that patch would look like:
-- >8 --
Subject: [PATCH] terminal: seek when switching betwee
On Tue, Aug 07, 2012 at 01:05:45AM +0200, Andreas Schwab wrote:
> > The stdio behavior on Solaris is weird. If I run this sample program:
> >
> > #include
> > int main(void)
> > {
> > FILE *fh = fopen("/dev/tty", "w+");
> > char buf[32] = {0};
> > fgets(buf, sizeof(buf), fh);
>
On Mon, Aug 06, 2012 at 07:31:30PM -0400, Ben Walton wrote:
> Excerpts from Jeff King's message of Mon Aug 06 18:42:22 -0400 2012:
>
> > +if (strbuf_getwholeline(sb, fd, term))
>
> Shouldn't this be strbuf_getwholeline_fd though?
Whoops, yes. When I got your email, I had just finished the p
Excerpts from Jeff King's message of Mon Aug 06 18:42:22 -0400 2012:
> +if (strbuf_getwholeline(sb, fd, term))
Shouldn't this be strbuf_getwholeline_fd though?
Otherwise, I think this is a good addition.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.56
Jeff King writes:
> The stdio behavior on Solaris is weird. If I run this sample program:
>
> #include
> int main(void)
> {
> FILE *fh = fopen("/dev/tty", "w+");
> char buf[32] = {0};
> fgets(buf, sizeof(buf), fh);
> fprintf(fh, "got %s\n", buf);
> return 0;
> }
>
> o
On Mon, Aug 06, 2012 at 06:39:55PM -0400, Ben Walton wrote:
> Excerpts from Jeff King's message of Mon Aug 06 18:31:13 -0400 2012:
>
> > Looking over the code, I recall now why I used stdio: strbuf_getline
> > requires it. These days we have strbuf_getwholeline_fd. It's
> > slightly less efficien
Excerpts from Jeff King's message of Mon Aug 06 18:31:13 -0400 2012:
> Looking over the code, I recall now why I used stdio: strbuf_getline
> requires it. These days we have strbuf_getwholeline_fd. It's
> slightly less efficient (it has to read() a character at a time),
> but since we are talking
On Mon, Aug 06, 2012 at 06:09:08PM -0400, Ben Walton wrote:
> > I'm currently in pkgutil hell trying to remember how to get a working
> > gcc on Solaris. Bleh. What kind of OS doesn't ship with a compiler by
> > default? :)
>
> One that's losing mindshare and isn't gaining traction? *g* Feel fre
Excerpts from Jeff King's message of Mon Aug 06 17:34:04 -0400 2012:
> On Mon, Aug 06, 2012 at 05:31:00PM -0400, Ben Walton wrote:
>
> > > I'm happy to spend a few cycles on it. I don't have access to any
> > > real Solaris boxes these days, but I imagine I can get OpenSolaris
> > > running under
Junio C Hamano writes:
> - When you have one object store and a repository that does not yet
>borrow from it, you may want to make the repository borrow from
>the object store. Obviously you can run "echo" like the sample
>script in the previous item above, but it is not obvious how
On Mon, Aug 06, 2012 at 05:31:00PM -0400, Ben Walton wrote:
> > I'm happy to spend a few cycles on it. I don't have access to any
> > real Solaris boxes these days, but I imagine I can get OpenSolaris
> > running under VirtualBox without too much trouble...
>
> I'm also happy to do this work and
Excerpts from Jeff King's message of Mon Aug 06 15:39:58 -0400 2012:
> On Sun, Aug 05, 2012 at 10:35:06PM -0400, Ben Walton wrote:
>
> > Excerpts from Junio C Hamano's message of Sun Aug 05 21:59:48 -0400 2012:
> > > Wouldn't
> > >
> > > #if solaris
> > > #define getpass getpassphrase
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The Makefile already offers the variable $(FIND) and uses it except in one
place. Fix it.
Signed-off-by: Johannes Sixt
---
For my Windows builds, I need "FIND=/usr/bin/find" in config.mak because
I have /usr/bin is too late in PATH to override MS's incompatible 'find'.
Makefile | 2 +-
1 file
It is an implementation detail that a new tag is created by adding a
file in the .git/refs/tags directory. The only thing the user needs
to know is that a "git tag" creates a ref in the refs/tags namespace,
and without "-f", it does not overwrite an existing tag.
Inspired by a report from 乙酸鋰 ; I
On Sat, Aug 04, 2012 at 01:11:46PM -0400, Jeff King wrote:
> +#define IMPLEMENT_CACHE(name, maptype, ktype, vtype) \
> +static struct map_persist_sha1pair_uint32 name##_map; \
A minor fixup, but this should obviously be "map_persist_##maptype". It
doesn't matter for this series (since we only ins
On Sat, Aug 04, 2012 at 03:58:10PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It is frequently useful to have a fast, generic data
> > structure mapping keys to values. We already have something
> > like this in the "decorate" API, but it has two downsides:
> >
> > 1. The key type
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
I am planning to tag 1.7.12-rc2 tomorrow. GSoC "index-v5" topic is
queued in 'pu' together with quick band-aid patches to give people
easier ac
On Sat, Aug 04, 2012 at 03:49:12PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There are some calculations that git makes repeatedly, even
> > though the results are invariant for a certain input (e.g.,
> > the patch-id of a certain commit). We can make a space/time
> > tradeoff by ca
On Sat, Aug 04, 2012 at 06:38:08PM +0200, Johannes Sixt wrote:
> And the reason for this is that we always told people "don't use seq"
> and they submitted an updated patch. What would we have to do now? We
> have to tell them "don't use seq, use test_seq". Therefore, the patch
> does not accompli
Jeff King writes:
> Erik has looked into doing a Windows alternative in compat/terminal.c,
> and I think an integer would be insufficient there. In particular, I
> think Windows needs two descriptors to accomplish the same thing (one
> for CONIN$ and one for CONOUT$). So you'd need to turn term_
Jeff King writes:
> From my reading of
> getpassphrase, it does seem to be a drop-in replacement.
>
> So I'm OK conceptually with the patch if we can't do any better. But
> getpass still sucks. It doesn't handle echoing, and it may or may not
> fall back to reading from stdin if the tty isn
On Mon, Aug 06, 2012 at 03:45:11PM -0400, Jeff King wrote:
> > This is not your fault but seeing term_t made me go "eek, yuck".
>
> Agreed.
>
> > As far as I can see, use of "FILE *" in existing compat/terminal.c
> > is not buying us anything useful. The stdio calls made on FILE *fh
> > are onl
On Sun, Aug 05, 2012 at 01:11:47PM -0700, Junio C Hamano wrote:
> Tay Ray Chuan writes:
>
> > Factor out the opening and closing of /dev/tty from
> > git_terminal_prompt(), so that callers may first test if a controlling
> > terminal is available before proceeding with prompting proper.
> >
> >
On Sun, Aug 05, 2012 at 10:35:06PM -0400, Ben Walton wrote:
> Excerpts from Junio C Hamano's message of Sun Aug 05 21:59:48 -0400 2012:
> > Wouldn't
> >
> > #if solaris
> > #define getpass getpassphrase
> > #endif
> >
> > without anything else be more than sufficient?
>
> Ye
Ralf Thielow writes:
> The outputs in handle_change_delete() contain a lot of placeholders.
> This could end up in confusion to translators. Add a hint for translators
> that they can easily understand it without study the code.
>
> Helped-by: Junio C Hamano
> Signed-off-by: Ralf Thielow
> ---
The outputs in handle_change_delete() contain a lot of placeholders.
This could end up in confusion to translators. Add a hint for translators
that they can easily understand it without study the code.
Helped-by: Junio C Hamano
Signed-off-by: Ralf Thielow
---
The first version did only explain t
Johannes Sixt wrote:
> Am 04.08.2012 00:09, schrieb Michał Kiedrowicz:
> > Junio C Hamano wrote:
> >> I do not have strong
> >> opinion on calling this test_seq when it acts differently from seq;
> >> it is not confusing enough to make me push something longer that is
> >> different from "seq",
Nguyễn Thái Ngọc Duy writes:
> These mails are about cosmetics only. But I think it helps maintenance
> in long term. I notice in your series we have many functions with _v2
> and _v5 mixed together. Worse, some functions that are _v2 only are
> not suffixed with _v2. I still think separating v2/
Hi Janusz,
It seems you're mixing up a few completely unrelated concepts here.
Core.quotepath enables quoting and escaping of special characters in file
names. This has nothing to do with character set encoding of file names
(i.e. Cp1250/ISO-8859-2/UTF-8). AFAIK, apart from git-svn, git current
Translate one new message came from git.pot update
in bb2ba06 (l10n: Update one message in git.pot).
Signed-off-by: Ralf Thielow
---
Hi German l10n team,
please review also this small update of German
translation. I'll squash it with the last update
and merge the commit messages together.
Thank
2012/8/6 Jiang Xin :
> 2012/8/6 Junio C Hamano :
>> OK, so there was no hidden message behind "At least for better
>> translation". Will apply this so 1.7.12 can have it.
>
> So I will not wait for Ralf's update on "de.po", he will catch up with next
> round of l10n with this fix. Pull request for
Nguyễn Thái Ngọc Duy writes:
> While at it, move die_errno() next to xmmap() call because it's the
> mmap's error code that we care about. Otherwise if close(fd); fails,
> it could overwrite mmap's errno.
Makes sense and is a sensible fix.
Thanks.
--
To unsubscribe from this list: send the line
On 08/06, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > These mails are about cosmetics only. But I think it helps maintenance
> > in long term. I notice in your series we have many functions with _v2
> > and _v5 mixed together. Worse, some functions that are _v2 only are
> > not su
Nguyễn Thái Ngọc Duy writes:
> These mails are about cosmetics only. But I think it helps maintenance
> in long term. I notice in your series we have many functions with _v2
> and _v5 mixed together. Worse, some functions that are _v2 only are
> not suffixed with _v2. I still think separating v2
---
Makefile|1 +
read-cache-v5.c | 1170 +++
read-cache.c| 27 ++
3 files changed, 1198 insertions(+), 0 deletions(-)
create mode 100644 read-cache-v5.c
diff --git a/Makefile b/Makefile
index b4a7c73..77be175 100644
--- a/Mak
---
Makefile|2 +
cache.h | 92 -
read-cache-v2.c | 570 +
read-cache.c| 591 +++
read-cache.h| 54 +
5 files changed, 734 insertions(+), 575 deleti
These mails are about cosmetics only. But I think it helps maintenance
in long term. I notice in your series we have many functions with _v2
and _v5 mixed together. Worse, some functions that are _v2 only are
not suffixed with _v2. I still think separating v2/v5 changes is a
good idea. So I played
Junio C Hamano venit, vidit, dixit 05.08.2012 00:04:
> Torsten Bögershausen writes:
>
>> Am 2012-07-30 11:57, schrieb Michael J Gruber:
>> (Sorry being late)
>>
>> That line:
>>> skip_all="filesystem does not convert utf-8 nfd to nfc"
>>
>> shouldn't it be the other way around?
>> skip_all="files
These assignments comes from the very first commit e83c516 (Initial
revision of "git", the information manager from hell - 2005-04-07).
Back then we did not die() when errors happened so correct errno was
required.
Since 5d1a5c0 ([PATCH] Better error reporting for "git status" -
2005-10-01), read_
On Mon, Aug 06, 2012 at 12:00:16PM +0100, Chris Webb wrote:
> Neil Horman writes:
>
> > Having read over this thread, I think this is definately the way to go. As
> > discussed having cherry-pick stop and give the user a chance to fix empty
> > history messages by default, and providing a switch
Neil Horman writes:
> Having read over this thread, I think this is definately the way to go. As
> discussed having cherry-pick stop and give the user a chance to fix empty
> history messages by default, and providing a switch to override that behavior
> makes sense to me. That said, shouldn't
On Thu, Aug 02, 2012 at 11:38:51AM +0100, Chris Webb wrote:
> Scripts such as git rebase -i cannot currently cherry-pick commits which
> have an empty commit message, as git cherry-pick calls git commit
> without the --allow-empty-message option.
>
> Add an --allow-empty-message option to git cher
61 matches
Mail list logo
