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 apeli...@gmail.com
---
contrib
.
Warn the user about the invalid reference, and continue the import,
instead of stopping right away.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote
On Sun, Dec 29, 2013 at 11:24 PM, Mike Hommey m...@glandium.org 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 cloning or fetching from a Mercurial
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 tbo...@web.de wrote:
On 2013-12-29 12.30, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty
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
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
reported-by line that you mentioned.
Thanks,
Antoine
--
To unsubscribe from this list: send the line
On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
br...@gernhardtsoftware.com 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
On Wed, Jul 10, 2013 at 9:03 PM, Eric Sunshine sunsh...@sunshineco.com 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 ?
On Tue, Jul 23, 2013 at 11:40 PM, Joern Hees d...@joernhees.de 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:
On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees d...@joernhees.de wrote:
On 24.07.2013, at 10:52, Antoine Pelisse apeli...@gmail.com 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
On Thu, Jul 25, 2013 at 9:12 PM, Felipe Contreras
felipe.contre...@gmail.com 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
On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras
felipe.contre...@gmail.com 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
On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey bca...@nvidia.com wrote:
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review,
.
Reported-by: Joern Hees d...@joernhees.de
Suggested-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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
--- 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 felipe.contre...@gmail.com
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 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 d...@joernhees.de
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
On Mon, Aug 5, 2013 at 9:31 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Aug 5, 2013 at 2:22 PM, Antoine Pelisse apeli...@gmail.com wrote:
From: Felipe Contreras felipe.contre...@gmail.com
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making
os.path.expanduser method.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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 100755
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse apeli...@gmail.com wrote:
$ git clone hg::~/my/repository cd repository git fetch
Fix that by using python os.path.expanduser method.
Shouldn't
On Mon, Aug 5, 2013 at 11:02 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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
On Tue, Aug 6, 2013 at 8:36 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Quoting that part I was asking about again:
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if os.path.exists
On Wed, Aug 7, 2013 at 4:00 PM, Stefan Beller
stefanbel...@googlemail.com 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
+++
...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..1897327
if the path is absolute, so that we don't
fix a path that doesn't need to be.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras felipe.contre...@gmail.com
wrote:
Shouldn't that be the job of the shell? (s/~/$HOME/)
I'm not sure what you mean
On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Shouldn't that be the job of the shell? (s/~/$HOME/)
I'm not sure what you mean here. Does
Confusion everywhere :-)
On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
So when we run:
git clone hg::~/my/repo
Git will remove the hg:: part, and Mercurial will expand tilde and
clone $HOME/my/repo.
Now you confused
On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano gits...@pobox.com 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
On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If I clone ~/git, and then change my username, and move my home
directory, doing a
):
+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 apeli...@gmail.com
Cheers,
--
To unsubscribe from this list: send the line
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh | 194 ---
I'm still not
On Tue, Aug 20, 2013 at 5:00 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org 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
-commit to find if an entry exists in mailmap file for
that pattern, and use that instead.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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 Fri, Aug 23, 2013 at 7:28 PM, Янчарук Александр a...@itvault.info 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
On Fri, Aug 23, 2013 at 9:03 PM, Junio C Hamano gits...@pobox.com 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
a passphrase to unlock the secret key for
user: Antoine Pelisse apeli...@gmail.com
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 apeli...@gmail.com
compare host [smtp.gmail.com:587
On Sun, Aug 25, 2013 at 7:16 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
existing author to
honor the mailmap, and use the name and email after applying the
mailmap.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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_message
On Sun, Aug 25, 2013 at 6:51 PM, Jeff King p...@peff.net 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
needed, and stored
On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano gits...@pobox.com 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:
On Thu, May 23, 2013 at 10:45 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Alessandro Di Marco wrote:
this is a hack I made a couple of years ago in order to store my current
location in git commits (I travel a lot and being able to associate a
place with the commit date helps me to
On Fri, May 24, 2013 at 6:18 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Damn; so it's impossible to have a custom-sorted completion list in
bash. Any idea about zsh? I know that there are completion groups,
but I'd really like custom sorting.
I think sorting is required for faster
On Fri, May 24, 2013 at 4:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
@@ -928,12 +936,22 @@ static void emit(const char *cp, const char *ep)
static void show_ref(struct refinfo *info, const char *format, int
quote_style)
{
const char *cp, *sp, *ep;
+ char
On Sat, May 25, 2013 at 1:50 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Antoine Pelisse wrote:
Is it not possible for color to be used uninitialized here ?
My compiler didn't complain; what am I missing? Doesn't the
declaration char color[COLOR_MAXLEN]; initialize an empty string
Hi,
Patch should be inlined, please have a look at
`Documentation/SubmittingPatches`.
Also, how is copy (an english word) better than copie (the literal
french translation) ?
On Sun, May 26, 2013 at 5:27 PM, 乙酸鋰 ch3co...@gmail.com wrote:
see patch
--
To unsubscribe from this list: send the line
Please do not forget to reply to all.
On Mon, May 27, 2013 at 1:34 AM, 乙酸鋰 ch3co...@gmail.com wrote:
git-gui/po/fr.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git b/git-gui/po/fr.po a/git-gui/po/fr.po
index 0aff186..40441db 100644
--- b/git-gui/po/fr.po
+++
On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt j...@kdbg.org wrote:
Am 26.05.2013 19:58, schrieb Antoine Pelisse:
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for break-rewrites
So now we have two fixes for the same issue, don't we ?
You probably missed $gmane/225534.
On Mon, May 27, 2013 at 4:20 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Commit a24a41e (git-commit: only append a newline to -m mesg if
necessary, 2013-02-18) introduced a regression: when
Hey Felipe,
I know that has been integrated a while ago.
On Thu, Apr 11, 2013 at 2:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
When cloning or pushing fails, we don't want to show a stack-trace.
diff --git a/contrib/remote-helpers/git-remote-hg
The culprit, according to some callgrind investigation, is
lookup_commit_reference_gently() [for the unannotated case] or
deref_tag() [annotated case] calling parse_object().
Using the scenario you described earlier, I think it ends-up spending
most of its time in check_sha1_signature (both
On Mon, May 27, 2013 at 9:14 AM, Antoine Pelisse apeli...@gmail.com wrote:
On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt j...@kdbg.org wrote:
I'm thinking of diffs of files with CRLF
Good you did, because I didn't ;-)
line breaks, where the CR would count as whitespace in the line, I think
On Fri, May 31, 2013 at 10:22 PM, Eugene Sajine eugu...@gmail.com wrote:
and trying to perform some operations like fetch or push. It is cloned
and fetches and pushes successfully.
The problem is that the file test_hook_out.txt doesn't have anything
in it after the execution, So the hook
On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano gits...@pobox.com wrote:
Sandro Santilli s...@keybit.net writes:
git merge anotherbranch
git add something
git commit --amend
After the steps above the addition of something can't be found in
the history anymore, but the file is there.
On Mon, Jun 3, 2013 at 8:02 PM, Eugene Sajine eugu...@gmail.com wrote:
Would you be able to advise how this should be done?
I don't get the error message (i mean the output of pwd) if i do this:
echo `pwd`
exit 1
What should it be?
Actually, after digging into the code, it looks like you
On Mon, Jun 3, 2013 at 9:01 PM, Torsten Bögershausen tbo...@web.de wrote:
The new 4015 does not pass under Mac OS:
a) The seq command, does not exits (we can use printf)
I was planning to reroll with test_seq instead of seq, as advised by
Johannes Sixt.
b) One sed expression is not
On Mon, Jun 3, 2013 at 11:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras
On Tue, Jun 4, 2013 at 10:46 PM, Junio C Hamano gits...@pobox.com wrote:
OK. Thanks.
I think the logic would be more like:
1. Start from xscr, find the first xchp that is !xchp-ignore;
if there is none, we are done. There is no more to show.
2. Remember the xchp as the beginning.
On Sat, Jun 8, 2013 at 4:04 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
Ofcourse they're implementation details. Even in this very test, I
check $dotest/autostash plenty of times.
The more the test relies on implementation details, the worst.
I'm not
around each hunk of interesting changes
- If two hunks are separated by less than inter-hunk-context, they
will be merged into one.
The current implementation does the interesting changes selection in a
single pass.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Hi,
On Tue, Jun 4, 2013 at 10
On Sun, Jun 9, 2013 at 7:07 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Antoine Pelisse wrote:
I don't understand why the code doesn't belong to libgit.a, and how
it's gonna make it more clean. I can see that it is needed only by
revert and cherry-pick, but is that the only reason
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano gits...@pobox.com wrote:
by
the way, do we also handle deletions and do your new tests check
them?
As stated in the commit message, yes we should, but we don't have
tests for that.
I will need to add some as I think I found a bug when removing
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano gits...@pobox.com wrote:
When any ignore blank option is used, there will be lines that
actually has changes (hence should be shown with +/-) but we
deliberately ignore their changes (hence, if they ever appear in the
hunk, they do so as context
On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor
mathieu.lienard--ma...@ensimag.fr wrote:
Le 2013-06-12 13:12, Célestin Matte a écrit :
Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :
Now, I'm not sure if we should always display the list of commits
already applied and those
On Mon, Jun 10, 2013 at 11:43 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano gits...@pobox.com wrote:
When any ignore blank option is used, there will be lines that
actually has changes (hence should
On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
Maybe we can display previous and next commits to provide some
context. Like we do for diff.
For example:
$ git status
# HEAD detached from ecb9f3e
# Already applied 330
each hunk of interesting changes
- If two hunks are separated by less than inter-hunk-context, they
will be merged into one.
The current implementation does the interesting changes selection in a
single pass.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Hey,
OK I think this version
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
So here is a more thorough description of the option:
- real changes are interesting
OK, I think I can understand it.
- blank lines that are close enough (less than context
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
So here is a more thorough description of the option:
- real changes are interesting
OK, I think I can understand it.
- blank lines that are close enough (less than context
+ } else if (changes != ULONG_MAX
+xch-i1 + changes - (lxch-i1 + lxch-chg1)
max_common) {
+ break;
If we are no longer in interesting zone (changes != ULONG_MAX), it
means we will stop if the distance is too big.
changes is used in
each hunk of interesting changes
- If two hunks are separated by less than inter-hunk-context, they
will be merged into one.
The implementation does the interesting changes selection in a single
pass.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Changes since last version:
- changes
On Fri, Jun 21, 2013 at 7:13 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
... I've noticed a significant decline in
list-reviews in general: a lot of good code on the list hasn't been
reviewed.
Hmph, I do not particularly see that happening.
Observer bias. To
On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins e...@demeterr.com 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
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 parameters?
On Thu, Jul 4, 2013 at 2:46 PM, Orgad Shaneh org...@gmail.com wrote:
On Thu, Jul 4, 2013 at 3:42 PM, Antoine Pelisse apeli...@gmail.com 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.
No, it isn't. Not by git
.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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
.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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
.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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
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 apeli...@gmail.com
---
builtin/fast-export.c
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
]-is_interesting
(added + deleted == 0)) {
continue;
}
Cheers,
Antoine Pelisse
-- Forwarded message --
From: Junio C Hamano gits...@pobox.com
Date: Mon, Nov 26, 2012 at 4:28 AM
Subject: Re: [PATCH] diff: Fixes shortstat number of files
To: Antoine
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com 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
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 requires
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
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 need
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 the
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
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
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
Remove the hard limit set by mail buffer in map_user and
use the strbuf API to replace it.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
mailmap.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..e636278 100644
the mailmap string_list structure filled with mailmap
information is passed along from rev_info to pretty_print_context
to provide mailmap information to pretty print each commits
with the correct username and email.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
commit.h | 1 +
log
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/log.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/log.c
On Tue, Dec 11, 2012 at 11:21 PM, Antoine Pelisse apeli...@gmail.com wrote:
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.
The question is which log commands actually ?
Shouldn't we put the option
Or it might be better to make those two strbufs output-only
parameter, e.g.
map_user(struct string_list *mailmap,
const char *name, size_t namelen,
const char *mail, size_t maillen,
struct strbuf *name_out, struct strbuf *mail_out);
Currently blame.c::get_acline, pretty.c::pp_user_info() and
shortlog.c::insert_one_record are parsing author name, email, time and
tz themselves.
Use ident.c::split_ident_line for better code reuse.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/blame.c| 59
Remove the hard limit set by mail buffer in map_user and
use the strbuf API to replace it.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
mailmap.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..3bc6491 100644
(instead of copying in static buffer)
- Caller can easily manipulate the buffer afterward.
- Caller doesn't have to call strlen() to calculate the size of the
new string.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/blame.c| 164
the mailmap string_list structure filled with mailmap
information is passed along from rev_info to pretty_print_context
to provide mailmap information to pretty print each commits
with the correct username and email.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
commit.h |1 +
log
Use the mailmap information to display the correct
username and email address in all log commands.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
pretty.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/pretty.c b
The new option '--use-mailmap' can be used to make
sure that mailmap file is used to convert name
when running log commands.
The test is simple and checks that the Author line
is correctly replaced when running log.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
t/t4203-mailmap.sh | 14
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Documentation/git-log.txt |5 +
builtin/log.c |9 -
2 files changed, 13
1 - 100 of 243 matches
Mail list logo
