'git rebase' uses the full onto sha1 for the reflog message whereas 'git
rebase -i' uses the short sha1. This is not only inconsistent, but can
lead to problems when the reflog is inspected at a later time at which
that abbreviation may have become ambiguous.
Make 'rebase -i' use the full onto
On Fri, Aug 10, 2012 at 6:52 AM, David Aguilar dav...@gmail.com wrote:
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar dav...@gmail.com
---
If you want to have --tool-help mentioned, use this patch.
Remove the entry for --tool-help in the documentation as it is
already mentioned in the documentation for --tool.
Signed-off-by: David Aguilar dav...@gmail.com
---
Incompatible with the previous patch, but if you prefer to
mention --tool-help in the docs for --tool only, then choose
this one.
On Fri, Aug 03, 2012 at 12:19:16PM -0400, Jeff King wrote:
Instead of having the client advertise a particular version
number in the git protocol, we have managed extensions and
backwards compatibility by having clients and servers
advertise capabilities that they support. This is far more
If we have capabilities to send to the server, we send the
regular want line followed by a NUL, then the
capabilities; otherwise, we do not even send the NUL.
However, when checking whether we want to send the quiet
capability, we check args-quiet, which is wrong. That flag
only tells us whether
Commit ff5effdf taught both clients and servers of the git
protocol to send an agent capability that just advertises
their version for statistics and debugging purposes.
However, the protocol-capabilities.txt document indicates
that the client's advertisement is actually a response, and
should
We already take care to parse a capability like foo=bar
properly, but the code does not provide a good way of
actually finding out what is on the right-hand side of the
=.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 2 ++
connect.c | 32
2 files
Fetch-pack's verbose mode is more of a debugging mode (and
in fact takes two -v arguments to trigger via the
porcelain layer). Let's mention the server version as
another possible item of interest.
Signed-off-by: Jeff King p...@peff.net
---
Like I mentioned before, I'm lukewarm on this one,
On Fri, Aug 10, 2012 at 3:58 AM, Jeff King p...@peff.net wrote:
+ * Parse features of the form feature=value. Returns NULL if the feature
+ * does not exist, the empty string if it exists but does not have an =, or
+ * the content to the right of the = until the first space (or end of
+ *
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a
dash instead of a slash. This is required for Git for Windows because
slashes in command line arguments get mangled with
On 08/09, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
On 08/09, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk
On Thu, Aug 09, 2012 at 05:13:51PM -0700, H. Peter Anvin wrote:
I have some contributors who consistently put their commentary
*before* the --- line rather than *after* it, presumably with the
notion that it is some kind of cover text. This messes with git
am, and so I end up having to edit
On 08/10/2012 12:36 PM, Jeff King wrote:
On Thu, Aug 09, 2012 at 05:13:51PM -0700, H. Peter Anvin wrote:
I have some contributors who consistently put their commentary
*before* the --- line rather than *after* it, presumably with the
notion that it is some kind of cover text. This messes
On Thu, Aug 09, 2012 at 08:39:51AM -0700, Martin von Zweigbergk wrote:
Add test cases for 'git rebase --keep-empty' with and without an
empty commit already in upstream. The empty commit that is about to
be rebased should be kept in both cases.
Signed-off-by: Martin von Zweigbergk
Junio C Hamano gits...@pobox.com writes:
If you found that an entry you read halfway has an inconsistent crc,
and if you suspect that is because somebody else was writing to the
same index, it is a _sure_ sign that you are not alone, and all the
entries you read so far to the core, even if
Hi,
I am not sure to understand why having two physically disconnected
events, in time and in place. Personally I'd rather see one event,
maybe longer than the previous occurrences to accommodate for the user
and developer centric topics. Along this line, maybe it would be best
to begin the event
Jeff King p...@peff.net writes:
If I understand your issue, somebody is writing:
From: them
To: you
Date: ...
Subject: [PATCH] subject line
commit message body
some cover letter material that should go below the ---
---
[diffstat + diff]
The users I am referring to generally have a --- line, rather than a scissor,
between the cover text and commit. Also, there is (almost) always a From: line
and subject at the top of the patch proper.
Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
If I understand
Thomas Rast tr...@student.ethz.ch writes:
But I think the idea always was that any write that changes the basic
layout of the file (so that you would read something wrong) will need a
full rewrite. Otherwise we're too far in DB land.
Most updates will be
of the update the stat and/or sha1
Hi folks
I'm a brand new subscriper of this mailing list, so please forgive if I
violate some protocol or talk about things that had been discussed to death
earlier.
I'm currently in the process of porting git (1.7.11.4 for now) to the HP
NonStop platform and found several issues:
- HP NonStop
From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
Behalf Of Joachim Schmitz
Sent: Friday, August 10, 2012 5:01 PM
To: git@vger.kernel.org
Cc: rsbec...@nexbridge.com
Subject: RE: [PATCH v2] add tests for 'git rebase --keep-empty'
Hi folks
I'm a brand new subscriper
On 08/10, Junio C Hamano wrote:
Thomas Rast tr...@student.ethz.ch writes:
But I think the idea always was that any write that changes the basic
layout of the file (so that you would read something wrong) will need a
full rewrite. Otherwise we're too far in DB land.
Most updates will
Joachim Schmitz j...@schmitz-digital.de writes:
- HP NonStop is lacking poll(),...
- HP NonStop is lacking getrlimit(), fsync(), setitimer()...
I would check compat/win32 and friends and see what other platforms
that lack this and that do, if I were you.
so telling configure to search for
On Fri, Aug 10, 2012 at 8:04 AM, Joachim Schmitz
j...@schmitz-digital.de wrote:
- HP NonStop is lacking poll(), git is making quite some use of it.
My Solution: I 'stole' the implementation from GNUlib, which implements
poll() using select().
Git should either provide its own poll(), not use
Patrick Renaud prenau...@gmail.com writes:
I am not sure to understand why having two physically disconnected
events, in time and in place. Personally I'd rather see one event,
maybe longer than the previous occurrences to accommodate for the user
and developer centric topics.
I think a
On 08/10/2012 09:15 AM, Junio C Hamano wrote:
H. Peter Anvin h...@zytor.com writes:
The users I am referring to generally have a --- line, rather than
a scissor, between the cover text and commit. Also, there is
(almost) always a From: line and subject at the top of the patch
proper.
On 31.07.12 20:37, Junio C Hamano wrote:
In practice, the majority of paths do not have utf8 that needs
the canonicalization. Lazily call iconv_open()/iconv_close() to
avoid unnecessary overhead.
Signed-off-by: Junio C Hamano gits...@pobox.com
Helped-by: Ralf Thielow ralf.thie...@gmail.com
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Friday, August 10, 2012 6:21 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org; rsbec...@nexbridge.com
Subject: Porting to a new platform
Joachim Schmitz j...@schmitz-digital.de writes:
- HP NonStop is lacking poll(),...
- HP NonStop
On Aug 10, 2012, at 11:17 AM, Neeraj Mathawan wrote:
We have decided to use GIT for a huge government implementation, I am looking
for some help with installation of GIT SERVER.
Few questions:-
1. What platform to choose - UNIX, MAC or Windows? We have lot of windows
2008
On Fri, Aug 10, 2012 at 10:32 AM, Joachim Schmitz
j...@schmitz-digital.de wrote:
then use `git init --bare` in a new directory to copy in the templates,
and see if
its the template copying code that is making an incorrect copy.
git init --bare gives the same error. It isn't copying any of the
On Fri, Aug 10, 2012 at 08:34:45AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Ugh, the jk/version-string topic breaks fetching from Google Code. With
my patch, the client unconditionally sends an agent=foo capability,
but the server does not like seeing the unknown
On Fri, Aug 10, 2012 at 11:17 AM, Neeraj Mathawan neer...@yahoo.com wrote:
Hi,
We have decided to use GIT for a huge government implementation, I am looking
for some help with installation of GIT SERVER.
Few questions:-
1. What platform to choose - UNIX, MAC or Windows? We have lot of
On Fri, Aug 10, 2012 at 8:37 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
Ugh, the jk/version-string topic breaks fetching from Google Code. With
my patch, the client unconditionally sends an agent=foo capability,
but the server does not like seeing the unknown
On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
I asked the folks who run code.google.com and they are indeed seeing
something like these in their logs:
Client asked for capability agent=git/1.7.12.rc2.79.g86c1702 that was
not advertised.
FWIW, this error comes from
Torsten Bögershausen tbo...@web.de writes:
On 31.07.12 20:37, Junio C Hamano wrote:
In practice, the majority of paths do not have utf8 that needs
the canonicalization. Lazily call iconv_open()/iconv_close() to
avoid unnecessary overhead.
Signed-off-by: Junio C Hamano gits...@pobox.com
On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
Thanks for the data point. I knew you guys ran some custom code, so I
wasn't sure how widespread this is. The fact that other dulwich-based
servers would see the same issue makes me doubly sure that my fix is the
right
Thanks Drew, I will look into this.
Neeraj Mathawan
610-213-0673
On Aug 10, 2012, at 1:57 PM, Drew Northup n1xim.em...@gmail.com wrote:
On Fri, Aug 10, 2012 at 11:17 AM, Neeraj Mathawan neer...@yahoo.com wrote:
Hi,
We have decided to use GIT for a huge government implementation, I am
Dave Borowitz dborow...@google.com writes:
You may also notice in that code a set of innocuous_capabilities,
which IIRC is the complete set of capabilities, at the time of
writing, that the C git client may send without the server advertising
them. Such a set (painstakingly assembled, I
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
So the packing parameters are the same these days for either method.
Note that git gc --aggressive will also use -f to recompute all
deltas. This is more expensive, but gives git more flexibility if the
old deltas were
Using git p4 on git version 1.7.12.rc2 has path issues. Standard
clone/sync ops apparently place detected master and branches on
independent and parallel directory structures instead of git branches.
See http://stackoverflow.com/q/11893688/1588831 for a full demo of the problem.
Thanks,
-Matt
Jeff King p...@peff.net writes:
Instead, each client must record whether we saw an agent
string from the server, and respond with its agent only if
the server mentioned it first.
Just a couple of minor comments.
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index
Junio C Hamano gits...@pobox.com wrote:
I should have asked this yesterday, but do you mean you want to have
your maint in the upcoming 1.7.12? This does look like a useful
thing to do, but does not seem like a regression fix to me.
Yeah, I wasn't sure what to name it since my master is still
Jeff King p...@peff.net writes:
+/*
+ * Parse features of the form feature=value. Returns NULL if the feature
+ * does not exist, the empty string if it exists but does not have an =, or
+ * the content to the right of the = until the first space (or end of
+ * string). The cannot contain
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Friday, August 10, 2012 7:33 PM
To: 'Shawn Pearce'
Cc: 'git@vger.kernel.org'; 'rsbec...@nexbridge.com'
Subject: RE: Porting git to HP NonStop
From: Shawn Pearce [mailto:spea...@spearce.org]
Sent: Friday, August 10, 2012 6:28
Felix Natter fnat...@gmx.net writes:
I have a few questions about this:
As I am coming from large depth is harmful school, I would
recommend
- git repack -a -d -f with large --window with reasonably short
--depth once,
So something like --depth=250 and --window=500?
I would use
Phil Hord phil.h...@gmail.com writes:
I agree that 'git reset --hard' should be mentioned in the hint for
newbies, but this conflicts with my desire to avoid giving chainsaws
to toddlers.
Exactly. So what are you suggesting?
Perhaps force the user to go through a series of quiz when git
Peter Baumann waste.mana...@gmx.de wrote:
First, let me thank you for your review and your detailed explanation.
I really appreciate it.
You're welcome, Peter. Thanks again for the patch. I've signed-off and
pushed for Junio.
The following changes since commit
A while ago when I was looking at revision.c, I was surprised to see
that commits are sorted even when --no-walk is passed, but as 8e64006
(Teach revision machinery about --no-walk, 2007-07-24) points out,
this can be useful for doing
$ git log --abbrev-commit --pretty=oneline --decorate --all
On Fri, Aug 10, 2012 at 12:45:19PM -0700, Junio C Hamano wrote:
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index fe56596..bc7a0f9 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -19,6 +19,7 @@ static int prefer_ofs_delta = 1;
static int no_done;
On 10.08.12 20:18, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
On 31.07.12 20:37, Junio C Hamano wrote:
In practice, the majority of paths do not have utf8 that needs
the canonicalization. Lazily call iconv_open()/iconv_close() to
avoid unnecessary overhead.
On Fri, Aug 10, 2012 at 01:01:11PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+/*
+ * Parse features of the form feature=value. Returns NULL if the feature
+ * does not exist, the empty string if it exists but does not have an =,
or
+ * the content to the right of
Jeff King p...@peff.net writes:
On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
Thanks for the data point. I knew you guys ran some custom code, so I
wasn't sure how widespread this is. The fact that other dulwich-based
servers would see the same issue makes me doubly sure
Eric Wong normalper...@yhbt.net writes:
Peter Baumann waste.mana...@gmx.de wrote:
First, let me thank you for your review and your detailed explanation.
I really appreciate it.
You're welcome, Peter. Thanks again for the patch. I've signed-off and
pushed for Junio.
The following changes
Junio C Hamano gits...@pobox.com wrote:
Eric Wong normalper...@yhbt.net writes:
Peter Baumann (1):
git svn: reset invalidates the memoized mergeinfo caches
Robert Luberda (1):
git svn: handle errors and concurrent commits in dcommit
OK, so these two are fit for 1.7.12-rc3
On Fri, Aug 10, 2012 at 02:25:51PM -0700, Junio C Hamano wrote:
I don't think there's any bug here. They are all of a class of features
where the client can handle the case where the server simply ignores the
request. However it is certainly food for thought if we are considering
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
There is also cherry-pick/revert, which I _think_ does not really want
the revisions sorted.
Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
call prepare_revision_walk().
It instead should first check the
Torsten Bögershausen tbo...@web.de writes:
After cloning, I set git config core.precomposeunicode true.
git is v1.7.12.rc2,
git_git/git is with your patch.
git v1.7.12.rc2:
tb@birne:~/projects/git/linux-2.6 for f in 1 2 3 4 5; do time git status ;
done 21 | egrep ^user|^real|^sys
real
On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
When evaluating a change in the interoperability area, it does not
add much more confidence to the correctness that the change has been
in use for months with the same partner than that it has been used
to talk to many different
Jeff King p...@peff.net writes:
I would think the extra memory allocation would dwarf it, anyway.
...
and a new caller can do something like
agent = server_supports(agent);
if (!agent || !agent[5])
... no agent ...
else {
int span =
Hi,
when I create a git repository, add a file containing utf-8 characters
or umlauts (like öäü.txt), commit and then export the HEAD revision to a
zip archive using git archive --format zip -o 1.zip HEAD, the zip file
contains incorrect filenames:
$ unzip -l 1.zip
Archive: 1.zip
On Fri, Aug 10, 2012 at 2:50 PM, Jeff King p...@peff.net wrote:
On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
When evaluating a change in the interoperability area, it does not
add much more confidence to the correctness that the change has been
in use for months with the
Shawn Pearce spea...@spearce.org writes:
On Fri, Aug 10, 2012 at 2:50 PM, Jeff King p...@peff.net wrote:
On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
When evaluating a change in the interoperability area, it does not
add much more confidence to the correctness that the
Sven Strickroth sven.strickr...@tu-clausthal.de writes:
when I create a git repository, add a file containing utf-8 characters
or umlauts (like öäü.txt), commit and then export the HEAD revision to a
zip archive using git archive --format zip -o 1.zip HEAD, the zip file
contains incorrect
Am 11.08.2012 00:47 schrieb Junio C Hamano:
Do you know in what encoding the pathnames are _expected_ to be
stored in zip archives?
re-encoding to latin1 does not always work and may break double byte
totally (e.g. chinese or japanese).
PKZIP APPNOTE seems to be the zip standard and it
On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
There is also cherry-pick/revert, which I _think_ does not really want
the revisions sorted.
Yes, I think sequencer.c::prepare_revs() is wrong to
66 matches
Mail list logo
