From: Pat Thoyts
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts
Signed-off-by: Stepan Kasal
---
Hi kusma,
On Tue, May 13, 2014 at 08:34:36AM +0200, Erik Faye-Lund wrote:
> Would it be better to set these if not already set, i.e:
>
> -CC = gcc
> -RM = rm -f
> -CFLAGS = -O2 -W
On Tue, May 13, 2014 at 8:01 AM, Stepan Kasal wrote:
> From: Pat Thoyts
> Date: Wed, 24 Oct 2012 00:15:29 +0100
>
> Signed-off-by: Pat Thoyts
> Signed-off-by: Stepan Kasal
> ---
> contrib/credential/wincred/Makefile | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/contrib/credential
Hi,
Commit 59d3924fb (prompt: fix missing file errors in zsh) added the
helper function eread() to git-prompt.sh. That function should be in
the git "namespace", i.e. prefixed with __git_, otherwise it might
collide with a function of the same name in the user's environment.
It's already
From: Pat Thoyts
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts
Signed-off-by: Stepan Kasal
---
contrib/credential/wincred/Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/contrib/credential/wincred/Makefile
b/contrib/credential/wincred/Makefile
index 39fa5e0..
From: Pat Thoyts
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts
Signed-off-by: Stepan Kasal
---
contrib/credential/wincred/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/credential/wincred/Makefile
b/contrib/credential/wincred/Makefile
index bad4
Hello again,
I revisited a patch that is present in msysgit since Oct 2012.
Dropping the cosmetic changes, there are two separate parts:
Pat Thoyts (2):
wincred: add install target
wincred: avoid overwriting configured variables
wincred: add install target
Git for Windows does contain gi
Am 5/13/2014 1:10, schrieb Max Kirillov:
> --- a/t/t7007-show.sh
> +++ b/t/t7007-show.sh
> @@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' '
> git checkout -b side HEAD^^ &&
> test_commit side2 &&
> test_commit side3
> + test_merge merge main3
> '
Broken &&-c
cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
then rev-parsed into an object ID. However, if the user is fetching a
tag rather than a branch HEAD, such as by executing:
$ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0
The object ID is a tag and is nev
In 2.0rc2, git-gui is unable to work inside submodules, where 1.9.2
did not show such a problem:
yann@home:~$ cd /tmp/
yann@home:tmp$ mkdir foo
yann@home:tmp$ cd foo/
yann@home:foo$ git init
Initialized empty Git repository in /tmp/foo/.git/
yann@home:foo (master)$ git submodule add
git://git.de
On Mon, May 12, 2014 at 09:59:39AM -0700, Junio C Hamano wrote:
> A good way to double-check may be to see the fixes to the tests to
> correct their wrong expectations, and if the updated expectation is
> sensible.
I have sent the fixes to tests. To me they look sensible.
Also fixed the things yo
When git show -s is called for merge commit it prints extra newline
after any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition shoul
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Signed-off-by: Max Kirillov
---
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7600-merge.sh | 11 +--
2 fi
Since v1:
* add Signed-off-by
* remove notion about '--format=%s' - found it in the
documentation
Since RFC:
* fix the CC issues
* add fixes for existing tests
Max Kirillov (2):
git-show: fix 'git show -s' to not add extra terminator after merge commit
t: git-show: adapt tests to fixed 'git
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Note that '--format=%s' works like '--pretty=tformat:%s'. This
is why non-merging cases pass, like t3505-cherry-pick-empty.sh
* fix the CC issues
* add fixes for existing tests
Max Kirillov (2):
git-show: fix 'git show -s' to not add extra terminator after merge commit
t: git-show: adapt tests to fixed 'git show'
combine-diff.c| 3 ++-
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7007-show.sh
When git show -s is called for merge commit it prints extra newline
after any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition shoul
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> > ...
> >> I was originally led to believe that its code quality was good
> >> enough, and that was why I merged the bottom three patches of the
> >> series even down to 'next' in the first place. But after seeing the
On Mon, May 12, 2014 at 02:07:15PM -0700, Junio C Hamano wrote:
> > And figuring out "B" here
> > would be prohibitively difficult, I would think, as it would require
> > applying the funcname rules internal to git-diff to a hunk that git-diff
> > itself never actually sees.
>
> You can actually
Jeff King writes:
> One, there is a slightly funny artifact in that the hunk header comes
> from the top of the context line, and that top is a different position
> for each of the split hunks. So in a file like:
>
> header_A
> content
> header_B
> one
> two
> three
>
On Fri, May 09, 2014 at 06:53:32PM +0200, Michael Haggerty wrote:
> On 04/26/2014 01:19 AM, Jeff King wrote:
> > On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> > [...]
> >> * fc/publish-vs-upstream (2014-04-21) 8 commits
> >> - sha1_name: add support for @{publish} marks
> >>
On Sat, May 10, 2014 at 10:41:28AM +0200, Chris “Kwpolska” Warrick wrote:
> when I’m using the HTTPS protocol to access repositories, a window
> from /usr/bin/qt4-ssh-askpass comes up. It asks for my “SSH pass
> phrase”, twice. Sadly, it’s wrong. The actual things it wants is the
> username in
Felipe Contreras writes:
> Junio C Hamano wrote:
> ...
>> I was originally led to believe that its code quality was good
>> enough, and that was why I merged the bottom three patches of the
>> series even down to 'next' in the first place. But after seeing the
>> "Of course" response that led to
Junio C Hamano wrote:
> Philippe Vaucher writes:
>
> >> It is *way* beyond the quality of any other tool in 'contrib/' and even
> >> some tools in the core, like 'git-request-pull' (which has known bugs),
> >> and probably even 'git-pt'.
> >
> > Junio, can you comment on this? I understand this p
On Sat, May 10, 2014 at 09:01:32PM +, brian m. carlson wrote:
> What it looks like is happening is that git is offering Negotiate data,
> and then your server is responding with a 401 Unauthorized. libgit2
> (presumably using WinHTTP) continues in this case, retrying with a
> longer set of cr
On Mon, May 12, 2014 at 09:42:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Good suggestion, but tricky as you point out. Another thing I've
> wanted many times is to make it smart enough that when you edit code
> like:
>
> A()
> B();
>
> And change it to:
>
> X();
>
> Y();
>
> The cha
Philippe Vaucher writes:
>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>> some tools in the core, like 'git-request-pull' (which has known bugs),
>> and probably even 'git-pt'.
>
> Junio, can you comment on this? I understand this probably doesn't
> really affect the
Torsten Bögershausen wrote:
> > I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
> >
> > It used to work before, on this same repository, since then git and hg were
> > both upgraded.
> In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0
> You can eiher
On Mon, May 12, 2014 at 8:39 PM, Jeff King wrote:
> On Sun, May 11, 2014 at 04:09:56PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the display of hunks in hunk splitting mode to preserve the diff
>> heading, which hasn't been done ever since the hunk splitting was
>> initially added in v1.4.
Good afternoon,
When running this command on Git for Windows (version 1.9.2-preview20140411)
git reset --quiet --hard with one file having read/write lock git ask this
question :
Unlink of file '' failed. Should I try again? (y/n)
I will have expected the command --quiet to remove the quest
> I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
>
> It used to work before, on this same repository, since then git and hg were
> both upgraded.
In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0
You can eiher downgrade hg, or rebuild Git and cherry-
On Mon, May 12, 2014 at 11:44:26AM -0700, Jonathan Nieder wrote:
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -331,7 +331,11 @@ extern void warning(const char *err, ...)
> > __attribute__((format (printf, 1, 2)))
> > * using the function as usual.
> > */
> > #if defined(__G
Peter Krefting writes:
> Torsten Bögershausen:
>
>> The function git_wcwidth() returns for a given unicode code point the
>> width on the display:
>> -1 for control characters,
>> 0 for combining or other non-visible code points
>> 1 for e.g. ASCII
>> 2 for double-width code points.
>
> This all
Max Kirillov writes:
> When "git show -s" is called for merge commit it prints extra newline
> between any merge commit and the next one. This looks especially ugly for
> --oneline and other single-line formats. Looks very much like a bug.
Yeah, it is not limited to one-line formats. For exampl
Torsten Bögershausen writes:
> The function git_wcwidth() returns for a given unicode code point the
> width on the display:
> -1 for control characters,
> 0 for combining or other non-visible code points
> 1 for e.g. ASCII
> 2 for double-width code points.
>
> This table had been originally b
Hi,
Jeff King wrote:
> On Mon, May 05, 2014 at 05:29:38PM -0400, Jeff King wrote:
>> I cannot think of any other way to make the compiler aware of the
>> constant value, but perhaps somebody else is more clever than I am.
>
> This came to me in a dream, and seems to work.
Clever. :) Thanks for
On Sun, May 11, 2014 at 04:09:56PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the display of hunks in hunk splitting mode to preserve the diff
> heading, which hasn't been done ever since the hunk splitting was
> initially added in v1.4.4.2-270-g835b2ae.
>
> Splitting the first hunk of this p
On Sun, May 11, 2014 at 10:22:03AM -0700, Junio C Hamano wrote:
> The alternative you mentioned up-thread "... to write out "return
> error(...)" as "error(...); return -1". In some ways that is more
> readable, though it is more verbose..." has one more downside you
> did not mention, and the ap
On Sat, 2014-05-10 at 21:01 +, brian m. carlson wrote:
> On Mon, May 05, 2014 at 12:21:33PM +0200, Ivo Bellin Salarin wrote:
> > Well, I'm on Windows.
> > using `git version 1.9.2.msysgit.0`.
> >
> > You can find all the exchanges, recorded with wireshark, of the
> > following usecases:
> > *
Michael Haggerty wrote:
> On 05/12/2014 02:29 PM, Felipe Contreras wrote:
> > Michael Haggerty wrote:
> > [...]
> >> 2. Moving git-remote-hg into the core would require you to continue your
> >>presence on the Git mailing list.
> >
> > That is another red herring. Moving them back to the contr
David Kastrup wrote:
> Felipe Contreras writes:
>
> > Then there's no point in reading what else you have to say. Whatever
> > reasons you might have to agree with Junio are known only to you, thus
> > your "agreement" is opaque and meaningless.
>
> Let me spell it out for you. Michael states "
Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
> wrote:
> > Paolo Ciarrocchi wrote:
> > > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> > > wrote:
>
> > > While I agree with you the this project is managed in a bit conservative
> > > way
> >
> > Only a bit? I
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi :
>
> No, sorry but I'm NOT interested in lying to git community.
>
It's not lying. See the "Helped-By: <>" lines in git.git commits.
Often the help was formulating a correct and easy-to-understand
commit message.
--
To unsubscribe from this list: send
Hello,
I have the following error while pushing to an hg repository though the "remote
translator":
$ git remote -v
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (push)
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (fetch)
$ git push origin
Password:
se
Hello
My name is joyJohnson
i saw your profile today and became
interested in you,i will also like to know you the more,and i want you to
send an email to my email address so that i can give you my picture for you to
know whom i am.Here is my email address (joyjohnson...@yahoo.com)
I believe w
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
wrote:
>
> Paolo Ciarrocchi wrote:
> > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> > wrote:
> >
> > While I agree with you the this project is managed in a bit conservative
> > way
>
> Only a bit? I don't think I've been involed in a mor
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
> Michael Haggerty wrote:
> [...]
>> 2. Moving git-remote-hg into the core would require you to continue your
>>presence on the Git mailing list.
>
> That is another red herring. Moving them back to the contrib/ area which
> is what Junio propose
Felipe Contreras writes:
> Michael Haggerty wrote:
>> On 05/12/2014 12:37 PM, Felipe Contreras wrote:
>> > Michael Haggerty wrote:
>> >> On 05/12/2014 01:34 AM, Felipe Contreras wrote:
>> >>> Recently Junio said he was willing to hear the opinion of other people
>> >>> regarding the move from con
Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> wrote:
>
> > Felipe, you seem to have so much potential. If you would put as
> > much effort in conducting social interactions as you do in coding,
> > the whole balance would change entirely, and any software project
Torsten Bögershausen:
The function git_wcwidth() returns for a given unicode code point the
width on the display:
-1 for control characters,
0 for combining or other non-visible code points
1 for e.g. ASCII
2 for double-width code points.
This all looks sane, but the problem is that this is al
Michael Haggerty wrote:
> On 05/12/2014 12:37 PM, Felipe Contreras wrote:
> > Michael Haggerty wrote:
> >> On 05/12/2014 01:34 AM, Felipe Contreras wrote:
> >>> Recently Junio said he was willing to hear the opinion of other people
> >>> regarding the move from contrib to the core[1]. This move is
Nevermind, it'd be more efficient to cover this in the other main
thread started by Felipe. You can answer my questions there instead as
it'll likely benefit a wider audience.
Philippe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
Stefan Beller wrote:
> 2014-05-12 10:12 GMT+02:00 Felipe Contreras :
> > Felipe Contreras wrote:
> >> Linus Torvalds wrote:
> >> > Felipe, stop this stupid blaming of everybody but yourself.
> >>
> >> Show me evidence that this decision was my fault. Junio certainly hasn't
> >> said so. You just ha
On 05/12/2014 12:37 PM, Felipe Contreras wrote:
> Michael Haggerty wrote:
>> On 05/12/2014 01:34 AM, Felipe Contreras wrote:
>>> Recently Junio said he was willing to hear the opinion of other people
>>> regarding the move from contrib to the core[1]. This move is already
>>> under way, but suddenl
Now gitk can be configured to display author and commit dates in their
original timezone, by putting %z into datetimeformat in ~/.gitk.
Signed-off-by: Anders Kaseorg
---
Re-sending from 2011:
http://thread.gmane.org/gmane.comp.version-control.git/165286/focus=174786
gitk | 24 ++
Michael Haggerty writes:
> This email is written in sorrow, not in anger. Felipe, you seem to
> have so much potential. If you would put as much effort in conducting
> social interactions as you do in coding, [...]
I think that's where you are mistaken. We are not talking about a lack
of effo
Michael Haggerty wrote:
> On 05/12/2014 01:34 AM, Felipe Contreras wrote:
> > Recently Junio said he was willing to hear the opinion of other people
> > regarding the move from contrib to the core[1]. This move is already
> > under way, but suddenly Junio changed his mind.
>
> I agree with Junio.
On Mon, May 12, 2014 at 5:56 AM, David Turner wrote:
>> So without watchman I got
>>
>>299.871ms read_index_from:1538 if (verify_hdr(hdr, mmap_size) < 0) go
>>498.205ms cmd_status:1300 refresh_index(&the_index, REFRESH_QUIE
>>796.050ms wt_status_collect:622 wt_status_collect_untracked(
Michael,
Thank you for writing this, I have to see I agree completely. As a
mostly lurker on this list, I tend to skip any thread Felipe is
participating in, as it tends to quickly spiral out of control.
This is also the main reason for me not to actively participate a bit
more, I prefer reasonab
2014-05-12 10:12 GMT+02:00 Felipe Contreras :
> Felipe Contreras wrote:
>> Linus Torvalds wrote:
>> > Felipe, stop this stupid blaming of everybody but yourself.
>>
>> Show me evidence that this decision was my fault. Junio certainly hasn't
>> said so. You just have no idea what we are talking abou
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
> Recently Junio said he was willing to hear the opinion of other people
> regarding the move from contrib to the core[1]. This move is already
> under way, but suddenly Junio changed his mind.
I agree with Junio. There are good technical arguments
Felipe Contreras wrote:
> Linus Torvalds wrote:
> > Felipe, stop this stupid blaming of everybody but yourself.
>
> Show me evidence that this decision was my fault. Junio certainly hasn't
> said so. You just have no idea what we are talking about.
Here, let me show you.
Junio, can you answer th
Linus Torvalds wrote:
> On May 12, 2014 8:35 AM, "Felipe Contreras"
> wrote:
> >
> > This move is already
> > under way, but suddenly Junio changed his mind.
>
> That "suddenly" wouldn't have anything to do with you being an ass and
> difficult as usual, arguing about everything and just generall
On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote:
> Junio C Hamano wrote:
> > Would it be sufficient to do
> >
> > git commit-tree $tree $headp -p "$rev^0"
> >
> > in that "not squashing" codepath instead?
>
> On line 561, sure. Do you want me to do a re-roll?
Sorry to bump,
63 matches
Mail list logo
