On Wed, Jul 16, 2014 at 05:36:03PM -0400, Ted Felix wrote:
On 07/16/2014 03:23 PM, John Keeping wrote:
Change from v1:
- add a test case
Test case is working fine for me. It passes with the patch and fails
without. However, it does seem to cause all the rest of the test cases
-pick --right-only`.
This does not change the result of the format-patch invocation, just how
we spell the arguments.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Unchanged from v1.
git-rebase--am.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/git
-pick --right-only`.
This does not change the result of the format-patch invocation, just how
we spell the arguments.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-rebase--am.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-rebase--am.sh b/git
On Mon, Jul 07, 2014 at 10:56:23AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Perhaps we shuld do something like this (which passes the test suite):
-- 8 --
diff --git a/git-rebase.sh b/git-rebase.sh
index 06c810b..0c6c5d3 100755
--- a/git-rebase.sh
+++ b
On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:
Starting with git 1.9.0, rebase no longer omits local commits that
appear in both the upstream and local branches.
I've bisected this down to commit bb3f458: rebase: fix fork-point with
zero arguments. The attached script
On Thu, Jul 03, 2014 at 08:09:17PM +0100, John Keeping wrote:
On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:
Starting with git 1.9.0, rebase no longer omits local commits that
appear in both the upstream and local branches.
It is the problem that bb3f458 fixes. The change
On Sun, Jun 29, 2014 at 11:40:40PM -0700, Gary Fixler wrote:
I sometimes pull things in from unrelated repositories to rebase or
cherry-pick items from a different line of development. I've done this
to bring isolated features into a project in their own feature
branches with their full
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but
On Wed, Jun 04, 2014 at 10:42:46AM -0700, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
t9001 used a '\n' in a sed expression to split one line into two lines.
Some versions of sed simply ignore the '\' before the 'n', treating
'\n' as 'n'.
As the test already
On Fri, May 23, 2014 at 02:11:55PM +0400, Sergei Organov wrote:
Hello,
After convertion of a project from CVS to git, I'd like to rename some
references in the created git repository (before it's published, so no
problems here). Is there a plumbing that would do:
git rename-ref old_name
On Fri, May 23, 2014 at 10:10:05AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Fri, May 23, 2014 at 02:11:55PM +0400, Sergei Organov wrote:
Hello,
After convertion of a project from CVS to git, I'd like to rename some
references in the created git
This should avoid future confusion after a subsequent patch has added
some options to __git_merge_options and some directly in _git_merge().
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib
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,
-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 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.
-
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, 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 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 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, 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 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 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 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
-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
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
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
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
: 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 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
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
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 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
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 Wed, Dec 18, 2013 at 11:53:47AM -0500, Martin Langhoff wrote:
On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond e...@thyrsus.com wrote:
Anyway I hope that incremental CVS import would be needed less
and less as CVS is replaced by any more modern version control system.
I agree. I have
On Sat, Dec 14, 2013 at 04:28:14PM +0100, Paul Menzel wrote:
in coreboot we try to check for whitespace errors before committing. Of
course a pre-commit hook is the way to go, but unfortunately it is not
so simple (at least for me) as the following requirements exist.
1. Only the files
On Mon, Dec 09, 2013 at 12:11:50PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Last time this came up [1], there was some discussion about moving the
added block of code to affect upstreams given on the command line as
well as when the upstream is discovered from
this behaviour. This option is turned on by default if no non-option
arguments are specified on the command line, otherwise we treat an
upstream specified on the command-line literally.
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Mon, Dec 09, 2013 at 08:40:08PM +, John Keeping wrote
Since commit d96855f (merge-base: teach --fork-point mode, 2013-10-23)
we can replace a shell loop in git-pull with a single call to
git-merge-base. So let's do so.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-pull.sh | 10 +-
1 file changed, 1 insertion(+), 9 deletions
argument is given on the command line.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Last time this came up [1], there was some discussion about moving the
added block of code to affect upstreams given on the command line as
well as when the upstream is discovered from the config. Having tried
On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:
I have been using a very basic workflow for branching, features each
in a branch.
My branches would be:
- develop = Main upstream branch
- feature/* fix/* = Feature and fix branches
- master = Integration of the whole feature
source file to builtin/get-tar-commit-id.c
to reflect its purpose and fix 'make install'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi,
John Keeping wrote:
builtin/tar-tree.c | 62 -
Here's a quick fixup on top. Thoughts
On Fri, Nov 22, 2013 at 02:22:30PM +0100, Odin Hørthe Omdal wrote:
I'm usually in a subfolder doing actual work. A very common problem I
have is wanting to do a submodule update, but git really hates that. And
I wonder why?
It wouldn't be hard to cd to the toplevel working directory, do the
On Mon, Nov 11, 2013 at 10:25:51AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git repo-config, git tar-tree, git lost-found and git
peek-remote have all been deprecated since at least Git 1.5.4.
With Git 2.0 approaching, I think that would be a good point
On Mon, Nov 11, 2013 at 11:13:45AM -0800, Jonathan Nieder wrote:
John Keeping wrote:
On Mon, Nov 11, 2013 at 10:25:51AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git repo-config, git tar-tree, git lost-found and git
peek-remote have all been deprecated since
The release notes for Git 1.5.4 say that git repo-config will be
removed in the next feature release. Since Git 2.0 is nearly here,
remove it.
Signed-off-by: John Keeping j...@keeping.me.uk
---
.gitignore | 1 -
Documentation/git-repo-config.txt | 23
git lost-found has been deprecated since commit fc8b5f0 (Deprecate
git-lost-found, 2007-11-08), included in version 1.5.4.
Signed-off-by: John Keeping j...@keeping.me.uk
---
.gitignore | 1 -
Documentation/git-lost-found.txt | 74
git repo-config, git tar-tree, git lost-found and git
peek-remote have all been deprecated since at least Git 1.5.4.
With Git 2.0 approaching, I think that would be a good point to remove
then completely, which is what this series does.
John Keeping (4):
repo-config: remove deprecated alias
This has been deprecated since commit 87194d2 (Deprecate peek-remote,
2007-11-24), included in version 1.5.4.
Signed-off-by: John Keeping j...@keeping.me.uk
---
.gitignore | 1 -
Documentation/git-peek-remote.txt | 43 --
Makefile
git tar-tree has been a thin wrapper around git archive since commit
fd88d9c (Remove upload-tar and make git-tar-tree a thin wrapper to
git-archive, 2006-09-24), which also made it print a message indicating
that git-tar-tree is deprecated.
Signed-off-by: John Keeping j...@keeping.me.uk
On Thu, Nov 07, 2013 at 07:10:11PM +0100, Nicolas wrote:
I’m developping a git command in shell and I would like colorize the output.
I don’t find anything in git-sh-setup.
What is the best way for don’t reinvent the wheel?
I normally use git config --get-color ... either with standard
On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote:
git-rev-parse --is-inside-git-dir outputs fatal: Not a git
repository (or any of the parent directories): .git, instead of
false when outside of a git directory. --is-inside-work-tree
behaves the same way. Both commands work
On Fri, Nov 01, 2013 at 06:35:39AM -0600, Felipe Contreras wrote:
One feature that is missing from git-integration is the ability to
parse existing integration branches.
Nice - I'd never thought of doing this.
It also has support for evil merges, so it should be perfectly
usable for git.git
On Sat, Nov 02, 2013 at 01:47:02PM -, Philip Oakley wrote:
From: John Keeping j...@keeping.me.uk
Sent: Saturday, November 02, 2013 10:58 AM
On Fri, Nov 01, 2013 at 06:19:51PM -0500, Ville Walveranta wrote:
git-rev-parse --is-inside-git-dir outputs fatal: Not a git
repository (or any
repo or not?
Something like this, maybe?
(cd $dir git rev-parse --git-dir /dev/null 21)
On Sat, Nov 2, 2013 at 12:03 PM, Philip Oakley philipoak...@iee.org wrote:
From: John Keeping j...@keeping.me.uk
Sent: Saturday, November 02, 2013 2:06 PM
On Sat, Nov 02, 2013 at 01:47:02PM -
On Mon, Oct 28, 2013 at 12:13:22PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The --reflog name has the advantage that it makes clear that this is
looking at something more than the commit graph and I don't think
--fork-point does imply that.
I think I
On Fri, Oct 25, 2013 at 02:38:08PM -0700, Junio C Hamano wrote:
It also comes with a documentation update. The option is not called
--reflog but --fork-point; naming a feature after what it does
(i.e. it finds the fork point) is a lot more sensible than naming
it after how it happens to do
On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
Am 10/25/2013 0:21, schrieb Junio C Hamano:
+test_expect_success 'using reflog to find the fork point' '
+ git reset --hard
+ git checkout -b base $E
+
+ for count in 1 2 3 4 5
+ do
+ git commit
On Mon, Oct 21, 2013 at 10:40:22PM -0700, Martin von Zweigbergk wrote:
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping j...@keeping.me.uk wrote:
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent,
--is-ancestor and --octopus are mutually exclusive and it is
better expressed in terms of the recently
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent
On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command
On Thu, Oct 24, 2013 at 10:40:07PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano
On Sun, Oct 20, 2013 at 10:03:29PM -0700, Martin von Zweigbergk wrote:
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping j...@keeping.me.uk wrote:
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream
On Thu, Oct 17, 2013 at 09:52:09AM +0300, Hemmo Nieminen wrote:
The log's graph's colors were off sometimes when merging several
branches. For example in the graph depicted below, the '-.' part
following the asterisk was colored with incorrect colors. This was
caused by the fact that the
actually the case. Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor of the current
branch if it can find one.
Change rebase so that it uses the same logic.
Signed-off-by: John Keeping j
On Wed, Oct 16, 2013 at 12:24:13PM -0700, Jonathan Nieder wrote:
John Keeping wrote:
Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor
On Wed, Oct 16, 2013 at 03:50:51PM -0400, Jacobs, Todd wrote:
When I use the `--progress` flag with the push command, I get transfer-speed
statistics like this:
$ git push -progress origin master 21 | tee /tmp/push
Counting objects: 30, done.
Compressing objects: 100% (20/20),
On Sun, Oct 13, 2013 at 08:42:40PM +, brian m. carlson wrote:
If I'm going to be adding an option to a command, should I update the
documentation in the same commit or in a separate commit?
I would say the same commit, where it can help a reviewer see the code
change in the context of the
On my system this is in /usr/share/asciidoc/dblatex not
/etc/asciidoc/dblatex. Extract this portion of the path to a variable
so that is can be set in config.mak.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
On Wed, Oct 02, 2013 at 10:25:25AM +0200, Matthijs Kooijman wrote:
sometimes when I send a patch, I want to reply it to an existing e-mail,
using pretty much the same recipient list. Currently, I have to:
- copy-paste the message id for --in-reply-to header
- copy one address for --to
-
On Fri, Sep 27, 2013 at 10:28:05AM +0200, Francis Moreau wrote:
On Fri, Sep 27, 2013 at 10:11 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
Hi,
On Thu, Sep 26, 2013 at 10:21 PM, John Keeping j...@keeping.me.uk wrote:
On Thu
, clarify the
following line by using strlen instead of a hard-coded length, which
also makes it consistent with nearby code.
Reported-by: Luke Noel-Storr luke.noel-st...@integrate.co.uk
Signed-off-by: John Keeping j...@keeping.me.uk
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
I'm trying to use git log --cherry ... in order to display new, kept
and removed commits between two branches A and B.
So commits which are only in B are considered new and should be marked
with '+'. Commits which are in both
On Thu, Sep 26, 2013 at 01:47:20PM -0700, Jonathan Nieder wrote:
John Keeping wrote:
The diff-algorithm option to the recursive merge strategy takes the
name of the algorithm as an option, but it uses strcmp on the option
string to check if it starts with diff-algorithm=, meaning
On Tue, Sep 24, 2013 at 10:00:30AM +0100, Luke Noel-Storr wrote:
I'm trying to use the diff-algorithm option for recursive merge, but
get the above error. I've tried various different ways of specifying
the option, but none work.
To try and find what the correct syntax is I tried peeping
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
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
201 - 300 of 839 matches
Mail list logo
