git under windows doesn't check case of letters in filename. So when
one rename for example images from *.JPG to *.jpg, git doesn't files
in a repository so when one deliver this repo on *nix -system, old
filenames preserve and this matters.
It can be very confusing when some of assets in your webs
On Sun, Aug 11, 2013 at 07:16:30AM +0200, Michael Haggerty wrote:
> 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 ver
On Sat, Aug 10, 2013 at 12:58 AM, Stephen Haberman
wrote:
> If a user is working on master, and has merged in their feature branch, but
> now
> has to "git pull" because master moved, with pull.rebase their feature branch
> will be flattened into master.
>
> This is because "git pull" currently d
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 mak
On Sat, Aug 10, 2013 at 9:24 PM, Nguyễn Thái Ngọc 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.
>
> receive-pack learns about --no-thin only for testing
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 6:34 PM, Fredrik Gustafsson 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 smb-moun
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 Du
At 11:59 +0200 10 Aug 2013, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set use
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 wit
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, but
[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 occasi
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 t
From: kazuki saitoh
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."
[pw: use unset, add
From: kazuki saitoh
Currently, git p4 does not support many of the view
wildcards, such as * and %%n. It only knows the
common ... mapping, and exclusions.
Redo the entire wildcard code around the idea of
directly querying the p4 server for the mapping. For each
unique file, invoke "p4 where /
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 an
---
GYUMIN SIM님이 Google 토크를 사용하도록 초대했습니다.
이미 Google 계정이 있는 경우 Gmail에 로그인하여 채팅 초대를 수락하세요.
http://mail.google.com/mail/invite/ANGjdJ-V370ibCmQi5Wf8-H5vRs1PXVjYktJLkwo3IP8X-YOQ2Au7ONYcx4uXUlURt3pzAaAgTe1kaNptUaZ
Google 계정에 가입한 후 Go
Michael Haggerty writes:
> 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 intentiona
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?
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 smb-mounted shares (sometimes you're forced to have stupid
> > setups). I
> 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 you're forced to have stupid
> setups). I doubt that git really is the right tool for your work, since
I reproduc
(my symdir was called 'gitto', fyi)
On Sat, Aug 10, 2013 at 7:22 PM, 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 smb-mounted shares (sometimes you're forced to
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.
On Sat, Aug 10, 2013 at 12:38 AM, Felipe Contreras
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 get_repo(url, alias):
>
The indentation should be tab not spaces.
Signed-off-by: sgm
---
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
--- a/Documentation/gi
On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras
wrote:
> On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano wrote:
>> Felipe Contreras 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 h
2013/8/10 Junio C Hamano :
> Jiang Xin 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 this will help any case you d
Ooops, that's exactly it =)
On Sat, Aug 10, 2013 at 2:28 AM, Junio C Hamano wrote:
> David writes:
>
>> On 10 August 2013 05:22, Diogo de Campos wrote:
>>> Had some problems rebasing a large repository, fatal error because a
>>> short SHA-1 ref was ambiguous.
>>
>> This recent disussion might a
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
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:\src>git clone https://github.com/jlewallen/jenkins-hipchat-plugin.git
> Cloning into 'je
Jeff King 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
GPG Key f
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:\src>git clone https://github.com/jlewallen/jenkins-hipchat-plugin.git
Cloning into 'jenkins-hipchat-plugin
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
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 th
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
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 co
On Sat, Aug 10, 2013 at 5:05 PM, Ramkumar Ramachandra
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 applies t
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
---
builtin/push.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --
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 --
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 ~/.g
On Sat, Aug 10, 2013 at 4:43 PM, Jeff King 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 do:
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
> > a
On Sat, Aug 10, 2013 at 04:24:48PM +0700, Nguyen Thai Ngoc Duy wrote:
> > Yeah, I read about the --thin option. However, it's only for
> > network-packs (i.e --stdout; why?). Also, is it turned on by default?
> > The documentation says so, but I ran it and found that the value of
> > thin is 0 in
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,
On Sat, Aug 10, 2013 at 4:24 PM, Duy Nguyen 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 control the def
On Sat, Aug 10, 2013 at 3:42 PM, Ramkumar Ramachandra
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 --stdou
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
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 rese
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 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
Duy Nguyen writes:
> On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera wrote:
>> On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> + uintmax_t pid;
>>
>> pid_t is always an signed type, therefore unintmax_t does not make
>> sense as a catch all value
>
> I only catch real p
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano wrote:
> Felipe Contreras 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
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 majord...@
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
54 matches
Mail list logo
