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
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
.
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
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
FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
tfn...@gmail.com 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
On Tue, Dec 17, 2013 at 2:43 PM, Michael Haggerty mhag...@alum.mit.edu 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 mhag...@alum.mit.edu
---
I don't think that this problem is
On Tue, Dec 17, 2013 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
for i in 1 2
do
test_expect_success orderfile using
On Sun, Dec 15, 2013 at 10:02 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Dec 15, 2013 at 3:35 PM, Torsten Bögershausen tbo...@web.de 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
On Sat, Dec 14, 2013 at 8:33 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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 does produce the same
On Sat, Dec 7, 2013 at 2:09 PM, Felipe Contreras
felipe.contre...@gmail.com 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 mjmda...@gmail.com
Signed-off-by: Felipe Contreras
On Wed, Dec 11, 2013 at 11:04 AM, Paulo Matos pa...@matos-sorge.com 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
On Tue, Dec 3, 2013 at 9:45 AM, Markus Trippelsdorf
mar...@trippelsdorf.de 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
On Mon, Dec 2, 2013 at 1:57 PM, Markus Trippelsdorf
mar...@trippelsdorf.de 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.
On Mon, Dec 2, 2013 at 8:29 PM, Christian Couder
chrisc...@tuxfamily.org wrote:
From: Junio C Hamano gits...@pobox.com
Jeff King p...@peff.net 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
On Mon, Dec 2, 2013 at 8:36 PM, Tom Byrer tomby...@gmail.com 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]:
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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:
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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
On Wed, Nov 27, 2013 at 1:00 PM, Thomas Gummerer t.gumme...@gmail.com 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 =
On Tue, Nov 26, 2013 at 8:50 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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 update all
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 Wed, 27 Nov 2013 15:17:27 +
Pete Forman petef4+use...@gmail.com 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 data
a longer path, simply use strbuf to build it.
Reported-by: Wataru Noguchi wnoguchi.0...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
abspath.c| 10 --
diffcore-order.c | 14 +-
unpack-trees.c | 2 ++
3 files changed, 19 insertions(+), 7 deletions
On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano gits...@pobox.com 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
to 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 apeli...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
contrib/remote-helpers/test-hg.sh| 11
On Sat, Nov 23, 2013 at 1:38 PM, Antoine Pelisse apeli...@gmail.com 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
On Sat, Nov 23, 2013 at 5:32 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Nov 23, 2013 at 6:38 AM, Antoine Pelisse apeli...@gmail.com wrote:
remote-hg is using a mercurial shared clone to store all remotes objects
in one place. Unfortunately, the sharedpath is stored
On Tue, Nov 19, 2013 at 10:04 PM, Christian Couder
chrisc...@tuxfamily.org 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
On Wed, Oct 23, 2013 at 2:45 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Oct 22, 2013 at 3:49 PM, Antoine Pelisse apeli...@gmail.com 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
On Wed, Oct 23, 2013 at 2:55 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 pclo...@gmail.com
On Wed, Oct 23, 2013 at 3:04 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Oct 23, 2013 at 7:58 PM, Antoine Pelisse apeli...@gmail.com wrote:
diff --git a/entry.c b/entry.c
index acc892f..d955af5 100644
--- a/entry.c
+++ b/entry.c
@@ -237,16 +237,18 @@ static int check_path(const char
On Wed, Oct 23, 2013 at 5:44 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
def c_style_unescape(string):
if string[0] == string[-1] == '':
return string.decode('string-escape')[1:-1]
return string
It's in git-remote-bzr.py.
Yeah
On Tue, Oct 22, 2013 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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 Mercurial
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 pclo...@gmail.com wrote:
On Sun, Oct 20,
Noguchi wnoguchi.0...@gmail.com
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
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
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
, and utf-8 encoded file-names.
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-helpers/git-remote-hg
index 92d994e..0141949 100755
--- a/contrib
On Thu, Oct 17, 2013 at 1:13 PM, Jakub Narębski jna...@gmail.com wrote:
Felipe Contrerasfelipe.contre...@gmail.com writes:
diff --git a/Documentation/git-checkout.txt
b/Documentation/git-checkout.txt
index ca118ac..8d98383 100644
--- a/Documentation/git-checkout.txt
+++
On Wed, Oct 16, 2013 at 7:56 PM, Jeff King p...@peff.net 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
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 wnoguchi.0...@gmail.com
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 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
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
-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
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
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 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
...@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 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
+++
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
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
.
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):
-
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,
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 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 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 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 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
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 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
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
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 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 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 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
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 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 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 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 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, 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
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
1 - 100 of 243 matches
Mail list logo
