Re: [git] [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
W. Trevor King wk...@tremily.us writes: 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. Or they may not even realize that they've just merged an unrelated branch at all, dragging in a thousand unrelated commits which they accidentally push to a central repository without looking, contaminating future branches based on the central repostitory without drastic rebase surgery ;). I just saw one of these earlier this week. I don't understand how the change would solve this. If pull would drag a lot of commits in the current branch, the rebase will rebase the current branch on a totally different history, and pushing the result would be equally bad. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] [submodule] Add depth to submodule update
On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote: Am 26.06.2013 23:03, schrieb Junio C Hamano: Fredrik Gustafsson iv...@iveqy.com writes: On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote: On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote: Used only when a clone is initialized. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com I this is a valid use case. But this option only makes sense when a submodule is newly cloned so I am not sure whether submodule update is the correct place. Let me think about this a little more. Since we do not have any extra command that initiates the clone this is probably the only place we can put this option. But at the moment it does not feel completely right. Apart from that the code looks good. If the user does a checkout of a revision that was not fetched submodule update will error out the same way as if someone forgot to push his submodule changes. So that should not be a problem. I agree and would love to say that I've a more beautiful solution, but I haven't. The only other solution I can think about is to add a git submodule clone that will do only clones of non-cloned submodules. The update subcommand already has --init to do init update, and it would not complain if a given submodule is what you already have shown interest in, so in that sense, I do not think what the posted patch does is too bad---if it is already cloned, it just ignores the depth altogether and makes sure the repository is there. A separate submodule clone would only make it more cumbersome to use, I suspect. Yup, I see no need for a new command either. I agree there is no reason for that. Me too thinks adding --depth to update makes sense (and I don't think that this pretty generic name will become a problem later in case someone wants to add a maximum recursion depth, as grep already uses --max-depth for the same purpose). Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. But --depth should also be added to the submodule add command. As an example we already have the --reference option, which is passed to clone on add and update. Additionally that one supports the form with and without '=', so I'd prefer the new update option to basically re-use the same code the reference option uses. And at least two tests, of course ;-) And add documentation, please :-) Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible error on the git-svn man page
Hello, On the git-svn(1) man page, the third example in the Basic Examples section discusses how one can speed up the initial clone of a Subversion repository by cloning it from Git first and linking it to Subversion afterwards. However, it seems this example is not correct. I have had several people try it on several different repositories, with different git versions (specifically, 1.7 and 1.8) - and every time the process fails at the same moment with the same error message: $ git checkout -b master FETCH_HEAD fatal: Cannot update paths and switch to branch 'master' at the same time. Did you intend to checkout 'FETCH_HEAD' which can not be resolved as commit? Therefore, I believe the man page ought to be updated so that the example works again. If you have any questions, please let me know (by direct e-mail - I am not subscribed to the mailing list). All the best, -- MS -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] completion: handle unstuck form of base git options
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 it is the -c option. This
allows users to use the stuck form of --work-tree=path and
--namespace=path but not the unstuck forms --work-tree path and
--namespace path. Fix this.
Similarly, 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-completion.bash
b/contrib/completion/git-completion.bash
index 6c3bafe..8fbf941 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2492,9 +2492,10 @@ __git_main ()
i=${words[c]}
case $i in
--git-dir=*) __git_dir=${i#--git-dir=} ;;
+ --git-dir) ((c++)) ; __git_dir=${words[c]} ;;
--bare) __git_dir=. ;;
--help) command=help; break ;;
- -c) c=$((++c)) ;;
+ -c|--work-tree|--namespace) ((c++)) ;;
-*) ;;
*) command=$i; break ;;
esac
--
1.8.3.1.676.gaae6535
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
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 git pull that is not a fast-forward until/unless the user expressed her preference between the two. Those who want the existing behaviour could just do git config --global pull.rebase false once, and they'd not even notice. http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326 for a full discussion. The fallout from this change to test suite is not very pretty, though. Signed-off-by: Junio C Hamano gits...@pobox.com --- [snip] diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh index c56a77d..af02c6d 100644 --- a/t/annotate-tests.sh +++ b/t/annotate-tests.sh @@ -79,7 +79,7 @@ test_expect_success \ 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 specified an explicit remote and branch. Similarly, if --ff, --no-ff or --ff-only are given then we can infer --merge in the absence of any other configuration. However, when I looked at doing this I decided that it would be difficult to get that ideal behaviour without rewriting git-pull as a builtin. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote: W. Trevor King wk...@tremily.us writes: 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. Or they may not even realize that they've just merged an unrelated branch at all, dragging in a thousand unrelated commits which they accidentally push to a central repository without looking, contaminating future branches based on the central repostitory without drastic rebase surgery ;). I just saw one of these earlier this week. I don't understand how the change would solve this. If pull would drag a lot of commits in the current branch, the rebase will rebase the current branch on a totally different history, and pushing the result would be equally bad. I want the warning that they had not made the required config choice between rebase/merge needed to handle a non-ff case, not the default merge (or rebase) behavior. The warning gives them a chance to realize that this was not an appropriate time for a `svn update` analog, and that the project may not to want to have the branches joined at all ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/5] git-prompt: cleaning and improvement
Hi, On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote: The merged result is ok! Yeah, it look good, thanks. Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] submodule: add 'exec' option to submodule update
This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the submodule update process may prove useful for integrating or extending other tools. Signed-off-by: Chris Packham judge.pack...@gmail.com -- Hi, At $dayjob we have a number of users that are accustomed to using stgit. Stgit doesn't play nicely with git rebase which would be the logical setting for submodule.*.update for our usage. Instead we need to run 'stg rebase --merged' on those submodules that have been initialised with stgit. Our current solution is an in-house script which is a poor substitute for git submodule update. I'd much rather replace our script with git submodule update but we do have a requirement to keep stgit for the foreseeable future. Rather than narrowing in on stgit it seems logical to allow an arbitrary update command to be executed. --- Documentation/git-submodule.txt | 8 +++- git-submodule.sh| 22 +- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index e576713..a0d8b89 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -16,7 +16,7 @@ SYNOPSIS 'git submodule' [--quiet] deinit [-f|--force] [--] path... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] - [--merge] [--recursive] [--] [path...] + [--merge] [--recursive] [--exec command] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] 'git submodule' [--quiet] foreach [--recursive] command @@ -172,6 +172,12 @@ If `--force` is specified, the submodule will be checked out (using `git checkout --force` if appropriate), even if the commit specified in the index of the containing repository already matches the commit checked out in the submodule. ++ +If `--exec` is specified the next argument is an arbitrary shell command that +can be used to gain finer control over how the update is done or integrate with +external tools. The command should take one argument namely the sha1 of the +commit to update to. The config variable `submodule.$name.update` can be set +to `exec` along with `submodule.$name.update.command`. summary:: Show commit summary between the given commit (defaults to HEAD) and diff --git a/git-submodule.sh b/git-submodule.sh index eb58c8e..44631c8 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -9,7 +9,7 @@ USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference re or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...] or: $dashless [--quiet] init [--] [path...] or: $dashless [--quiet] deinit [-f|--force] [--] path... - or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--exec command] [--] [path...] or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] [commit] [--] [path...] or: $dashless [--quiet] foreach [--recursive] command or: $dashless [--quiet] sync [--recursive] [--] [path...] @@ -32,6 +32,7 @@ nofetch= update= prefix= custom_name= +update_exec_command= # The function takes at most 2 arguments. The first argument is the # URL that navigates to the submodule origin repo. When relative, this URL @@ -677,6 +678,12 @@ cmd_update() --checkout) update=checkout ;; + --exec) + case $2 in '') usage ;; esac + update=exec + update_exec_command=$2 + shift + ;; --) shift break @@ -718,6 +725,11 @@ cmd_update() update_module=$(git config submodule.$name.update) fi + if test -z $update_exec_command + then + exec_command=$(git config submodule.$name.update.command) + fi + if test $update_module = none then echo Skipping submodule '$prefix$sm_path' @@ -799,6 +811,14 @@ Maybe you want to use 'update --init'?) say_msg=$(eval_gettext Submodule path '\$prefix\$sm_path': merged in '\$sha1') must_die_on_failure=yes ;; + exec) + test -n $exec_command || \ + die
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Am 28.06.2013 11:53, schrieb Chris Packham:
This allows the user some finer grained control over how the update is
done. The primary motivation for this was interoperability with stgit
however being able to intercept the submodule update process may prove
useful for integrating or extending other tools.
Signed-off-by: Chris Packham judge.pack...@gmail.com
--
Hi,
At $dayjob we have a number of users that are accustomed to using stgit.
Stgit doesn't play nicely with git rebase which would be the logical
setting for submodule.*.update for our usage. Instead we need to run
'stg rebase --merged' on those submodules that have been initialised
with stgit.
Our current solution is an in-house script which is a poor substitute
for git submodule update. I'd much rather replace our script with git
submodule update but we do have a requirement to keep stgit for the
foreseeable future. Rather than narrowing in on stgit it seems logical
to allow an arbitrary update command to be executed.
Hhmmm...
Can't the same be accomplished with
git submodule foreach 'your-update-script $sha1'
Am I missing something?
Stefan
--
/dev/random says: Preserve nature... pickle a squirrel.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Hi, On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote: This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the submodule update process may prove useful for integrating or extending other tools. Signed-off-by: Chris Packham judge.pack...@gmail.com -- Hi, At $dayjob we have a number of users that are accustomed to using stgit. Stgit doesn't play nicely with git rebase which would be the logical setting for submodule.*.update for our usage. Instead we need to run 'stg rebase --merged' on those submodules that have been initialised with stgit. Our current solution is an in-house script which is a poor substitute for git submodule update. I'd much rather replace our script with git submodule update but we do have a requirement to keep stgit for the foreseeable future. Rather than narrowing in on stgit it seems logical to allow an arbitrary update command to be executed. --- Documentation/git-submodule.txt | 8 +++- git-submodule.sh| 22 +- 2 files changed, 28 insertions(+), 2 deletions(-) technically it looks fine to me (except for the lack of tests) but I'm not sure I follow the use case. In your case, you want to run a script to determinate if that certain submodule should use merge or rebase depending on whatever. And this can't be done with git submodule foreach because you want to know the sha1 to update to. Have I understood you correctly? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add completer for status
On Fri, Jun 28, 2013 at 12:56:01PM +0200, SZEDER Gábor wrote:
On Fri, Jun 28, 2013 at 12:29:36PM +0200, SZEDER Gábor wrote:
On Mon, Jun 24, 2013 at 10:52:55PM +0530, Ramkumar Ramachandra wrote:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
+ __git_complete_index_file
With or without this change we can't ask for the status of a certain
deleted file:
$ git rm version.h
rm 'version.h'
$ git status
# On branch master
# Changes to be committed:
# (use git reset HEAD file... to unstage)
#
# deleted:version.h
#
$ git status vTAB
varint.c varint.h vcs-svn/ version.c
Well, at least the deleted is there if I only remove it from the work
tree (i.e. use 'rm' instead of 'git rm'):
$ rm version.h
$ git status
# On branch master
# Changes not staged for commit:
# (use git add/rm file... to update what will be committed)
# (use git checkout -- file... to discard changes in working
# directory)
#
# deleted:version.h
#
no changes added to commit (use git add and/or git commit -a)
$ git status vTAB
varint.c varint.h vcs-svn/ version.c version.h
Ok, how about this on top?
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 912fb988..b68024c6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1697,6 +1697,8 @@ _git_stage ()
_git_status ()
{
+ __git_has_doubledash return
+
case $cur in
--untracked-files=*)
__gitcomp no normal all ${cur##--untracked-files=}
@@ -1718,7 +1720,7 @@ _git_status ()
return
;;
esac
- __git_complete_index_file
+ __git_complete_index_file --with-tree=HEAD --cached --deleted
}
__git_config_get_set_variables ()
In my cursory testing it seemed to do the right thing for deleted and
tracked files:
$ rm version.h
$ git rm version.c
rm 'version.c'
$ echo varint.h
$ echo v-added
$ git add v-added
$ echo v-untracked
$ git status
# On branch master
# Changes to be committed:
# (use git reset HEAD file... to unstage)
#
# new file: v-added
# deleted:version.c
#
# Changes not staged for commit:
# (use git add/rm file... to update what will be committed)
# (use git checkout -- file... to discard changes in working
# directory)
#
# modified: varint.h
# deleted:version.h
#
# Untracked files:
# (use git add file... to include in what will be committed)
#
# v-untracked
$ git status v
v-addedvarint.c varint.h vcs-svn/ version.c version.h
Note, however, that this doesn't offer untracked files (Ram's original
didn't do that either), but in case somebody really needs that he can
have it by using '--':
$ git status -- v
v-added varint.c varint.h vcs-svn/ v-untracked
Best,
Gábor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone -b
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
--
/dev/random says: Second star to the right straight on till morning...
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 28.06.2013 13:59, schrieb Stefan Näwe:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
Oh, and while at it:
This doesn't look/feel right:
$ git clone -b refs/heads/master git/.git other-git
Cloning into 'other-git'...
fatal: Remote branch refs/heads/master not found in upstream origin
fatal: The remote end hung up unexpectedly
(where git is git's git which definitely has refs/heads/master...)
Stefan
--
/dev/random says: In God we trust; all else we walk through.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote: Hi there! Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) or a tag (from refs/tags/) ? Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/) to communicate between the 'branch integrator' (who creates the ref in refs/releases/) and the 'build master' who wants to build that ref. It would be a little easier if the build master could simply say git clone -b refs/releases/the-release-for-today URL instead of: git clone... ; cd ... ; git fetch... ; git checkout Any answer or even a better idea to solve that is appreciated. Stefan I don't understand what the alternative should be. You can't look in /refs/* because there's a lot of other stuff like bisect/remotes etc. there. Of course you could add to also look in /refs/releases/ but as I understand you that a special solution for your company. Why should all git users have that addition? Two questions about your setup: 1. Why do you always clone your repository? To me clone is a one time operation. 2. Why don't you tag your releases with an ordinary tag? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 28.06.2013 14:18, schrieb Fredrik Gustafsson:
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
I don't understand what the alternative should be. You can't look in
/refs/* because there's a lot of other stuff like bisect/remotes etc.
there.
Well, I tell clone exactly what I want. There is no reason try something
from refs/*.
Of course you could add to also look in /refs/releases/ but as I
understand you that a special solution for your company. Why should all
git users have that addition?
It wouldn't hurt, IMHO. Maybe it would even make sense to allow any SHA-1
to be passed to '-b'.
Two questions about your setup:
1. Why do you always clone your repository? To me clone is a one
time operation.
We would use 'git archive' if that would be submodule-aware...
2. Why don't you tag your releases with an ordinary tag?
Because we use that 'refs/release' thing as a hidden ref that other
developers will not see when they fetch (unless they are told to checkout
that particular ref).
Think of using this similar to the way github uses refs/pull/*/{head,merge}
for their pull request mechanism.
Stefan
--
/dev/random says: The Definition of an Upgrade: Take old bugs out, put new ones
in.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug on OS X...
On 27.06.2013, at 12:17, John Szakmeister wrote: I wanted to look at some OpenWRT bits this morning and ran into an issue cloning the packages repository when setting up the package feed. The feeds script executes this under the hood: git clone --depth 1 git://nbd.name/packages.git feeds/packages When trying to run the command directly on OS X, I see: :: git clone --depth 1 git://nbd.name/packages.git Cloning into 'packages'... remote: Counting objects: 4728, done. remote: Compressing objects: 100% (4013/4013), done. remote: Total 4728 (delta 158), reused 3339 (delta 94) Receiving objects: 100% (4728/4728), 3.85 MiB | 1.79 MiB/s, done. Resolving deltas: 100% (158/158), done. error: unable to find 9f041557a0c81f696280bb934731786e3d009b36 fatal: object of unexpected type fatal: index-pack failed I tried on Linux, and it succeeded. I tested with both 1.8.2 and 1.8.3.1. Unfortunately, I don't have time to dig through what's wrong at the moment so I thought I'd put it out there for others. I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1 nor with current git maint. Command run inside /tmp, which is on a normal HFS+ volume (using the default settings, i.e. the FS is case insensitive). $ git --version git version 1.8.3.1.42.ge2652c0 $ git clone --depth 1 git://nbd.name/packages.git Cloning into 'packages'... remote: Counting objects: 4711, done. remote: Compressing objects: 100% (3998/3998), done. remote: Total 4711 (delta 157), reused 3326 (delta 94) Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done. Resolving deltas: 100% (157/157), done. Cheers, Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add completer for status
SZEDER Gábor wrote:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 912fb988..b68024c6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1697,6 +1697,8 @@ _git_stage ()
_git_status ()
{
+ __git_has_doubledash return
+
This line makes absolutely no sense to me. When the case statement
fails to match anything (which it will, when a double-dash is
present), we'll use the __git_complete_index_file which is superior to
returning and falling back to the dumb zsh file listing, no? As a
result, without that line,
$ git status -- fooTAB
will complete fine when foo* isn't necessarily a file in the
filesystem, but something that our ls-files returns, no?
case $cur in
--untracked-files=*)
__gitcomp no normal all ${cur##--untracked-files=}
@@ -1718,7 +1720,7 @@ _git_status ()
return
;;
esac
- __git_complete_index_file
+ __git_complete_index_file --with-tree=HEAD --cached --deleted
Might as well go all the way with --cached --deleted --unmerged
--others no? What is the point of --with-tree=HEAD?
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [submodule] Add --depth to submodule update/add
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
Documentation/git-submodule.txt | 13 +++--
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 18 ++
t/t7406-submodule-update.sh | 28
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..b17001a 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--depth depth] [--] repository
[path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,15 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ A shallow repository has a number of limitations (you cannot clone
+ or fetch from it, nor push from nor into it), but is adequate if
+ you are only interested in the recent history of a large project
+ with a long history.
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..c99bc7c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -234,7 +236,7 @@ module_clone()
(
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
- --separate-git-dir $gitdir $url $sm_path
+ --separate-git-dir $gitdir $depth $url
$sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout)
update=checkout
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -735,7 +753,7 @@ Maybe you want to use 'update --init'?)
Re: [git] [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
W. Trevor King wk...@tremily.us writes:
I want the warning that they had not made the required config choice
between rebase/merge needed to handle a non-ff case, not the default
merge (or rebase) behavior. The warning gives them a chance to
realize that this was not an appropriate time for a `svn update`
analog, and that the project may not to want to have the branches
joined at all ;).
You're assuming that the config is not made, but this is supposed to
happen once initially. Then, the user will chose either merge or rebase,
and whatever is chosen, the result will be bad.
I'm hoping that reading the error message reminds them that these
cross-branch pulls are not recommended (for us), and that they skip
the configuration step (so they'll get the same warning after their
next subconcious pull). Of course, there are no guarantees. But if
they do configure their rebase/merge preference and make and push bad
merge, at least I'll have something I can suggest as a finger-breaker.
Of course, they should already be seeing their editor with a merge
commit message that they are ok-ing. If that's not enough to make
them think twice, a warning that:
The pull does not fast-forward; …
may fall on deaf ears (blind eyes?). However, for folks used to only
having a single branch, this may be enough of a jolt to wake them up.
I'm not making a very strong case, and this whole line of reasoning is
getting off topic for this PR. Unless we adapt it to:
pull.non-ff = {merge,rebase,never}
which is, I think, even less likely to land ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: Bug on OS X...
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de wrote: [snip] I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1 nor with current git maint. Command run inside /tmp, which is on a normal HFS+ volume (using the default settings, i.e. the FS is case insensitive). $ git --version git version 1.8.3.1.42.ge2652c0 $ git clone --depth 1 git://nbd.name/packages.git Cloning into 'packages'... remote: Counting objects: 4711, done. remote: Compressing objects: 100% (3998/3998), done. remote: Total 4711 (delta 157), reused 3326 (delta 94) Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done. Resolving deltas: 100% (157/157), done. OK, so I finally tracked it down. Commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f fixes it: commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com Date: Sun May 26 08:16:15 2013 +0700 fetch-pack: prepare updated shallow file before fetching the pack index-pack --strict looks up and follows parent commits. If shallow information is not ready by the time index-pack is run, index-pack may be led to non-existent objects. Make fetch-pack save shallow file to disk before invoking index-pack. git learns new global option --shallow-file to pass on the alternate shallow file path. Undocumented (and not even support --shallow-file= syntax) because it's unlikely to be used again elsewhere. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com It looks like I was hitting the race condition. It's fixed on master, so I assume it will be in 1.8.3.2. Thanks for taking a look though! -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add completer for status
Ramkumar Ramachandra wrote: + __git_complete_index_file --with-tree=HEAD --cached --deleted Might as well go all the way with --cached --deleted --unmerged --others no? What is the point of --with-tree=HEAD? Ugh, --deleted doesn't work as advertised (terrible documentation). The minimally correct combination we need seems to be --with-tree=HEAD --cached --others. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add completer for status
On Fri, Jun 28, 2013 at 06:50:02PM +0530, Ramkumar Ramachandra wrote:
SZEDER Gábor wrote:
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 912fb988..b68024c6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1697,6 +1697,8 @@ _git_stage ()
_git_status ()
{
+ __git_has_doubledash return
+
This line makes absolutely no sense to me.
That was my quick attempt to provide a way to complete untracked
files, but M-/ or '--others' will do as well.
When the case statement
fails to match anything (which it will, when a double-dash is
present), we'll use the __git_complete_index_file which is superior to
And slower, too.
returning and falling back to the dumb zsh file listing, no? As a
result, without that line,
$ git status -- fooTAB
will complete fine when foo* isn't necessarily a file in the
filesystem, but something that our ls-files returns, no?
If you want fancy completion replies, then you won't type the
doubledash.
case $cur in
--untracked-files=*)
__gitcomp no normal all ${cur##--untracked-files=}
@@ -1718,7 +1720,7 @@ _git_status ()
return
;;
esac
- __git_complete_index_file
+ __git_complete_index_file --with-tree=HEAD --cached --deleted
Might as well go all the way with --cached --deleted --unmerged
--others no?
'--unmerged' is definitely not good, it implies '--stage', which
changes the output format.
What is the point of --with-tree=HEAD?
To list files that are deleted from the index:
$ rm version.h
$ git rm version.c
rm 'version.c'
$ git ls-files --deleted
version.h
$ git ls-files --deleted --with-tree=HEAD
version.c
version.h
Gábor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase -i: fixup fixup! fixup!
Excerpts from Junio C Hamano's message of Thu Jun 27 13:52:33 -0700 2013: Two issues here, which I'll locally amend (no need to resend): Great! Thank you for your help and patience. cat expected -EOF pick ... ... EOF test_cmp expected actual Is that two issues? Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] completion: complete rebase --edit-todo
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 6c3bafe..b51c9e3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1609,6 +1609,10 @@ _git_rebase ()
{
local dir=$(__gitdir)
if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
+ if [ -e $dir/rebase-merge/interactive ]; then
+ __gitcomp --continue --skip --abort --edit-todo
+ return
+ fi
__gitcomp --continue --skip --abort
return
fi
--
1.8.3.1.585.g9832cb9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Batch completion improvements
Hi, An older iteration of [2/4] was just reviewed by SZEDER on the list. [1/4] and [3/4] have been sent out in the past, but haven't been picked up. [4/4] is new. Thanks. Ramkumar Ramachandra (4): completion: complete rebase --edit-todo completion: add completer for status completion: add completer for rev-parse completion: prefer to use local git-completion.bash contrib/completion/git-completion.bash | 45 ++ contrib/completion/git-completion.zsh | 2 +- 2 files changed, 46 insertions(+), 1 deletion(-) -- 1.8.3.1.585.g9832cb9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] completion: add completer for status
Helped-by: SZEDER Gábor sze...@ira.uka.de
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 27 +++
1 file changed, 27 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b51c9e3..278018f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1699,6 +1699,33 @@ _git_stage ()
_git_add
}
+_git_status ()
+{
+ case $cur in
+ --untracked-files=*)
+ __gitcomp no normal all ${cur##--untracked-files=}
+ return
+ ;;
+ --ignore-submodules=*)
+ __gitcomp none untracked dirty all
${cur##--ignore-submodules=}
+ return
+ ;;
+ --column=*)
+ __gitcomp always never auto column row plain dense nodense
${cur##--column=}
+ return
+ ;;
+ --*)
+ __gitcomp
+ --short --branch --long --porcelain --ignored
+ --untracked-files --ignore-submodules --column
+ --untracked-files= --ignore-submodules= --column=
+
+ return
+ ;;
+ esac
+ __git_complete_index_file --with-tree=HEAD --cached --others
+}
+
__git_config_get_set_variables ()
{
local prevword word config_file= c=$cword
--
1.8.3.1.585.g9832cb9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] completion: prefer to use local git-completion.bash
git-completion.zsh looks in various default locations for
git-completion.bash. During development, the location
$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
is the most obvious and up-to-date version. Push it up on the list of
locations.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..6fca145 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.3.1.585.g9832cb9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] completion: add completer for rev-parse
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 14 ++
1 file changed, 14 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 278018f..f2959a7 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2247,6 +2247,20 @@ _git_reset ()
__gitcomp_nl $(__git_refs)
}
+_git_rev_parse ()
+{
+ case $cur in
+ --*)
+ __gitcomp
+ --short --show-toplevel --is-inside-work-tree
+ --symbolic-full-name --verify
+
+ return
+ ;;
+ esac
+ __gitcomp_nl $(__git_refs)
+}
+
_git_revert ()
{
case $cur in
--
1.8.3.1.585.g9832cb9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clone: Skip pack-*.keep files when cloning locally
The pack-*.keep files are temporary, and serve no purpose in the
clone. They would probably also never be deleted from the clone if
copied, since the process that created them only expects to have to
delete them from the original repository.
Worse, though, they are created with access bits 0600, so if the
user trying to clone the repository is different from the user that
caused the pack-*.keep file to be created, the clone will likely
fail due to not being allowed to read (and thus copy) the file in
the first place.
Signed-off-by: Jens Lindstrom j...@opera.com
---
builtin/clone.c |5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index 035ab64..0ec0ec9 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -342,6 +342,11 @@ static void copy_or_link_directory(struct strbuf *src,
struct strbuf *dest,
continue;
}
+ /* Skip pack-*.keep files, they are temporary and not
+ relevant to the clone, and might not be accessible. */
+ if (!strcmp(src-buf + strlen(src-buf) - 5, .keep))
+ continue;
+
/* Files that cannot be copied bit-for-bit... */
if (!strcmp(src-buf + src_baselen, /info/alternates)) {
copy_alternates(src, dest, src_repo);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git stash: Avoid data loss when saving a stash
I have been recently again bitten by git stash versus an uncommitted
file-to-directory change that happily threw away few gigabytes of my
data. This has been recently discussed in the past, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/202332/
and I implemented Junio's suggestion in this patch - if ls-files --killed
produced any output, the stash save is stopped and the user is required
to pass --force to really have the data removed.
A test case is included. I think that the (currently failing) tests
'stash file to directory' and 'stash directory to file' are related to
this, but I consider their expectation to be bogus - I would personally
be surprised by `git stash` suddenly importing the complete
never-meant-to-be-tracked contents of my directory to Git during a stash
save, and I think the approach of aborting in this situation is more
reasonable.
Other parts of Git also behave in a troublesome way in case of tracked
file being replaced by an untracked directory - I wouldn't expect `git
reset --hard` alone to remove the directory (i.e. touch untracked files)
either. However, this matter is much more complicated since `git reset
--hard` is assumed to never fail in ordinary circumstances (see e.g.
git-stash code ;-) and I'm unable to devote sufficient effort to seeing
such a change through.
Signed-off-by: Petr Baudis pa...@ucw.cz
---
Please Cc me, I'm currently not subscribed on the list.
Documentation/git-stash.txt | 12 ++--
git-stash.sh| 10 ++
t/t3903-stash.sh| 16
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..52d4def 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,7 +14,8 @@ SYNOPSIS
'git stash' ( pop | apply ) [--index] [-q|--quiet] [stash]
'git stash' branch branchname [stash]
'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
-[-u|--include-untracked] [-a|--all] [message]]
+[-u|--include-untracked] [-a|--all] [-f|--force]
+[message]]
'git stash' clear
'git stash' create [message]
'git stash' store [-m|--message message] [-q|--quiet] commit
@@ -44,7 +45,7 @@ is also possible).
OPTIONS
---
-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] [message]::
+save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] [-f|--force] [message]::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. The message part is optional and gives
@@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch`
mode.
+
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
++
+In some cases, saving a stash could mean irretrievably removing some
+data - if a directory with untracked files replaces a tracked file of
+the same name, the new untracked files are not saved (except in case
+of `--include-untracked`) but the original tracked file shall be restored.
+Normally, stash save will abort; `--force` will make it remove the
+untracked files.
list [options]::
diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..3cb9b05 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -195,6 +195,7 @@ save_stash () {
keep_index=
patch_mode=
untracked=
+ force=
while test $# != 0
do
case $1 in
@@ -215,6 +216,9 @@ save_stash () {
-u|--include-untracked)
untracked=untracked
;;
+ -f|--force)
+ force=t
+ ;;
-a|--all)
untracked=all
;;
@@ -258,6 +262,12 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+ if test -z $untracked$force -a -n $(git ls-files --killed | head -n
1); then
+ say $(gettext The following untracked files would NOT be
saved but need to be removed by stash save:)
+ test -n $GIT_QUIET || git ls-files --killed | sed 's/^/\t/'
+ say $(gettext Abording. Consider using either the --force or
--include-untracked switches.) 2
+ exit 1
+ fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..4ac4ebe 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,19 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
'
+test_expect_success SYMLINKS 'stash symlink to non-empty directory' '
+ git reset --hard
+ ln -s file2 linkdir
+ git add linkdir
+ git commit -m+linkdir as symlink
+ rm linkdir mkdir
[PATCH] fixup-builtins: remove unused cruft
The fixup-builtins script is only used by an unused remove-dashes target in the Makefile: remove that along with the script. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Makefile | 3 --- fixup-builtins | 16 2 files changed, 19 deletions(-) delete mode 100755 fixup-builtins diff --git a/Makefile b/Makefile index e158376..6b0ddf8 100644 --- a/Makefile +++ b/Makefile @@ -2302,9 +2302,6 @@ check: common-cmds.h exit 1; \ fi -remove-dashes: - ./fixup-builtins $(BUILT_INS) $(PROGRAMS) $(SCRIPTS) - ### Installation rules ifneq ($(filter /%,$(firstword $(template_dir))),) diff --git a/fixup-builtins b/fixup-builtins deleted file mode 100755 index 63dfa4c..000 --- a/fixup-builtins +++ /dev/null @@ -1,16 +0,0 @@ -#!/bin/sh -while [ $1 ] -do - if [ $1 != git-sh-setup -a $1 != git-parse-remote -a $1 != git-svn ]; then - old=$1 - new=$(echo $1 | sed 's/git-/git /') - echo Converting '$old' to '$new' - sed -i s/\\$old\\/$new/g $(git ls-files '*.sh') - fi - shift -done - -sed -i 's/git merge-one-file/git-merge-one-file/g -s/git rebase-todo/git-rebase-todo/g' $(git ls-files '*.sh') -git update-index --refresh /dev/null -exit 0 -- 1.8.3.1.643.gebeea52.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Parse --o in format-patch
Hi, I don't quite manage to figure out gits argv parsing and would need some help on the way. I want: git format-patch -o outdir HEAD~ Work exactly the way it does now, setting output_directory to outdir. But I also want git format-patch -o HEAD~ to set output_directory with a NULL value so that I can assign a default value to it. Is that even possible with the current argv-parsing implementation? The currect argv parser is using OPTION_CALLBACK so I thought that that callback should be able to determine if there was an outdir supplied or not. Or is the correct solution to also add a bolean type OPTION_BOOLEAN for -o? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parse --o in format-patch
On Fri, Jun 28, 2013 at 06:05:00PM +0200, Fredrik Gustafsson wrote: I don't quite manage to figure out gits argv parsing and would need some help on the way. I want: git format-patch -o outdir HEAD~ Work exactly the way it does now, setting output_directory to outdir. But I also want git format-patch -o HEAD~ to set output_directory with a NULL value so that I can assign a default value to it. Is that even possible with the current argv-parsing implementation? It's possible to have an optional argument by using the PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the user's perspective, as they must use the sticked form: git format-patch -ooutdir ... to specify the argument. Otherwise, it is not clear in: git format-patch -o outdir HEAD~ whether outdir is the argument to -o, or if it is simply the next argument. However, if you are just interested in turning off a previously given argument, we usually spell that with the --no- prefix to the long option (e.g., --no-output-directory in this case). I'm not clear how that interacts with your example, though. Your example tries to use -o to set output_directory to NULL. But it is already NULL if you do not specify any -o at all. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fixup-builtins: remove unused cruft
On Fri, Jun 28, 2013 at 09:16:19PM +0530, Ramkumar Ramachandra wrote: The fixup-builtins script is only used by an unused remove-dashes target in the Makefile: remove that along with the script. I am not sure of this justification. If you read the commit message from 36e5e70, which introduced the target, it was meant to be run manually as part of migrating away from dashed forms. Running it today does still uncover some places that could be tweaked. However, I note that it also has a lot of false positives (e.g., removing dashes from places that are not commands, like filenames or config options). It also produces crappy output for documentation (if we do want to change dashed mentions, we would probably want to switch git-foo to `git foo` with some kind of quoting to make it more obvious). So I think it is probably a good idea to remove it, but the justification is not this is unused cruft, but more like: This script was added in 36e5e70 (Start deprecating git-command in favor of git command, 2007-06-30) with the intent of aiding the transition away from dashed forms. However, nobody is really working on that transition, and even if they did, this tool will probably lead them in the wrong direction, as it produces a large number of questionable changes. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parse --o in format-patch
On Fri, Jun 28, 2013 at 12:31:53PM -0400, Jeff King wrote: It's possible to have an optional argument by using the PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the user's perspective, as they must use the sticked form: git format-patch -ooutdir ... to specify the argument. Otherwise, it is not clear in: git format-patch -o outdir HEAD~ whether outdir is the argument to -o, or if it is simply the next argument. That would be a possibility but I don't like breaking backwards compability. I'm not clear how that interacts with your example, though. Your example tries to use -o to set output_directory to NULL. But it is already NULL if you do not specify any -o at all. my goal is to make: git format-patch [-k] [(-o|--output-directory) dir | --stdout] [ since | revision range ] to be: git format-patch [-k] [(-o|--output-directory) [dir] | --stdout] [ since | revision range ] that would do: git format patch - current dir git format patch -o - default dir (for example GIT_DIR/.outgoing/) git format patch -o dir - user defined dir But I guess I would need a new option instead. Something like --default-output-dir. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parse --o in format-patch
On Fri, Jun 28, 2013 at 06:44:40PM +0200, Fredrik Gustafsson wrote: On Fri, Jun 28, 2013 at 12:31:53PM -0400, Jeff King wrote: It's possible to have an optional argument by using the PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the user's perspective, as they must use the sticked form: That would be a possibility but I don't like breaking backwards compability. Yes, I did not say it outright, but I meant ...and that is why we cannot go that route. :) my goal is to make: git format-patch [-k] [(-o|--output-directory) dir | --stdout] [ since | revision range ] to be: git format-patch [-k] [(-o|--output-directory) [dir] | --stdout] [ since | revision range ] that would do: git format patch - current dir git format patch -o - default dir (for example GIT_DIR/.outgoing/) git format patch -o dir - user defined dir Ah, that makes much more sense to me. But I guess I would need a new option instead. Something like --default-output-dir. It depends on how the default is specified. Is it hard-coded? Or do you specify format.outputDirectory? If the latter, I would think you would want it on all the time when -o is not given[1], and no new option is required. Otherwise, yes, I'd think you would want a new option. -Peff [1] format-patch may be considered plumbing, in which case an output directory config option might cause problems with scripts that expect to run it and find the output in the current directory. I'm not sure how big a deal that is. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug on OS X...
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de wrote:
[snip]
I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1
nor with current git maint. Command run inside /tmp, which is on
a normal HFS+ volume (using the default settings, i.e. the FS is
case insensitive).
$ git --version
git version 1.8.3.1.42.ge2652c0
$ git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4711, done.
remote: Compressing objects: 100% (3998/3998), done.
remote: Total 4711 (delta 157), reused 3326 (delta 94)
Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done.
Resolving deltas: 100% (157/157), done.
OK, so I finally tracked it down. Commit
6035d6aad8ca11954c0d7821f6f3e7c047039c8f fixes it:
commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Date: Sun May 26 08:16:15 2013 +0700
fetch-pack: prepare updated shallow file before fetching the pack
...
It looks like I was hitting the race condition. It's fixed on master,
so I assume it will be in 1.8.3.2.
Hmmmph, I do not think the cited change is about any race.
If it were that we spawn index-pack and write updated shallow
information at the same time, and depending on the timings,
index-pack may not read the updated one and fail, then it would have
been a race, but that is not the above change is about. If you
saw the issue on MacOS, you would have seen the same breakage, as
long as you started from the same repository status, on other
platforms, and reliably.
An early part of nd/clone-connectivity-shortcut topic contains the
said commit, and I do not mind merging it to the maintenance track,
but I suspect that there is something else going on on your OS X
box, if you saw differences between platforms.
Perhaps on your OS X box you have {transfer,fetch}.fsckobjects set
to true while on others it is set to false, or something?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] git-prompt: cleaning and improvement
SZEDER Gábor sze...@ira.uka.de writes: On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote: The merged result is ok! Yeah, it look good, thanks. Thanks, both, for double checking (and thank you for preparing the pre-merged results). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] configure: fix help screen
The configure option to disable threading is '--disable-pthreads', not '--without-pthreads'. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f3462d9..2f43393 100644 --- a/configure.ac +++ b/configure.ac @@ -193,7 +193,7 @@ AC_ARG_ENABLE([pthreads], [FLAGS is the value to pass to the compiler to enable POSIX Threads.] [The default if FLAGS is not specified is to try first -pthread] [and then -lpthread.] - [--without-pthreads will disable threading.])], + [--disable-pthreads will disable threading.])], [ if test x$enableval = xyes; then AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads]) -- 1.8.3.1.605.g85318f5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
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 specified an explicit remote and branch. The whole point of the topic is It used to be that when you said 'git pull' and did not tell us your preferred way to integrate your work and work by the others', we default to merging, but we no longer do so---you have to choose. 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. Even though, as an old timer, I find it mildly irritating that we now have to be explicit in these tests, this change is in line with the spirit of the topic. If we didn't have to change this example and the pull silently succeeded without complaining, we achieved nothing. Similarly, if --ff, --no-ff or --ff-only are given then we can infer --merge in the absence of any other configuration. Isn't that already there in the patch to git-merge? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fixup-builtins: remove unused cruft
Jeff King wrote: This script was added in 36e5e70 (Start deprecating git-command in favor of git command, 2007-06-30) with the intent of aiding the transition away from dashed forms. However, nobody is really working on that transition, and even if they did, this tool will probably lead them in the wrong direction, as it produces a large number of questionable changes. Sure, that sounds good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] status: really ignore config with --porcelain
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: You lose the assertion that finalize_deferred_config has been called, but I think the resulting code would be simpler, as it drops this die(BUG) state entirely. Am I missing something? Probably not. Depending on -z, NONE is sometimes converted to PORCELAIN and sometimes left as-is. I originally wanted to keep the unspecified state as long as possible so that this deferred config logic and the -z default logic can be kept separate. The final patch ended up folding that -z default logic into the same function, so it probably is saner to remove UNSPECIFIED. Actually, the code needs to be able to differentiate between git status --no-short git status the former telling us explicitly to defeat status.short while the latter telling us to use whatever random value we happen to have in the configuration. Initializing the variable to UNSPECIFIED is one way to achieve that, as the former will explicitly set it to NONE while the latter will leave it UNSPECIFIED when the command line parsing finishes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
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 specified an explicit remote and branch. The whole point of the topic is It used to be that when you said 'git pull' and did not tell us your preferred way to integrate your work and work by the others', we default to merging, but we no longer do so---you have to choose. 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 that I think is important is that the bring my branch up-to-date operation should force the user to choose what to do if the branch does not fast-forward to its upstream. If that was spelled git update then having git pull perform a merge would be fine, but we spell this operation as git pull so the change needs to happen there. 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 this [1] did talk about only git pull with no arguments. Even though, as an old timer, I find it mildly irritating that we now have to be explicit in these tests, this change is in line with the spirit of the topic. If we didn't have to change this example and the pull silently succeeded without complaining, we achieved nothing. I disagree that we would have achieved nothing. New users will not be using explicit arguments to git-pull when just trying to bring a branch up-to-date. [1] http://article.gmane.org/gmane.comp.version-control.git/225240 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] configure: fix help screen
Stefano Lattarini stefano.lattar...@gmail.com writes: The configure option to disable threading is '--disable-pthreads', not '--without-pthreads'. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- Thanks. configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f3462d9..2f43393 100644 --- a/configure.ac +++ b/configure.ac @@ -193,7 +193,7 @@ AC_ARG_ENABLE([pthreads], [FLAGS is the value to pass to the compiler to enable POSIX Threads.] [The default if FLAGS is not specified is to try first -pthread] [and then -lpthread.] - [--without-pthreads will disable threading.])], + [--disable-pthreads will disable threading.])], [ if test x$enableval = xyes; then AC_MSG_NOTICE([Will try -pthread then -lpthread to enable POSIX Threads]) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: Skip pack-*.keep files when cloning locally
Jens Lindstrom j...@opera.com writes: Hmph. I am of two minds here. The pack-*.keep files are temporary, and serve no purpose in the clone. They are not temporary, actually. A user can deliberatey create a keep marker after packing with a good set of parameters, so that the resulting pack will be kept, instead of letting a later repack (with faster set of parameters) remove and replace it with less optimal results. Worse, though, they are created with access bits 0600, so if the user trying to clone the repository is different from the user that caused the pack-*.keep file to be created, the clone will likely fail due to not being allowed to read (and thus copy) the file in the first place. I am perfectly fine with a change that allows a local clone to skip and not error out when such a keep marker cannot be copied, I do not know if it is a good idea to unconditionally skip and not even attempt to copy it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git stash: Avoid data loss when saving a stash
Petr Baudis pa...@ucw.cz writes:
Signed-off-by: Petr Baudis pa...@ucw.cz
---
Please Cc me, I'm currently not subscribed on the list.
Heh, long time no see.
@@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch`
mode.
+
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
++
+In some cases, saving a stash could mean irretrievably removing some
+data - if a directory with untracked files replaces a tracked file of
+the same name, the new untracked files are not saved (except in case
+of `--include-untracked`) but the original tracked file shall be restored.
+Normally, stash save will abort; `--force` will make it remove the
+untracked files.
It _might_ look obvious from the context after somebody spends
enough time thinking about this case (and only this case) that
in such a case is implied in Normally, ... will abort, but for a
casual reader who encounters this paragraph for the first time, I do
not think it is obvious. I'd rephrase to:
By default, `stash save` will abort in such a case; `--force` will
allow it to remove the untracked files.
@@ -258,6 +262,12 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+ if test -z $untracked$force -a -n $(git ls-files --killed | head -n
1); then
Split the line at the semicolon in ; then. Also git grep will
tell us that we tend to avoid -a in test.
if test -z $untracked$force
test -n $(git ls-files --killed | head -n 1)
then
...
+ say $(gettext The following untracked files would NOT be
saved but need to be removed by stash save:)
+ test -n $GIT_QUIET || git ls-files --killed | sed 's/^/\t/'
+ say $(gettext Abording. Consider using either the --force or
--include-untracked switches.) 2
s/Abord/Abort/;
+ exit 1
+ fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..4ac4ebe 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,19 @@ test_expect_success 'store updates stash ref and reflog'
'
grep quux bazzy
'
+test_expect_success SYMLINKS 'stash symlink to non-empty directory' '
+ git reset --hard
+ ln -s file2 linkdir
+ git add linkdir
+ git commit -m+linkdir as symlink
+ rm linkdir mkdir linkdir touch linkdir/file
Use linkdir/file instead for clarity, when you are not interested
in modifying the timestamp of an existing file.
+ ! git stash save symlink to non-empty directory
Use test_must_fail
+ [ -e linkdir/file ]
test -f linkdir/file You not only want to see it exists, you know
it must be a regular file.
+'
+
+test_expect_success SYMLINKS 'stash symlink to non-empty directory (forced)'
'
+ git stash save --force symlink to non-empty directory (forced)
+ [ ! -e linkdir/file ] [ -L linkdir ]
+'
git grep will tell us that test -h is preferred over test -L
in our codebase.
+
test_done
Also I do not think you need to limit the tests on symlink-capable
platforms. You can create the linkdir as a regular file and
commit, and make a local change to turn it into a directory, and try
to stash save to recover that original regular file.
Thanks. I'll queue it with a pair of fix-up commits on top, so that
they can later be squashed in.
The result of squashing the fix-ups would look like this.
-- 8 --
From: Petr Baudis pa...@ucw.cz
Date: Fri, 28 Jun 2013 17:05:32 +0200
Subject: [PATCH] git stash: avoid data loss when git stash save kills a
directory
stash save is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs to be removed.
Which is fine when running git stash save --include-untracked,
but without that option, untracked, newly created files in the
directory will have to be discarded.
Introduce a safety valve to fail the operation in such case, using
the ls-files --killed which was designed for this exact purpose.
The stash save is stopped when untracked files need to be
discarded because their leading path ceased to be a directory, and
the user is required to pass --force to really have the data
removed.
Signed-off-by: Petr Baudis pa...@ucw.cz
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-stash.txt | 12 ++--
git-stash.sh| 12
t/t3903-stash.sh| 18 ++
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..7c8b648 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@
Re: [PATCH] [submodule] Add depth to submodule update
Heiko Voigt hvo...@hvoigt.net writes: On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote: ... Me too thinks adding --depth to update makes sense (and I don't think that this pretty generic name will become a problem later in case someone wants to add a maximum recursion depth, as grep already uses --max-depth for the same purpose). Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. I do not have a strong opinion either way, but as you suggest, it might be a good idea to call this new option --clone-depth to be more specific. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fixup-builtins: remove unused cruft
Jeff King p...@peff.net writes: So I think it is probably a good idea to remove it, but the justification is not this is unused cruft, but more like: This script was added in 36e5e70 (Start deprecating git-command in favor of git command, 2007-06-30) with the intent of aiding the transition away from dashed forms. However, nobody is really working on that transition, and even if they did, this tool will probably lead them in the wrong direction, as it produces a large number of questionable changes. It is not nobody is working on, but it has already been used to help the transision and served its purpose, and is no longer is very useful for follow-up work because the majority of remaining matches it finds are false positives. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to update git on Mac OS X Mountain Lion 10.8.4
Hello, I've learnt that Xcode installs git by default on the Mac. My current version of git is 1.7.12.4 and it's located in /usr/bin/git. I wanted to update git to the latest stable version available: 1.8.3.1. I proceeded with the instructions on: http://git-scm.com/downloads and typed: git clone https://github.com/git/git.git (rather than using the .dmg file because I don't want to install a new version of git in addition to the existing one used by Xcode. Furthermore, I have no idea where the new version would end up being installed and I've read that users have had trouble doing this!) This rendered the following results: Oliviers-iMac:~ odebroqueville$ git clone https://github.com/git/git.git Cloning into 'git'... remote: Counting objects: 157697, done. remote: Compressing objects: 100% (53116/53116), done. remote: Total 157697 (delta 114700), reused 143715 (delta 102625) Receiving objects: 100% (157697/157697), 39.56 MiB | 2.01 MiB/s, done. Resolving deltas: 100% (114700/114700), done. Oliviers-iMac:~ odebroqueville$ which git /usr/bin/git Oliviers-iMac:~ odebroqueville$ git --version git version 1.7.12.4 (Apple Git-37) As you can see, nothing seems to have changed! Would you have any explanations? Thank you in advance for your help. Best regards, Olivier de Broqueville. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] status: really ignore config with --porcelain
On Fri, Jun 28, 2013 at 10:37:26AM -0700, Junio C Hamano wrote: The final patch ended up folding that -z default logic into the same function, so it probably is saner to remove UNSPECIFIED. Actually, the code needs to be able to differentiate between git status --no-short git status the former telling us explicitly to defeat status.short while the latter telling us to use whatever random value we happen to have in the configuration. Initializing the variable to UNSPECIFIED is one way to achieve that, as the former will explicitly set it to NONE while the latter will leave it UNSPECIFIED when the command line parsing finishes. Hmm. I would have thought --no-short would just set it to LONG. That is, we are no longer NONE at that point, as the user has told us something on the command line. So we are whatever --no-short is, which is LONG. But I guess that would wreck git status --no-short -z which currently defaults to porcelain. Which, to be honest, seems a little crazy to me, but I guess there is no reason to break it. I am just trying to prevent the future maintenance confusion where a reader of the code says Huh? What is the difference between NONE and UNSPECIFIED? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git stash: Avoid data loss when saving a stash
Petr Baudis pa...@ucw.cz writes:
diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..3cb9b05 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -258,6 +262,12 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+ if test -z $untracked$force -a -n $(git ls-files --killed | head -n
1); then
+ say $(gettext The following untracked files would NOT be
saved but need to be removed by stash save:)
I think ls-files --killed was not adjusted for the new world order
when submodules were introduced. With this change, you see t7402
break, even though git status would say
# Changes not staged for commit:
# (use git add file... to update what will be committed)
# (use git checkout -- file... to discard changes in working
# directory)
#
# modified: file
# modified: submodule (new commits)
The path submodule in HEAD and the index is already submodule, so
stash save that reverts to the original state will _not_ have to
kill it, but the new check triggers it.
Exactly the same breakage this patch introduces triggers in t7610,
too.
I think another patch to teach ls-files --killed what to do with
submodules is needed as a preliminary step before this patch.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to update git on Mac OS X Mountain Lion 10.8.4
Olivier de Broqueville olivier.debroquevi...@gmail.com writes: Hello, I've learnt that Xcode installs git by default on the Mac. My current version of git is 1.7.12.4 and it's located in /usr/bin/git. I wanted to update git to the latest stable version available: 1.8.3.1. I proceeded with the instructions on: http://git-scm.com/downloads and typed: git clone https://github.com/git/git.git (rather than using the .dmg file because I don't want to install a new version of git in addition to the existing one used by Xcode. Furthermore, I have no idea where the new version would end up being installed and I've read that users have had trouble doing this!) This rendered the following results: Oliviers-iMac:~ odebroqueville$ git clone https://github.com/git/git.git Cloning into 'git'... remote: Counting objects: 157697, done. remote: Compressing objects: 100% (53116/53116), done. remote: Total 157697 (delta 114700), reused 143715 (delta 102625) Receiving objects: 100% (157697/157697), 39.56 MiB | 2.01 MiB/s, done. Resolving deltas: 100% (114700/114700), done. Oliviers-iMac:~ odebroqueville$ which git /usr/bin/git Oliviers-iMac:~ odebroqueville$ git --version git version 1.7.12.4 (Apple Git-37) As you can see, nothing seems to have changed! Would you have any explanations? You seem to have successfully downloaded the source, but I do not see the steps you built and installed the downloaded source. I think that would be a sufficient explanation? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] status: really ignore config with --porcelain
Jeff King p...@peff.net writes: Hmm. I would have thought --no-short would just set it to LONG. That is, we are no longer NONE at that point, as the user has told us something on the command line. So we are whatever --no-short is, which is LONG. But I guess that would wreck git status --no-short -z which currently defaults to porcelain. Which, to be honest, seems a little crazy to me, but I guess there is no reason to break it. I am just trying to prevent the future maintenance confusion where a reader of the code says Huh? What is the difference between NONE and UNSPECIFIED? Yeah, I share your sentiment, but I did not think of a better way to do this without unnecessarily changing behaviour. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
On Thu, Jun 27, 2013 at 8:10 PM, Junio C Hamano gits...@pobox.com wrote: Now that I look at it more, I see that `git-mailinfo` was missed and there's a `git-apply` towards the bottom. So I'm not sure it's helping the consistency argument. Hmph, true. Having said that, I'd still prefer to see documentation changes in a patch separate from a do not call git-foo form patch. I'll send a new version of the patch next week to address this and also use quotes when replacing a hyphenated form in prose. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] Do not call built-in aliases from scripts
On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: --- a/git-merge-octopus.sh +++ b/git-merge-octopus.sh @@ -97,7 +97,7 @@ do if test $? -ne 0 then echo Simple merge did not work, trying automatic merge. - git-merge-index -o git-merge-one-file -a || + git merge-index -o git-merge-one-file -a || This is a problem. 'git-merge-one-file' cannot be split here AFAICT. Of course, we could teach merge-index to read *two* parameters instead of one when it encounters git as the merge-program. But that would be as hacky as the whole dashed-form business to begin with. I agree to all of your comments except this one: I did not split 'git-merge-one-file' here ... diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh index c9da747..343fe7b 100755 --- a/git-merge-resolve.sh +++ b/git-merge-resolve.sh @@ -45,7 +45,7 @@ then exit 0 else echo Simple merge failed, trying Automatic merge. - if git-merge-index -o git-merge-one-file -a + if git merge-index -o git-merge-one-file -a As above, with -octopus. Sorry, I can't follow you here. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] Do not call built-in aliases from scripts
Hi Sebastian, On Fri, 28 Jun 2013, Sebastian Schuberth wrote: On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: --- a/git-merge-octopus.sh +++ b/git-merge-octopus.sh @@ -97,7 +97,7 @@ do if test $? -ne 0 then echo Simple merge did not work, trying automatic merge. - git-merge-index -o git-merge-one-file -a || + git merge-index -o git-merge-one-file -a || This is a problem. 'git-merge-one-file' cannot be split here AFAICT. Of course, we could teach merge-index to read *two* parameters instead of one when it encounters git as the merge-program. But that would be as hacky as the whole dashed-form business to begin with. I agree to all of your comments except this one: I did not split 'git-merge-one-file' here ... I know. That is what I pointed out. git-merge-one-file was *not* un-dashed. And I explained the reason, too. But if we really want to solve the problem you described earlier, we also must not rely on git-merge-one-file to be present in libexec. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug on OS X...
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano gits...@pobox.com wrote:
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de wrote:
[snip]
I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1
nor with current git maint. Command run inside /tmp, which is on
a normal HFS+ volume (using the default settings, i.e. the FS is
case insensitive).
$ git --version
git version 1.8.3.1.42.ge2652c0
$ git clone --depth 1 git://nbd.name/packages.git
Cloning into 'packages'...
remote: Counting objects: 4711, done.
remote: Compressing objects: 100% (3998/3998), done.
remote: Total 4711 (delta 157), reused 3326 (delta 94)
Receiving objects: 100% (4711/4711), 3.85 MiB | 0 bytes/s, done.
Resolving deltas: 100% (157/157), done.
OK, so I finally tracked it down. Commit
6035d6aad8ca11954c0d7821f6f3e7c047039c8f fixes it:
commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Date: Sun May 26 08:16:15 2013 +0700
fetch-pack: prepare updated shallow file before fetching the pack
...
It looks like I was hitting the race condition. It's fixed on master,
so I assume it will be in 1.8.3.2.
Hmmmph, I do not think the cited change is about any race.
If it were that we spawn index-pack and write updated shallow
information at the same time, and depending on the timings,
index-pack may not read the updated one and fail, then it would have
been a race, but that is not the above change is about. If you
saw the issue on MacOS, you would have seen the same breakage, as
long as you started from the same repository status, on other
platforms, and reliably.
Hmmm, that's what the message seemed to say to me (that it was racy).
An early part of nd/clone-connectivity-shortcut topic contains the
said commit, and I do not mind merging it to the maintenance track,
but I suspect that there is something else going on on your OS X
box, if you saw differences between platforms.
Perhaps on your OS X box you have {transfer,fetch}.fsckobjects set
to true while on others it is set to false, or something?
Good suggestion! I have a gitconfig that I propagate to many of the
machines I use, but I had not updated the Linux machine I was testing
with. Turning on transfer.fsckObjects did indeed cause the issue to
appear on Linux as well.
-John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: Skip pack-*.keep files when cloning locally
Junio C Hamano gits...@pobox.com writes:
I am perfectly fine with a change that allows a local clone to skip
and not error out when such a keep marker cannot be copied, I do
not know if it is a good idea to unconditionally skip and not even
attempt to copy it.
That is, something like this, perhaps?
We could even create an empty file, as it is only the presense that
matters for .keep files, but I found it a bit too much special
casing to my taste.
builtin/clone.c| 9 -
t/t5701-clone-local.sh | 15 +++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 66bff57..4b7cd9b 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -356,8 +356,15 @@ static void copy_or_link_directory(struct strbuf *src,
struct strbuf *dest,
die_errno(_(failed to create link '%s'),
dest-buf);
option_no_hardlinks = 1;
}
- if (copy_file_with_time(dest-buf, src-buf, 0666))
+ if (copy_file_with_time(dest-buf, src-buf, 0666)) {
+ if (!strncmp(src-buf + src_baselen, /pack/pack-, 11)
+ !suffixcmp(src-buf, .keep))
+ goto skip;
+
die_errno(_(failed to copy file to '%s'), dest-buf);
+ skip:
+ warning(skipping %s, src-buf);
+ }
}
closedir(dir);
}
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index 7ff6e0e..bb5 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -134,4 +134,19 @@ test_expect_success 'cloning a local path with --no-local
does not hardlink' '
! repo_is_hardlinked force-nonlocal
'
+test_expect_success SANITY 'clone --no-hardlinks with unreadable .keep' '
+ mkdir strictsrc
+ (
+ cd strictsrc
+ git init
+ git commit --allow-empty -m initial
+ git repack -a -d
+ packname=$(echo .git/objects/pack/pack-*.idx)
+ keepname=${packname%.idx}.keep
+ $keepname
+ chmod a= $keepname
+ )
+ git clone --local --no-hardlinks strictsrc dst
+'
+
test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
Sebastian Schuberth sschube...@gmail.com writes: On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: --- a/git-merge-octopus.sh +++ b/git-merge-octopus.sh @@ -97,7 +97,7 @@ do if test $? -ne 0 then echo Simple merge did not work, trying automatic merge. - git-merge-index -o git-merge-one-file -a || + git merge-index -o git-merge-one-file -a || This is a problem. 'git-merge-one-file' cannot be split here AFAICT. Of course, we could teach merge-index to read *two* parameters instead of one when it encounters git as the merge-program. But that would be as hacky as the whole dashed-form business to begin with. I agree to all of your comments except this one: I did not split 'git-merge-one-file' here ... I do not think Dscho was pointing out any problem with your patch. He is merely pointing out that the goal of No git-foo anywhere on the filesystem is an unworkable one, as sometimes you need to give the path of a specific binary to commands. It is not limited to the -o option of git merge-index, but the above is a good example. And I agree with Dscho that this is not a problem with your patch per-se. echo Simple merge failed, trying Automatic merge. - if git-merge-index -o git-merge-one-file -a + if git merge-index -o git-merge-one-file -a As above, with -octopus. Sorry, I can't follow you here. The same issue above, that you have to have git-merge-one-file somewhere in your filesystem on $GIT_EXEC_PATH, he pointed out when he commented on the patch to git-merge-octopus.sh, can be seen here. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug on OS X...
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano gits...@pobox.com wrote:
An early part of nd/clone-connectivity-shortcut topic contains the
said commit, and I do not mind merging it to the maintenance track,
but I suspect that there is something else going on on your OS X
box, if you saw differences between platforms.
Perhaps on your OS X box you have {transfer,fetch}.fsckobjects set
to true while on others it is set to false, or something?
Good suggestion! Turning on transfer.fsckObjects did indeed
cause the issue to appear on Linux as well.
Good.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [submodule] Add depth to submodule update
Am 28.06.2013 20:44, schrieb Junio C Hamano: Heiko Voigt hvo...@hvoigt.net writes: On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote: ... Me too thinks adding --depth to update makes sense (and I don't think that this pretty generic name will become a problem later in case someone wants to add a maximum recursion depth, as grep already uses --max-depth for the same purpose). Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. I do not have a strong opinion either way, but as you suggest, it might be a good idea to call this new option --clone-depth to be more specific. No strong opinion here either, but I'm leaning towards --depth because on one hand we already have the --reference option which is passed on to the clone command (and not --clone-reference) and on the other hand I cannot see the need for yet another depth option (even my --max-depth example doesn't seem to be terribly useful). But I might be wrong on the last one ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to update git on Mac OS X Mountain Lion 10.8.4
Hi, Did you do a sudo make install as the last step? As a general rule of thumb on OS X, don't update or otherwise do anything to stuff installed by Apple. You have to install the newer version from the Git repository to a different directory, eg /usr/local or /usr/local/git . ./configure --prefix=/usr/local or ./configure --prefix=/usr/local/git make all sudo make install Then change your login profile, from the terminal, to reflect the new bin location, eg /usr/local/bin or /usr/local/git/bin . Hope this help. Mel Olivier de Broqueville wrote: Hello, I've learnt that Xcode installs git by default on the Mac. My current version of git is 1.7.12.4 and it's located in /usr/bin/git. I wanted to update git to the latest stable version available: 1.8.3.1. I proceeded with the instructions on: http://git-scm.com/downloads and typed: git clone https://github.com/git/git.git (rather than using the .dmg file because I don't want to install a new version of git in addition to the existing one used by Xcode. Furthermore, I have no idea where the new version would end up being installed and I've read that users have had trouble doing this!) This rendered the following results: Oliviers-iMac:~ odebroqueville$ git clone https://github.com/git/git.git Cloning into 'git'... remote: Counting objects: 157697, done. remote: Compressing objects: 100% (53116/53116), done. remote: Total 157697 (delta 114700), reused 143715 (delta 102625) Receiving objects: 100% (157697/157697), 39.56 MiB | 2.01 MiB/s, done. Resolving deltas: 100% (114700/114700), done. Oliviers-iMac:~ odebroqueville$ which git /usr/bin/git Oliviers-iMac:~ odebroqueville$ git --version git version 1.7.12.4 (Apple Git-37) As you can see, nothing seems to have changed! Would you have any explanations? Thank you in advance for your help. Best regards, Olivier de Broqueville. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git stash: Avoid data loss when saving a stash
Junio C Hamano gits...@pobox.com writes:
Petr Baudis pa...@ucw.cz writes:
diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..3cb9b05 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -258,6 +262,12 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+if test -z $untracked$force -a -n $(git ls-files --killed | head -n
1); then
+say $(gettext The following untracked files would NOT be
saved but need to be removed by stash save:)
I think ls-files --killed was not adjusted for the new world order
when submodules were introduced. With this change, you see t7402
break,...
Exactly the same breakage this patch introduces triggers in t7610,
too.
I think another patch to teach ls-files --killed what to do with
submodules is needed as a preliminary step before this patch.
Which may be just the matter of doing this.
-- 8 --
Subject: treat_directory(): do not declare submodules in index to be untracked
When the working tree walker encounters a directory, it asks this
function if it should descend into it, show it as an untracked
directory, or do something else. When the directory is the top of
the submodule working tree, we used to say That is an untracked
directory, which was quite bogus. It is an entity that is tracked
in the index of the repository we are looking at, and that is not to
be descended into it. Return path_none.
The existing case that path_untracked is returned for a newly
discovered submodule that is not tracked in the index (this only
happens when DIR_NO_GITLINKS option is not used) is unchanged and
returns path_untracked, but that is exactly because the submodule is
not tracked in the index.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index 897c874..b99c40e 100644
--- a/dir.c
+++ b/dir.c
@@ -1038,7 +1038,7 @@ static enum path_treatment treat_directory(struct
dir_struct *dir,
case index_gitdir:
if (dir-flags DIR_SHOW_OTHER_DIRECTORIES)
return path_none;
- return path_untracked;
+ return path_none;
case index_nonexistent:
if (dir-flags DIR_SHOW_OTHER_DIRECTORIES)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [submodule] Add --depth to submodule update/add
Fredrik Gustafsson iv...@iveqy.com writes: diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index a4ffea0..b2d0f0e 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -31,8 +31,9 @@ test_expect_success 'setup a submodule tree' ' git clone super rebasing git clone super merging git clone super none + pwd=$(pwd) Broken -chain (will locally amend later but not today). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [submodule] Add --depth to submodule update/add
Apparently due to a newly added test at the end of t7400 this patch doesn't
apply cleanly to neither pu, next nor master for me. But it addresses all
issues raised in the first round.
Am 28.06.2013 15:22, schrieb Fredrik Gustafsson:
When a submodule is clone, clone it width the --depth flag. This is useful
Maybe rephrase this as:
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful e.g.
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Having to change existing tests is looking a bit fishy to me. Maybe just
sed the URLs into the file:// form requested by clone --depth right after
cloning the superproject in t7406?
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
Documentation/git-submodule.txt | 13 +++--
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 18 ++
t/t7406-submodule-update.sh | 28
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..b17001a 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--depth depth] [--] repository
[path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit)
n]
[commit] [--] [path...]
@@ -328,6 +328,15 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ A shallow repository has a number of limitations (you cannot clone
+ or fetch from it, nor push from nor into it), but is adequate if
+ you are only interested in the recent history of a large project
+ with a long history.
Nice description, only a linkgit:git-clone[1] would be nice here.
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..c99bc7c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -234,7 +236,7 @@ module_clone()
(
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
- --separate-git-dir $gitdir $url $sm_path
+ --separate-git-dir $gitdir $depth $url
$sm_path
Maybe also quote $depth here (even though that shouldn't be necessary
because it never should contain spaces, I'd prefer being consistent here).
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
[PATCH --clone-depth version] [submodule] Add --depth to submodule update/add
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
I neither have an opinion about what word to use. --depth is more
consistent and easier to code. But also eaiser to be confused about.
Here is a --clone-depth version of the patch. Nothing else is changed.
Please take the one thats most suited.
Documentation/git-submodule.txt | 13 +++--
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 18 ++
t/t7406-submodule-update.sh | 28
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..41b9610 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--clone-depth depth] [--]
repository [path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--clone-depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,15 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--clone-depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ A shallow repository has a number of limitations (you cannot clone
+ or fetch from it, nor push from nor into it), but is adequate if
+ you are only interested in the recent history of a large project
+ with a long history.
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..0a949d1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+clone_depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ clone_depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -234,7 +236,7 @@ module_clone()
(
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
- --separate-git-dir $gitdir $url $sm_path
+ --separate-git-dir $gitdir $clone_depth
$url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --clone-depth)
+ case $2 in '') usage ;; esac
+ clone_depth=--depth=$2
+ shift
+ ;;
+ --clone-depth=*)
+ clone_depth=$(echo $1 | sed -e 's/^--clone/-/')
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$clone_depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout)
update=checkout
;;
+ --clone-depth)
+
[ANNOUNCE] Git v1.8.3.2
The latest maintenance release Git v1.8.3.2 is now available at the
usual places. It contains fixes that have already been applied to
the 'master' branch for 1.8.4.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4a6585dd81a542e7803e5f54a5c85b1c1a5869aa git-1.8.3.2.tar.gz
adffaa379e1994fc6d6cb6491aed680ad6bb37ad git-htmldocs-1.8.3.2.tar.gz
5ce8c00fe9e2755c67d29b2f2135fc8c4202fc1f git-manpages-1.8.3.2.tar.gz
The following public repositories all have a copy of the v1.8.3.2
tag and the maint branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.
Git v1.8.3.2 Release Notes
==
Fixes since v1.8.3.1
* Cloning with git clone --depth N while fetch.fsckobjects (or
transfer.fsckobjects) is set to true did not tell the cut-off
points of the shallow history to the process that validates the
objects and the history received, causing the validation to fail.
* git checkout foo DWIMs the intended upstream and turns it into
git checkout -t -b foo remotes/origin/foo. This codepath has been
updated to correctly take existing remote definitions into account.
* git fetch into a shallow repository from a repository that does
not know about the shallow boundary commits (e.g. a different fork
from the repository the current shallow repository was cloned from)
did not work correctly.
* git subtree (in contrib/) had one codepath with loose error
checks to lose data at the remote side.
* git log --ancestry-path A...B did not work as expected, as it did
not pay attention to the fact that the merge base between A and B
was the bottom of the range being specified.
* git diff -c -p was not showing a deleted line from a hunk when
another hunk immediately begins where the earlier one ends.
* git merge @{-1}~22 was rewritten to git merge frotz@{1}~22
incorrectly when your previous branch was frotz (it should be
rewritten to git merge frotz~22 instead).
* git commit --allow-empty-message -m '' should not start an
editor.
* git push --[no-]verify was not documented.
* An entry for file:// scheme in the enumeration of URL types Git
can take in the HTML documentation was made into a clickable link
by mistake.
* zsh prompt script that borrowed from bash prompt script did not
work due to slight differences in array variable notation between
these two shells.
* The bash prompt code (in contrib/) displayed the name of the branch
being rebased when rebase -i/-m/-p modes are in use, but not the
plain vanilla rebase.
* git push $there HEAD:branch did not resolve HEAD early enough, so
it was easy to flip it around while push is still going on and push
out a branch that the user did not originally intended when the
command was started.
* difftool --dir-diff did not copy back changes made by the
end-user in the diff tool backend to the working tree in some
cases.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
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 that I think is important is that the bring my branch up-to-date operation should force the user to choose what to do if the branch does not fast-forward to its upstream. If that was spelled git update then having git pull perform a merge would be fine, but we spell this operation as git pull so the change needs to happen there. I am not sure I quite get what you want to say with git update, and I am not sure if I necessarily want to know---I do not think we would want to add yet another command that DWIMs for certain _I_, that may not match newbie expectations. 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 this [1] did talk about only git pull with no arguments. If you want to limit the scope to only git pull (without any command line argument), I actually do not have strong preference for or against it either way. Perhaps a follow-up patch to be squashed? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [submodule] Add depth to submodule update
Jens Lehmann jens.lehm...@web.de writes: Am 28.06.2013 20:44, schrieb Junio C Hamano: Heiko Voigt hvo...@hvoigt.net writes: ... Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. I do not have a strong opinion either way, but as you suggest, it might be a good idea to call this new option --clone-depth to be more specific. No strong opinion here either, but I'm leaning towards --depth because on one hand we already have the --reference option which is passed on to the clone command (and not --clone-reference)... OK, then --depth it is. The points in your review on the last version with --depth (which I picked up and parked on 'pu') still need to be addressed, I think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [submodule] Add depth to submodule update
On Fri, Jun 28, 2013 at 03:51:41PM -0700, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: Am 28.06.2013 20:44, schrieb Junio C Hamano: Heiko Voigt hvo...@hvoigt.net writes: ... Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. I do not have a strong opinion either way, but as you suggest, it might be a good idea to call this new option --clone-depth to be more specific. No strong opinion here either, but I'm leaning towards --depth because on one hand we already have the --reference option which is passed on to the clone command (and not --clone-reference)... OK, then --depth it is. The points in your review on the last version with --depth (which I picked up and parked on 'pu') still need to be addressed, I think? I agree, I'm on it -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to update git on Mac OS X Mountain Lion 10.8.4
On Fri, Jun 28, 2013 at 2:06 PM, Melton Low (devl) softw.d...@gmail.com wrote: Hi, Did you do a sudo make install as the last step? As a general rule of thumb on OS X, don't update or otherwise do anything to stuff installed by Apple. You have to install the newer version from the Git repository to a different directory, eg /usr/local or /usr/local/git . It's never any fun doing this stuff yourself. If you're new to this stuff then I would highly recommend using homebrew: http://mxcl.github.io/homebrew/ Once you've installed it you can say, brew install git. ./configure --prefix=/usr/local or ./configure --prefix=/usr/local/git make all sudo make install Then change your login profile, from the terminal, to reflect the new bin location, eg /usr/local/bin or /usr/local/git/bin . Hope this help. Mel Olivier de Broqueville wrote: Hello, I've learnt that Xcode installs git by default on the Mac. My current version of git is 1.7.12.4 and it's located in /usr/bin/git. I wanted to update git to the latest stable version available: 1.8.3.1. I proceeded with the instructions on: http://git-scm.com/downloads and typed: git clone https://github.com/git/git.git (rather than using the .dmg file because I don't want to install a new version of git in addition to the existing one used by Xcode. Furthermore, I have no idea where the new version would end up being installed and I've read that users have had trouble doing this!) This rendered the following results: Oliviers-iMac:~ odebroqueville$ git clone https://github.com/git/git.git Cloning into 'git'... remote: Counting objects: 157697, done. remote: Compressing objects: 100% (53116/53116), done. remote: Total 157697 (delta 114700), reused 143715 (delta 102625) Receiving objects: 100% (157697/157697), 39.56 MiB | 2.01 MiB/s, done. Resolving deltas: 100% (114700/114700), done. Oliviers-iMac:~ odebroqueville$ which git /usr/bin/git Oliviers-iMac:~ odebroqueville$ git --version git version 1.7.12.4 (Apple Git-37) As you can see, nothing seems to have changed! Would you have any explanations? Thank you in advance for your help. Best regards, Olivier de Broqueville. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
