Hi Max,
Thank you for working on this.
I believe it would be fair that you forget about patch 1/3 as you fix
it in this patch (2/3).
Also, I think it would be best NOT to integrate a patch (mine) that
breaks a test, as it
would make bisect harder to use.
Thanks,
Antoine
On Wed, Mar 19, 2014 at 1
together (or all
> three even?), and edit the message. But I'd like to properly attribute that
> you discovered the issue, so perhaps I can add something like "Reported-by:
> Antoine Pelisse" or so?
Yes,
I think you can squash all three commits into one, and use the
repor
On Tue, Nov 19, 2013 at 10:04 PM, Christian Couder
wrote:
> To avoid spamming the list again, I am going to send the following
> patches from the 86 patch long series to replace prefixcmp() with
> starts_with():
>
> [PATCH v2 00/86] replace prefixcmp() with starts_with()
> [PATCH v2 01/86] strbuf:
On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano wrote:
> * rh/remote-hg-bzr-updates (2013-11-18) 9 commits
> (merged to 'next' on 2013-11-20 at a36f3c4)
> + remote-bzr, remote-hg: fix email address regular expression
> + test-hg.sh: help user correlate verbose output with email test
> + test-
reflect the new absolute path.
Check mercurial sharedpath file when getting the local hg repository,
and update it manually with the new path if necessary.
Signed-off-by: Antoine Pelisse
---
contrib/remote-helpers/git-remote-hg | 4
contrib/remote-helpers/test-hg.sh| 11 +++
2
On Sat, Nov 23, 2013 at 1:38 PM, Antoine Pelisse wrote:
> remote-hg is using a mercurial shared clone to store all remotes objects
> in one place. Unfortunately, the sharedpath is stored as an absolute
> path by mercurial, creating a dependency on the location of the git
> reposito
On Sat, Nov 23, 2013 at 5:32 PM, Felipe Contreras
wrote:
> On Sat, Nov 23, 2013 at 6:38 AM, Antoine Pelisse wrote:
>> remote-hg is using a mercurial shared clone to store all remotes objects
>> in one place. Unfortunately, the sharedpath is stored as an absolute
>> path by
longer path, simply use strbuf to build it.
Reported-by: Wataru Noguchi
Signed-off-by: Antoine Pelisse
---
abspath.c| 10 --
diffcore-order.c | 14 +-
unpack-trees.c | 2 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/abspath.c b/abspath.c
index
>> On Wed, 27 Nov 2013 15:17:27 +
>> Pete Forman wrote:
>>
>>> I am looking for a way of detecting up front whether a git pull or git
>>> merge would fail. The sort of script I want to perform is to update a
>>> server.
>>>
>>> git fetch
>>> git okay
>>> stop server
>>> backup
Hello,
Should we be worried by this behavior ?
git-scm.com is returning 301 to www.git-scm.com (I don't remember that
it was happening before)
And www.git-scm.com is returning 200: Sorry, no Host found.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
On Tue, Nov 26, 2013 at 8:50 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> Some buffers created with PATH_MAX length are not checked when being
>> written, and can overflow if PATH_MAX is not big enough to hold the
>> path.
>
> Perhaps it is time to up
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> Make git read the index file version 5 without complaining.
>
> This version of the reader reads neither the cache-tree
> nor the resolve undo data, however, it won't choke on an
> index that includes such data.
>
> Helped-by: Junio C Haman
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> +static int verify_hdr(void *mmap, unsigned long size)
> +{
> + uint32_t *filecrc;
> + unsigned int header_size;
> + struct cache_header *hdr;
> + struct cache_header_v5 *hdr_v5;
> +
> + if (size < sizeof(struc
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer wrote:
> @@ -447,6 +463,7 @@ int cmd_ls_files(int argc, const char **argv, const char
> *cmd_prefix)
> struct dir_struct dir;
> struct exclude_list *el;
> struct string_list exclude_list = STRING_LIST_INIT_NODUP;
> + s
On Mon, Dec 2, 2013 at 1:57 PM, Markus Trippelsdorf
wrote:
> When git is compiled with current gcc and "-march=native"
> git-blame segfaults:
>
> For example:
>
> % gdb --args /var/tmp/git/git-blame gcc/tree-object-size.c
> ...
> Program received signal SIGSEGV, Segmentation fault.
> 0x00
On Mon, Dec 2, 2013 at 8:29 PM, Christian Couder
wrote:
> From: Junio C Hamano
>>
>> Jeff King writes:
>>
>>> On Sun, Dec 01, 2013 at 08:49:13AM +0100, Christian Couder wrote:
>>>
This is a new patch series along the lines Junio suggested in this
thread:
http://thread.gmane.o
On Mon, Dec 2, 2013 at 8:36 PM, Tom Byrer wrote:
> Seems that grep.exe is too outdated for some scripts:
> https://github.com/creationix/nvm/issues/75#issuecomment-13735767
-o is not an option of POSIX grep [1] and you should probably not rely
on it for portable script.
[1]: http://pubs.opengrou
On Tue, Dec 3, 2013 at 9:45 AM, Markus Trippelsdorf
wrote:
> Should be fixed in gcc soon. For the curious, here is the assembler diff
> (bad vs. good):
Cool, Thanks. Good to know this has nothing to do with Git :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
On Wed, Dec 11, 2013 at 11:04 AM, Paulo Matos wrote:
> On 10/12/2013 19:34, Junio C Hamano wrote:
>>
>> Perhaps immediately after "cherry-pick" stopped and asked your help
>> to resolve the conflicts, running
>>
>> $ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c
>>
>> and lookin
On Sat, Dec 7, 2013 at 2:09 PM, Felipe Contreras
wrote:
> If the repository is moved, the absolute path of the shared repository
> would fail.
>
> Make sure it's always up-to-date.
>
> Reported-by: Michael Davis
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/git-remote-hg | 3
On Wed, Dec 11, 2013 at 12:19 PM, Paulo Matos wrote:
> On 11/12/2013 11:09, Antoine Pelisse wrote:
>>>
>>>
>>> I don't know how to interpret the fact that the line you sent (with the
>>> obvious --conflicts being --conflict) outputs nothing...
>&
memory on each call. Note that prefix_filename() returns
this static buffer so each callers should copy or use the string
immediately (this is currently true).
Reported-by: Wataru Noguchi
Signed-off-by: Antoine Pelisse
---
abspath.c| 16 +---
diffcore-order.c | 11
On Sat, Dec 14, 2013 at 8:33 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> If you only want to see the diff applied to master, you
>> should run:
>>
>> $ git diff --ours
>
> Does "git diff HEAD" have the same/similar effect?
Yes, it d
On Sun, Dec 15, 2013 at 10:02 AM, Duy Nguyen wrote:
> On Sun, Dec 15, 2013 at 3:35 PM, Torsten Bögershausen wrote:
>> If we really want to go away from PATH_MAX, is a hard-coded value of 4096 so
>> attractive ?
>> Because we can either
>>
>> a) Re-define PATH_MAX in git-compat-util.h
>> b) Use a
On Tue, Dec 17, 2013 at 2:43 PM, Michael Haggerty wrote:
> Dimension the buffer based on PATH_MAX rather than a magic number, and
> verify that the path fits in it before continuing.
>
> Signed-off-by: Michael Haggerty
> ---
>
> I don't think that this problem is remotely exploitable, because the
On Tue, Dec 17, 2013 at 6:54 PM, Junio C Hamano wrote:
> Samuel Bronson writes:
>
>> On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano wrote:
>>> Samuel Bronson writes:
>>>
for i in 1 2
do
test_expect_success "orderfile using option ($i)" '
git diff -Oorder_file_
FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
wrote:
> This was discussed on the Git user list recently [1].
>
> #in a repo with no files
>> git add -A
> fatal: pathspec '.' did not match any files
>
> The same goes for git a
Since e71d1378 (remote-hg: fix 'shared path' path, 2013-12-07),
Mercurial 'shared_path' file is correctly updated whenever a clone is
moved. Make sure it keeps working, especially as this is depending on a
private Mercurial file.
Signed-off-by: Antoine Pelisse
---
contrib
reference.
Warn the user about the invalid reference, and continue the import,
instead of stopping right away.
Signed-off-by: Antoine Pelisse
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-h
On Sun, Dec 29, 2013 at 11:24 PM, Mike Hommey wrote:
> On Sun, Dec 29, 2013 at 12:30:02PM +0100, Antoine Pelisse wrote:
>> Mercurial can have bookmarks pointing to "nullid" (the empty root
>> revision), while Git can not have references to it.
>> When cloni
Thanks for noticing,
I can reproduce at work, I will try to come-up with an improved version soon,
Cheers,
Antoine
On Mon, Jan 6, 2014 at 2:52 PM, Torsten Bögershausen wrote:
> On 2013-12-29 12.30, Antoine Pelisse wrote:
>> Mercurial can have bookmarks pointing to "nullid&qu
On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano wrote:
> * jh/remote-hg-fetch-fix (2013-07-25) 2 commits
> (merged to 'next' on 2013-07-25 at 33161ad)
> + Revert "remotes-hg: bugfix for fetching non local remotes"
> (merged to 'next' on 2013-07-24 at 9c96641)
> + remotes-hg: bugfix for fetch
On Wed, Aug 28, 2013 at 10:48 PM, Felipe Contreras
wrote:
> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
> wrote:
>> Felipe Contreras writes:
>>
>>> + echo greg >> content &&
>>> + git add content &&
>>> + git commit -m one
>>
>> test_commit would make it shorter.
>
> And it would m
On Thu, Aug 29, 2013 at 11:24 PM, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH 9/8] contrib/remote-helpers: style updates for test scripts
>
> During the review of the main series it was noticed that these test
> scripts can use updates to conform to our coding style better, but
> fixing the
I've not followed the thread so much but, in that
entry.c::checkout_entry,() we do:
memcpy(path, state->base_dir, len);
strcpy(path + len, ce->name);
which can of course result in memory violation if PATH is not long enough.
On Thu, Oct 3, 2013 at 12:26 AM, Wataru Noguchi wrote:
> Hi,
>
> At la
On Wed, Oct 16, 2013 at 7:56 PM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 04:03:11AM -0400, Jeff King wrote:
>
>> > I have some free time to come, and would like to work on that feature.
>> > Does the offer still hold ?
>> > If it does, I would be interested in your patches.
>>
>> I'm sorry I ha
On Thu, Oct 17, 2013 at 1:13 PM, Jakub Narębski wrote:
>> Felipe Contreras writes:
>>> diff --git a/Documentation/git-checkout.txt
>>> b/Documentation/git-checkout.txt
>>> index ca118ac..8d98383 100644
>>> --- a/Documentation/git-checkout.txt
>>> +++ b/Documentation/git-checkout.txt
>>> @@ -1,9 +
Hello,
I ran into the following bug today: "BUG: PATHSPEC_PREFER_CWD requires
arguments". It's not that bad because I'm trying to run `git log
--merge` on an already resolved conflict. Still, I don't think I
should hit a "BUG:" :-)
Here is a script to reproduce:
git init .
>a
git add a
git commit
h ".
It has been tested with quotes, spaces, and utf-8 encoded file-names.
Signed-off-by: Antoine Pelisse
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 92d994e..014
Noguchi
Signed-off-by: Antoine Pelisse
---
abspath.c| 10 +++---
diffcore-order.c | 2 +-
entry.c | 14 ++
unpack-trees.c | 2 ++
4 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/abspath.c b/abspath.c
index 64adbe2..0e60ba4 100644
--- a/abspath.c
My main motive was to not *stop* the process when a long path is met.
Because somebody created a repository on Linux with a long file-name
doesn't mean you should not be able to clone it *at all* on Windows.
On Sun, Oct 20, 2013 at 12:33 PM, Duy Nguyen wrote:
> On Sun, Oct 20, 2013 at 12:47 PM, T
On Tue, Oct 22, 2013 at 9:13 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> git-fast-import documentation says that paths can be C-style quoted.
>> Unfortunately, the current remote-hg helper doesn't unquote quoted
>> path and pass them as-is to Mercuri
On Wed, Oct 23, 2013 at 2:45 AM, Felipe Contreras
wrote:
> On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse wrote:
>
>> It is true that I have expected "valid output" from git-fast-export.
>> And I don't have in mind any easy solution to detect that the output
&g
On Wed, Oct 23, 2013 at 2:55 PM, Nguyễn Thái Ngọc Duy wrote:
> The old code does not do boundary check so any paths longer than
> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
> paths of arbitrary length.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> To get this topic go
On Wed, Oct 23, 2013 at 3:04 PM, Duy Nguyen wrote:
> On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse wrote:
>>> diff --git a/entry.c b/entry.c
>>> index acc892f..d955af5 100644
>>> --- a/entry.c
>>> +++ b/entry.c
>>> @@ -237,16 +237,18 @@
On Wed, Oct 23, 2013 at 5:44 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>>> def c_style_unescape(string):
>>> if string[0] == string[-1] == '"':
>>> return string.decode('string-escape')[1:-1]
>>>
On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins wrote:
> On the other hand
> trying to figure
> out the history of events from a large directed graph of commits
> without any clue about
> what topics first spawned each commit is actively harmful in many
> cases (trying to display
> a clear history of
>> Your problem is that your hook script is not checking $2 so it is
>> overwriting the message even when you do not want to do so.
>
> No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the
> hook I provided...
So what you mean is that the hook is not executed with the correct parame
On Thu, Jul 4, 2013 at 2:46 PM, Orgad Shaneh wrote:
> On Thu, Jul 4, 2013 at 3:42 PM, Antoine Pelisse wrote:
>>>> Your problem is that your hook script is not checking $2 so it is
>>>> overwriting the message even when you do not want to do so.
>>>
>&
On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
wrote:
> I am somewhat stuck on how to fix it. Any ideas?
I don't have anything to reproduce here, but usually I start
investigating this kind of problems by attaching the hung process with
gdb to see the current state (if it's stuck in a specific
On Wed, Jul 10, 2013 at 9:03 PM, Eric Sunshine wrote:
> +static void check_mailmap(struct string_list *mailmap, const char *contact)
> +{
> + const char *name, *mail;
> + size_t namelen, maillen;
> + struct ident_split ident;
> + char term = null_out ? '\0' : '\n';
> +
> +
On Tue, Jul 23, 2013 at 11:40 PM, Joern Hees wrote:
> 6796d49 introduced a bug by making shared_path == ".git/hg' which
> will most likely exist already, causing a new remote never to be
> cloned and subsequently causing hg.share to fail with error msg:
> "mercurial.error.RepoError: repository .gi
On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>> I think the best way would be to create the shared repository in
>> .git/hg/$share, with $share being a path that can't be a remote name
>> (so that it doesn't c
On Thu, Jul 25, 2013 at 9:12 PM, Felipe Contreras
wrote:
> Besides, I don't see
> the point of having a '.shared/.hg' directory, and nothing else on
> that '.shared' folder.
Is it not already true about the ".git/hg/$alias/clone/" directory ?
> So, here's my patch. If only Junio read them.
>
> S
On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras
wrote:
> That's true. Maybe something like:
>
> for x in repos:
> local_hg = os.path.join(shared_path, x, 'clone', '.hg')
> if os.path.exists(local_hg):
> shutil.copytree(local_hg, hg_path)
> break
I think that would work, but I think
On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
> ---
> This email message is for the sole use of the intended recipient(s) and may
> contain
> confidential information. Any unauthorized review, use, disclosure
.
Reported-by: Joern Hees
Suggested-by: Felipe Contreras
Signed-off-by: Antoine Pelisse
---
Hey,
OK, I think this version will work in all cases.
Either you clone local and then remote, or remote and then local,
or old version local and then remote, or old version remote and then local:
You
> --- a/contrib/remote-helpers/git-remote-hg.py
> +++ b/contrib/remote-helpers/git-remote-hg.py
> @@ -391,11 +391,22 @@ def get_repo(url, alias):
> os.makedirs(dirname)
> else:
> shared_path = os.path.join(gitdir, 'hg')
> -if not os.path.exists(shared_path):
> -
From: Felipe Contreras
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial
.
It's trivial to upgrade to the new organization by copying the Mercurial
repo from one of the remotes (e.g. 'origin'), so let's do so.
Reported-by: Joern Hees
Signed-off-by: Felipe Contreras
Signed-off-by: Antoine Pelisse
---
contrib/remote-helpers/git-remote-hg | 21 ++
On Mon, Aug 5, 2013 at 9:31 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 2:22 PM, Antoine Pelisse wrote:
>> From: Felipe Contreras
>>
>> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
>> making the shared repository '.git/hg',
Fix that by using python os.path.expanduser method.
Signed-off-by: Antoine Pelisse
---
contrib/remote-helpers/git-remote-hg |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 02404dc..4bbd296 1
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse wrote:
>> $ git clone hg::~/my/repository && cd repository && git fetch
>>
>> Fix that by using python os.path.expanduser method.
>
> Shouldn
On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
> Is the untold
> and obvious-to-those-who-are-familiar-with-this-codepath assumption
> that it is guaranteed that there is at most one "*/clone/.hg" under
> shared_path?
No, there is no
On Tue, Aug 6, 2013 at 8:36 AM, Junio C Hamano wrote:
> Antoine Pelisse writes:
> Quoting that part I was asking about again:
>
>> +# check and upgrade old organization
>> +hg_path = os.path.join(shared_path, '.hg')
>> +i
On Wed, Aug 7, 2013 at 4:00 PM, Stefan Beller
wrote:
> ---
> builtin/pack-objects.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 1742ea1..0bd8f3b 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.
.
It's trivial to upgrade to the new organization by copying the Mercurial
repo from one of the remotes (e.g. 'origin'), so let's do so. If we
can't find any existing repo, we create an empty one.
Reported-by: Joern Hees
Signed-off-by: Felipe Contreras
Signed-off-
tch
Expand the tilde when checking if the path is absolute, so that we don't
fix a path that doesn't need to be.
Signed-off-by: Antoine Pelisse
---
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
wrote:
> Shouldn't that be the job of the shell? (s/~/$HOME/)
I'm not sure wh
On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>> On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
>> wrote:
>>> Shouldn't that be the job of the shell? (s/~/$HOME/)
>>
>> I'm not sure what you mean here. Doe
On Fri, Aug 9, 2013 at 10:03 PM, Felipe Contreras
wrote:
> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
> making the shared repository '.git/hg', which is already used before
> that patch, so clones that happened before that patch, fail after that
> patch, because there's
Confusion everywhere :-)
On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So when we run:
>>
>> git clone hg::~/my/repo
>>
>> Git will remove the "hg::" part, and Mercurial will expand tilde and
>> c
On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano wrote:
> OK, so clone works, but subsequent fetch from the cloned resoitory
> does not? "git fetch hg::~/my_repo" will still work but the call to
> "git config" done near the place your patch touches does not store
> "hg::~/my_repo" because it think
On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras
wrote:
> On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> If I clone ~/git, and then change my username, and move my home
>>> directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
>>> we h
break
> +if not os.path.exists(hg_path):
> +shutil.move(local_hg, hg_path)
> +shutil.rmtree(os.path.join(shared_path, x, 'clone'))
>
> # setup shared repo (if not there)
> try:
FWIW,
Reviewed-by: Antoine Pelisse
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
wrote:
> builtin/repack.c | 410
> +
> contrib/examples/git-repack.sh | 194 +++
> git-repack.sh | 194 ---
I'm still not sure I understand the tr
On Sat, Jul 20, 2013 at 2:22 AM, Jeff King wrote:
> I do plan to finish it eventually, but if anyone else feels like picking
> it up, I'd be glad to review patches and/or share my work-in-progress as
> a starting point.
Hi Jeff,
I have some free time to come, and would like to work on that featur
On Tue, Aug 20, 2013 at 5:00 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> The deflate loop in bulk-checkin::stream_to_pack expects to get all bytes
>> from a file that it requests to read in a single function call. But it
>> used xread(), which does not give that guarantee. Replace it b
w git-commit to find if an entry exists in mailmap file for
that pattern, and use that instead.
Signed-off-by: Antoine Pelisse
---
Hi,
I would use that feature at work where I happen to commit some work for
other colleagues, while we heavily rely on mailmap file to have decent indents.
On the
On Fri, Aug 23, 2013 at 7:28 PM, Янчарук Александр wrote:
> But those settings seems does not affect on |git add -p|. How to set tab
> size for hunks in *git add -p* command?
That's because "git add -p" doesn't go through less/pager.
You can certainly change the tabs size for your terminal with "
On Fri, Aug 23, 2013 at 9:03 PM, Junio C Hamano wrote:
> OK, so how about labelling it as a bugfix, like this perhaps? We
> obviously need a test or two, though.
OK,
I will resubmit tomorrow with some tests.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
c to find a matching existing author to
honor the mailmap, and use the name and email after applying the
mailmap.
Signed-off-by: Antoine Pelisse
---
builtin/commit.c | 7 ++-
t/t4203-mailmap.sh | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/builtin/commit.
You need a passphrase to unlock the secret key for
user: "Antoine Pelisse "
2048-bit RSA key, ID DE2A8792, created 2010-12-31 (main key ID A066A853)
gpg: encrypted with 2048-bit RSA key, ID DE2A8792, created 2010-12-31
"Antoine Pelisse "
compare host [smtp.gmail.com:587]
On Sun, Aug 25, 2013 at 7:16 AM, Junio C Hamano wrote:
> Jeff King writes:
>> Do we need to clear_mailmap before returning to avoid a leak?
>
> Good question. What I queued yesterday seems to have a call to
> clear_mailmap(&mailmap) before that return.
Indeed, the version you queued has clear_ma
c to find a matching existing author to
honor the mailmap, and use the name and email after applying the
mailmap.
Signed-off-by: Antoine Pelisse
---
Hey,
So I kept clear_mailmap() where you put it, but I think it could be moved
right after get_revision(). That is because I think format_commit_messag
On Sun, Aug 25, 2013 at 12:30 PM, Jeff King wrote:
> On Sun, Aug 25, 2013 at 12:01:29PM +0200, Antoine Pelisse wrote:
>
>> So I kept clear_mailmap() where you put it, but I think it could be moved
>> right after get_revision(). That is because I think format_commit_message()
&
On Sun, Aug 25, 2013 at 6:51 PM, Jeff King wrote:
> On Sun, Aug 25, 2013 at 03:37:24PM +0200, Antoine Pelisse wrote:
>
>> So we would stop passing mailmap string_list along down to map_user(),
>> and the mailmap file (or blob) would be read the first time it's
>> n
at doesn't.
Signed-off-by: Antoine Pelisse
---
diff.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data,
struct diff_
at doesn't.
Signed-off-by: Antoine Pelisse
---
diff.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data,
struct diff_
at doesn't.
Signed-off-by: Antoine Pelisse
---
diff.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data,
struct diff_
references have been removed by prune
because some marks will refer to non-existing commits.
Let's warn when we have a mark for a commit we don't know.
Also, increment the last_idnum before, so we don't override
the mark.
Signed-off-by: Antoine Pelisse
---
builtin/fast-export.c | 11
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
---
This will also break all translation files, should I also send a patch
to update them ?
Cheers,
Antoine Pelisse
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1
bly should
the way it's done in stat. That is with something like this:
if (!data->files[i]->is_interesting &&
(added + deleted == 0)) {
continue;
}
Cheers,
Antoine Pelisse
-- Forwarded message --
From: Junio C Ha
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
wrote:
> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano wrote:
>> Is this a safe and sane thing to do, and if so why? Could you
>> describe that in the log message here?
> Why would fast-export try to export something that was pruned? Doesn't
>
> If that's the case, I don't think it should throw a warning even just skip
> them.
Removing the warning seems fine to me.
> Then, in the actual export if some of these objects are referenced the
> export would fail anyway (but they won't).
Of course it will fail to export anything that requir
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse
---
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23
> I am not sure I follow the above, but anyway, I think the patch does
> is safe because (1) future "fast-export" will not refer to these
> pruned objects in its output (we have decided that these pruned
> objects are not used anywhere in the history so nobody will refer to
> them) and (2) we still
> Yeah, I think I agree that you would need to make sure that the
> other side does not use the revision marked with :2, once you retire
> the object you originally marked with :2 by pruning. Shouldn't the
> second export show :1 and :3 but not :2? It feels like a bug in the
> exporter to me that t
Hi Junio,
That does make a lot of sense and I would have indeed missed a couple
of things here.
I've been thinking about that "Unmerged" line quite a lot, and I can't
get myself any good reason to keep it.
Would you mind taking a couple of minutes to make it clear ?
I feel like (but I can obviou
Hi,
I was thinking about that last week.
It could indeed be very interesting to have mailmap applied to git-log and
especially to git-log --author/--committer.
My first look at the code let me think that we would need to change the
parse_commit_buffer to replace, at reading time, the name of auth
of the new option
[1]: http://thread.gmane.org/gmane.comp.version-control.git/211270
Antoine Pelisse (5):
Use split_ident_line to parse author and committer
mailmap: Remove buffer length limit in map_user
mailmap: Add mailmap structure to rev_info and pp
pretty: Use mailmap to display
1 - 100 of 271 matches
Mail list logo
