On Thu, Jan 02, 2014 at 07:11:42PM +0100, Sebastian Schuberth wrote:
On 02.01.2014 18:33, Johannes Schindelin wrote:
-- snip --
On Linux, we can get away with assuming that the directory separator is a
forward slash, but that is wrong in general. For that purpose, the
is_dir_sep()
On Thu, Jan 09, 2014 at 04:36:18PM +0100, Andreas Krey wrote:
since ad8261d (rebase: use reflog to find common base with upstream)
a rebase without arguments says fatal: Not a valid object name: '',
caused by trying to determine the fork point with an empty $switch_to.
I don't really see
to test this didn't
actually need the fork-point behaviour, so enhance it to make sure that
the fork-point is applied correctly. The modified test fails without
the change to git-rebase.sh in this patch.
Reported-by: Andreas Krey a.k...@gmx.de
Signed-off-by: John Keeping j...@keeping.me.uk
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 6 ++
1 file changed, 6 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4fe5ce3..e74d402 100644
--- a/contrib/completion/git
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index e74d402..3c1a11f 100644
--- a/contrib/completion/git
On Thu, Jan 16, 2014 at 12:55:21PM -0800, W. Trevor King wrote:
On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
@@ -155,13 +155,31 @@ it contains local modifications.
update::
Update the registered submodules, i.e. clone
On Thu, Jan 16, 2014 at 06:47:38PM -0800, Siddharth Agarwal wrote:
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out fatal: No such
ref: '' if git pull --rebase is run on
On Fri, Jan 17, 2014 at 10:57:56AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out fatal: No such
ref: '' if git pull --rebase is run on branches without
with no arguments, which
results in an error suppressed by redirecting stderr to /dev/null. Now
we invoke git-merge-base with an empty branch name, which also results
in an error. Suppress this in the same way.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-pull.sh | 2 +-
1 file changed
: multiple definition of
`mark_tree_uninteresting'
/tmp/ccKQRkZV.ltrans2.ltrans.o:/home/john/src/git/revision.c:108: first
defined here
Signed-off-by: John Keeping j...@keeping.me.uk
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index
On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
The file is for past commits only.
New commits can contain these info in their messages.
If it's not forgotten. Experience shows that things like issue numbers
have a tendency to be
On Sun, Feb 02, 2014 at 12:42:52PM +0100, David Kastrup wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
The file is for past commits only.
New commits can contain these info
On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup d...@gnu.org wrote:
Looking in the Makefile, I just find support for coverage reports using
gcov. Whatever is there with profile in it
worth it here.
[1] http://clang-analyzer.llvm.org/
[2] https://github.com/xiw/stack
John Keeping (5):
notes-utils: handle boolean notes.rewritemode correctly
utf8: fix iconv error detection
utf8: use correct type for values in interval table
builtin/mv: don't use memory after free
iconv(3) returns (size_t) -1 on error. Make sure that we cast the
-1 properly when checking for this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
utf8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utf8.c b/utf8.c
index 0d20e0a..24c3c5c 100644
--- a/utf8.c
+++ b
We treat these as unsigned everywhere and compare against unsigned
values, so declare them using the typedef we already have for this.
While we're here, fix the indentation as well.
Signed-off-by: John Keeping j...@keeping.me.uk
---
utf8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
If we carry on after outputting config_error_nonbool then we're
guaranteed to dereference a null pointer.
Signed-off-by: John Keeping j...@keeping.me.uk
---
notes-utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/notes-utils.c b/notes-utils.c
index 2975dcd..4aa7023
We are guaranteed that 'nst' is non-null because it is allocated with
xmalloc(), and in fact we rely on this three lines later by
unconditionally dereferencing it.
Signed-off-by: John Keeping j...@keeping.me.uk
---
streaming.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
the KEEP_TRAILING_SLASH flag, so any
trailing '/' will have been stripped; but static analysis tools are not
clever enough to realise this and so warn that 'src' could be used after
having been free'd. Fix this by checking that 'src_w_slash' is indeed
newly allocated memory.
Signed-off-by: John Keeping j
-by: John Keeping j...@keeping.me.uk
---
builtin/rev-parse.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index aaeb611..645cc4a 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -738,9 +738,12 @@ int cmd_rev_parse(int
On Tue, Feb 18, 2014 at 07:56:20AM +0100, Guido Günther wrote:
Without this when maintaining stable branches it's easy to forget to use
-x to track where a patch was cherry-picked from.
Signed-off-by: Guido Günther a...@sigxcpu.org
---
Documentation/git-cherry-pick.txt | 8
On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
Prevent is a strong word. I meant we only do it if they force
it. Something like this..
-- 8 --
diff --git a/branch.c b/branch.c
index 723a36b..3f0540f 100644
--- a/branch.c
+++
On Tue, Feb 18, 2014 at 11:51:05AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
There's already the arbitrary set of prefixes in
refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see
how a user might think that since git log refs/heads/name
On Tue, Feb 18, 2014 at 04:25:37PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
John Keeping j...@keeping.me.uk writes:
There are two problems here:
1) If no argument is provided, then the command segfaults
2) The argument is not consumed, so
On Thu, Feb 20, 2014 at 02:41:23PM -0800, David Aguilar wrote:
On Thu, Feb 20, 2014 at 1:03 PM, Jens Lehmann jens.lehm...@web.de wrote:
Sorry for the late reply, but here we go ...
Am 10.02.2014 07:33, schrieb Gábor Lipták:
Hi Jens,
So git status says:
On Sat, Mar 08, 2014 at 04:46:51PM +, brian m. carlson wrote:
On Sat, Mar 08, 2014 at 04:23:43PM +, Guillaume Gelin wrote:
Hi,
http://pastebin.com/Np7L54ar
We're failing to rename because we got an EFAULT, and then we try to
print the failing filename, and we get a segfault right
as the other
arrays.
Reported-by: Guillaume Gelin cont...@ramnes.eu
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Sat, Mar 08, 2014 at 06:12:18PM +, John Keeping wrote:
This fixes it for me:
Here it is as a proper patch.
builtin/mv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
as the other
arrays.
Reported-by: Guillaume Gelin cont...@ramnes.eu
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Sat, Mar 08, 2014 at 07:15:42PM +, brian m. carlson wrote:
Yup, that's the same conclusion I came to. There are also two cases
where we don't shrink the array properly. I'll rebase
On Wed, Mar 19, 2014 at 10:53:01AM -0700, Junio C Hamano wrote:
rebase - with your change still says something like this:
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to @{-1}.
instead of Fast-forwarded HEAD to -. Somebody may later
On Wed, Mar 19, 2014 at 12:02:01PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Mar 19, 2014 at 10:53:01AM -0700, Junio C Hamano wrote:
rebase - with your change still says something like this:
First, rewinding head to replay your work on top
On Wed, Mar 19, 2014 at 12:41:31PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Mar 19, 2014 at 12:02:01PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Mar 19, 2014 at 10:53:01AM -0700, Junio C Hamano wrote:
rebase
On Sat, Apr 19, 2014 at 11:03:07AM +, Schittli Thomas wrote:
last night, brian m. Carlson explained, that Git wants a key that can
be used by GnuPG and therefore X.509 certificates are not supported.
As you probably know, since 3 years gpg supports X.509 -
unfortunately, gpg does not
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
- remote-hg: trivial cleanups
- remote-hg: make sure we omit multiple heads
- git-remote-hg: use internal clone's hgrc
- t: remote-hg: split into setup test
-
On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:
John Keeping wrote:
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting associated tools when Git
On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Having said all that, there is one caveat.
Since the remote helper interface is stable and the remote helpers do
not use any of the Git internals, I consider the risks of including
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
...
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
git-reintegrate[1] supports this.
-
-22 04:16:22 -0700 106) git ...
^cc29195 107) test...
On a slight tangent, I tried this in a fairly young repository and got
this (with master at v2.0.0-rc2-4-g1dc51c6):
$ git blame Makefile | head -5
7a3fc144 (John Keeping 2013
On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On a slight tangent, I tried this in a fairly young repository and got
this (with master at v2.0.0-rc2-4-g1dc51c6):
$ git blame Makefile | head -5
7a3fc144 (John Keeping 2013
On Thu, May 08, 2014 at 11:10:24PM +0100, John Keeping wrote:
On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On a slight tangent, I tried this in a fairly young repository and got
this (with master at v2.0.0-rc2-4-g1dc51c6
On Thu, May 08, 2014 at 08:54:29PM -0500, William Giokas wrote:
So I have been looking into the python code in the git tree recently
(contrib and core tree) and noticed that almost none of the files fully
conform to pep8. Now I'm not just saying this because I like the code to
be clean,
On Wed, Aug 06, 2014 at 07:32:14AM +0200, Steffen Prohaska wrote:
[...]
The expectation on the process size is tested using /usr/bin/time. An
alternative would have been tcsh, which could be used to print memory
information as follows:
tcsh -c 'set time=(0 %M); cmd'
Although the
On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote:
...
# Then I realize I need more changes and it gets complex enough to
# warrant a topic branch. I create the 'topic' branch that will track
# 'master' branch and reset 'master' back to its origin (remote
# origin/master in
On Sat, Jul 13, 2013 at 01:08:09PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push
---
On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I don't think git pull remote branch falls into the same category as
plain git pull so I'm not convinced that defaulting to merge there is
unreasonable. The original message about
On Tue, Jul 09, 2013 at 12:53:27PM -0700, Junio C Hamano wrote:
diff --git a/remote.c b/remote.c
index 81bc876..e9b423a 100644
--- a/remote.c
+++ b/remote.c
@@ -1938,3 +1938,62 @@ struct ref *get_stale_heads(struct refspec *refs, int
ref_count, struct ref *fet
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems. For SVN, one can use
bugtraq-properties [1] to specify e.g. the issue tracker URL or how to
parse the bug ID from a
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
into groups with subheadings.
The text of option descriptions does not change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-rev-parse.txt | 104 +++-
1 file changed, 61 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-rev
, there is no reason for this restriction and it
might confuse users if these arguments appear to be ignored.
There is no need for any documentation change here as the restrictions
on these options are not documented.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/rev-parse.c | 28
This adds a new patch to remove the restrictions on --local-env-var and
--resolve-git-dir so that they do not need to appear first on the
command line.
The other patch is update to reflect this as well as to split up the
catch-all Options for Input subsection a bit.
John Keeping (2):
rev-parse
into groups with subheadings.
The text of option descriptions does not change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-rev-parse.txt | 104
1 file changed, 64 insertions(+), 40 deletions(-)
diff --git a/Documentation/git-rev
On Sun, Jul 21, 2013 at 11:57:43PM -0700, Junio C Hamano wrote:
* jk/fast-import-empty-ls (2013-06-23) 4 commits
- fast-import: allow moving the root tree
- fast-import: allow ls or filecopy of the root tree
- fast-import: set valid mode on root tree in ls
- t9300: document fast-import
On Tue, Jul 23, 2013 at 01:40:05PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
then smart HTTP works fine. I wonder if there is a problem in the cgit
setup on kernel.org (or if it was even intended that you could fetch
from the cgit URL at all; the cgit page shows the clone URLs in
I wrote this script a few months ago and have been using it pretty much
daily since then, so I figure it's time to see if anyone else finds it
useful...
git-integration [1] is a script to help manage integration branches in
Git. By defining a base point and a set of branches to be merged to
form
On Tue, Jul 30, 2013 at 09:45:49AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I wrote this script a few months ago and have been using it pretty much
daily since then, so I figure it's time to see if anyone else finds it
useful...
git-integration [1
On Wed, Jul 31, 2013 at 05:31:47PM -0400, Dale R. Worley wrote:
Notice that the whole commit message has been formatted as if it is
part of the Subject line, and the line breaks in the commit message
have been refilled.
The file Documentation/SubmittingPatches says that git format-patch
On Mon, Aug 05, 2013 at 12:01:44PM +0100, Rafal W. wrote:
Hi,
When applying patch via git, it is doing sometimes SEGV.
Please find more details in the attached crash logs.
This looks like the issue fixed by commit 212eb96 (apply: carefully
strdup a possibly-NULL name, 2013-06-21), which is in
On Wed, Aug 07, 2013 at 11:01:57AM -0700, Kyle J. McKay wrote:
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4
On Thu, Aug 08, 2013 at 08:06:09PM +0200, Matthieu Moy wrote:
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -532,12 +532,7 @@ commit, and you can tell it to show a whole series of
diffs.
Alternatively, you can tell it to be silent, and not show the
On Fri, Aug 09, 2013 at 01:01:48PM -0700, Junio C Hamano wrote:
After doing a bit of archaeology, I now know why whatchanged with
an unwieldy long name persisted in the user's mindset for so long.
My conclusions are:
- It is better to encourage new users to use `log` very early in
the
On Fri, Aug 09, 2013 at 01:57:19PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
+New users are encouraged to use linkgit:git-log[1] instead. The
+`whatchanged` command is essentially the same as linkgit:git-log[1]
+run with different defaults that shows a --raw
On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
On 2013-08-14 12:49, Tim Chase wrote:
If it makes any difference, this is within a cmd.exe shell (with
$PATH set appropriately so git is being found).
Just a follow-up, I tried it within the bashish shell included in
the git
On Thu, Aug 15, 2013 at 06:12:29AM -0500, Tim Chase wrote:
On 2013-08-15 09:00, John Keeping wrote:
On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
On 2013-08-14 12:49, Tim Chase wrote:
If it makes any difference, this is within a cmd.exe shell (with
$PATH set
On Sat, Aug 17, 2013 at 02:40:05PM +0200, Steffen Prohaska wrote:
Previously, filtering more than 2GB through an external filter (see
test) failed on Mac OS X 10.8.4 (12E55) with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:
When rebasing a branch which contains commits with notes onto another
branch it happens that some commits are already presents in the target
branch.
In that case
. That does not make it right or wrong,
but I do not think it is in line with the original discussion (that
is why John Keeping is kept on the Cc: line).
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost
On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong
On Wed, Sep 04, 2013 at 09:47:12AM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
test_cmp_rev follows the same order of arguments a diff -u and
produces the same output as plain git diff. It's perfectly readable
and normal.
This is way off tangent, but I am
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One other thing that I can see being useful occasionally is:
git rebase
On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
When git pull stops because what was fetched in FETCH_HEAD does
not fast-forward, then what did _you_ do (and with the knowledge you
currently
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches
On Fri, Sep 06, 2013 at 03:14:25PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am
On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
1.
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement. So perhaps:
- drop
On Mon, Sep 09, 2013 at 04:44:16PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
I think that would address the concern I raised, because it does not
create a roadblock to new users accomplishing their task. They can
ignore the warning, or choose
On Mon, Sep 09, 2013 at 06:02:35PM -0500, Felipe Contreras wrote:
On Mon, Sep 9, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote:
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses git rm when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
Signed-off-by: John Keeping j
Instead of re-implementing the remove trailing slashes loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/rm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git
The first patch is the important one here, the second one I noticed
while checking if any other commands fail to handle submodule paths with
a trailing slash and is just a simplification.
John Keeping (2):
reset: handle submodule with trailing slash
rm: re-use parse_pathspec's trailing-slash
On Tue, Sep 10, 2013 at 09:37:45PM +0200, Jens Lehmann wrote:
Am 10.09.2013 21:13, schrieb John Keeping:
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses git rm when dealing with
I think you meant to say git reset in the line above
On Wed, Sep 11, 2013 at 08:05:44AM +0200, Johannes Sixt wrote:
Am 10.09.2013 21:13, schrieb John Keeping:
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses git rm when dealing with
submodules. Now that we have parse_pathspec we can
On Wed, Sep 11, 2013 at 02:48:51PM +0700, Duy Nguyen wrote:
On Wed, Sep 11, 2013 at 2:13 AM, John Keeping j...@keeping.me.uk wrote:
Instead of re-implementing the remove trailing slashes loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off
On Wed, Sep 11, 2013 at 05:54:48PM +0700, Duy Nguyen wrote:
On Wed, Sep 11, 2013 at 3:20 PM, John Keeping j...@keeping.me.uk wrote:
On Wed, Sep 11, 2013 at 08:05:44AM +0200, Johannes Sixt wrote:
Am 10.09.2013 21:13, schrieb John Keeping:
When using tab-completion, a directory path
On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
reset --soft does not go through these code paths (i.e. it does not
need index at all). If we fail to load index index in reset --soft I
think it's ok to die(). Corrupt index is fatal
On Wed, Sep 11, 2013 at 11:14:57AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
reset --soft does not go through these code paths (i.e. it does not
need
On Thu, Sep 12, 2013 at 11:36:56AM +0200, Sebastian Schuberth wrote:
Just wondering if that is the root of the problem, or if maybe there is
something else subtle going on. Also, does __CRT_INLINE just turn into
inline, or is there perhaps some other pre-processor magic going on?
This is
Changes since v1:
* Improvements to existing pathspec code to use is_dir_sep instead of
comparing against '/' and handle multiple trailing slashes
* Remove calls to read_cache() made redundant by a new call in
builtin/reset.c::parse_args()
John Keeping (4):
pathspec: use is_dir_sep
the read_cache() call before the
parse_pathspec() call. All of the existing paths through cmd_reset()
that do not die early already call read_cache() at some point, so there
is no performance impact to doing this in the common case.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin
This allows us to replace the submodule path trailing slash removal in
builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
parse_pathspec() without changing the behaviour with respect to multiple
trailing slashes.
Signed-off-by: John Keeping j...@keeping.me.uk
---
pathspec.c | 27
This allows us to correctly removing trailing backslashes on Windows
when checking for submodules.
Signed-off-by: John Keeping j...@keeping.me.uk
---
pathspec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index ad1a9f5..7c6963b 100644
Instead of re-implementing the remove trailing slashes loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/rm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git
On Thu, Sep 12, 2013 at 12:48:10PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
This allows us to replace the submodule path trailing slash removal in
builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
parse_pathspec() without changing the behaviour
On Fri, Sep 13, 2013 at 08:28:24AM +0700, Duy Nguyen wrote:
On Fri, Sep 13, 2013 at 3:21 AM, John Keeping j...@keeping.me.uk wrote:
On Thu, Sep 12, 2013 at 12:48:10PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
This allows us to replace the submodule path
real0m0.661s
user0m0.617s
sys 0m0.044s
After:
$ time git log --cherry next...pu /dev/null
real0m0.509s
user0m0.478s
sys 0m0.030s
Signed-off-by: John Keeping j...@keeping.me.uk
---
patch-ids.c | 142
patch-ids.h
On Sun, May 19, 2013 at 11:36:23PM -0700, Jonathan Nieder wrote:
I don't know what it should mean to try to use --cherry without
--no-merges or --first-parent, so I guess this is harmless.
Currently --no-merges doesn't actually get passed down this far. We do
the patch ID calculations without
On Mon, May 20, 2013 at 09:32:21AM +0400, Kirill Berezin wrote:
When you trying to add submodule, that already has submodule, it craches.
For example you could try: git clone --recursive
http://github.com/Exsul/al_server
Which version of Git were you using? I was not able to reproduce this
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote:
Dmitry Marakasov amd...@amdmi3.ru writes:
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
it's required for systems which don't use bash by default (for example,
FreeBSD), while there seem to be no
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:
I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.
Our basic workflow will be based around:
1 - 100 of 839 matches
Mail list logo