On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote:
Junio C Hamano gits...@pobox.com 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
Linus Torvalds wrote:
On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com
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
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 these
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
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com:
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
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
On Mon, May 12, 2014 at 5:56 AM, David Turner dtur...@twopensource.com 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
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. There
Michael Haggerty mhag...@alum.mit.edu 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
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 ande...@mit.edu
---
Re-sending from 2011:
http://thread.gmane.org/gmane.comp.version-control.git/165286/focus=174786
gitk | 24
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 suddenly Junio
Stefan Beller wrote:
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com:
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
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
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 already
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
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
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
Felipe Contreras felipe.contre...@gmail.com 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
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 proposed would
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
While I agree with you the this project is managed in a bit conservative
way
Only a bit? I don't
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
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:
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com:
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
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
While I agree with you the this project is managed in a bit conservative
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 contrib/ area which
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:
* git vanilla
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 approach to
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 patch
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
Torsten Bögershausen tbo...@web.de 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
Max Kirillov m...@max630.net 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.
Peter Krefting pe...@softwolves.pp.se 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.
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(__GNUC__) !
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
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
On Mon, May 12, 2014 at 8:39 PM, Jeff King p...@peff.net 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
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 downgrade
Philippe Vaucher philippe.vauc...@gmail.com 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
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 change from A-X
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
Junio C Hamano wrote:
Philippe Vaucher philippe.vauc...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
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 the
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
- sha1_name:
Jeff King p...@peff.net 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
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 apply a
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com 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
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
* 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
'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
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
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
'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 m...@max630.net
---
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7600-merge.sh | 11
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 you
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
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
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 -chain.
--
56 matches
Mail list logo
