On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN).
On Sat, Aug 10, 2013 at 12:18 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Hmph, do you mean the third example of this?
$ python
import os
os.path.expanduser(~/repo)
'/home/junio/repo'
On Fri, Aug 09, 2013 at 04:19:28PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
but
Felipe Contreras felipe.contre...@gmail.com writes:
If I clone ~/git, and then change my username, and move my home
directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
we have expanded the path and fixed it to my old home, if instead we
simply return without fixing, it
Jeff King wrote:
Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
Junio C Hamano wrote:
Documentation/git-whatchanged.txt | 41
---
1 file changed, 8 insertions(+), 33 deletions(-)
Looks good. Thanks for doing this.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If I clone ~/git, and then change my username, and move my home
directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
we have expanded the path and
Duy Nguyen pclo...@gmail.com writes:
On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera andre...@zoho.com wrote:
On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
+ uintmax_t pid;
pid_t is always an signed type, therefore unintmax_t does not make
sense as a
On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic if you have
/etc/mailname, that is a trustworthy address, and if you do not,
On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
The next occurrences are at:
/* Never use a non-valid filename anywhere if at all possible */
name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
a_one =
On Sat, Aug 03, 2013 at 09:57:28AM -0700, Jonathan Nieder wrote:
All is not lost. Your local files should be stored in the repository's
reflog. Examine the output of git reflog. You can then reset your
working directory to obtain those files by doing something _like_
git reset --hard
Jeff King wrote:
[...]
First off, thanks for the fabulous writeup. I hope more contributors
read this, and get interested in tackling the problems.
You are missing a step in the preparation of the delta list. If we
already have a delta on-disk, we will check whether it is usable and
keep a
On Sat, Aug 10, 2013 at 3:42 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
As Junio mentioned, that is what --thin is about; the sender omits the
base and the receiver adds it back in (index-pack --fix-thin).
Yeah, I read about the --thin option. However, it's only for
network-packs (i.e
On Sat, Aug 10, 2013 at 4:24 PM, Duy Nguyen pclo...@gmail.com wrote:
push has --thin turned off by default favoring server resources over
network traffic, see a4503a1 (Make --no-thin the default in git-push
to save server resources - 2007-09-09)
Side note, I think the server should be able to
On Sat, Aug 10, 2013 at 02:12:46PM +0530, Ramkumar Ramachandra wrote:
First off, thanks for the fabulous writeup. I hope more contributors
read this, and get interested in tackling the problems.
You're welcome. I'll just respond to a few questions/points you raised
in your response:
Yeah, I
On Sat, Aug 10, 2013 at 08:24:39AM +0700, Nguyen Thai Ngoc Duy wrote:
the other end cannot use). You _might_ be able to get by with a kind of
two-level hack: consider your main pack as group A and newly pushed
packs as group B. Allow storing thin deltas on disk from group B
against group
On Sat, Aug 10, 2013 at 4:43 PM, Jeff King p...@peff.net wrote:
push has --thin turned off by default favoring server resources over
network traffic, see a4503a1 (Make --no-thin the default in git-push
to save server resources - 2007-09-09)
Hmm. I don't think that is the case anymore.
If I
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
I intentionally don't set user.email in my
Duy Nguyen wrote:
Right. transport_get() is also run for push and it sets
smart_options-thin = 1 unconditionally.
So, it looks like smart http implies the thin capability. I think
sop's patch (6 years ago) was about turning off thin on dumb http: can
we check that before deciding that push
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/push.c | 5 ++---
1 file changed, 2 insertions(+), 3
On Sat, Aug 10, 2013 at 5:05 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
Right. transport_get() is also run for push and it sets
smart_options-thin = 1 unconditionally.
So, it looks like smart http implies the thin capability.
smart_options is a bit misleading. This
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit
On Sat, Aug 10, 2013 at 05:10:07PM +0700, Nguyen Thai Ngoc Duy wrote:
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
Signed-off-by: Nguyễn Thái Ngọc Duy
On 08/10/2013 12:28 PM, Jeff King wrote:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
On Sat, Aug 10, 2013 at 06:31:23AM -0400, Jeff King wrote:
It might be nice to have a test, but I am not sure of a good way to
check whether a push was thin. I guess we can grep the output of
GIT_TRACE, though it feels a bit hacky.
In theory, if we have a way to tell receive-pack not to pass
Hi,
I verified this behavior on Git 1.7.8 and 1.8.3.
My D:\src folder is a symlink to another folder in my Google Drive, created
by Windows command mklink /d d:\src d:\Google Drive\src
D:\srcgit clone https://github.com/jlewallen/jenkins-hipchat-plugin.git
Cloning into
Jeff King p...@peff.net writes:
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said please set
your identity before committing?
FWIW, this is what both hg and bzr do.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
On Sat, Aug 10, 2013 at 03:10:49PM +0300, Sedat Kapanoglu wrote:
My D:\src folder is a symlink to another folder in my Google Drive, created
by Windows command mklink /d d:\src d:\Google Drive\src
D:\srcgit clone https://github.com/jlewallen/jenkins-hipchat-plugin.git
Cloning into
Jeff King dixit:
It was not clear to me whether his site has /etc/mailname. If it does
Some may, some may not but…
But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.
… that won’t happen. The problem is that they
Ooops, that's exactly it =)
On Sat, Aug 10, 2013 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote:
David bouncingc...@gmail.com writes:
On 10 August 2013 05:22, Diogo de Campos cam...@esss.com.br wrote:
Had some problems rebasing a large repository, fatal error because a
short SHA-1 ref
2013/8/10 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
So always show the remote tracking branch in the output of git status
and other commands will help users to see where the current branch
will push to and pull from. E.g.
...
Hmmph.
I do not know if
On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If I clone ~/git, and then change my username, and move my home
directory, doing a
On Sat, Aug 10, 2013 at 12:38 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
Same as before, except with commit messages updated, and improved the second
patch:
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -400,8 +400,9 @@ def
The indentation should be tab not spaces.
Signed-off-by: sgm sim0...@gmail.com
---
Documentation/git-svn.txt | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 4dd3bcb..c13d0ed 100644
---
Hello,
It's been almost a year since the last release of tig, so here is a much
needed update. It brings a lot of cool new features, such as the ability
to jump directly from diff to the corresponding line in the changed
file, a stash view, improvements to the log view, plus a bunch of bug
fixes.
(my symdir was called 'gitto', fyi)
On Sat, Aug 10, 2013 at 7:22 PM, Sedat Kapanoglu
se...@eksiteknoloji.com wrote:
git is a disk intense program, so this setup is not sane at all. With
that said I know that git on windows historically had problems with
working on smb-mounted shares (sometimes
On Sun, Aug 04, 2013 at 08:24:09PM +0200, Jens Lehmann wrote:
I'm a bit confused. The commit message talks about git status, but the code
you changed handles git submodule summary. Looks like you are trying to fix
the output of status when the status.submodulesummary option is set, right?
---
GYUMIN SIM님이 Google 토크를 사용하도록 초대했습니다.
이미 Google 계정이 있는 경우 Gmail에 로그인하여 채팅 초대를 수락하세요.
http://mail.google.com/mail/invite/ANGjdJ-V370ibCmQi5Wf8-H5vRs1PXVjYktJLkwo3IP8X-YOQ2Au7ONYcx4uXUlURt3pzAaAgTe1kaNptUaZ
Google 계정에 가입한 후
ksaitoh...@gmail.com wrote on Tue, 06 Aug 2013 15:45 +0900:
In Perforce, View setting of p4 client can describe
-//depot/project/files/*.xls //client/project/files/*.xls
to exclude Excel files.
But git p4 --use-client-spec cannot support '*'.
In git-p4.py, map_in_client method analyzes
From: kazuki saitoh ksaitoh...@gmail.com
In the tests, p4d is started without using internationalized
mode. Make sure this environment variable is unset, otherwise
a mis-matched user setting would break the tests. The error
message would be Unicode clients require a unicode enabled server.
Matthieu Moy wrote:
That would mean executing SOMETEXTTOEXECUTE each time the config file is
read. This raises two issues:
* A security issue, as SOMETEXTTOEXECUTE could also be something
dangerous. It would not be much worse than the current situation (if
your config file is not
[CCing folks involved in the recent stash-refuse-to-kill merge.]
I keep portions of my home directory in git. I tried to git stash
some local changes, and it ran for several minutes with no progress. ps
showed that it was running git ls-files --killed, which was taking
100% CPU, and
In our current setup, we have automatic tagging in git of all
successful release builds. This makes it easy to go back to stable
points in history and compare functionality, check when bugs were
introduced etc.
To help with this process further, it would be useful to be able to
use git bisect,
On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote:
In our current setup, we have automatic tagging in git of all
successful release builds. This makes it easy to go back to stable
points in history and compare functionality, check when bugs were
introduced etc.
To help with
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only for testing purposes, hence
no document update.
Signed-off-by: Nguyễn Thái Ngọc
On Sat, Aug 10, 2013 at 6:34 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote:
git is a disk intense program, so this setup is not sane at all. With
that said I know that git on windows historically had problems with
working on
Hi,
Please document git blame --no-follow and git diff --no-follow
Regards,
ch3cooli
--
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
On Sat, Aug 10, 2013 at 9:24 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only
On 08/11/2013 01:20 AM, Fredrik Gustafsson wrote:
[...]
It would be very hard to do a tool such as you describe, the reason is
that there's no sane way to order your tags. Git today show tags
alphabetically, all versions does not have a alphabtic order. [...]
It would be quite easy to make a
49 matches
Mail list logo
