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
> simply return without fixing, it would still work just fine.
On Fri, Aug 09, 2013 at 11:40:56PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Even if it worked, though, I am not sure it would be worth such a rule.
> > The /etc/mailname file is not a standard, so you would effectively be
> > cutting off the auto-ident behavior for people on every o
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
Jeff King wrote:
> Even if it worked, though, I am not sure it would be worth such a rule.
> The /etc/mailname file is not a standard, so you would effectively be
> cutting off the auto-ident behavior for people on every other system. If
> we are going to do that, we might as well do it uniformly.
On Sat, Aug 10, 2013 at 12:18 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Hmph, do you mean the third example of this?
>>>
>>> $ python
>>> >>> import os
>>> >>> os.path.expanduser("~/repo")
>>> '/home/junio/repo'
>>> >>> os.path.expanduser("
On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:
> Jeff King 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). Warn
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 also interest you:
> http://thread.gmane.org/gmane.comp.version-control.git/229091
I was wond
Jeff King writes:
> ... The reason we do not store thin-packs on disk is that you
> run into problems with cycles in the delta graph (e.g., A deltas against
> B, which deltas against C, which deltas against A; at one point you had
> a full copy of one object which let you create the cycle, but yo
Felipe Contreras writes:
>> Hmph, do you mean the third example of this?
>>
>> $ python
>> >>> import os
>> >>> os.path.expanduser("~/repo")
>> '/home/junio/repo'
>> >>> os.path.expanduser("~junio/repo")
>> '/home/junio/repo'
>> >>> os.path.
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 does not know about rebase's preserve
merges flag, which would avoid thi
Hi,
Another language support (French) is coming soon. I will send new
pull request later after Avila corrects indent error and rewrites the
commit logs.
Folks who have interests on French l10n may help to review.
-- Forwarded message --
From: Jean-Noël Avila
Date: 2013/8/10
Subj
On Sat, Aug 10, 2013 at 5:16 AM, Jeff King wrote:
> Another solution could involve not writing the duplicate of Y in the
> first place. The reason we do not store thin-packs on disk is that you
> run into problems with cycles in the delta graph (e.g., A deltas against
> B, which deltas against C,
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 also interest you:
http://thread.gmane.org/gmane.comp.version-control.git/229091
--
To unsubscribe from this list: se
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 process id. In practice we don't
On Fri, Aug 9, 2013 at 6:39 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> OK, I think I see why you are puzzled.
>
> Cloning works fine because we "fix the path" *after* the clone is
Felipe Contreras writes:
> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
OK, I think I see why you are puzzled.
Cloning works fine because we "fix the path" *after* the clone is done
successfully, for the following reason:
>>>
>>> So if
Jonathan Nieder writes:
>> +# The 2 following authors are probably the same person,
>> +# but both emails bounce.
>> Nanako Shiraishi
>> Nanako Shiraishi
>
> I don't know how to contact Nanako these days. :( Maybe mailmap
> should learn a way to say "there's no current public email address f
Jonathan Nieder writes:
> From a quick search for homepages:
Thanks for digging.
So I'll discard this patch for now, and instead send this message
CC'ed to these guessed addresses.
-- >8 --
Dear Amos, Daniel, Jason, Jens, and Rutger:
our record indicates that you contributed to our proje
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 use it.
>
> 3. It looks obviously bogus (e.g., we do not have a dom
Jeff King 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). Warn
> but use it.
>
> 3. It looks obviously bogus (e.g., we do not have a d
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):
local_hg = os.path.join(shared_path, x, 'clone', '.hg')
If we have an old organization (v1.8.3), and want to upgrade to a newer
one (v1.8.4), the user would have to fetch the whole repository, instead
we can just move the repository, so the user would not notice any
difference.
Also, remove other clones, so in time they get set up as shared.
Signed-of
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
So, instead of simply checking if the
On Fri, Aug 09, 2013 at 12:42:14PM -0700, Jonathan Nieder wrote:
> I wonder if it's too gentle and long to get the point across. Would
> something the following (including the guesses in the message for
> easier copy-pasting) help?
>
> No name and email address configured, so I had to gues
Could you please add the following functionality:
I want to be able pass a command line argument to git, which will
generate an rss file with the latest changes.
Several codes already exist:
* git2rss (http://bent.latency.net/git2rss)
* git-rss (https://github.com/iarna/git-rss)
Thanks,
Leon
--
T
On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> OK, I think I see why you are puzzled.
>>>
>>> Cloning works fine because we "fix the path" *after* the clone is done
>>> successfully, for the following reason:
>>
>> So if we didn't store a different path, it
Felipe Contreras writes:
>> OK, I think I see why you are puzzled.
>>
>> Cloning works fine because we "fix the path" *after* the clone is done
>> successfully, for the following reason:
>
> So if we didn't store a different path, it would work. So instead of
> expanding '~' ourselves, it would b
On Fri, Aug 09, 2013 at 07:04:23PM +0530, Ramkumar Ramachandra wrote:
> I'll raise some (hopefully interesting) points. Let's take the example
> of a simple push: I start send-pack, which in turn starts receive_pack
> on the server and connects its stdin/stdout to it (using git_connect).
> Now, it
On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano wrote:
> OK, so clone works, but subsequent fetch from the cloned resoitory
> does not? "git fetch hg::~/my_repo" will still work but the call to
> "git config" done near the place your patch touches does not store
> "hg::~/my_repo" because it think
On Fri, Aug 9, 2013 at 4:19 PM, Antoine Pelisse wrote:
> Confusion everywhere :-)
>
> On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano wrote:
>> Antoine Pelisse writes:
>>
>>> So when we run:
>>>
>>> git clone hg::~/my/repo
>>>
>>> Git will remove the "hg::" part, and Mercurial will expand tilde
On Fri, Aug 9, 2013 at 6:32 AM, Johannes Sixt wrote:
> Am 8/9/2013 12:03, schrieb shawn wilson:
>> The question still stands though - why is that unassociated commit left
>> there?
>
> Because your command did not remove it. filter-branch does not know that
> it is "unassociated" when you ask it
Felipe Contreras writes:
> On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse wrote:
>> On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
>> wrote:
>>> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
>>> making the shared repository '.git/hg', which is already used before
>>
Antoine Pelisse writes:
> OK, I think I see why you are puzzled.
> ...
> But my issue is when I do that:
>
> git clone hg::~/my_repo my_new_repo
>
> The clone works successfully by cloning $HOME/my_repo, but then, when
> we try to fix the repo path, we think that ~/my_repo is not an
> absolut
git-contacts invokes git-blame once for each patch hunk it encounters.
No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Reduce the number of git-blame invocations by taking advantage of the
ability t
git-contacts invokes git-blame immediately upon encountering a patch
hunk. No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Any effort to reduce the number of times git-blame is run will need to
to k
Rather than calling get_blame() with a zero-length hunk only to have it
rejected immediately, perform hunk-length validation earlier in order to
avoid calling get_blame() unnecessarily.
This is a preparatory step to simplify later patches which reduce the
number of git-blame invocations by collect
This patch series aims to make contrib/git-contacts faster by reducing
the number of expensive git-blame invocations it makes. It does so by
taking advantage of git-blame's new ability to accept multiple -L ranges
in a single invocation [1] (es/blame-L-twice in 'next').
Some numbers, given a rando
Thanks.
--
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
Confusion everywhere :-)
On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So when we run:
>>
>> git clone hg::~/my/repo
>>
>> Git will remove the "hg::" part, and Mercurial will expand tilde and
>> clone $HOME/my/repo.
>
> Now you confused me. If the impleme
Jiang Xin writes:
> If the current branch has an upstream branch, and there are changes
> between the current branch and its upstream, some commands (such as
> "git status", "git status -bs", and "git checkout") will report their
> relationship. E.g.
>
> $ git status
> # On branch master
John Keeping writes:
>> +New users are encouraged to use linkgit:git-log[1] instead. The
>> +`whatchanged` command is essentially the same as linkgit:git-log[1]
>> +run with different defaults that shows a --raw diff outputat the
>
> s/outputat/output at/
Thanks.
> Although I wonder if it woul
Antoine Pelisse writes:
> So when we run:
>
> git clone hg::~/my/repo
>
> Git will remove the "hg::" part, and Mercurial will expand tilde and
> clone $HOME/my/repo.
Now you confused me. If the implementation were for us to remove
the hg:: prefix and let Mercurial do whatever it wants to do wit
On Fri, Aug 9, 2013 at 7:13 AM, Лежанкин Иван wrote:
> I have tried to cherry-pick a range of ~200 commits from one branch to
> another. And you can't imagine how I was surprised when the git
> process ate 8 Gb of RAM and died - before cherry-picking was complete.
Try this:
http://article.gmane.o
On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser wrote:
> Jonathan Nieder dixit:
>>I wonder if it's too gentle and long to get the point across. Would
>>something the following (including the guesses in the message for
>>easier copy-pasting) help?
>
> Definitely not. It needs to fail hard if user
On Fri, Aug 9, 2013 at 3:19 PM, Antoine Pelisse wrote:
> On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
> wrote:
>> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
>> making the shared repository '.git/hg', which is already used before
>> that patch, so clones that happe
In t/t7407-submodule-foreach.sh there is a typo in one of the
path names given for a test step. The correct path is
nested1/nested2/.git, but nested1/nested1/nested2/.git is
given instead. The typo is hidden because this line also
accidentally omits the && chain operator. The omitted chain
also
On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
wrote:
> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
> making the shared repository '.git/hg', which is already used before
> that patch, so clones that happened before that patch, fail after that
> patch, because there's
Jonathan Nieder dixit:
>Can you say a little more about your setup? In a university
>environment with sysadmin-managed email and /etc/mailname set up
>correctly it is handy that people can start working without doing
Ah okay. We don’t have /etc/mailname set up I think and,
additionally, the Unix
On Fri, Aug 09, 2013 at 01:01:48PM -0700, Junio C Hamano wrote:
> After doing a bit of archaeology, I now know why "whatchanged" with
> an unwieldy long name persisted in the user's mindset for so long.
>
> My conclusions are:
>
> - It is better to encourage new users to use `log` very early in
On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>> On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
>> wrote:
>>> Shouldn't that be the job of the shell? (s/~/$HOME/)
>>
>> I'm not sure what you mean here. Does it mean that I should stop cloning
>> using "~" ?
Hi,
Here's my proposal split into two patches, as I suggested. With the fix for
when there's more than one shared repo.
Felipe Contreras (2):
remote-hg: simplify share repo setup
remote-hg: add shared repo upgrade
contrib/remote-helpers/git-remote-hg | 22 +-
1 file chan
We don't need the initial clone, if the repository is shared, pulling
from the child updates the parent's storage; it's exactly the same as
cloning.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial to upgrade to the new org
Hi,
>From a quick search for homepages:
Stefan Beller wrote:
[...]
> +# The 2 following authors are probably the same person,
> +# but both emails bounce.
> +Amos Waterland
> +Amos Waterland
>From the history of http://people.seas.harvard.edu/~apw/sreplay/sreplay.git
this looks like the same
After doing a bit of archaeology, I now know why "whatchanged" with
an unwieldy long name persisted in the user's mindset for so long.
My conclusions are:
- It is better to encourage new users to use `log` very early in
the document;
- It is not sensible to remove the command at this point
Hi Thorsten,
Thorsten Glaser wrote[1]:
> git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
> because just too many cow-orkers seem to be unable to follow basic
> instructions
Heh.
Can you say a little more about your setup? In a university
environment with sysadmin-managed e
I've looked into this a bit and I think this is a bug in Webstorm.
Webstorm saves files a lot without you actually hitting save, so
that's why I didn't put 2 and 2 together. It appears that any file
change in Webstorm is screwing up the permissions on git's index --
but only in 64b Ubuntu, it wasn'
I had some problems rebasing a repository that had empty commits,
which caused the rebase to stop. After continuing it with git rebase
--continue, it seems that the strategies I originally gave were
forgotten.
I quickly glanced at the code, and it seems that a lot of rebase
options are stored in i
Had some problems rebasing a large repository, fatal error because a
short SHA-1 ref was ambiguous.
After a quick inspection of git-rebase--interactive.sh, I found that
it uses short refs in a few places (git rev-parse --short). Removing
that option fixed my problem.
See:
https://github.com/git/
Ramsay Jones writes:
> $path is part of the public API, so we can't just remove it. It would
> require a deprecation period, etc,. (Adding/documenting $sm_path as an
> alternative *may* be worth doing. dunno.)
I think exporting sm_path (if not done already) and documenting the
transition may be
Antoine Pelisse writes:
> The current code fixes the path to make it absolute when cloning, but
> doesn't consider tilde expansion, so that scenario fails throwing an
> exception because /home/myuser/~/my/repository doesn't exists:
>
> $ git clone hg::~/my/repository && cd repository && git f
Philip,
Yes, this is msysgit, version 1.8.3.
Now I switched back to 1.7.11 -- there is no such issue in this older version.
09.08.2013, 22:31, "Philip Oakley" :
> From: "Dmitry Kuzminov"
>
> Dmitry,
> The Git for Windows development list is at msys...@googlegroups.com.
>
> Is this "git for Windo
From: "Dmitry Kuzminov"
Dmitry,
The Git for Windows development list is at msys...@googlegroups.com.
Is this "git for Windows" or one of the other git versions on windows,
and their installers?
There is a standard command prompt icon in taskbar for GIT Bash
instead of GIT icon
Steps to r
We cannot be sure whether these are the same person,
hence we will not map their different mail addresses
to one person. However this commit documents, some
bouncing mail addresses, so these need not be tried
again, when somebody continues the .mailmap cleanup.
Signed-off-by: Stefan Beller
---
.
Hello,
Patch 1 is fixing up the mistakes of the previous series.
Patch 2 should really be discussed as I am unsure about the approach.
During the time trying to get the .mailmap file in shape I wrote lots
of emails. There have been many bounces, because some addresses are no
longer valid. Someti
This patch adds no new names, but fixes the mistakes I made in the previous
commits. (94b410bba8, f4f49e225, c07a6bc57, 2013-07-12, .mailmap: Map
email addresses to names).
These mistakes are double white spaces between name and surname,
different capitalization in email address, or just the email
The option "--diff3" was added to "git merge-file" in e0af48e
(xdiff-merge: optionally show conflicts in "diff3 -m" style)
but it was never documented in "Documentation/git-merge-file.txt".
Add documentation for this option.
Signed-off-by: Ralf Thielow
---
Documentation/git-merge-file.txt | 5 ++
2013/8/9 Junio C Hamano :
> Elia Pinto writes:
>
>> Git use, as many project that use autoconf, private m4 macros.
>>
>> When not using automake, and just relying on autoconf, the macro
>> files are not picked up by default.
>>
>> A possibility, as git do today, is to put the private m4 macro
>> i
Andres Perera writes:
>> +/* return NULL on success, else hostname running the gc */
>> +static const char *lock_repo_for_gc(int force, pid_t* ret_pid)
>> +{
>> + static struct lock_file lock;
>> + static char locking_host[128];
>> + char my_host[128];
>> + struct strbuf s
Ramkumar Ramachandra writes:
> I'll raise some (hopefully interesting) points. Let's take the example
> of a simple push: I start send-pack, which in turn starts receive_pack
> on the server and connects its stdin/stdout to it (using git_connect).
> Now, it reads the (sha1, ref) pairs it receives
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> It is meant to teach them "if you want to do your own 'git log', you
>> can do so with 'rev-list' piped to 'diff-tree --stdin'". Changing
>> 'whatchanged' to 'log' in the latter statement is an improvement,
>> but dropping 'can be done by combi
On Thu, Aug 08, 2013 at 06:44:22PM +0100, Ramsay Jones wrote:
> $path is part of the public API, so we can't just remove it. It would
> require a deprecation period, etc,. (Adding/documenting $sm_path as an
> alternative *may* be worth doing. dunno.)
Maybe something for git 2.0? Well, Jens and Ju
The current code fixes the path to make it absolute when cloning, but
doesn't consider tilde expansion, so that scenario fails throwing an
exception because /home/myuser/~/my/repository doesn't exists:
$ git clone hg::~/my/repository && cd repository && git fetch
Expand the tilde when checkin
Fredrik Gustafsson wrote:
> On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote:
>> But we'll have to use sm_path here (like everywhere else in the
>> submodule script), because we'll run into problems under Windows
>> otherwise (see 64394e3ae9 for details). Apart from that the patch
>> is
There is a standard command prompt icon in taskbar for GIT Bash instead of GIT
icon
Steps to reproduce:
Select Taskbar Properties, Taskbar buttons, set to "Never combine"
Run GIT Bash
Best regards,
Dmitry Kuzminov
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
> That doesn't make sense. If you are the owner of the file, why do you need
> sudo???
I've just never seen a chmod command without sudo. I assumed it was
needed. Is this relevant to the bug that I'm seeing?
On Fri, Aug 9, 2013 at 5:40 AM, Andreas Schwab wrote:
> Justin Collum writes:
>
>>
Elia Pinto writes:
> Git use, as many project that use autoconf, private m4 macros.
>
> When not using automake, and just relying on autoconf, the macro
> files are not picked up by default.
>
> A possibility, as git do today, is to put the private m4 macro
> in the configure.ac file, so they wil
From: Felipe Contreras
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial
On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy wrote:
> This may happen when `git gc --auto` is run automatically, then the
> user, to avoid wait time, switches to a new terminal, keeps working
> and `git gc --auto` is started again because the first gc instance has
> not clean up the reposi
Duy Nguyen writes:
> On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano wrote:
>> When we see a recent lockfile created by a "gc" running elsewhere,
>> we do not set "should_exit". Is that a good thing? I am wondering
>> if the last two lines should be:
>>
>> - !strcmp(locking_host, my_host)
for "git pull --rebase". I see it run when I do "git rebase -i ...".
Is this a bug or feature? It's with git version 1.7.11.7.
--
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/m
> We have a patch in Git for Windows allowing rebase = interactive
> which I did not have time to send upstream.
Cool, so, would rebase=preserve and rebase=interactive be completely
orthogonal?
E.g. do we have to worry about the user wanting to do both, like with
something ugly like rebase=prese
On Fri, Aug 09, 2013 at 11:04:45PM +0800, gnehzuil.liu wrote:
> �� 2013-8-9��10:46��Josef 'Jeff' Sipek д
>
> > On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
> >> From: Zheng Liu
> >>
> >> Currently guilt doesn't support FreeBSD platform. This commit tries to
> >> add this
在 2013-8-9,下午10:46,Josef 'Jeff' Sipek 写道:
> On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
>> From: Zheng Liu
>>
>> Currently guilt doesn't support FreeBSD platform. This commit tries to
>> add this support. The file called 'os.FreeBSD' is copied from os.Darwin
>> due to these two
On Fri, Aug 9, 2013 at 6:03 AM, shawn wilson wrote:
> On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt wrote:
>> Let's check: After running your command above to remove other files, does
>> the command
>>
>>git filter-branch -f HEAD webban.pl
>>
>
> Ahha, no but:
> git filter-branch -f HEAD -- w
On Fri, Aug 09, 2013 at 08:32:28PM +0800, Zheng Liu wrote:
> From: Zheng Liu
>
> Currently guilt doesn't support FreeBSD platform. This commit tries to
> add this support. The file called 'os.FreeBSD' is copied from os.Darwin
> due to these two platforms have almost the same command tools.
Out
Git use, as many project that use autoconf, private m4 macros.
When not using automake, and just relying on autoconf, the macro
files are not picked up by default.
A possibility, as git do today, is to put the private m4 macro
in the configure.ac file, so they will copied over the final configur
Hi,
On Thu, 8 Aug 2013, Junio C Hamano wrote:
> Stephen Haberman writes:
>
> > Hi Johannes,
> >
> >> This should probably be added to config.txt and
> >> Documentation/git-pull.txt, too, right?
> >
> > Yep, I meant to note that I'd do that after getting an initial
> > confirmation that the pull
Jeff King wrote:
> It depends on what each side has it, doesn't it? We generally try to
> reuse on-disk deltas when we can, since they require no computation. If
> I have object A delta'd against B, and I know that the other side wants
> A and has B (or I am also sending B), I can simply send what
On Fri, Aug 9, 2013 at 1:46 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Old operation's updates are removed as new ones are added to keep the
>> size under 1 MB. ILOG keeps minimum 10 operations regardless of its
>> size. These contansts should be configurable later one. ILOG c
On Fri, Aug 9, 2013 at 12:10 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I fail to see the point here. There are two different things: what we
>> want to send, and what we can make deltas against. Shallow boundary
>> affects the former. What the recipient has affects latter. What is the
>
Duy Nguyen writes:
> On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer wrote:
>> Duy Nguyen writes:
>>
>> [..]
>>
+static int read_entries(struct index_state *istate, struct
directory_entry **de,
+ unsigned int *entry_offset, void **mmap,
+
Andreas Schwab writes:
> Justin Collum writes:
>
>> sudo chmod 644 ./.git/index
>
> That doesn't make sense. If you are the owner of the file, why do you
> need sudo???
I suspect that some over-use of "sudo" resulted in files or directories
belonging to root. What does
find . -user 0
On 08/09/2013 02:27 PM, Ben Tebulin wrote:
> Hello everybody!
>
> I have some _very interesting_ news regarding this issue!
> Here is the deal:
>
> 1. I was able to *reproduce the error on a machine of a coworker!*
>
> 2. I was able to rule out
> - HDD: It's reproducible from /dev/shm
On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano wrote:
> When we see a recent lockfile created by a "gc" running elsewhere,
> we do not set "should_exit". Is that a good thing? I am wondering
> if the last two lines should be:
>
> - !strcmp(locking_host, my_host) &&
> - !kill(pid, 0);
Justin Collum writes:
> sudo chmod 644 ./.git/index
That doesn't make sense. If you are the owner of the file, why do you
need sudo???
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something comple
From: Zheng Liu
Currently guilt doesn't support FreeBSD platform. This commit tries to
add this support. The file called 'os.FreeBSD' is copied from os.Darwin
due to these two platforms have almost the same command tools.
Signed-off-by: Zheng Liu
---
Hi all,
After applied this patch, the reg
Hello everybody!
I have some _very interesting_ news regarding this issue!
Here is the deal:
1. I was able to *reproduce the error on a machine of a coworker!*
2. I was able to rule out
- HDD: It's reproducible from /dev/shm
- Memory: Memory tests works fine
now the interesting
Hi,
I have tried to cherry-pick a range of ~200 commits from one branch to
another. And you can't imagine how I was surprised when the git
process ate 8 Gb of RAM and died - before cherry-picking was complete.
I downloaded git sources from master and built it with gperftools
support (-ltcmalloc).
On Fri, Aug 09, 2013 at 01:34:48AM +0530, Ramkumar Ramachandra wrote:
> Certainly. A push will never use an existing pack as-is, as it's very
> highly unlikely that the server requested exactly what gc --auto
> packed for us locally.
>
> Sure, undeltified objects in the pack are probably better f
1 - 100 of 110 matches
Mail list logo