Jed Brown wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown j...@59a2.org wrote:
...
We have
to assume that every Git (remote-hg) User is dealing with Hg Team
No, we don't.
Really? If there is no Hg Team, why bother with an Hg upstream?
Ramkumar Ramachandra wrote:
After some discussion, I hope to be able to finalize a list of fields
that will suffice for (nearly) everything.
The task is actually much easier than this. All we have to do is
finalize the list of fields that will mandatorily be written to the
link object. As I
Ramkumar Ramachandra wrote:
Great. Now, we just have to write refs/modules/branch/* at
commit-time.
Actually, we have to update things in refs/modules/ everytime we
update things in refs/heads/. In the case of a 'git branch -M' for
example, refs/heads/oldname is rewritten to
Ramkumar Ramachandra wrote:
diff --git a/builtin/clone.c b/builtin/clone.c
index e0aaf13..1b798e6 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -658,11 +659,22 @@ static void write_refspec_config(const char*
src_ref_prefix,
strbuf_release(value);
}
+static int
Ramkumar Ramachandra wrote:
diff --git a/link.c b/link.c
index bb20a51..349646d 100644
--- a/link.c
+++ b/link.c
@@ -20,8 +20,30 @@ struct link *lookup_link(const unsigned char *sha1)
int parse_link_buffer(struct link *item, void *buffer, unsigned long size)
{
+ char *bufptr =
Am 05.04.2013 07:27, schrieb Duy Nguyen:
On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano gits...@pobox.com wrote:
A brief summary or outcome from these links in the comment would
be nice.
A summary of what to consider in Documentation/technical/ somewhere
may be a very welcome addition.
Simon Ruderich si...@ruderich.org writes:
--- a/t/t4209-log-pickaxe.sh
+++ b/t/t4209-log-pickaxe.sh
@@ -116,4 +116,18 @@ test_expect_success 'log -S -i (nomatch)' '
test_cmp expect actual
'
+test_expect_success 'log -S --textconv (missing textconv tool)' '
+ echo * diff=test
Junio C Hamano wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/log-tree.h b/log-tree.h
index 9140f48..e6a2da5 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -13,6 +13,9 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
Ramkumar Ramachandra wrote:
This needs to be replaced by a .git/config parser. However, I can't
use the parser from config.c as-it-is, because it expects a section
like [core] to be present. So, we have to refactor it to optionally
parse section-less configs.
Er, sorry about the thinko: I
Antoine Pelisse wrote:
* internally, the marks are using the hg sha1s instead of the hg rev ids.
The latter are not necessarily invariant, and using the sha1s makes it
much easier to recover from semi-broken states.
I doubt this makes any difference (except for more wasted space).
I
On Thu, 2013-04-04 at 10:04 -0700, Junio C Hamano wrote:
Carlos Martín Nieto c...@elego.de writes:
On Wed, 2013-04-03 at 23:25 +0100, Philip Oakley wrote:
+ Replace the tip of the current branch with a fresh commit.
[or updated commit, or new commit, or ...]
Ack, we should lead
On Thu, Apr 4, 2013 at 10:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
From: Dusty Phillips du...@linux.ca
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4
On Thu, Apr 4, 2013 at 6:27 PM, Junio C Hamano gits...@pobox.com wrote:
Mihai Capotă mi...@mihaic.ro writes:
The git manual contains an explicit warning about the output of a
porcelain command changing: The interface to Porcelain commands on
the other hand are subject to change in order to
Document the use of kibibytes, not kilobytes, in the output of count-objects
and the reason for not correcting the output.
Also, make cvsimport comment and variable name reflect unit actually used.
Signed-off-by: Mihai Capotă mi...@mihaic.ro
---
Documentation/git-count-objects.txt |7
I'm seeing a strange problem where git diff --quiet sometimes returns an
exit code of zero even though the tree is dirty and other invocations of
git diff --quiet in the same directory return an exit code of 1. I'm
using git v1.8.2 from Debian unstable but I've also seen the problem when
running
The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='. Change this
for consistency with other Git commands.
Note that this doesi not change the handling of diff-algorithm in
merge-recursive.c since the primary interface to
Hi,
As some people suggested this is necessary for some use-cases, because revision
id numbers can change and point to different revisions.
Seems to work fine, but I wouldn't merge it just yet.
Felipe Contreras (4):
remote-hg: shuffle some code
remote-hg: improve node traversing
In preparation to shift to SHA-1's.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
We won't be able to count the unmarked commits, but we are not going to
be able to do that anyway when we switch to SHA-1 ids.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 02fda2d..9e124e1 100755
---
Otherwise we won't know if revisions are replaced.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 40 +++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
Commit 07924d4 (diff: Introduce --diff-algorithm command line option
2013-01-16) added diff-algorithm as a parameter to the recursive merge
strategy but did not document it. Do so.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/merge-strategies.txt | 6 ++
1 file changed,
John Keeping j...@keeping.me.uk writes:
The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='. Change this
for consistency with other Git commands.
Note that this doesi not change the handling of diff-algorithm in
On Thu, Apr 4, 2013 at 10:14 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Apr 2, 2013 at 4:23 PM, Max Horn m...@quendi.de wrote:
* internally, the marks are using the hg sha1s instead of the hg rev ids.
The latter are not necessarily invariant, and using the sha1s makes it
Joachim Schmitz j...@schmitz-digital.de writes:
Jed Brown wrote:
Really? If there is no Hg Team, why bother with an Hg upstream?
Huh? the counterpart of every user wpuld be some users and not no user
or no HG team, isn't it?
I'm not sure what you're getting at here, but the whole
The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='. Change this
for consistency with other Git commands.
Note that this does not change the handling of diff-algorithm in
merge-recursive.c since the primary interface to
Hi
Basically, I'm at a place where I'm considering giving up getting this
to work reliably. In general, my setup work really fine, except for the
itty-bitty detail that when I put pressure on things I tend to get into
various kinds of trouble with the central repo being corrupted.
Can
[strace attachment has been removed, email being resent]
It looks like there is a race condition going on, especially since the location
and message changes.
Could it be the file creation, file read, apply file security is happening when
it should be file create, apply security, file read?
Felipe Contreras felipe.contre...@gmail.com writes:
@@ -76,12 +78,19 @@ class Marks:
def __init__(self, path):
self.path = path
+self.clear()
+self.load()
+
+if self.version VERSION:
+self.clear()
It's friendlier to just upgrade the
git log -S doesn't respect --no-textconv:
$ echo '*.txt diff=wrong' .gitattributes
$ git -c diff.wrong.textconv='xxx' log --no-textconv -Sfoo
error: cannot run xxx: No such file or directory
fatal: unable to read files to diff
Reported-by: Matthieu Moy
On Thu, Apr 04, 2013 at 01:48:52PM -0700, Junio C Hamano wrote:
If I am reading the code correctly, it is has_changes(), which is
used for log -S (not log -G that uses diff_grep()), that does
the unnecessary get_textconv() unconditionally. The way diff_grep()
divides the work to make
Kenneth Ölwing kenn...@olwing.se writes:
Basically, I'm at a place where I'm considering giving up getting this
to work reliably. In general, my setup work really fine, except for
the itty-bitty detail that when I put pressure on things I tend to get
into various kinds of trouble with the
I noticed that it doesn't like getting multiple overlapping ranges
from the user. This fixes it.
Thomas Rast (2):
log -L: check range set invariants when we look it up
log -L: fix overlapping input ranges
line-log.c | 43 +++--
t/t4211-line-log.sh
lookup_line_range() is a good place to check that the range sets
satisfy the invariants: they have been computed and set in earlier
iterations, and we now start working with them.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
line-log.c | 26 ++
1 file changed, 26
The existing code was too defensive, and would trigger the assert in
range_set_append() if the user gave overlapping ranges.
The intent was always to define overlapping ranges as just the union
of all of them, as evidenced by the call to sort_and_merge_range_set().
(Which was already used, unlike
On 2013-04-05 15:42, Thomas Rast wrote:
Can you run the same tests under strace or similar, and gather the
relevant outputs? Otherwise it's probably very hard to say what is
going wrong. In particular we've had some reports on lustre that
boiled down to impossible returns from libc functions,
Hi!
On Thu, Apr 04, 2013 at 10:41:41PM +0200, Thomas Rast wrote:
As pointed out by Eric Wong (thanks), the initial close needs to go:
die() would again write nowhere if we close STDERR beforehand.
Perhaps we should also do the following:
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@
When we introduced the concept of detached HEAD, we made sure that
commands that operate on the history of the current branch just
work in that state. They update the HEAD to point at the new
history without affecting any branch when the HEAD is detached, just
like they update the tip of the
On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Linus Torvalds wrote:
Or you could also just edit and carry a dirty .gitmodules around for
your personal use-case.
I'm sorry, but a dirty worktree is unnecessarily painful to work with.
Bzzt. Wrong.
A dirty
From: John Keeping j...@metanate.com
When running git log -p --submodule=log, the submodule log is not
indented by the graph output, although all other lines are. Fix this by
prepending the current line prefix to each line of the submodule log.
Signed-off-by: John Keeping j...@keeping.me.uk
---
When running git log -p --submodule=log, the submodule log is not
indented by the graph output, although all other lines are. Fix this by
prepending the current line prefix to each line of the submodule log.
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Fri, Apr 05, 2013 at 05:06:30PM
Hi John,
On Fri, 5 Apr 2013, John Keeping wrote:
When running git log -p --submodule=log, the submodule log is not
indented by the graph output, although all other lines are. Fix this by
prepending the current line prefix to each line of the submodule log.
Nice! I agree that submodules are
Linus Torvalds wrote:
So you absolutely need a dirty worktree. You need it for testing, and
you need it for merging. Having a model where you don't have a
in-progress entity that works as a temporary is absolutely and
entirely wrong.
I agree entirely. My comment was just a by the way, and
Jeff King p...@peff.net writes:
I didn't actually test that patch beyond compilation (but it's
_obviously_ correct, right?), and I'm about to go to bed. Do you want to
take care of adapting your commit message to it?
The code looks obviously correct, yes.
We might have to revisit the Is
Chris Wilson chris+git...@aptivate.org writes:
They fixed it by checking in a rectified .gitmodules file.
In the mean time, I ran git submodule init, and now I've ended up in a
situation where git submodule update doesn't work, and there's no
submodule command to fix it, so I have to remove
Jan Kara wrote:
Hum, I have somewhat hard time to understand what do you mean by
'magically optimized syscalls'. What should happen in VFS to speedup your
load?
In retrospect, I think this is a terrible hack to begin with. Tuning
the filesystem specifically for git repositories is inelegant
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
git log -p .gitmodules would be a way to review what changed in
the information about submodules. Don't you need git log-link for
exactly the same reason why you need git diff-link in the first
place?
So you may not
Duy Nguyen pclo...@gmail.com writes:
The above should have written will turn on auto coloring on the
following _textual_ placeholder. I didn't intend %C(auto) to be
followed by %C(color) as it's already covered by %C(auto,red). But of
course we could make it work too.
You are right that
Junio C Hamano wrote:
Once you start recording the latter also at path A, it becomes
unclear what git diff A should show.
That is what I said in the message, to which you invented diff-link
as a solution to the unclear-ness.
I just thought it would be a stopgap until we get diff to support
Thanks; will replace the one in 'pu' with this.
--
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
Thomas Rast tr...@inf.ethz.ch writes:
I noticed that it doesn't like getting multiple overlapping ranges
from the user. This fixes it.
Both look sensible. Will queue on top of tr/line-log.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Petr Baudis pa...@ucw.cz writes:
} elsif ($pid == 0) {
- if (defined $opts{STDERR}) {
- close STDERR;
- }
if ($opts{STDERR}) {
open (STDERR, '', $opts{STDERR})
On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 01/03/2013 08:03 AM, Junio C Hamano wrote:
I'd like a datastore that maps a pair of commit object names to
another object name, such that:
* When looking at two commits A and B, efficiently query all data
Should we use that opportunity to implement an option like -h (for
humanize) similar to what ls(1), df(1), du(1) does ? Of course -h is
already used for help, so we could use -H or any other sensible
choice.
It can become tough to read the size when it gets big enough.
On Thu, Apr 4, 2013 at 6:27
When we generate relative names (e.g., master~20^2), we
format the name into a static buffer, then xstrdup the
result to attach it to the commit. Since the first thing we
add into the static buffer is the already-computed name of
the child commit, the names may get longer and longer as
the
The error messages that git generates for routine http problems can
sometimes be a bit verbose or confusing. They also provide no
opportunity for the server to communicate any free-form text, even
though the server knows much better than the git client the reason for
the error or what the next
We currently set curl's FAILONERROR option, which means that
any http failures are reported as curl errors, and the
http body content from the server is thrown away.
This patch introduces a new option to http_get_strbuf which
specifies that the body content from a failed http response
should be
If an http request to a remote git server fails, we show
only the http response code, or sometimes a custom message
for particular codes. This gives the server no opportunity
to offer a more detailed explanation of the reason for the
failure, or to give extra advice.
This patch teaches
When we get an http 404 trying to get the initial list of
refs from the server, we try to be helpful and remind the
user that update-server-info may need to be run. This looks
like:
$ git clone https://github.com/non/existent
Cloning into 'existent'...
fatal:
When we get an http 404 trying to get the initial list of
refs from the server, we try to be helpful and remind the
user that update-server-info may need to be run. This looks
like:
$ git clone https://github.com/non/existent
Cloning into 'existent'...
fatal:
When we report http errors in fetching the initial ref
advertisement, we show the full URL we attempted to use,
including info/refs?service=git-upload-pack. While this
may be useful for debugging a broken server, it is
unnecessarily verbose and confusing for most cases, in which
the client user is
This helper function should really be a one-liner that
prints an error message, but it has ended up unnecessarily
complicated:
1. We call error() directly when we fail to start the curl
request, so we must later avoid printing a duplicate
error in http_error().
It would be much
When we report an http error code, we say something like:
error: The requested URL reported failure: 403 Forbidden while accessing
http://example.com/repo.git
Everything between error: and while is written by curl,
and the resulting sentence is hard to read (especially
because there is no
When we encounter an unknown http error (e.g., a 403), we
hand the error code to http_error, which then prints it with
error(). After that we die with the redundant message HTTP
request failed.
Instead, let's just drop http_error entirely, which does
nothing but pass arguments to error(), and
This function is a single-liner and is only called from one
place. Just inline it, which makes the code more obvious.
Signed-off-by: Jeff King p...@peff.net
---
This is a cleanup made possible by the previous patch.
http-push.c | 2 +-
http.c | 5 -
http.h | 5 -
3 files
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A handful of topics that have been stalled for quite a while have
been discarded; for those that are not superseded by something else,
On Fri, Apr 5, 2013 at 6:46 AM, Jed Brown j...@59a2.org wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
@@ -76,12 +78,19 @@ class Marks:
def __init__(self, path):
self.path = path
+self.clear()
+self.load()
+
+if self.version VERSION:
+
RANT
While I am not really interested in exchanging any further emails or any other
form of communication with Felipe, as I find his vitriolic style of
communication unbearable, I feel compelled to reply to a few points. I'll
probably regret this... anyway, I promise this will be my last mail
On Fri, Apr 5, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote:
Add a blanket description to the glossary to cover them instead.
The general principle is that operations to update the branch work
and affect on the HEAD, while operations to update the information
s/work and affect on
Jeff King wrote:
When we generate relative names (e.g., master~20^2), we
format the name into a static buffer, then xstrdup the
result to attach it to the commit. Since the first thing we
add into the static buffer is the already-computed name of
the child commit, the names may get longer
On Fri, Apr 5, 2013 at 4:30 PM, Max Horn m...@quendi.de wrote:
On 04.04.2013, at 08:42, Felipe Contreras wrote:
Please consider that the willingness of people to collaborate with you in any
way is directly related to how you treat them. That includes bug reports. The
way you acted towards
On Thu, Apr 4, 2013 at 10:43 PM, Jeff King p...@peff.net wrote:
On Thu, Apr 04, 2013 at 10:34:49PM -0700, Junio C Hamano wrote:
+static void get_head(char *arg)
+{
+ struct strbuf buf = STRBUF_INIT;
+ head_ref_namespaced(show_text_ref, buf);
+ send_strbuf(text/plain, buf);
Max Horn m...@quendi.de writes:
OK, I'll try to keep a professional tone from now on :-).
Please consider that the willingness of people to collaborate with
you in any way is directly related to how you treat them. That
includes bug reports. The way you acted towards Jed, who was very
On Fri, Apr 5, 2013 at 7:28 PM, Junio C Hamano gits...@pobox.com wrote:
A tool that is in contrib/ follows the contrib/README rule.
I do not maintain it. Maintenance is up to the person who asked to
include it there. I do ask the people who propose to add something
in contrib/ to promise
Hi,
Here are a couple fixes for remote-bzr, some of these can be really annoying to
certain users. I believe all of them should be safe.
Christophe Simonis (2):
remote-bzr: fix directory renaming
remote-bzr: remove files before modifications
David Engster (1):
remote-bzr: set author if
From: Christophe Simonis christo...@kn.gl
Allow re-add of a deleted file in the same commit.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: David Engster d...@randomsample.de
[fc: added tests]
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 7 ++-
contrib/remote-helpers/test-bzr.sh| 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git
Apparently, that's the only way it's possible.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
They have no content, there's nothing we can do with them.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
From: Timotheus Pokorra timotheus.poko...@gmail.com
[fc: added tests]
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
contrib/remote-helpers/test-bzr.sh| 25 +
2 files changed, 27 insertions(+), 2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 6 ++
contrib/remote-helpers/test-bzr.sh| 31 +++
2 files changed, 37 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
Hello,
I'm am trying to patch git to refuse to commit if there are both staged and
unstaged changes, and I pass the -a flag. I expected this simple addition
to parse_and_validate_options() in commit.c to accomplish most of what I
want:
if (all s-workdir_dirty)
die(_(Cannot commit with -a if
On Sat, Apr 06, 2013 at 12:15:33AM -0400, Drew Gross wrote:
I'm am trying to patch git to refuse to commit if there are both staged and
unstaged changes, and I pass the -a flag. I expected this simple addition
to parse_and_validate_options() in commit.c to accomplish most of what I
want:
On Fri, Apr 05, 2013 at 04:49:15PM -0700, Jonathan Nieder wrote:
Though this is a stack overflow, I don't know that it's exploitable for
anything interesting; an attacker does not get to write arbitrary data,
but rather only a sequence of ^%d and ~%d relative history markers.
Perhaps in
Hi,
I believe this to be a bug. git apply --index does add new files but
git apply --index --reject does not even those that apply without
errors.
Regards
Karoly Negyesi
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
85 matches
Mail list logo
