On Wed, Aug 14, 2013 at 09:39:10AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > This does not have anything to do with C, but is a breakage in our
> > autoconf script.
I've meant C-programmers does understand autoconf, too. But I do not :(.
> > It appears that anything that is mea
git init
git commit --allow-empty -m "init"
git checkout -b test
echo foo > foo
git add foo
git commit -am 'add foo'
git checkout master
echo 'Important data' > foo #[1]
echo foo > .gitignore
git checkout test
If I tried a `git checkout test` after [1], I would get the error message
error: T
With git 1.8.3.3,
$ seq 5 >data
$ git add data
$ git commit -mdata
$ sed -i '2 d' data
$ git commit -pmchange
At the prompt, type e to edit the hunk. The editor doesn't start, but git
records a commit.
I found that builtin/commit.c sets the GIT_EDITOR env var to ":" when the user
specifie
On Thu, Aug 15, 2013 at 5:51 AM, Matthieu Moy
wrote:
> There's a real problem with git-repack being shell (I already mentionned
> it in the previous thread about the rewrite): it creates dependencies on
> a few external binaries, and a restricted server may not have them.
There's also the Windows
On Thu, Aug 15, 2013 at 12:25 AM, Martin Fick wrote:
> The script really is mostly a policy script, and with the
> discussions happening in other threads about how to improve
> git gc, I think it is helpful to potentially be able to
> quickly modify the policies in this script, it makes it
> easie
Add filename search config option and add it to the drop-down.
---
gitweb/gitweb.perl | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a7b0a5..087b4cb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
Add another item to the search drop-down (author/committer/etc)
to search for file names instead of file content. Output is similar
to the grep contents output, with each entry linking to the file.
---
gitweb/gitweb.perl | 59 ++
1 file changed,
2013/8/14 Junio C Hamano
> > /*
> > - * Return true if there is anything to report, otherwise false.
> > + * Return false if cannot stat a tracking branch (not exist or invalid),
> > + * otherwise true.
> > */
> > int stat_tracking_info(struct branch *branch, int *num_ours, int
> > *num_their
On Wed, Aug 14, 2013 at 3:20 PM, XinLingchao wrote:
> Hi Guys,
>
> I think I have got some trouble when I use `git clone --depth=n` command.
> Take a real repo for example:
>
>
> `git clone https://github.com/douglarek/vimrc.git --depth=1`
>
>
> then I use `git log`:
>
> ```
> commit d04ca09e
On Wednesday, August 14, 2013 05:25:42 pm Martin Fick wrote:
> On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
>
> wrote:
> > Antoine Pelisse writes:
> > > On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> > >
> > > wrote:
> > >> builtin/repack.c | 410
> > >> +
On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano
wrote:
> Martin Fick writes:
> > One suggestion would be to change the repack code to
> > create pack filenames based on the sha1 of the
> > contents of the pack file instead of on the sha1 of
> > the objects in the packfile. ...
> > I am n
On 2013-08-14 12:49, Tim Chase wrote:
> If it makes any difference, this is within a cmd.exe shell (with
> $PATH set appropriately so git is being found).
Just a follow-up, I tried it within the "bash"ish shell included in
the git install and got the same error regarding "/tmp/report.tmp".
-tkc
On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
wrote:
> Antoine Pelisse writes:
> > On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> >
> > wrote:
> >> builtin/repack.c | 410
> >> +
> >> contrib/examples/git-repack.sh | 194
> >> +
Junio C Hamano writes:
> Stefan Beller writes:
>
>> I asked for a todo wish list a few weeks ago, but got no real answer,
>> but rather: "Pick your choice and try to come up with good patches".
>
> Hmph, I hope that wasn't me.
>
> There are some good ones here;
>
> http://git-blame.blogspot.co
Martin Fick writes:
> One suggestion would be to change the repack code to create
> pack filenames based on the sha1 of the contents of the pack
> file instead of on the sha1 of the objects in the packfile.
> ...
> I am not 100% sure if the change in naming convention I
> propose wouldn't ca
Stefan Beller writes:
> I asked for a todo wish list a few weeks ago, but got no real answer,
> but rather: "Pick your choice and try to come up with good patches".
Hmph, I hope that wasn't me.
There are some good ones here;
http://git-blame.blogspot.com/search?q=leftover
Some are trivial,
Antoine Pelisse writes:
> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> wrote:
>> builtin/repack.c | 410
>> +
>> contrib/examples/git-repack.sh | 194 +++
>> git-repack.sh | 194 ---
>
> I
On Wednesday, August 14, 2013 04:16:35 pm Stefan Beller
wrote:
> On 08/14/2013 07:25 PM, Martin Fick wrote:
> > I have been holding off a bit on expressing this
> > opinion too because I don't want to squash someone's
> > energy to improve things, and because I am not yet a
> > git dev, but since
On 08/14/2013 07:25 PM, Martin Fick wrote:
> I have been holding off a bit on expressing this opinion too
> because I don't want to squash someone's energy to improve
> things, and because I am not yet a git dev, but since it was
> brought up anyway...
It's ok, if you knew a better topic to wor
Johannes Sixt writes:
> Am 14.08.2013 20:05, schrieb Junio C Hamano:
>> Stefano Lattarini writes:
>>
>>> My problems is that some new automagical interpretation of the bare
>>> @' character (introduced after 1.8.3) has destroyed my use case:
>>> ...
>>> I don't want to ask you to revert this new
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Stefano Lattarini writes:
My problems is that some new automagical interpretation of the bare
@' character (introduced after 1.8.3) has destroyed my use case:
...
I don't want to ask you to revert this new behaviour, but I'd like to
at least have an
[re-sending to the list, sorry Junio for the duplicate mail]
On 08/14/2013 07:05 PM, Junio C Hamano wrote:
> Stefano Lattarini writes:
>
>> My problems is that some new automagical interpretation of the bare
>> @' character (introduced after 1.8.3) has destroyed my use case:
>> ...
>> I don't wa
I've been sparring with the proper syntax and hope someone can give
me the magic I'm missing. I want to do something of the form
c:\temp> git svn clone "file:///x:/path/to/repo/trunk/utils/project1"
but get various failures. My best-effort (above) gets me as far as
actually starting some sort
On Wed, 14 Aug 2013, Junio C Hamano wrote:
> Also repacking may have a funny corner case. I do not recall the
> details as the above was a long time ago, but when I was tracking it
> down, a delta was made against one copy of the base object, and
> referred to it using delta-offset, while there wa
On Wed, 14 Aug 2013, Jeff King wrote:
> 1. Is sha1_entry_pos wrong to barf on duplicate items in the index? If
> so, do we want to fix it, or simply retire GIT_USE_LOOKUP?
I'd think that sha1_entry_pos should be more lenient here, especially if
this doesn't compromize the overall git beha
Junio C Hamano writes:
> Jeff King writes:
>
>> lookup does not. It hits an assert() that can only be triggered in the
>> face of duplicate objects. For example:
>>
>> $ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
>> commit
>>
>> $ GIT_USE_LOOKUP=1 git cat-file -t 4ea4acbcb09
Jeff King writes:
> lookup does not. It hits an assert() that can only be triggered in the
> face of duplicate objects. For example:
>
> $ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
> commit
>
> $ GIT_USE_LOOKUP=1 git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
> g
Stefano Lattarini writes:
> ... But in that case, I'd like some assurance that such a character
> is not going to be turned into a magical character some time in the
> future ;-)
I'd say that any special letter could be considered a fair game by
the next person who would want a funky short-cut.
I'm tracking down a rather odd problem in a packfile I found on GitHub.
This particular packfile contains the same object at various offsets
within the file. In fact there are several packfiles that exhibit this
behavior, all in the same repository, and in each one there are several
duplicated obje
Stefano Lattarini writes:
> My problems is that some new automagical interpretation of the bare
> @' character (introduced after 1.8.3) has destroyed my use case:
> ...
> I don't want to ask you to revert this new behaviour, but I'd like to
> at least have an option to disable it.
I do not think
Hello list.
In the last year or so, I developed a personal idiom of using a
naming scheme of "@/BRANCH-NAME/"to "save" the older versions
of branches I'm going to rebase (interactively or not). Here is an
idealized example of my use case:
$ git co --help
`git co' is aliased to `checkout'
Antoine Pelisse writes:
> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> wrote:
>> builtin/repack.c | 410
>> +
>> contrib/examples/git-repack.sh | 194 +++
>> git-repack.sh | 194 ---
>
> I
On Wednesday, August 14, 2013 10:49:58 am Antoine Pelisse
wrote:
> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
>
> wrote:
> > builtin/repack.c | 410
> > +
> > contrib/examples/git-repack.sh | 194
> > +++ git-repack.sh
Good Day,
I appologize for using this medium of internet to reach you, though it has
been greatly abused, but I chose to reach you because it is still the
fastest meansof communication in the world,however this correspondent is
unofficial and private.
My name is Yong Wong, I work with the hang
On Wed, Aug 14, 2013 at 07:04:37PM +0200, Stefan Beller wrote:
> But apart from my blabbering, I think ivegy made a good point:
> The C parts just don't rely on external things, but only libc and
> kernel, so it may be nicer than a shell script. Also as it is used
> serversided, the performance as
On 08/14/2013 06:49 PM, Antoine Pelisse wrote:
> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> wrote:
>> builtin/repack.c | 410
>> +
>> contrib/examples/git-repack.sh | 194 +++
>> git-repack.sh | 194
Stefan Beller writes:
> diff --git a/builtin/repack.c b/builtin/repack.c
> new file mode 100644
> index 000..d39c34e
> --- /dev/null
> +++ b/builtin/repack.c
> @@ -0,0 +1,410 @@
> +/*
> + * The shell version was written by Linus Torvalds (2005) and many others.
> + * This is a translation int
Stefan Beller writes:
> On 08/14/2013 12:06 AM, Junio C Hamano wrote:
>> * sb/parseopt-boolean-removal (2013-08-07) 9 commits
>> (merged to 'next' on 2013-08-08 at b138a2d)
>> + revert: use the OPT_CMDMODE for parsing, reducing code
>> + checkout-index: fix negations of even numbers of -n
>>
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
wrote:
> builtin/repack.c | 410
> +
> contrib/examples/git-repack.sh | 194 +++
> git-repack.sh | 194 ---
I'm still not sure I understand the tr
On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty wrote:
> On 08/14/2013 12:40 PM, Andres Perera wrote:
>> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
>>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty writes:
> # all reflog entries that are not on
Junio C Hamano writes:
> This does not have anything to do with C, but is a breakage in our
> autoconf script. It appears that anything that is meant to be
> appended at end via $config_appended_defs mechanism is missing from
> the end result.
>
> In fact, symbols whose explicit substitution the
* Suggestions by Matthieu Moy have been included.
* I think it is completed apart from small todos and bugfixes.
* breaks the test suite, first breakage is t5301 (gc, sliding window)
Signed-off-by: Stefan Beller
---
Makefile | 2 +-
builtin.h | 1 +
On 08/14/2013 09:26 AM, Matthieu Moy wrote:
> I suggested that you first enrich the test suite if needed. Did you
> check that the testsuite had good enough coverage for git-repack?
There are already quite some tests using git-repack for testing other
purposes. Also git repack seems to be called f
Alexey Shumkin writes:
>>From time to time, I use `git grep -P` to search text in sources using PCRE.
> Today I was suprised when that command gave me the error
> "fatal: cannot use Perl-compatible regexes when not compiled with
> USE_LIBPCRE"
>
> As far as I always use
> ./configure
Jeff King writes:
> Or hmm. Maybe that is what you mean by "choke on it". Choke on the
> invalid config, not on the new syntax.
Yes ;-)
--
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.kern
Jiang Xin writes:
> Command "git branch -vv" will report tracking branches, but invalid
> tracking branches are also reported. This is because the function
> stat_tracking_info() can not distinguish whether the upstream branch
> does not exist, or nothing is changed between one branch and its
> u
Jiang Xin writes:
> Command "git branch -vv" will report tracking branches, but invalid
> tracking branches are also reported. This is because the function
> stat_tracking_info() can not distinguish whether the upstream branch
> does not exist, or nothing is changed between one branch and its
> u
[updated subject, as we are very far off the original topic]
On Wed, Aug 14, 2013 at 07:00:58AM -0700, Junio C Hamano wrote:
> > > This whole discussion is basically implementing conditional config.
> > > [...] The problem is that it would be tricky to do in a
> > > backwards-compatible way.
> >
Junio C Hamano writes:
> On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
> wrote:
>>
>> Jeff King writes:
>>
>> > This whole discussion is basically implementing conditional config.
>> > [...] The problem is that it would be tricky to do in a
>> > backwards-compatible way.
>>
>> That could be don
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
wrote:
>
> Jeff King writes:
>
> > This whole discussion is basically implementing conditional config.
> > [...] The problem is that it would be tricky to do in a
> > backwards-compatible way.
>
> That could be done with "conditional comments" like
>
Hello, Stefan!
I'll begin from afar.
>From time to time, I use `git grep -P` to search text in sources using PCRE.
Today I was suprised when that command gave me the error
"fatal: cannot use Perl-compatible regexes when not compiled with
USE_LIBPCRE"
As far as I always use
./configur
Peff, thanks for your detial explain, and I think I have got the point :P
-Lingchao Xin
> Date: Wed, 14 Aug 2013 07:59:56 -0400
> From: p...@peff.net
> To: dougla...@outlook.com
> CC: stefanbel...@googlemail.com; git@vger.kernel.org; junchunx.g...@gmail.c
On Wed, Aug 14, 2013 at 05:19:36PM +0800, XinLingchao wrote:
> > There was a similar discussion going on in July this year,
> > maybe this is an interesting read with respect to this topic
> > http://www.spinics.net/lists/git/msg196138.html
> >
> Stefan, I do NOT think so, the key point is not abo
> My best theory so far:
> malloc()/free() actually use mmap()/munmap() for large allocations.
> mallopt(3) tells me that [...]
Many things I don't grab at first go :-)
Last night I did a long git-bisect of the kernel and was able to
pinpoint a change in the Linux memory management as cause (see
Hi,
I want to get rid of my script attaching fake Header lines to a pull-request to
be send to my imap by imap-send.
Or in other words, I want "git request-pull <...> | git imap-send" to work as
expected. Bevore I'm going to work on the code and send patches I want to hear
from you if such a patc
Hello everybody!
I'm the guy having the issue, that in a particular Git repository the
reads of an object fail the SHA1 reproducible on *two independent
machines* .
The issue occurs on a very specific repository starting with Linux
Kernel 3.7.2. Unfortunately my E-Mail to the kernel list dit get
Raza Ali writes:
> I have force added a file we usually like to ignore (but keep in the
> repository). That was a change a while ago, and cannot be undone
> without serious pain. I would like to re-ignore the file though, as we
> dont want to track changes to it. Some of the options I came across
---
> Date: Wed, 14 Aug 2013 10:51:53 +0200
> From: stefanbel...@googlemail.com
> To: dougla...@outlook.com
> CC: git@vger.kernel.org; junchunx.g...@gmail.com
> Subject: Re: About *git clone --depth=n* puzzle
>
> On 08/14/2013 10:20 AM, XinLingchao wrote:
>> Hi G
Ben Tebulin writes:
> 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
On 08/14/2013 12:40 PM, Andres Perera wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty writes:
>>>
# all reflog entries that are not on a branch, tag, or remote
d1 = !gitk --date-order $(git l
On 08/14/2013 10:20 AM, XinLingchao wrote:
> Hi Guys,
>
> I think I have got some trouble when I use `git clone --depth=n` command.
> Take a real repo for example:
>
>
> `git clone https://github.com/douglarek/vimrc.git --depth=1`
>
>
> then I use `git log`:
>
> ```
> commit d04ca09e
Jeff King writes:
> This whole discussion is basically implementing conditional config.
> [...] The problem is that it would be tricky to do in a
> backwards-compatible way.
That could be done with "conditional comments" like
# if then
[core]
pager = less
# endif
That's rather ugly, a
Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command. Take
a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
```
commit d04ca09ecc723739123fae11ad56784eb0c9b36a
Author: Lingchao Xin
Date:
On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> I guess we could do something like:
> >>
> >> [include "repo:...your regex here..."]
> >> path = .gitconfig-only-for-some-repos
> >> [include "env:USE_MY_MAGIC_CONFIG"
On Wed, Aug 14, 2013 at 09:09:05AM +0200, Michael Haggerty wrote:
> Gaaak! Let me again plead for supporting a post-clone hook rather than
> inventing some crazy config-file syntax that is becoming ever more
> complicated. A post-clone hook would make all of these things that have
> been suggest
Junio C Hamano writes:
> Jeff King writes:
>
>> I guess we could do something like:
>>
>> [include "repo:...your regex here..."]
>> path = .gitconfig-only-for-some-repos
>> [include "env:USE_MY_MAGIC_CONFIG"]
>> path = .gitconfig-only-when-magic-env-set
>
> I am not sure if "env" is
Stefan Beller writes:
> This is the beginning of the rewrite of the repacking.
(please, mark your patch as RFC/PATCH in the subject in this case)
A few quick comments on style below.
> Makefile | 2 +-
> builtin.h | 1 +
> builtin/repack.c
Stefan Beller writes:
> Also I'd like to propose a small technical change:
> I found no easy way to get a subset of files in a specific directory,
> which is very easy in the shell version via * (rm
> file/in/dir/startswithprefix-*),
> So maybe instead of just prefixing the temporary files such
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>> Sitaram Chamarty writes:
>>
>>> # all reflog entries that are not on a branch, tag, or remote
>>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches
>>> --tags --re
On 08/13/2013 01:46 PM, Jeff King wrote:
> On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:
>
>> I applied this on top of latest next (1da3ebde8999d07), and it worked
>> perfectly for my use case.
>>
>> For what it's worth, it also passed the test suite!
>>
>> Would be great to see t
On Wed, Aug 14, 2013 at 12:02:24PM +0530, Sitaram Chamarty wrote:
> >> # all reflog entries that are not on a branch, tag, or remote
> >> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches
> >> --tags --remotes
> [...]
>
> > A potential problem is that the output from "log
71 matches
Mail list logo
