On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com 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 --remotes
# all dangling commits not on a branch,
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
+ config parsing options: allow
On Wed, Aug 14, 2013 at 07:42:11AM +0200, Daniel Knittl-Frank wrote:
So would that be a bug? Or maybe a feature? I would like it that
when you do a rebase and select no commits, it will rebase ontop of
the commit you chose, and remove all the commits not shown in the
interactive listing
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 -g
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 this, or
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
# all reflog entries that are not on a branch, tag, or remote
d1 = !gitk --date-order $(git log -g --pretty=%H) --not
Stefan Beller stefanbel...@googlemail.com 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
Stefan Beller stefanbel...@googlemail.com 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 +
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net 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
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 suggested
On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
I guess we could do something like:
[include repo:...your regex here...]
path = .gitconfig-only-for-some-repos
[include
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
Jeff King p...@peff.net 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 some-condition then
[core]
pager = less
# endif
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
On 08/14/2013 12:40 PM, Andres Perera wrote:
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
# all reflog entries that are not on a branch, tag, or remote
d1 = !gitk
Ben Tebulin tebu...@googlemail.com 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
-
---
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 Guys,
I
Raza Ali r...@ebi.ac.uk 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
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
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 patch
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
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 about the
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.com
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
./configure
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Jeff King p...@peff.net writes:
This whole discussion is basically implementing conditional config.
[...] The problem is that it would be tricky to do in a
[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.
That
Jiang Xin worldhello@gmail.com 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
Jiang Xin worldhello@gmail.com 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
Jeff King p...@peff.net 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
Alexey Shumkin alex.crez...@gmail.com 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
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
* 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 stefanbel...@googlemail.com
---
Makefile | 2 +-
builtin.h
Junio C Hamano gits...@pobox.com 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
On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 12:40 PM, Andres Perera wrote:
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
#
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh | 194 ---
I'm still not
Stefan Beller stefanbel...@googlemail.com 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
On 08/14/2013 06:49 PM, Antoine Pelisse wrote:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh
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
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
On Wednesday, August 14, 2013 10:49:58 am Antoine Pelisse
wrote:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh
Hello list.
In the last year or so, I developed a personal idiom of using a
naming scheme of @/BRANCH-NAME/NUMto 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'
Stefano Lattarini stefano.lattar...@gmail.com 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
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
Stefano Lattarini stefano.lattar...@gmail.com 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
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net 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
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
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 was
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
[re-sending to the list, sorry Junio for the duplicate mail]
On 08/14/2013 07:05 PM, Junio C Hamano wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
My problems is that some new automagical interpretation of the bare
@' character (introduced after 1.8.3) has destroyed my use
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Stefano Lattarini stefano.lattar...@gmail.com 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
Johannes Sixt j...@kdbg.org writes:
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Stefano Lattarini stefano.lattar...@gmail.com 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
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 work
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 it was
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh
Stefan Beller stefanbel...@googlemail.com 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;
Martin Fick mf...@codeaurora.org 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
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com 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;
On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
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 bashish shell included in
the git install and got the same error regarding /tmp/report.tmp.
-tkc
--
On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano
wrote:
Martin Fick mf...@codeaurora.org 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.
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 apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c
On Wed, Aug 14, 2013 at 3:20 PM, XinLingchao dougla...@outlook.com 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
2013/8/14 Junio C Hamano gits...@pobox.com
/*
- * 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
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
+++
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,
On Thu, Aug 15, 2013 at 12:25 AM, Martin Fick mf...@codeaurora.org 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
On Thu, Aug 15, 2013 at 5:51 AM, Matthieu Moy
matthieu@grenoble-inp.fr 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.
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
specifies
71 matches
Mail list logo
