Am 6/26/2013 12:19, schrieb Alexey Shumkin:
One can set an alias
$ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local
to see the log as a pretty tree (like *gitk* but in
1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) says this is not allowed, as they contradict each other.
However, --ff-only is about asserting the input of the merge, and
--no-ff is about instructing merge to always create a merge commit, i.e.
it makes sense to use
Am 28.06.2013 13:59, schrieb Stefan Näwe:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator'
brian m. carlson:
+ /* Check the value here */
+ if (codepoint = 0xd800 codepoint = 0xdfff)
+ return bad_offset;
if ((x 0xF800) == 0xD800)
is slightly shorter, albeit a bit more difficult to read.
Please also consider adding some
brian m. carlson:
int offset = 0;
+ static const unsigned int max_codepoint[] = {
+ 0x7f, 0x7ff, 0x, 0x1f
+ };
Since Unicode is not defined beyond U+10, you can easily make the
last range end at U+10FFF. Doing that, ...
if
Benoît Person benoit.per...@ensimag.fr writes:
Another idea crossed my mind: for now the test suite creates a symlink
of git-remote-mediawiki in the toplevel if it's not installed. It
would be better to use the bin-wrapper in the testsuite I think ?
Absolutely. The symlink was a dirty hack
On 01/07/13 03:30, Jens Lehmann wrote:
Am 29.06.2013 11:11, schrieb Chris Packham:
On 28/06/13 22:42, Fredrik Gustafsson wrote:
technically it looks fine to me (except for the lack of tests) but I'm
not sure I follow the use case.
In your case, you want to run a script to determinate if that
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows the
user some finer grained control over how the update is done. The primary
motivation for this was interoperability with stgit however being able
to intercept
On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano gits...@pobox.com wrote:
The pack-*.keep files are temporary, and serve no purpose in the
clone.
They are not temporary, actually. A user can deliberatey create a
keep marker after packing with a good set of parameters, so that
the resulting
On 07/01/2013 09:01 AM, Miklos Vajna wrote:
1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) says this is not allowed, as they contradict each other.
However, --ff-only is about asserting the input of the merge, and
--no-ff is about instructing merge to always
Hi Michael,
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
mhag...@alum.mit.edu wrote:
On 07/01/2013 09:01 AM, Miklos Vajna wrote:
1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) says this is not allowed, as they contradict each other.
However,
Michael Haggerty mhag...@alum.mit.edu writes:
So I think that command invocations with more than one of {--ff,
--no-ff, --ff-only} should respect the last option listed rather
than complaining about cannot combine options.
If I find the time (unlikely) I might submit a patch to implement
On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano gits...@pobox.com
wrote:
As to --no-ff vs --ff-only, --ff-only has always meant only
fast-forward updates are allowed. We do not want to create a merge
commit with this operation. I do agree with you that the proposed
patch changes
Jens Lindström j...@opera.com writes:
On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano gits...@pobox.com wrote:
The pack-*.keep files are temporary, and serve no purpose in the
clone.
They are not temporary, actually. A user can deliberatey create a
keep marker after packing with a good set
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
t/t7500-commit.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 436b7b6..e166ac8 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -13,8 +13,8 @@ commit_msg_is ()
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
t/lib-rebase.sh |2 ++
1 file changed, 2 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index cfd3409..7f119e2 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -17,6 +17,8 @@
# (squash, fixup, edit, or reword)
Excerpts from Junio C Hamano's message of Thu Jun 27 13:50:45 -0700 2013:
Andrew Pimlott and...@pimlott.net writes:
I should update the function I introduced first. I will re-submit
the rebase -i --autosquash patch and wait for acceptance before
trying to fix other things.
Thanks.
Chris Packham judge.pack...@gmail.com writes:
Subject: Re: [RFC/PATCHv2] submodule: add ability to configure update command
ability to configure wants to be rephrased to make it more useful
in the shortlog output to help me update release notes ;-)
Subject: [PATCH] submodule update: allow
Miklos Vajna vmik...@suse.cz writes:
OK, so if I get it right, the problem is that users got used to
that the --ff-only not only means a precondition for the merge,
but also means either don't create a merge commit or fail, while
my patch would change this second behaviour.
It is not just
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Because they are common enough, and doing the same for an arbitrary
object is just as easy to do something like:
git clone
Chris Packham judge.pack...@gmail.com writes:
+ !*)
+ command=$(expr $update_module : '!\(.*\)')
command=${command#!}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Andrew Pimlott and...@pimlott.net writes:
Applies on top of rebase -i patch already accepted. Mostly whitespace
changes.
Thanks, will queue.
--
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
Eric Sunshine sunsh...@sunshineco.com writes:
In this submission, the command name has changed to git-contacts since
git-related felt too generic. (git-contacts seemed best of several
possibilities I surveyed: git-people, git-interested, git-mentioned,
git-blame-us.)
I admit I am pretty bad
Excerpts from Junio C Hamano's message of Mon Jul 01 09:52:05 -0700 2013:
Wow. How could all of us missed this for a long time?
:-) I don't know, but little is more frustrating than a misleading
diagnostic.
BTW, I didn't expect git-send-email to send those two messages in a
thread. I'll keep
It would be nice to support more generic specs for the --branch
switch. But it is complicated because the refs have not been fetched
yet during the clone, and so normal refs operations -- which expect to
work on a local repository -- do not work. So, the ref is looked up
locally from a list in
Eric Sunshine sunsh...@sunshineco.com writes:
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
new file mode 100755
index 000..9007bae
--- /dev/null
+++ b/contrib/contacts/git-contacts
@@ -0,0 +1,121 @@
+#!/usr/bin/perl
+
+# List people who might be
Right, the format and implementation in JGit can do Counting objects
in 87ms for the Linux kernel history.
Actually, that was the timing when I first pushed the change. With the
improvements submitted throughout the year, we can do counting in
50ms, on my same machine.
But I think we are
Eric Sunshine sunsh...@sunshineco.com writes:
Accept multiple patch files rather than only one. For example:
% git contacts feature/*.patch
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
@@ -93,6 +96,7 @@ sub commits_from_patch {
while ($f) {
if (/^From
Junio C Hamano gits...@pobox.com writes:
while ($f) {
if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
# beginning of a patch
$id = $1;
}
next if (!defined $id);
# inline the
OS X's sed only accepts basic regular expressions, which does not
allow the + quantifier. However '..*' (anything, followed by zero or
more anything) is the same as '.\+' (one or more anything) and valid
in any regular expression language.
Signed-off-by: Brian Gernhardt
On Mon, Jul 1, 2013 at 11:47 AM, Colby Ranger cran...@google.com wrote:
But I think we are comparing
apples to steaks here, Vincent is (rightfully) concerned about process
startup performance, whereas our timings were assuming the process was
already running.
I did some timing on loading
Junio C Hamano gits...@pobox.com writes:
- If the patch were prepared with a non-standard src/dst-prefix,
unconditional substr($1, 2) would call blame on a wrong (and
likely to be nonexistent) path without a useful diagnosis (the
invocation of git blame will likely die with no such
Brian Gernhardt br...@gernhardtsoftware.com writes:
OS X's sed only accepts basic regular expressions, which does not
allow the + quantifier. However '..*' (anything, followed by zero or
more anything) is the same as '.\+' (one or more anything) and valid
in any regular expression language.
This has multiple benefits: with more than one of {--ff, --no-ff,
--ff-only} respects the last option; also the command-line option to
always take precedence over the config file option.
Signed-off-by: Miklos Vajna vmik...@suse.cz
---
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
On Sat, 22 Jun 2013 23:21:03 +, Junio C Hamano wrote:
...
Are there examples of other daemon programs outside Git that have
this particular support to help such inetd implementations?
Unfortunately I only know one server that exclusively uses this
interface, and isn't even capable of
Miklos Vajna vmik...@suse.cz writes:
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
mhag...@alum.mit.edu wrote:
If I find the time (unlikely) I might submit a patch to implement these
expectations.
Seeing that the --no-ff / --ff-only combo wasn't denied just sort of
I have no time to dig this down, but I just noticed this by accident:
$ make
$ cd t
$ sh ./t7011-skip-worktree-reading.sh -d
$ cd trash*.t7011*
$ git reset --hard HEAD
error: Entry '1' not uptodate. Cannot merge.
fatal: Could not reset index
On Mon, Jul 01, 2013 at 02:28:52PM -0700, Junio C Hamano wrote:
I have no time to dig this down, but I just noticed this by accident:
$ make
$ cd t
$ sh ./t7011-skip-worktree-reading.sh -d
$ cd trash*.t7011*
$ git reset --hard HEAD
error:
When the working tree walker encounters a directory, it asks the
function treat_directory() if it should descend into it, show it as
an untracked directory, or do something else. When the directory is
the top of the submodule working tree, we used to say That is an
untracked directory, which was
The second patch is the real thing, but ls-files --killed needed
to be taught about submodules to avoid breaking stash save in a
repository with submodules, as the new safety uses it to detect what
will need to be killed (i.e. file D/F in the working tree getting
removed because we need to check
From: Petr Baudis pa...@ucw.cz
stash save is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the
Johan Herland jo...@herland.net writes:
On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano gits...@pobox.com wrote:
... I think we can go either way, and the above I think this is
being rerolld was primarily keeping the options open.
You're right. No point in setting things prematurely in
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Yes, I will send a v2 (soon-ish, I hope).
Ping?
No need to hurry, but just to make sure this didn't disappear from
everybody's radar.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Heiko Voigt hvo...@hvoigt.net writes:
This is only for review. I will resubmit this once 1.8.3 is out.
Ping?
No need to hurry, but just to make sure this didn't disappear from
everybody's radar.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Drew Northup n1xim.em...@gmail.com writes:
On Sun, Jun 2, 2013 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote:
...
--
[Stalled]
...
* jk/gitweb-utf8 (2013-04-08) 4 commits
- gitweb: Fix broken blob action parameters on blob/commitdiff
John Keeping j...@keeping.me.uk writes:
This series addressed Dave Abraham's recent bug report [1] about using
fast-import's ls command with an empty path. I also found a couple of
other places that do not handle the empty path when it can reasonably be
interpreted as meaning the root tree
Jens Lehmann jens.lehm...@web.de writes:
Am 02.06.2013 20:50, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
Am 30.05.2013 01:58, schrieb Junio C Hamano:
* jl/submodule-mv (2013-04-23) 5 commits
(merged to 'next' on 2013-04-23 at c04f574)
+ submodule.c: duplicate
Michael Haggerty mhag...@alum.mit.edu writes:
My understanding is that we are waiting on two things:
1. Consensus from the community. I would characterize the feedback on
the mailing list as limited in quantity but strongly positive [1-4] and
I think that most/all of the wishes for
Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days? I am getting this:
$ git push -n -v repo.or.cz:srv/git/alt-git.git/
403 forbidden
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
It is now in the middle of 5th week of this release cycle [*1*], and
due to the season being summer and with US holidays, I expect that
things will be more quiet than other weeks. It was a good time to
review the recent issues of whats-cooking, and that is what I just
did.
Here is a list of
Junio C Hamano gits...@pobox.com writes:
Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days? I am getting this:
$ git push -n -v repo.or.cz:srv/git/alt-git.git/
403 forbidden
fatal: Could not read from remote repository.
Please
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are in the middle of 5th week now in the 11-week releace cycle
for 1.8.4, and quite a few topics have graduated to 'master'.
Please help
Junio C Hamano gits...@pobox.com writes:
Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days? I am getting this:
$ git push -n -v repo.or.cz:srv/git/alt-git.git/
403 forbidden
fatal: Could not read from remote repository.
Seems like
My apologies.
repo.or.cz recently had some updates to support:
1) smart HTTP fetch
2) smart HTTP push (over https)
3) user removal of projects
Along with those updates it started doing more validation on paths.
I believe all the paths listed on http://repo.or.cz/w/alt-git.git are
accepted
On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
One can set an alias
$ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit
Kyle McKay mack...@gmail.com writes:
I was not previously aware that URLs not shown on that page were
accepted, thank you for bringing it to my attention.
Do you feel that it's important to accept these alternate URL versions
that are not listed on the project page:
1) Optional trailing
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t7102-reset.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t6006-rev-list-format.sh | 140 +
1 file changed, 77 insertions(+), 63 deletions(-)
diff --git
v8 of this patch series includes the following changes against v7:
1. [PATCH v8 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected
outputs
untouched
2. [PATCH v8 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs
untouched
3. [PATCH v8 3/5] t4205
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t4205-log-pretty-formats.sh | 48 +++
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git
One can set an alias
$ git config [--global] alias.lg log --graph
--pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log
One can set an alias
$ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log messages written
I have often reported problems with git fetch when there are
many refs in a repo, and I have been pleasantly surprised
how many problems I reported were so quickly fixed. :) With
time, others have created various synthetic test cases to
ensure that git can handle many many refs. A simple
On Mon, Jul 01, 2013 at 09:02:31PM -0600, Martin Fick wrote:
A simple synthetic test case with 1M refs all pointing to the same
sha1 seems to be easily handled by git these days. However, in our
experience with our internal git repo, we still have performance
issues related to having too
On Tue, Jul 02, 2013 at 12:07:58AM -0400, Jeff King wrote:
And yet another alternative would be to keep the list unsorted during
the mark_complete calls, and then sort it at the end. Like this:
Amusingly, I seem to have posted the exact same patch last year:
On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:
I replicated your test setup, and the problem is that we have many
common objects on both sides during the ref negotiation. So we end up in
rev_list_push for each one, which has the same O(n^2) behavior.
Switching it to just sort at
The earliest iteration of this test script used a magic string
110282 as the common prefix for ambiguous object names, but the
final edition switched the common prefix to 00 (10 0s).
Unfortunately, instances of the original prefix were left in the
comments and a few tests. Replace them
Here is a small two-patch series to break a test that has been
passing by mistake.
Junio C Hamano (2):
t1512: correct leftover constants from earlier edition
get_short_sha1(): correctly disambiguate type-limited abbreviation
sha1_name.c | 2 +-
One test in t1512 that expects a failure incorrectly passed. The
test prepares a commit whose object name begins with ten 0s, and
also prepares a tag that points at the commit. The object name of
the tag also begins with ten 0s. There is no other commit-ish
object in the repository whose name
Jeff King p...@peff.net writes:
On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:
I replicated your test setup, and the problem is that we have many
common objects on both sides during the ref negotiation. So we end up in
rev_list_push for each one, which has the same O(n^2)
On Mon, Jul 01, 2013 at 10:19:51PM -0700, Junio C Hamano wrote:
Like the patch below, which is built on top of next (which has Junio's
prio_queue implementation), and has both the priority queue fix for
rev_list_push and the mark_complete sort-at-the-end fix.
Wow, I saw 160 lines in my
71 matches
Mail list logo
