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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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, 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
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 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
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
, 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 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
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 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 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 Mon, Jul 08, 2013 at 03:47:19PM +0200, Matthieu Moy wrote:
John Keeping j...@keeping.me.uk writes:
static const char message_advice_pull_before_push[] =
N_(Updates were rejected because the tip of your current branch is
behind\n
- its remote counterpart. Merge the remote
On Mon, Jul 08, 2013 at 02:56:57PM +0200, Michael Schubert wrote:
$gmane/201715 brought up the idea to fetch --prune by default.
Since --prune is a potentially destructive operation (Git doesn't
keep reflogs for deleted references yet), we don't want to prune
without users consent.
To
On Sat, Jul 06, 2013 at 09:12:31PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
@@ -1096,19 +1101,18 @@ sub smtp_auth_maybe {
# Helper to come up with SSL/TLS certification validation params
# and warn when doing no verification
sub ssl_verify_params
On Wed, Jul 03, 2013 at 11:47:50AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Since commit 00b347d (git-config: do not complain about duplicate
entries, 2012-10-23), git config --get does not exit with an error if
there are multiple values for the specified key
(in terms of being a command) and seems to cover the
merge and rebase cases nicely.
John Keeping (2):
push: avoid suggesting merging remote changes
pull: change the description to integrate changes
Documentation/git-pull.txt | 2 +-
builtin/push.c | 12 ++--
git-pull.sh
'git pull' to 'git pull ...' to hint to users
that they may want to add other parameters.
Suggested-by: Philip Oakley philipoak...@iee.org
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/push.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin
Since git-pull learned the --rebase option it has not just been about
merging changes from a remote repository (where merge is in the sense
of git merge). Change the description to use integrate instead of
merge in order to reflect this.
Signed-off-by: John Keeping j...@keeping.me.uk
In order to clarify which value is used when there are multiple values
defined for a key, re-order the list of file locations so that it runs
from least specific to most specific. Then add a paragraph which simply
says that the last value will be used.
Signed-off-by: John Keeping j
On Mon, Jul 08, 2013 at 12:00:02AM +0200, Robin Rosenberg wrote:
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
Documentation/git-config.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
On Fri, Jul 05, 2013 at 11:25:36PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I'd rather have '$smtp_ssl_cert_path ne ' in the first if condition
(instead of the '-d $smtp_ssl_cert_path') ...
I agree. The signal for no certs should be an explicit nonsense
On Fri, Jul 05, 2013 at 03:48:31PM +0530, Ramkumar Ramachandra wrote:
Due to a recent change in the Net::SMTP::SSL module, send-email emits
the following ugly warning everytime a email is sent via SSL:
***
Using the default of
On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
You've covered the STARTTLS case, but not the SSL one right above it.
Someone using smtps on port 465 will still see the warning. You can
pass SSL_verify_mode to
On Fri, Jul 05, 2013 at 11:30:11AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
You've covered the STARTTLS case, but not the SSL one right
On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote:
Hi,
If a prepare-commit-msg hook is used, git gui executes it for New Commit.
If the New Commit is selected, and then immediately Amend (before
the hook returns), when the hook returns the message is replaced with
the one
On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote:
On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote:
On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote:
Hi,
If a prepare-commit-msg hook is used, git gui executes it for New Commit.
If the New
On Thu, Jul 04, 2013 at 08:10:07PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Thu, Jul 4, 2013 at 7:56 PM, Thomas Koch tho...@koch.ro wrote:
we're evaluating Git to be used in our companies Tool. But a hard
requirement
is the possibility to set an intend-to-edit flag on a file (better path).
On Wed, Jul 03, 2013 at 10:02:34AM +0200, Michael Haggerty wrote:
On 07/03/2013 12:21 AM, Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
def get(self, name, default=''):
try:
values = self._split(read_git_output(
On Wed, Jul 03, 2013 at 09:29:02AM +0100, John Keeping wrote:
Doesn't git config --get return an error if there are multiple values?
The answer is apparently no - I wrote the text below from
git-config(1) and then checked the behaviour. This seems to be a
regression in git-config (bisect
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which behaves predictably
whatever locale is in use.
Signed-off-by: John Keeping j...@keeping.me.uk
---
This patch
On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which
On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
Hello!
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
[1]: http://marc.info/?l=gitm=135215709307126q=raw
When I use `git log
On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
Lukas Fleischer g...@cryptocrack.de writes:
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
[...]
$ git log --oneline --follow builtin/clone.c | wc -l
125
$ git log --oneline --follow --reverse
On Wed, Jul 03, 2013 at 12:53:39AM +0530, Ramkumar Ramachandra wrote:
class CommandError(Exception):
def __init__(self, cmd, retcode):
self.cmd = cmd
self.retcode = retcode
Exception.__init__(
self,
'Command %s failed with retcode
On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Here, git pull . branch1 is merely saying I want to integrate
the work on my current branch with that of branch1 without saying
how that integration wants to happen.
The change
Hi Junio, I don't think you've picked this up. Are you expecting a
re-roll or did it just get lost in the noise?
On Sat, Jun 22, 2013 at 12:25:17PM +0100, John Keeping wrote:
git-completion.bash's parsing of the command name relies on everything
preceding it starting with '-' unless
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
Because letting a trivial merge automatically handled by Git is so
easy with git pull, a person who is new to Git may not realize
that the project s/he is interacting with may prefer rebase
workflow. Add a safety valve to fail
On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
test_expect_success \
'merge-setup part 3' \
-'git pull . branch1'
+'git pull --merge . branch1'
I think the --merge should be implied here because the suer has
On Wed, Jun 26, 2013 at 11:06:41PM +0300, Kevin Bracey wrote:
git am was previously modified to provide --continue for consistency
with rebase, merge etc, and the documentation changed to showing
--continue as the primary form.
Complete the work by replacing remaining uses of --resolved by
On Thu, Jun 27, 2013 at 11:05:09AM -0700, Junio C Hamano wrote:
John Szakmeister j...@szakmeister.net writes:
On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
diff --git a/git-am.sh b/git-am.sh
index 9f44509..ad67194 100755
--- a/git-am.sh
+++
On Sat, Jun 22, 2013 at 07:16:48PM -0700, Dave Abrahams wrote:
on Sat Jun 22 2013, John Keeping john-AT-keeping.me.uk wrote:
On Fri, Jun 21, 2013 at 02:21:47AM -0700, Dave Abrahams wrote:
The docs for fast-import seem to imply that I can use ls to get the
SHA1 of a commit for which I
On Sun, Jun 23, 2013 at 07:19:25AM -0700, Dave Abrahams wrote:
on Sun Jun 23 2013, John Keeping john-AT-keeping.me.uk wrote:
In this case, I think I do now understand why the mode is 0: in
parse_ls a new tree object is created and the SHA1 of the original is
copied in but the mode is left
This prevents a failure later when we lift the restriction on ls with
the empty path.
Signed-off-by: John Keeping j...@keeping.me.uk
---
fast-import.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fast-import.c b/fast-import.c
index 23f625f..bdbadea 100644
--- a/fast-import.c
+++ b/fast
://article.gmane.org/gmane.comp.version-control.git/228586
John Keeping (4):
t9300: document fast-import empty path issues
fast-import: set valid mode on root tree in ls
fast-import: allow ls or filecopy of the root tree
fast-import: allow moving the root tree
fast-import.c | 58
...@boostpro.com
Signed-off-by: John Keeping j...@keeping.me.uk
---
t/t9300-fast-import.sh | 65 ++
1 file changed, 65 insertions(+)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index ac6f3b6..f4b9355 100755
--- a/t/t9300-fast-import.sh
+++ b/t
is invalid).
However, the implementation also caught the empty path, which should
represent the root tree. Relax this restriction so that the empty path
is explicitly allowed and refers to the root tree.
Reported-by: Dave Abrahams d...@boostpro.com
Signed-off-by: John Keeping j...@keeping.me.uk
path and handling it.
Signed-off-by: John Keeping j...@keeping.me.uk
---
fast-import.c | 21 ++---
t/t9300-fast-import.sh | 2 +-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index e2c9d50..21db3fc 100644
--- a/fast
On Sun, Jun 23, 2013 at 12:19:05PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
+my $diff_algorithm = ($repo-config('diff.algorithm') or 'default');
+
my $use_readkey = 0;
my $use_termcap = 0;
my %term_escapes;
@@ -731,6 +733,9 @@ sub run_git_apply
On Fri, Jun 21, 2013 at 02:21:47AM -0700, Dave Abrahams wrote:
The docs for fast-import seem to imply that I can use ls to get the
SHA1 of a commit for which I have a mark:
Reading from a named tree
The dataref can be a mark reference (:idnum) or the full
40-byte
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 2 ++
t/t9902-completion.sh | 1 +
2 files changed, 3 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8fbf941..c3290af
, the completion only handles the stuck form --git-dir=path
and not --git-dir path, so fix this as well.
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git
On Sat, Jun 22, 2013 at 05:13:29PM +0530, Ramkumar Ramachandra wrote:
Corresponding to woman.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-help.txt | 3 +++
builtin/help.c | 11 ---
2 files changed, 11 insertions(+), 3 deletions(-)
On Tue, Jun 18, 2013 at 03:25:22PM +0200, Alexander Nestorov wrote:
Recently I had to write some automation scripts and I found
that git reset --hard actually restores each file's permissions.
That is causing both the created and the last-modified dates
of the file to get changed to the time
Only leading whitespace is changed in this patch.
Signed-off-by: John Keeping j...@keeping.me.uk
---
t/t7401-submodule-summary.sh | 80 ++--
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule
and matches the sm_path variable.
* I audited the code again and fixed a few more cases that weren't
printing relative paths (notably submodule init and submodule
foreach).
* More tests.
John Keeping (6):
t7401: make indentation consistent
t7403: modernize style
t7403: add missing
Change the indentation to use tabs consistently and start content on the
line after the paren opening a subshell.
Also don't put a space in file and remove : from : file to be
consistent with the majority of tests elsewhere.
Signed-off-by: John Keeping j...@keeping.me.uk
---
t/t7403-submodule
-by: John Keeping j...@keeping.me.uk
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..bdb438b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -485,7 +485,7 @@ cmd_foreach
relative URLs
in git submodule add when not at the top level of the working tree.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-submodule.sh | 135 ---
t/t7400-submodule-basic.sh | 80 +
t/t7401-submodule
Signed-off-by: John Keeping j...@keeping.me.uk
---
t/t7403-submodule-sync.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 38f6cc4..bf90098 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t7403-submodule-sync.sh
of
the working tree but need to handle relative paths given by the user on
the command line.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-rev-parse.txt | 16 +++
builtin/rev-parse.c | 24 ---
t/t1513-rev-parse-prefix.sh | 96
A simple style fix; no functional change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Nothing in maint..pu is touching this at the moment, so hopefully this
is a good time to fix the whitespace here.
Documentation/Makefile | 42 +-
1 file changed
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index af3d8a4..0cfdc36 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -81,6 +81,7
Instead of needing a wrapper to call the diff/merge command, simply
provide the diff_cmd and merge_cmd functions for user-specified tools in
the same way as we do for built-in tools.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 82
On Sat, Jun 15, 2013 at 06:18:46PM +0200, Thomas Koch wrote:
I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore
file
referenced by core.excludesfile that looks like this:
# ignore everything by default
*
# but do not ignore emacs stuff
!.emacs.d/
# but than
301 - 400 of 839 matches
Mail list logo
