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 m
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.
> > P
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:
>
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
Signed-off-by: Felipe Contreras
---
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
b/contrib/remote-helpers/git-remote-bzr
index 0
From: Timotheus Pokorra
[fc: added tests]
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
contrib/remote-helpers/test-bzr.sh| 25 +
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote
They have no content, there's nothing we can do with them.
Signed-off-by: Felipe Contreras
---
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
index 9466cb9..0bcf8c5 10075
Apparently, that's the only way it's possible.
Signed-off-by: Felipe Contreras
---
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
index a99a924..9466cb9 100
From: David Engster
[fc: added tests]
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 7 ++-
contrib/remote-helpers/test-bzr.sh| 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/cont
From: Christophe Simonis
Allow re-add of a deleted file in the same commit.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remo
From: Christophe Simonis
Git does not handle directories, renaming a directory is renaming every
files in this directory.
[fc: added tests]
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 8 +++-
contrib/remote-helpers/test-bzr.sh| 24 +
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 ava
On Fri, Apr 5, 2013 at 7:28 PM, Junio C Hamano 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 that they arran
Max Horn 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
> calmly and mat
On Thu, Apr 4, 2013 at 10:43 PM, Jeff King 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",
On Fri, Apr 5, 2013 at 4:30 PM, Max Horn 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 Jed, who wa
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 lon
On Fri, Apr 5, 2013 at 11:19 AM, Junio C Hamano 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 the/work on and
On Fri, Apr 05, 2013 at 11:57:19AM -0700, Junio C Hamano wrote:
> Petr Baudis writes:
> >> > -if (defined $opts{STDERR}) {
> >> > -close STDERR;
> >> > -}
> >> > if ($opts{STDERR}) {
> >> >
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 in thi
On Fri, Apr 5, 2013 at 6:46 AM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> @@ -76,12 +78,19 @@ class Marks:
>>
>> def __init__(self, path):
>> self.path = path
>> +self.clear()
>> +self.load()
>> +
>> +if self.version < VERSION:
>> +self.cle
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,
intereste
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
---
This is a cleanup made possible by the previous patch.
http-push.c | 2 +-
http.c | 5 -
http.h | 5 -
3 files changed, 1 insertio
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 in
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
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 s
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 i
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: https://github.com/non/existent/
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: https://github.com/non/existent/
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 remote-curl
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 pl
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 step
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 traver
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:2
On Thu, Jan 3, 2013 at 10:59 AM, Michael Haggerty 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
>>associated w
Petr Baudis writes:
>> >} elsif ($pid == 0) {
>> > - if (defined $opts{STDERR}) {
>> > - close STDERR;
>> > - }
>> >if ($opts{STDERR}) {
>> >open (STDERR, '>&', $opts{STDERR})
>>
Thomas Rast 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 majord...@vger.k
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
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
Duy Nguyen 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 there is no need
Ramkumar Ramachandra 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 hav
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 inelega
Chris Wilson 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 the broken submodules
Jeff King 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 unmerged?" thi
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", a
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
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
---
On Fri, Apr 05, 2013 at 05:06:30PM +0100, John Keeping
From: John Keeping
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
---
diff.c | 1 +
submodule.c
On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra 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 worktree is not o
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 "
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
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,
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
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
---
line-log.c | 26 ++
1 file changed, 26 insertions(+)
diff --
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
Kenneth Ölwing 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 central repo bein
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 f
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
Signed-off-by: Simon Rude
Felipe Contreras 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 marks in-place. Th
[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?
Loo
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 anyone
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 t
Joachim Schmitz 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 premise of a
t
On Thu, Apr 4, 2013 at 10:14 AM, Felipe Contreras
wrote:
> On Tue, Apr 2, 2013 at 4:23 PM, Max Horn 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-
John Keeping 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
Otherwise we won't know if revisions are replaced.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 40 +++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/gi
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
---
Documentation/merge-strategies.txt | 6 ++
1 file changed, 6 insertions(+)
di
Signed-off-by: Felipe Contreras
---
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
--- a/contrib/remote-helpers/gi
In preparation to shift to SHA-1's.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index d82eb2
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
---
contrib/remote-helpers/git-remote-hg | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-he
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
remote-hg:
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
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
runnin
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ă
---
Documentation/git-count-objects.txt |7 +++
git-cvsimport
On Thu, Apr 4, 2013 at 6:27 PM, Junio C Hamano wrote:
> Mihai Capotă 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 improve the end user
>> ex
On Thu, Apr 4, 2013 at 10:50 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> From: Dusty Phillips
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> contrib/remote-helpers/git-remote-hg | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/contrib/remote-helpers/git-remote-hg
On Thu, 2013-04-04 at 10:04 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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 w
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
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:
Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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 *);
>>
Simon Ruderich 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" >.gitattr
Am 05.04.2013 07:27, schrieb Duy Nguyen:
> On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano 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. Thanks fo
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 *bufp
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:
> Great. Now, we just have to write refs/modules//* 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/ is rewritten to refs/heads/:
similarly, refs/
85 matches
Mail list logo
