On Thu, Apr 11, 2013 at 5:32 AM, Jeff King wrote:
> When the http-backend is set up to allow anonymous read but
> authenticated write, the http-backend manual suggests
> catching only the "/git-receive-pack" POST of the packfile,
> not the initial "info/refs?service=git-receive-pack" GET in
> whic
On Thu, Apr 11, 2013 at 3:56 AM, Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:19:19AM +0200, Magnus Therning wrote:
>
>> Nope. I'm pretty sure this had *nothing* to do with my config. This
>> is the original config, which doesn't work:
>>
>> $HTTP["url"] =~ "^/git" {
>> cgi.assign = ( "" =>
Hi,
I can no longer clone my git repository from v1.7 client, i get error: Trying
to write ref refs/heads/master with nonexistant object.
It is a remote repo that im using ssh to connect to, and i have done everything
i can find on google from creating a new master branch, cleaning up the repo,
On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:
> > ALLOWED_ENV="PATH HOME"
> > HOME=/
>
> I can work around it by changing the init script to use su - git -c "bla
> bla" to launch the thing, instead of using --user=git --group=daemon,
> but that's just a bandaid for the buste
On Thu, Apr 11, 2013 at 02:59:33AM +0100, Adam Spiers wrote:
> check-attr and check-ignore have the potential to deadlock callers
> which do not read back the output in real-time. For example, if a
> caller writes N paths out and then reads N lines back in, it risks
> becoming blocked on write()
On Thu, Apr 11, 2013 at 02:59:32AM +0100, Adam Spiers wrote:
> @@ -111,14 +110,11 @@ static int check_ignore_stdin_paths(struct
> path_exclude_check check, const char
> die("line is badly quoted");
> strbuf_swap(&buf, &nbuf);
> }
>
On Thu, Apr 11, 2013 at 02:59:31AM +0100, Adam Spiers wrote:
> Initialisation of the dir_struct and path_exclude_check structs was
> previously done within check_ignore(). This was acceptable since
> check_ignore() was only called once per check-ignore invocation;
> however the next commit will c
On Thu, Apr 11, 2013 at 12:05 AM, Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:53:38PM -0500, Felipe Contreras wrote:
>
>> > But if we push some commits to the helper, moving Y up to Z, then it
>> > would build the new commit (which contains the foreign-vcs's equivalent of
>> > Y..Z) on top of Z,
On Wed, Apr 10, 2013 at 11:53:38PM -0500, Felipe Contreras wrote:
> > But if we push some commits to the helper, moving Y up to Z, then it
> > would build the new commit (which contains the foreign-vcs's equivalent of
> > Y..Z) on top of Z, not Y.
>
> Why would it do that? If X points to say revi
On Fri, Apr 05, 2013 at 12:44:48PM +, Pyeron, Jason J CTR (US) wrote:
> [strace attachment has been removed, email being resent]
I had trouble finding anything interesting in either this, or in the
full strace you sent me off-list, mostly because the syscalls are
foreign to me (I had hoped to
On Wed, Apr 10, 2013 at 11:33 PM, Jeff King wrote:
> On Wed, Apr 10, 2013 at 07:07:12PM -0500, Felipe Contreras wrote:
>
>> When pushing, the remote namespace is updated correctly
>> (e.g. refs/origin/master), but not the remote helper's
>> (e.g. refs/testgit/origin/master).
>>
>> Let's update it
On 4/11/13 8:46 AM, David Aguilar wrote:
Apologies because I don't know the Tk API very well.
In Qt there is an API method to raise windows -- QWidget::raise().
Is there no similar API in Tk?
I seems like this may be related:
http://wiki.tcl.tk/9457
..but it seems that -topmost may not be ex
On Wed, Apr 10, 2013 at 07:07:12PM -0500, Felipe Contreras wrote:
> When pushing, the remote namespace is updated correctly
> (e.g. refs/origin/master), but not the remote helper's
> (e.g. refs/testgit/origin/master).
>
> Let's update it correctly.
I would have thought it was the helper's respon
2013/4/11 Harring Figueiredo :
> How do I pull the git.pot from my upstream?
First add git://github.com/git-l10n/git-po.git as a new remote if you have not
do this and fetch from it.
$ git remote add git-po git://github.com/git-l10n/git-po.git
$ git fetch git-po
After that, the commit wi
On Wed, Apr 10, 2013 at 07:07:11PM -0500, Felipe Contreras wrote:
> If there's already a remote-helper tracking ref, we can fetch the SHA-1
> to report proper push messages (as opposed to always reporting
> [new branch]).
>
> The remote-helper currently can specify the old SHA-1 to avoid this
> p
On Wed, 2013-04-10 at 09:56 -0400, W. Trevor King wrote:
> On Wed, Apr 10, 2013 at 07:33:35AM +0200, Mike Galbraith wrote:
> > /usr/lib/git/git-daemon --syslog --detach --reuseaddr --user=git
> > --group=daemon --pid-file=/var/run/git-daemon.pid --export-all --user-path
> > --enable=receive-pack
On Wed, Apr 10, 2013 at 04:13:20PM -0700, rh wrote:
> > +++ b/transport-helper.c
> > @@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf
> > *buffer) if (strbuf_getline(buffer, helper, '\n') == EOF) {
> > if (debug)
> > fprintf(stderr, "Debug: Remot
The examples in the documentation are all for Apache. Let's
at least cover the basics: an anonymous server, an
authenticated server, and a "half auth" server with
anonymous read and authenticated write.
Signed-off-by: Jeff King
---
I am by no means a lighttpd expert, so there may be better ways t
When the http-backend is set up to allow anonymous read but
authenticated write, the http-backend manual suggests
catching only the "/git-receive-pack" POST of the packfile,
not the initial "info/refs?service=git-receive-pack" GET in
which we advertise refs.
This does work and is secure, as we do
On Wed, Apr 10, 2013 at 09:56:13PM -0400, Jeff King wrote:
> The documentation should probably make the use of http.receivepack more
> clear in this situation.
Here's a patch series to do that. The first one would (hopefully) have
helped you arrive at the http.receivepack fix, as well as any othe
Hello,
I apologize for being picky but that patch fixes 3 typos.
>From 59f60e37b6d684963e2408b85a636b04c753f74f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Bourbi=C3=A9?=
Date: Wed, 10 Apr 2013 22:00:25 -0500
Subject: [PATCH] fix it's -> its typo
---
INSTALL | 2 +-
Hi,
In a recent e-mail[1] it was suggested that gitifyhg and git-remote-hg had many
differences, and that some users might be best served by using gitifyhg. While
that e-mail was answered properly, I would like to point out what are the
actual differences that affect users, not the ones that are p
The 'PIPE' test prerequisite was already defined identically by t9010
and t9300, therefore it makes sense to make it a predefined
prerequisite.
Signed-off-by: Adam Spiers
---
My first attempt at writing a test for check-ignore's new streaming
behaviour involved mkfifo, during which I noticed this
The expected contents of STDOUT for the final --stdin tests can be
derived from the expected contents of STDOUT for the same tests when
--verbose is given, in the same way that test_expect_success_multi
derives this for earlier tests.
Signed-off-by: Adam Spiers
---
t/t0008-ignores.sh | 16 +-
Some callers, such as the git-annex web assistant, find it useful to
invoke git check-ignore as a persistent background process, which can
then have queries fed to its STDIN at any point, and the corresponding
response consumed from its STDOUT. For this we need to invoke
check_ignore() once per li
If `-n` or `--non-matching` are specified, non-matching pathnames will
also be output, in which case all fields in each output record except
for will be empty. This can be useful when running
check-ignore as a background process, so that files can be
incrementally streamed to STDIN, and for each
check-attr and check-ignore have the potential to deadlock callers
which do not read back the output in real-time. For example, if a
caller writes N paths out and then reads N lines back in, it risks
becoming blocked on write() to check-*, and check-* is blocked on
write back to the caller. Someb
Initialisation of the dir_struct and path_exclude_check structs was
previously done within check_ignore(). This was acceptable since
check_ignore() was only called once per check-ignore invocation;
however the next commit will convert it into an inner loop which is
called once per line of STDIN wh
On Thu, Apr 11, 2013 at 01:19:19AM +0200, Magnus Therning wrote:
> Nope. I'm pretty sure this had *nothing* to do with my config. This
> is the original config, which doesn't work:
>
> $HTTP["url"] =~ "^/git" {
> cgi.assign = ( "" => "" )
> setenv.add-environment = (
> "GIT_PROJ
On Wed, Apr 10, 2013 at 07:33:35AM +0200, Mike Galbraith wrote:
> /usr/lib/git/git-daemon --syslog --detach --reuseaddr --user=git
> --group=daemon --pid-file=/var/run/git-daemon.pid --export-all --user-path
> --enable=receive-pack
>
> Try to pull as root or normal user results in:
>
> [pid 267
When pushing, the remote namespace is updated correctly
(e.g. refs/origin/master), but not the remote helper's
(e.g. refs/testgit/origin/master).
Let's update it correctly.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 12
transport-helper.c| 23 ++
Hi,
Here are a couple of patches that fix a few problems with remote-helpers.
Felipe Contreras (2):
transport-helper: improve push messages
transport-helper: update remote helper namespace
t/t5801-remote-helpers.sh | 26 ++
transport-helper.c| 24
If there's already a remote-helper tracking ref, we can fetch the SHA-1
to report proper push messages (as opposed to always reporting
[new branch]).
The remote-helper currently can specify the old SHA-1 to avoid this
problem, but there's no point in forcing all remote-helpers to be aware
of git c
Hi,
Thanks for looking it over.
Ramkumar Ramachandra wrote:
> - Why are you hard-coding ".gitmodules" instead of using a simple #define?
Advantage of ".gitmodules": it's obvious what it means.
Advantage of DOT_GITMODULES: protection against spelling errors.
Git has a lot of use of both styles
On Wed, Apr 10, 2013 at 05:47:22PM -0400, Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:30:59PM +0200, Jakub Narębski wrote:
>
>>> 1. GET $repo/info/refs?service=git-receive-pack
>>>
>>> This makes initial contact and gets the ref information which
>>> push uses to decide what it is g
#1 would actually work. Though long term it would be cool to view it
with all the most recent commit information, kind of like github does.
You know, showing "updated 4 days ago".
On Wed, Apr 10, 2013 at 11:03 AM, Jakub Narębski wrote:
> W dniu 07.04.2013 05:02, Trenton D. Adams pisze:
>
>> On
Jeff King wrote:
> To flesh out my earlier example:
>
> $ git clone https://github.com/upstream/project.git
> $ cd project
> $ hack hack hack; commit commit commit
> $ git tag -m 'something of note' my-tag
> $ git remote add me https://github.com/me/project.git
> $ git config branch.mas
Jens Lehmann wrote:
> builtin/rm.c | 14 +++--
> submodule.c| 31
> submodule.h| 1 +
> t/t3600-rm.sh | 72
> ++
> t/t7400-submodule-basic.sh | 14 +++--
> t/t7610-
On Thu, Apr 11, 2013 at 03:41:33AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > It's not that it's not potentially useful. It's that it may be
> > surprising and annoying to users who did not want that.
>
> Besides, I'm not able to imagine one scenario where this is the wrong
> or an
On Thu, Apr 11, 2013 at 03:36:10AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > It's not that it's not potentially useful. It's that it may be
> > surprising and annoying to users who did not want that.
>
> ... but this is a new syntax, and doesn't break any existing
> expectations.
Jeff King wrote:
> It's not that it's not potentially useful. It's that it may be
> surprising and annoying to users who did not want that.
Besides, I'm not able to imagine one scenario where this is the wrong
or annoying thing to do. Can you provide an example?
--
To unsubscribe from this list:
Currently using "git rm" on a submodule removes the submodule's work tree
from that of the superproject and the gitlink from the index. But the
submodule's section in .gitmodules is left untouched, which is a leftover
of the now removed submodule and might irritate users (as opposed to the
setting
Jeff King wrote:
> It's not that it's not potentially useful. It's that it may be
> surprising and annoying to users who did not want that.
... but this is a new syntax, and doesn't break any existing
expectations. Why are you imagining what users will expect with a git
push -- master next; that
On Thu, Apr 11, 2013 at 03:12:20AM +0530, Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
> > My first hunch is not to like this, since it means
> >
> > git push -- master next
> >
> > might push to two different remotes and because it's not obvious
> > to me when it would be useful.
On Wed, Apr 10, 2013 at 10:45:44PM +0200, Magnus Therning wrote:
> I was putting together a *long* response, with my different
> configurations when it suddenly hit me how to make it work.
>
> So, this is the accesslog for a successful `git push`:
>
> 192.168.1.84 tracsrv.local - [10/Apr/2013:22
On Wed, Apr 10, 2013 at 11:30:59PM +0200, Jakub Narębski wrote:
> > 1. GET $repo/info/refs?service=git-receive-pack
> >
> > This makes initial contact and gets the ref information which push
> > uses to decide what it is going to push. So it is read-only, and in
> > an anonymous-
On Wed, Apr 10, 2013 at 5:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
Jonathan Nieder wrote:
> My first hunch is not to like this, since it means
>
> git push -- master next
>
> might push to two different remotes and because it's not obvious
> to me when it would be useful.
Yes, it will push to two different remotes. And why is it not useful?
If we also h
On Wed, Apr 10, 2013 at 2:28 PM, Jeff King wrote:
> Now that's the kind of whole-hearted endorsement I strive for. :)
It's nothing wrong with your patch, the main problem is that there's
not really a good place to point users at.
> If you have better wording, I'm open to it. I do note that we do
Ramkumar Ramachandra wrote:
> If we're going to break "matching" anyway, let's break it fully.
Wait, let's not break anything. Instead, let us invent a new
push.default that does this ref-to-remote matching, and make git push
-- master push-implicit; consistent with that. Then "matching" can be
Jeff King wrote:
> On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
>> % git push
>> error: The requested URL returned error: 403 Forbidden while accessing
>>
http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack
>
> Something in your config is blocki
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>>git push master
>> ...
>> a) Error: you didn't tell me which remote to push to.
>> b) Just behave like "git push my-personal-remote master".
>> c) Behave like "git push origin master".
>
> Here, I'd argue for (d): push to branch.mas
On Wed, Apr 10, 2013 at 02:23:56PM -0700, Sverre Rabbelier wrote:
> On Wed, Apr 10, 2013 at 2:16 PM, Jeff King wrote:
> > When we try to read from a remote-helper and get EOF or an
> > error, we print a message indicating that the helper died.
> > However, users may not know that a remote helper
On Wed, Apr 10, 2013 at 2:16 PM, Jeff King wrote:
> When we try to read from a remote-helper and get EOF or an
> error, we print a message indicating that the helper died.
> However, users may not know that a remote helper was in use
> (e.g., when using git-over-http), or even what a remote
> help
Jonathan Nieder wrote:
> When people disagree about sane defaults, that's a sign that we didn't
> understand the problem well. Often more thinking can lead to a
> simpler answer.
Okay, let's see if we can all agree.
In a different email, you wrote:
>git push master
> ...
> a) Error: you
Jeff King wrote:
> On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
>> git push
>>
>> and "[push] default = upstream", then it is obvious what the user
>> wanted to happen. But what about when "[push] default = matching"?
>> Which of the following behaviors is correct?
>>
>>
On Wed, Apr 10, 2013 at 2:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
Ramkumar Ramachandra wrote:
>My point is that we should have "sane"
> defaults, and fine-grained configurability so that uses who disagree
> can maintain their own configs.
I don't agree with this principle. I like a tool that behaves sanely
with little work and t
Junio C Hamano wrote:
> On the other hand, a good thing is that the remote.pushdefault makes
> perfect sense whether you use the upstream mode or the matching
> mode. I vaguely recall that I kept telling you that the overall
> default should be there and per-branch stuff can come later if/as
> nee
When we try to read from a remote-helper and get EOF or an
error, we print a message indicating that the helper died.
However, users may not know that a remote helper was in use
(e.g., when using git-over-http), or even what a remote
helper is.
Let's print the name of the helper (e.g., "git-remote
From: Felipe Contreras
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
helper has died while reading back the ref status from the
helper. However, we don't print any mess
I think this topic is close to being done, so I just wanted to move it
along.
[1/2]: transport-helper: report errors properly
This is Felipe's v4 patch with the adjustments I suggested in
review. It explains more in the commit message, and should fix
Thomas's valgrind failures (it c
Jeff King wrote:
> But I think all of this discussion just reinforces my point. We do not
> have to agree on what the user intended. But the fact that we do not
> agree means that out of a sample size of 2 users, we have 2 different
> things the user expects to happen. If we choose a behavior and s
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/ of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.
Achieve that b
On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> >> Huh, why? Simply because he specified master alongside it? How can
> >> we infer what you said in a consistent system?
> >
> > T
Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> If we are not going to break the existing behavior, I think it can be
>> argued that consistency and simplicity of the rules is important, so the
>> user can predict what will happen. But the more we discuss, the more I
>> think we should simply cha
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
>> Huh, why? Simply because he specified master alongside it? How can
>> we infer what you said in a consistent system?
>
> That's kind of my point. Why would they put two refs together in a
> single push com
On Tue, Apr 09, 2013 at 02:24:26PM +0200, Jakub Narębski wrote:
> On 09.04.2013, Magnus Therning wrote:
>
> > I've been trying to set up git-http-backend+lighttpd. I've managed to
> > set up anonymous read-only access, and I then successfully configured
> > authentication for both read and write.
On Tue, Apr 09, 2013 at 01:12:47PM -0400, Jeff King wrote:
> On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
>
>> I've been trying to set up git-http-backend+lighttpd. I've managed
>> to set up anonymous read-only access, and I then successfully
>> configured authentication for b
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Maybe. But no more so than the current:
>> >
>> > git push
>> >
>> > which may also push master and next to the same remote.
>>
>> I would argue that this was not really a problem i
The goal is to propose a structure for storing and pre-merging pairs of commits.
Data-structure
==
We could use a note ref to store the pre-merge information. Each commit
would be annotated with a blob containing the list of pre-merges (one
sha1 per line with sha1 pointing to a merge
Ramkumar Ramachandra writes:
> As the author of branch..pushremote, I apologize for not having
> caught this earlier. I've been using push.default = current for a
> long time, and don't often think about the other settings.
Possibly, but I do not know it is such a big issue.
On the other hand,
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> > Right, the example above might include multiple remotes if pushremote is
> > respected. Or it might not come up with an answer at all for a tag.
> > If you do:
> >
> > git push -- v1.2.3 master
> >
> > where does v1.2.3 go
Jeff King writes:
> If we changed push.default=matching to ignore branch.*.remote, then that
> would be consistent, and would probably be safer over all. It is a
> regression, but I doubt that anybody was using branch.*.remote for this;
> it really only makes sense with the "upstream" mode.
True
On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Maybe. But no more so than the current:
> >
> > git push
> >
> > which may also push master and next to the same remote.
>
> I would argue that this was not really a problem in practice, until I
> intro
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
>
>> Ramkumar Ramachandra wrote:
>> > git push -- master next; pushes to my current branch's
>> > branch..pushremote? Isn't that a disaster?
>>
>> Actually, branch..pushremote already breaks the current design
On Wed, Apr 10, 2013 at 11:00 PM, Jens Lehmann wrote:
>
> Am 10.04.2013 20:24, schrieb Orgad Shaneh:
> > Executes checkout without -q
>
> Nice, looks like you picked the proposal I made last September:
> http://permalink.gmane.org/gmane.comp.version-control.git/204747
Took me a while, but I fin
On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> Currently, humanization of downloaded size is done in the same
>> function as text formatting in 'process.c'. This is an issue if anyone
>> else wants to use this.
>>
>> Separate text formatting from size simpli
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
> I don't see a big problem here, actually. What's so wrong with
> branch..remote affecting what "git push" does? If
> branch.crazy-feature.remote is my-personal-remote and I run
>
> git push
>
> and "[push] default = upstr
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkou
Jeff King wrote:
> Maybe. But no more so than the current:
>
> git push
>
> which may also push master and next to the same remote.
I would argue that this was not really a problem in practice, until I
introduced branch..pushremote.
Let us imagine that I was working on artagnon/git.git (remote:
On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
> > git push -- master next; pushes to my current branch's
> > branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way, as Junio po
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> git push -- master next; pushes to my current branch's
>> branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way
I don't see a big problem here, actually. What's so wro
Am 10.04.2013 20:24, schrieb Orgad Shaneh:
> Executes checkout without -q
Nice, looks like you picked the proposal I made last September:
http://permalink.gmane.org/gmane.comp.version-control.git/204747
The change is looking good, but you still need to document the
new option in Documentation/g
On Wed, Apr 10, 2013 at 9:43 PM, Jonathan Nieder wrote:
> Antoine Pelisse wrote:
>>One of the drawbacks is that speed will now look like
>> this when download is stalled: "0 bytes/s" instead of "0 KiB/s".
>
> At first glance that is neither obviously a benefit nor obviously a
>
Antoine Pelisse writes:
> Currently, humanization of downloaded size is done in the same
> function as text formatting in 'process.c'. This is an issue if anyone
> else wants to use this.
>
> Separate text formatting from size simplification and make the function
> public in strbuf so that it can
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote:
> > > This returns no error on the command line and produced the segfault
> > > reported by the kernel. git clone returns immediately.
> >
> > It does correctly report a failed exit code. The lack of message is
> > because git assumes that the h
Ramkumar Ramachandra wrote:
> git push -- master next; pushes to my current branch's
> branch..pushremote? Isn't that a disaster?
Actually, branch..pushremote already breaks the current design
in a way, as Junio pointed out in a different email: a push.default
set to anything except "current" is
On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> >> > If branch.$name.remote is "when I am on this branch, I want to talk to
> >> > this remote", that rule is not be impacted by the presen
Antoine Pelisse wrote:
> Separate text formatting from size simplification and make the function
> public in strbuf so that it can easily be used by other clients.
>
> We now can use strbuf_humanize() for both downloaded size and download
> speed calculation.
Sounds like a good thing to do.
>
Felipe Contreras writes:
> On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
> wrote:
>
>> --- a/contrib/remote-helpers/git-remote-hg
>> +++ b/contrib/remote-helpers/git-remote-hg
>
>> @@ -731,6 +722,26 @@ def do_export(parser):
>> if peer:
>> parser.repo.push(peer, force=False)
>>
Jakub Narębski writes:
> P.S. From some StackOverflow questions the connection between "(no
> branch)" and detached HEAD is not clear for git newbies...
If _that_ is the problem you are really trying to address, the
output from recent Git already says "(detached from xx)" or
something, so I
Ramkumar Ramachandra wrote:
> Otherwise, I think we're consistent. git push master; pushes the
> refspec master (with no explicit : counterpart) to the "default
> place to push to" (either depending on which branch I am, or global).
> I think Junio was mixing up refspecs with refs (branches, and h
Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
>> > If branch.$name.remote is "when I am on this branch, I want to talk to
>> > this remote", that rule is not be impacted by the presence of refspecs
>> > at all.
>>
>> So running the above while on 'maint' will se
Junio C Hamano writes:
> Jeremy Rosen writes:
>
>> is there some way to know how far you are within a rebase when the
>> rebase is interupted by a conflict other than the message given by
>> git rebase when it was interrupted ?
>
> I do not think there is a "git $anything" command to do that, bu
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
wrote:
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -625,6 +625,10 @@ def parse_commit(parser):
> if merge_mark:
> get_merge_files(repo, p1, p2, files)
>
> +# Check if the ref is
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
wrote:
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -731,6 +722,26 @@ def do_export(parser):
> if peer:
> parser.repo.push(peer, force=False)
>
> +# handle bookmarks
> +for b
The prev message was garbled :( Here is the correct patch (I hope).
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is t
On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
> As for why dmesg reports git-remote-http, I'm not sure. If you "strace
> -f" the command, you can see that git is running git-remote-https. Why
> the kernel chooses to report "git-remote-http", I don't know; you'd have
> to look into how
Use the new humanize() function to print loose objects size, pack size,
and garbage size in verbose mode, or loose objects size in regular mode.
This patch doesn't change the way anything is displayed when the option
is not used.
Also update the documentation.
Signed-off-by: Antoine Pelisse
---
1 - 100 of 154 matches
Mail list logo
