Re: On using receive.denyNonFastForwards and advice.pushNonFastForward
From: Christopher Tiwald To: Hilco Wijbenga Cc: Git Users Bcc: Subject: Re: On using receive.denyNonFastForwards and advice.pushNonFastForward Reply-To: In-Reply-To: On Sun, Jul 08, 2012 at 02:26:50PM -0700, Hilco Wijbenga wrote: > I was wondering how hard it would be to make "git push" more adamant > about not pushing non-ff updates. So I wanted to see the effects of > receive.denyNonFastForwards and advice.pushNonFastForward. (By the > way, why is one plural and the other singular? That doesn't seem > consistent?) 'advice.pushNonFastForward' doesn't control whether or not the remote accepts non-fast-forward updates. Rather, it controls whether or not advice displays when 'git push' errors because the user attempted a non-fast-forward update. As of 1.7.11 (f25950f3), it was supplemented with 'advice.pushNonFFCurrent', 'advice.pushNonFFDefault', and 'pushNonFFMatching'. Setting the original 'advice.pushNonFastForward' config option to 'false' will disable all three of these situational hints. None of them will affect the actual operation of 'git push'. As for this series of commands, none of these are non-fast-forward updates (i.e. a situation where a pushed branch tip is behind its remote counterpart): > HERE=$(pwd) && > git init --bare remote-repo && > cd remote-repo/ && > git config --add receive.denyNonFastForwards true && > cd .. && > git clone file://$HERE/remote-repo local-repo && > cd local-repo/ && > git config --add advice.pushNonFastForward true && > echo "1" > one.txt && > git add -A . && git commit -m 1 && git push origin master && This is the inital push to the remote: $ git log --graph --oneline * 32bbda2 1 $ git diff master origin/master ;# noop > git checkout -b next && > echo "a" > two.txt && > git add -A . && git commit -m 2 && > git checkout master && > echo "2" > one.txt && > git add -A . && git commit -m 3 && git push origin master && This is a standard fast-forward update to the remote: $ git log --graph --oneline * 0176f87 3 * 32bbda2 1 $ git diff master origin/master ;# noop > git merge next && > git push This is also a standard fast-forward update to the remote: $ git log --graph --oneline * b881618 Merge branch 'next' |\ | * 843a285 2 * | 0176f87 3 |/ * 32bbda2 1 $ git diff master origin/master ;# noop If you want to see a true non-fast-forward error from this point, try this: git reset --hard HEAD~1 && echo "non-ff" > one.txt && git add . && git commit -m 4 && git push origin master You should get something like this (the advice will change based on your version of git): [master cf28ce8] 4 1 file changed, 1 insertion(+), 1 deletion(-) To /tmp/remote-repo ! [rejected]master -> master (non-fast-forward) error: failed to push some refs to '/tmp/remote-repo' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. The "hint" lines at the end are configured by the 'advice' options described above. -- Christopher Tiwald -- 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 1/2] rm: don't fail when removing populated submodules
Junio C Hamano writes: >> Nope. Only the "--recursive" option to the git submodule script >> works like that (and almost everyone seems to use that option by >> default anyway). But for all commands that understand the >> "--recurse-submodule" option (currently these are clone, fetch, >> merge, pull and push) that means "include submodules in what you >> do and don't stop at the first level but recurse all the way down". >> Without this option they won't even touch the first level of >> submodules. > > OK, but what does "rm --no-recurse-submodules path" could possibly > mean in that case? If you remove "path" by definition anything > underneath "path" cannot be remain, so in the context of "rm", once > you decide to remove submodule at "path", not recursing is an option. Yikes, I hate myself after making silly typoes. Of course the above needs s/cannot .. remain/cannot remain/; and more importantly, not recursing is _not_ an option once you decide to remove 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/RFC v2 1/2] Strip namelen out of ce_flags into a ce_namelen field
Thomas Gummerer writes: > Strip the name length from the ce_flags field and move it > into its own ce_namelen field in struct cache_entry. This > will both give us a tiny bit of a performance enhancement > when working with long pathnames and is part of the > refactoring for the index-v5 file format. Careful. I do not mind moving name length out of low bits of ce_flags in principle, but if you claim this helps performance, you need to substanticate it. FYI, the current layout was designed for performance to take advantage of the fact that most paths are short (among 39k paths in the kernel tree, the longest seems to be 80 bytes long) and using strlen() is rarely needed (the code even skips the first 4k bytes when it has to use strlen()). It of course also shaves a few hundred kilobytes of memory necessary to hold the length separately in cache entries). > Index-v5 won't store the name length in the on disk index > file, so storing it in the flags wouldn't make sense for > index-v5. I think this split could make sense even without a new on-disk format. On the other hand, even if the result of this patch were to prove undesirable, it is still possible for the read_index code for v5 format to convert from its ondisk_cache_entry (which does not have length anywhere) to the canonical cache_entry struct (which stores length for common short path names in lower bits of flags field), and write_index code could do the reverse. Because of the above two points, what index-v5 has or does not have is mostly immaterial when judging this patch, unless such a conversion has very high cost. > It also enhances readability, by making it more clear what > is a flag, and where the length is stored and make it clear > which functions use stages in comparisions and which only > use the length. That can be true, but if we were to go this route, the patch should be able to make CE_NAMEMASK totally private to the codepath that reads and writes v2/v3/v4 format and nowhere else. The ce_flags field in "struct cache_entry" that is visible to everybody from cache.h shouldn't need the padding of 12-low bits that is not used (I think CE_STAGESHIFT could even become 0, even though I do not see an immediate need for such a change). Shouldn't "struct ondisk_cache_entry" in read-cache.c the only place that need to know about this old layout, no? > diff --git a/builtin/apply.c b/builtin/apply.c > index dda9ea0..10f83fc 100644 > --- a/builtin/apply.c > +++ b/builtin/apply.c > @@ -3502,7 +3502,8 @@ static void add_index_file(const char *path, unsigned > mode, void *buf, unsigned > ce = xcalloc(1, ce_size); > memcpy(ce->name, path, namelen); > ce->ce_mode = create_ce_mode(mode); > - ce->ce_flags = namelen; I think this should have been create_ce_flags(namelen, 0) originally, so I would prefer the new code to spell it as create_ce_flags(0). > + ce->ce_flags = 0; > + ce->ce_namelen = namelen; > diff --git a/builtin/blame.c b/builtin/blame.c > index 24d3dd5..e181368 100644 > --- a/builtin/blame.c > +++ b/builtin/blame.c > @@ -2153,7 +2153,8 @@ static struct commit *fake_working_tree_commit(struct > diff_options *opt, > ce = xcalloc(1, size); > hashcpy(ce->sha1, origin->blob_sha1); > memcpy(ce->name, path, len); > - ce->ce_flags = create_ce_flags(len, 0); > + ce->ce_flags = 0; Likewise. I think it is more in line with your "making it more clear" if you said create_ce_flags(0) here. I won't repeat this for the remainder of the patch where a bare number is stored without using create_ce_flags(stage). > +#define ce_namelen(ce) ((ce)->ce_namelen) Good. > @@ -448,6 +440,7 @@ extern int discard_index(struct index_state *); > extern int unmerged_index(const struct index_state *); > extern int verify_path(const char *path); > extern struct cache_entry *index_name_exists(struct index_state *istate, > const char *name, int namelen, int igncase); > +extern int index_name_stage_pos(const struct index_state *, const char > *name, int stage, int namelen); The name string and its length form a pair; keep them next to each other (i.e. swap stage and namelen). > @@ -857,6 +850,7 @@ extern int validate_headref(const char *ref); > extern int base_name_compare(const char *name1, int len1, int mode1, const > char *name2, int len2, int mode2); > extern int df_name_compare(const char *name1, int len1, int mode1, const > char *name2, int len2, int mode2); > extern int cache_name_compare(const char *name1, int len1, const char > *name2, int len2); > +extern int cache_name_stage_compare(const char *name1, int stage1, int len1, > const char *name2, int stage2, int len2); Likewise. > diff --git a/read-cache.c b/read-cache.c > index ef355cc..ea75c89 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -395,10 +395,8 @@ int df_name_compare(const char *name1, int len1, int > mode1, > return c1 - c2; > } > > -int cache_name_compare(const char *name1, int flags1, const char *
Re: [PATCH/RFC v2 2/2] Replace strlen() with ce_namelen()
Thomas Gummerer writes:
> Replace strlen(ce->name) with ce_namelen() in a couple
> of places which gives us some additional bits of
> performance.
>
> Signed-off-by: Thomas Gummerer
Very sensible, with or without the previous patch.
I am kind of surprised that we are very good and have only these
three places that had these unnecessary pessimization.
> ---
> read-cache.c |4 ++--
> unpack-trees.c |2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index ea75c89..a77877a 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1124,7 +1124,7 @@ int refresh_index(struct index_state *istate, unsigned
> int flags, const char **p
> continue;
>
> if (pathspec &&
> - !match_pathspec(pathspec, ce->name, strlen(ce->name), 0,
> seen))
> + !match_pathspec(pathspec, ce->name, ce_namelen(ce), 0,
> seen))
> filtered = 1;
>
> if (ce_stage(ce)) {
> @@ -1852,7 +1852,7 @@ int read_index_unmerged(struct index_state *istate)
> if (!ce_stage(ce))
> continue;
> unmerged = 1;
> - len = strlen(ce->name);
> + len = ce_namelen(ce);
> size = cache_entry_size(len);
> new_ce = xcalloc(1, size);
> memcpy(new_ce->name, ce->name, len);
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 9981dd3..abd0988 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1289,7 +1289,7 @@ static int verify_clean_subdirectory(struct cache_entry
> *ce,
>* First let's make sure we do not have a local modification
>* in that directory.
>*/
> - namelen = strlen(ce->name);
> + namelen = ce_namelen(ce);
> for (i = locate_in_src_index(ce, o);
>i < o->src_index->cache_nr;
>i++) {
--
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 1/2] test: git-stash conflict sets up rerere
Phil Hord writes: > Add a failing test to confirm a conflicted stash apply invokes > rerere to record the conflicts and resolve the the files it can. OK. > In this failing state, mergetool may be confused by a left-over > state from previous rerere activity. It is unclear to me what relevance this has to this patch. Does it have this sequence: "previous rerere activity" (whatever that is) test_must_fail git stash apply && git mergetool and demonstrate that "git mergetool" fails because there is a wrong rerere state in the repository after "git stash apply" returns? Or perhaps you are relying on the state that is left by the previous test piece? > Also, the next test expected us to finish up with a reset, which > is impossible to do if we fail (as we must) and it's an > unreasonable expectation anyway. Begin the next test with a reset > of his own instead. Yes, it is always a good discipline to start a new test piece from a known state. > @@ -193,7 +203,37 @@ test_expect_success 'mergetool skips resolved paths when > rerere is active' ' > git reset --hard > ' > > +test_expect_failure 'conflicted stash sets up rerere' ' > +git config rerere.enabled true && > +git checkout stash1 && > +echo "Conflicting stash content" >file11 && > +git stash && > + > +git checkout --detach stash2 && > +test_must_fail git stash apply && > + > +test -e .git/MERGE_RR && > +test -n "$(git ls-files -u)" && > +conflicts="$(git rerere remaining)" && Checking that the index is conflicted with "ls-files -u" and asking the public API "git rerere remaining" to see what paths rerere thinks it did not touch, like you do in the second and third lines, are very sensible, but it is probably not a good idea for this test to check implementation details with "test -f .git/MERGE_RR". > +test "$conflicts" = "file11" && > +output="$(git mergetool --no-prompt)" && > +test "$output" != "No files need merging" && > + > +git commit -am "save the stash resolution" && > + > +git reset --hard stash2 && > +test_must_fail git stash apply && > + > +test -e .git/MERGE_RR && > +test -n "$(git ls-files -u)" && > +conflicts="$(git rerere remaining)" && Likewise. > +test -z "$conflicts" && > +output="$(git mergetool --no-prompt)" && > +test "$output" = "No files need merging" > +' > + > test_expect_success 'mergetool takes partial path' ' > +git reset --hard > git config rerere.enabled false && > git checkout -b test12 branch1 && > git submodule update -N && -- 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-remote-mediawiki: update comments to reflect credential support
thanks; 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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Jens Lehmann writes: >>> What you describe here is exactly how I think "git submodule rm" and >>> "git rm --recurse-submodules" should behave. >> >> If you have a directory A with a file B in it (i.e. A/B), "git rm A" >> is refused and you have to say "git rm -r A". So I can see why the >> above description of the mine is wrong with respect to "-r" option >> (all cases should fail if you did not give "-r" option). > > I think that depends on how you see submodules in the context of > the superproject. I am OK with "git rm path" removing the submodule working tree and the index entry for path without -r (of course "git rm dir" would not remove submodule "dir/path" in a plain directory "dir" and needs to be spelled "git rm -r dir" or "git rm dir/path" but that is the same if "path" were a regular file and a submodule is not special); thinking about it again, I think it makes more sense, because a submodule is just one single path entity in the context of the superproject. >> But I do not think "git rm" needs "--recurse-submodules". Wasn't >> "--recurse-submodules" the option to control, when you tell Git to >> do something to submodule "A", what should happen to submodules >> contained in the submodule "A" (e.g. "A/B" that appears at path "B" >> that itself is a separate project bound as a submodule to "A")? > > Nope. Only the "--recursive" option to the git submodule script > works like that (and almost everyone seems to use that option by > default anyway). But for all commands that understand the > "--recurse-submodule" option (currently these are clone, fetch, > merge, pull and push) that means "include submodules in what you > do and don't stop at the first level but recurse all the way down". > Without this option they won't even touch the first level of > submodules. OK, but what does "rm --no-recurse-submodules path" could possibly mean in that case? If you remove "path" by definition anything underneath "path" cannot be remain, so in the context of "rm", once you decide to remove submodule at "path", not recursing is an option. So I still think "--recurse-submodules" does not make any sense to the "rm" command. I would understand a "Do not attempt to remove submodules and ignore their existence altogether" option, even though I do not think it is useful. > All other core commands happily change the index without updating > the submodule's work tree. What are "all other core commands"? "fetch" by definition does not touch working tree inside or outside working tree. "add" is about recording the state from the working tree to the index, and following the earlier point you raised (I unfortunately culled from the quote), as the rest of core Git considers a submodule a single path entity in the context of the superproject, "the state from the working tree" for the submodule is where its HEAD points at, so it is correct not to look at the working tree. Without going outside the context of "rm", I think the current behaviour of "git rm path" for submodule is merely punting---erroring out against a request for an unimplemented feature. If you ask an unpopulated submodule to be removed, we could simply rmdir() it and remove the entry from the index, but that is far insufficient for handling a submodule repository that is already "init"ed. And we did not want to plug the "check if removal will lose any state from the submodule repository" logic because the information is no use for us for a long time until we added the "gitfile" support to allow us to relocate path/.git for the submodule safely away when we remove the working tree of it. But now we do have gitfile, so we could remove submodule working tree. I think not erroring out and removing only the index entry is a irresponsible thing to do. It would mean that we pretend as if a feature that was earlier unimplemented (hence errored out) is now supported, but it does not do what the user asked us to do, no? I do not know what other commands you have in mind, but some of them may be similar "recursing down and performing an operation that potentially can fail is too complex, and we are not sure if we have enough sequencing infrastructure to guide the user to sort out the mess in the half-result, so let's punt and not to that part and have the user sort out" half-features, and if that is the case, I do not think it is prudent to model "rm", which is something that we now could implement properly, with the necessary infrastructure already in place, after them. -- 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] Restore umasks influence on the permissions of work tree created by clone
Alex Riesen writes:
> The original (shell coded) version of the git-clone just used mkdir(1)
> to create the working directories. The builtin changed the mode argument
> to mkdir(2) to 0755, which was a bit unfortunate, as there are use
A much more important reason why this is a good change (I think you
could even say this is a bugfix) is because directories and files in
the working tree are created with entry.c::create_directories() and
entry.c::create_file(), and they do honour umask settings, and the
top-level of the working tree should be handled the same way, no?
> cases where umask-controlled creation is preferred and in any case
> it is a well-known behaviour for new directory/file creation.
> ---
Sign-off?
>
> On Fri, 6 Jul 2012, Daniel Barkalow wrote:
>> On Fri, 6 Jul 2012, Alex Riesen wrote:
>>> when git-clone was built in, its treatment of umask has changed: the shell
>>> version respected umask for newly created directories by using plain
>>> mkdir(1),
>>> and the builtin version just uses mkdir(work_tree, 0755).
>>>
>>> Is it intentional?
>>
>> I have the vague feeling that it was intentional, but it's entirely
>> plausible that I just overlooked that mkdir(2) applies umask and went for
>> the mode that you normally want. I don't think there's any particular need
>> for this operation to be more restrictive than umask.
>
> I didn't look hard enough, but still, I found not much of complaining either
> way (frankly - none, but as I said, I didn'l look hard): none before - for
> being too permissive, the only one in original post after building the thing
> in - for being too restrictive.
>
> Maybe we should reconsider and go back to the old permission handling?
>
> builtin/clone.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index d3b7fdc..e314b0b 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -708,7 +708,7 @@ int cmd_clone(int argc, const char **argv, const char
> *prefix)
> if (safe_create_leading_directories_const(work_tree) < 0)
> die_errno(_("could not create leading directories of
> '%s'"),
> work_tree);
> - if (!dest_exists && mkdir(work_tree, 0755))
> + if (!dest_exists && mkdir(work_tree, 0777))
> die_errno(_("could not create work tree dir '%s'."),
> work_tree);
> set_git_work_tree(work_tree);
--
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
Please pull git-po master branch with l10n updates for several languages
Hi Junio, The following changes since commit 726016725d45894c061e8d187385327f82803c9f: Sync with i18n-po updates in maint (2012-07-02 15:37:54 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 6792b93b1965561e85be3733bb3ab00b2e598119: l10n: zh_CN.po: translate 29 new messages (2012-07-06 09:11:15 +0800) Jiang Xin (2): l10n: Update git.pot (29 new messages) l10n: zh_CN.po: translate 29 new messages Peter Krefting (1): Update Swedish translation (1095t0f0u) Ralf Thielow (1): l10n: de.po: translate 29 new messages Tran Ngoc Quan (1): l10n: Update translation for Vietnamese po/de.po| 569 ++-- po/git.pot | 537 - po/sv.po| 545 +- po/vi.po| 600 po/zh_CN.po | 566 ++-- 5 files changed, 1727 insertions(+), 1090 deletions(-) -- Jiang Xin -- 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
On using receive.denyNonFastForwards and advice.pushNonFastForward
Hi all, I was wondering how hard it would be to make "git push" more adamant about not pushing non-ff updates. So I wanted to see the effects of receive.denyNonFastForwards and advice.pushNonFastForward. (By the way, why is one plural and the other singular? That doesn't seem consistent?) HERE=$(pwd) && git init --bare remote-repo && cd remote-repo/ && git config --add receive.denyNonFastForwards true && cd .. && git clone file://$HERE/remote-repo local-repo && cd local-repo/ && git config --add advice.pushNonFastForward true && echo "1" > one.txt && git add -A . && git commit -m 1 && git push origin master && git checkout -b next && echo "a" > two.txt && git add -A . && git commit -m 2 && git checkout master && echo "2" > one.txt && git add -A . && git commit -m 3 && git push origin master && git merge next && git push To my surprise there was neither warning nor error. Does this last push really qualify as a FF update? Apparently, linear history and FF-only updates are not the same thing? Cheers, Hilco -- 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: Problems pushing???
Am 08.07.2012 17:43, schrieb pbGit: Just tried starting again on my local machine because when I tried pushing, git said that it local was also set to bare init. When I looked this was the case. Silly me. So I deleted on my local and added a single file and when I try pushing this I get the following: ! [rejected]master -> master (non-fast-forward) error: failed to push some refs to 'paul@localhost:/Users/paul/' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. When I try and pull I then get the following: fatal: No remote repository specified. Please, specify either a URL or a remote name from which new revisions should be fetched. I then addded my repo with the following command, but this is the wrong syntax!!! git pull --repo= What the hell am I doing wrong??? This is the moment where you have to begin reading man pages, i.e. "git fetch", "git help pull", "git help remote" "git help push" (read the examples as they show typical use cases) or preferably read about it in books like Pro Git (git-scm.com/book/) or tutorials. For example the --repo parameter in "git push --repo=" doesn't exactly do what you think it does. It only sets the default remote repo from "origin" to . Normally you would just use "git push ". And the equivalent pull command would be "git pull ". Naturally you can configure that git pull or git push will just do what you want, but for that you need to know what a refspec is and how to use "git remote". Generally git pull and git push are not complementary. Neither in effect nor in parameters they take. For example assume you have just cloned a remote repository. This will add configuration that connects both repositories and adds a default remote repo named origin and adds default refspecs "git pull" without parameters will then fetch all remote branches into correpondingly named local remote tracking branches (under .git/refs/remotes/, do a git branch -a to list them too), but then only merge one of them with the branch you are in at the moment. But "git push" will push *all* your local branches into branches of the same name on the remote repository. Another difference: If you pull, the merge might fail because of merge conflicts and you have to manually merge conflicting files. If you push, this manual merge is not possible so usually only trivial merges called fast-forward-merges are allowed. That is what happened on your push Something like "git remote add -m master origin " does the same configuration as a "git clone" would do and would allow you to just use "git pull" without parameters. -- 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-remote-mediawiki: update comments to reflect credential support
Signed-off-by: Matthieu Moy
---
Junio, can you add this to mm/credential-plumbing in pu, or better,
squash it into the last patch of the serie (i.e. a7271ad1dccaf1,
git-remote-mediawiki: add credential support)?
Thanks,
contrib/mw-to-git/git-remote-mediawiki | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki
b/contrib/mw-to-git/git-remote-mediawiki
index 539718e..c07b4f0 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -26,9 +26,6 @@
# - Git renames could be turned into MediaWiki renames (see TODO
# below)
#
-# - login/password support requires the user to write the password
-# cleartext in a file (see TODO below).
-#
# - No way to import "one page, and all pages included in it"
#
# - Multiple remote MediaWikis have not been very well tested.
@@ -74,9 +71,7 @@ my @tracked_categories = split(/[ \n]/, run_git("config
--get-all remote.". $rem
chomp(@tracked_categories);
my $wiki_login = run_git("config --get remote.". $remotename .".mwLogin");
-# TODO: ideally, this should be able to read from keyboard, but we're
-# inside a remote helper, so our stdin is connect to git, not to a
-# terminal.
+# Note: mwPassword is discourraged. Use the credential system instead.
my $wiki_passwd = run_git("config --get remote.". $remotename .".mwPassword");
my $wiki_domain = run_git("config --get remote.". $remotename .".mwDomain");
chomp($wiki_login);
--
1.7.11.1.147.g47a574d
--
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: Problems pushing???
Just tried starting again on my local machine because when I tried pushing, git said that it local was also set to bare init. When I looked this was the case. Silly me. So I deleted on my local and added a single file and when I try pushing this I get the following: ! [rejected]master -> master (non-fast-forward) error: failed to push some refs to 'paul@localhost:/Users/paul/' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. When I try and pull I then get the following: fatal: No remote repository specified. Please, specify either a URL or a remote name from which new revisions should be fetched. I then addded my repo with the following command, but this is the wrong syntax!!! git pull --repo= What the hell am I doing wrong??? -- View this message in context: http://git.661346.n2.nabble.com/Problems-pushing-tp7562695p7562707.html Sent from the git mailing list archive at Nabble.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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Am 08.07.2012 09:32, schrieb Junio C Hamano: > Jens Lehmann writes: > >>> One possible sane behaviour of "git rm $path" might be: >>> >>> - If --force is given, remove it from the index and from the >>>working tree (i.e. "rm -rf $path"), but use the "gitfile" >>>facility to save $path/.git away to $GIT_DIR/modules/$name; error >>>out if the submodule directory $path cannot be removed like this. >>>We would probably want to remove "submodule..*" entries in >>>.gitmodules for for which "submodule..path" matches >>>the $path. >>> >>> - If --cached is given, remove it from the index if the version in >>>the index match either HEAD or the $path/.git/HEAD, without >>>touching the working tree. This is consistent with what happens >>>to a regular file. >>> >>> - If neither --force nor --cached is given, run an equivalent of >>>(cd $path && git status), and also check if $path/.git/HEAD >>>matches the index version. Error out if the submodule directory >>>is dirty (again I am not sure about this part). If the submodule >>>directory is clean, do the same as the case with --force. >> >> What you describe here is exactly how I think "git submodule rm" and >> "git rm --recurse-submodules" should behave. > > If you have a directory A with a file B in it (i.e. A/B), "git rm A" > is refused and you have to say "git rm -r A". So I can see why the > above description of the mine is wrong with respect to "-r" option > (all cases should fail if you did not give "-r" option). I think that depends on how you see submodules in the context of the superproject. If you see the submodule entry as an abstraction describing the whole work tree below it with a single SHA1, "-r" isn't necessary (but won't harm either). Only if you think that the individual files of a submodule make sense in the superproject's context, you'd need "-r". I think we always use the first approach: you either get all files which are in a submodule's work tree, or none. So I don't think we should require "-r" here, as a submodule is a single object of the superproject. And for the same reason "git rm A/B" issues an error: the file A/B doesn't exist in the superproject. > But I do not think "git rm" needs "--recurse-submodules". Wasn't > "--recurse-submodules" the option to control, when you tell Git to > do something to submodule "A", what should happen to submodules > contained in the submodule "A" (e.g. "A/B" that appears at path "B" > that itself is a separate project bound as a submodule to "A")? Nope. Only the "--recursive" option to the git submodule script works like that (and almost everyone seems to use that option by default anyway). But for all commands that understand the "--recurse-submodule" option (currently these are clone, fetch, merge, pull and push) that means "include submodules in what you do and don't stop at the first level but recurse all the way down". Without this option they won't even touch the first level of submodules. > I am OK if you choose to implement the behaviour described above > only in "git submodule rm A" and not plain "git rm -r A", but if you > are going that route, I do not see how it is an improvement for it > to remove the index entry for A from the index if your "git rm -r A" > does not remove working tree files for submodule A. The user asked > to remove A with a command that would remove both index entry and > working tree file for a regular file (or a directory), the command > may decide it is not prudent to do so for whatever reason. Perhaps > the entity being asked to remove has local changes the user may > regret losing. Perhaps we decided that such an opration to cause a > large structural change should not be done with a plain "rm" but > should be done with "git submodule rm". The reasons do not matter > much, but for the end result to be consistent, shouldn't the command > keep the index entry intact if it does not remove the working tree? All other core commands happily change the index without updating the submodule's work tree. My first patch intended to make "git rm" behave the same: Don't care if the submodule's work tree is still there, but just record in the index what the user told you. Right now it *always* throws an error no matter if the submodule is modified or not, while a "rm" should either just work on unmodified content or leave submodules alone. That's what I'm trying to fix. To me checking out a commit before the submodule was added should leave work tree and index in the same state with respect to the submodule as when I do a "git rm sub". In the former case the submodule directory is still there with all files but it won't be present in the index (and .gitmodules) anymore. And checkout doesn't care at all about any modifications in the submodule before updating. "git rm" will behave just the same after my patch (of course I'm talking about the upcoming v2 without checking the HEAD). But I agree with you that rm
Re: Problems pushing???
Hi Holger, I think you were correct. I deleted my git init on the remote(Well, locally on my machine...), did what you said I was able to push successfully. Can I check the files have been successfully transferred to correct location??? Just wanted a bit of confidence it has done what it should of. I guess I can simply clone this from another machine and test? -- View this message in context: http://git.661346.n2.nabble.com/Problems-pushing-tp7562695p7562705.html Sent from the git mailing list archive at Nabble.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
[PATCH v9] git on Mac OS and precomposed unicode
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano
Signed-off-by: Torsten Bögershausen
---
Thanks to Junio & Andreas for the comments
Changes since 7v:
Code is 3% easier to read:
s/precomposed/precompomse/
s/__PRECOMPOSED_UNICODE_[H]C__/PRECOMPOSE_UNICODE_[CH]/
Documentation/config.txt:
clarified what happens when core.precomposeunicode == false:
- When false, file names are handled fully transparent by git, which means
- that file names are stored as decomposed unicode in the repository.
+ When false, file names are handled fully transparent by git,
+ which is backward compatible with older versions of git.
s/Git for Windows/msysGit 1.7.10/Git for Windows 1.7.10 or higher/
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c| 1 +
cache.h | 1 +
compat/precompose_utf8.c | 190 +++
compat/precompose_utf8.h | 45 ++
config.c | 5 ++
environment.c| 1 +
git-compat-util.h| 9 ++
parse-options.c | 1 +
t/t3910-mac-os-precompose.sh | 164 +
utf8.c | 26 +++---
utf8.h | 1 +
13 files changed, 446 insertions(+), 10 deletions(-)
create mode 100644 compat/precompose_utf8.c
create mode 100644 compat/precompose_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0bcea8a..e6a50fa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -211,6 +211,15 @@ The default is false, except linkgit:git-clone[1] or
linkgit:git-init[1]
will probe and set core.ignorecase true if appropriate when the repository
is created.
+core.precomposeunicode::
+ This option is only used by Ma
Re: [PATCH v8] git on Mac OS and precomposed unicode
Torsten Bögershausen writes: > Unlike on > HFS+, Mac OS X files on a VFAT drive (e.g. an USB drive), in ^stores? ^s/,// > precomposed unicode, but readdir() still returns file names in > decomposed unicode. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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 v8] git on Mac OS and precomposed unicode
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X files on a VFAT drive (e.g. an USB drive), in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano
Signed-off-by: Torsten Bögershausen
---
Thanks to Junio for the comments
Changes since 7v:
Code is 3% easier to read:
s/precomposed/precompomsed/
s/__PRECOMPOSED_UNICODE_[H]C__/PRECOMPOSE_UNICODE_[CH]/
Documentation/config.txt:
clarified what happens when core.precomposeunicode == false:
- When false, file names are handled fully transparent by git, which means
- that file names are stored as decomposed unicode in the repository.
+ When false, file names are handled fully transparent by git,
+ which is backward compatible with older versions of git.
s/Git for Windows/msysGit 1.7.10/Git for Windows 1.7.10 or higher/
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c| 1 +
cache.h | 1 +
compat/precompose_utf8.c | 190 +++
compat/precompose_utf8.h | 45 ++
config.c | 5 ++
environment.c| 1 +
git-compat-util.h| 9 ++
parse-options.c | 1 +
t/t3910-mac-os-precompose.sh | 164 +
utf8.c | 26 +++---
utf8.h | 1 +
13 files changed, 446 insertions(+), 10 deletions(-)
create mode 100644 compat/precompose_utf8.c
create mode 100644 compat/precompose_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0bcea8a..e6a50fa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -211,6 +211,15 @@ The default is false, except linkgit:git-clone[1] or
linkgit:git-init[1]
will probe and set core.ignorecase true if appropriate when the repository
is created.
+core.precomposeunicode::
+ This option is only used by Mac OS implementa
Re: Problems pushing???
On Sun, Jul 08, 2012 at 01:52:03PM +0200, Holger Hellmuth wrote: >>http://www.petermac.com/setup-git-local-and-remote-repositories/ this . All > > The recipe at this address seems to have a "--bare" parameter > missing at the git init in step 7 The OP stated that «This is intended to be the remote machine too.» wich hints he wants to also receive changes to this repo from the outside. Supposedly he should stick to pulls only. Or set up a bare repo on the local machine and then clone it to its "working" repo using a plain path like /path/to/that/shared/repo. -- 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: Problems pushing???
Am 08.07.2012 11:12, schrieb pbGit: http://www.petermac.com/setup-git-local-and-remote-repositories/ this . All The recipe at this address seems to have a "--bare" parameter missing at the git init in step 7 -- 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: Problems pushing???
On Sun, Jul 08, 2012 at 02:12:46AM -0700, pbGit wrote: > I have installed git locally to my machine. It is running mac os lion. > This is intended to be the remote machine too. I have followed, what I think > is the correct way to do this, using > http://www.petermac.com/setup-git-local-and-remote-repositories/ this . All > seemed to be ok until I tried to push. When I try the following command. > > git push --all --repo= > > I get the following output > > Counting objects: 12, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (11/11), done. > Writing objects: 100% (12/12), 5.23 KiB, done. > Total 12 (delta 1), reused 0 (delta 0) > remote: error: refusing to update checked out branch: refs/heads/master [...] > Hope someone can help with this because I have spent a bit of time trying to > solve this and still stuck!!! Becasue pushing to a so-called "non-bare" repository (this is a "normal" repository, in which there is a work tree) either has no sense or requires extra steps to reconcile the results of pushing with the repository's work tree. Most probably you should reconsider your workflow. Read [1] for an in-depth explanation. Googling for "receive.denyCurrentBranch" will also provide you with a number of useful links (such as stackoverflow discussions). 1. http://sitaramc.github.com/concepts/bare.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] branch: add -u as a shortcut for --set-upstream
On Fri, 2012-07-06 at 10:32 -0500, Jonathan Nieder wrote:
> Hi Carlos,
>
> Carlos Martín Nieto wrote:
>
> > Add this shortcut just like git-push has it.
> [...]
> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char
> > *prefix)
> > OPT__QUIET(&quiet, "suppress informational messages"),
> > OPT_SET_INT('t', "track", &track, "set up tracking mode (see
> > git-pull(1))",
> > BRANCH_TRACK_EXPLICIT),
> > - OPT_SET_INT( 0, "set-upstream", &track, "change upstream info",
> > + OPT_SET_INT('u', "set-upstream", &track, "change upstream
> > info",
> > BRANCH_TRACK_OVERRIDE),
>
> I think this is a bad idea. The --set-upstream option is confusing:
>
> $ git branch --set-upstream=foo
> error: option 'set-upstream' takes no value
> $ ???
It is confusing, see the other thread (about making --set-upstream
behave more sanely) for the second part of this. I wanted to add a hack
so
git branch --set-upstream foo
would set the current branch to track foo.
>
> -u to set the corresponding upstream branch at the same time as
> creating a branch, analagous to "git push -u" might seem intuitive:
>
> # create foo branch, setting its upstream at the same time
> git branch -u foo origin/foo
>
> But that is what --track does and is not what --set-upstream is for.
Right, it's for altering the configuration after the branch has already
been created. I wasn't thinking about creating the branch. That usage of
--set-upstream seems unintuitive to me, but changing the upstream for a
branch that already exists is quite intuitive and what push -u does.
>
> Unlike --track, I don't think --set-upstream is a common enough
> operation to deserve a one-letter synonym.
I find myself using it surprisingly often, though it's certainly still
not in the top-10.
>
> Instead, I'd suggest the following changes:
>
> 1) Add support for
>
> # change upstream info
> git branch --set-upstream=origin/foo foo
>
> for existing branches only.
I submitted the patch I mentioned above which changes --set-upstream to
something closer to what the user probably expects, which behaves mostly
like this, except that you'd have to omit the '=' as it still expected
the branch as an argument to the command. Not the cleanest wrt how
options should take arguments, but it got the job done without much code
churn.
However, Junio doesn't like that it changes existing behaviour which is
even consistent (as long as you know that --set-upstream is a flag,
rather than an option with an argument) and some people might depend on
it behaving like it does with a single argument. He'd accept a
--set-upstream-to that behaves just like you describe. This could do
with having a short alias, as the name is quite long-winded. Another
reason for adding -u is that it would add confusion if --set-upstream
has the short alias -u in push, but it means something else in branch,
even though they have the same option (though it would be
--set-upstream-to here, but we'll end up deprecating --set-upstream, so
it works out in the long run).
>
> 2) Introduce an --unset-upstream option which removes the
> "corresponding upstream branch" configuration for an existing
> branch.
This is a good idea. I'll add it to the patch series.
>
> 3) Warn on
>
> # acts just like --track
> git branch --set-upstream foo origin/foo
>
> for branches that do not exist yet. Plan to make this a hard
> error in the future.
>
> 4) Warn on
>
> # sets upstream for "foo" to the current branch
> git branch --set-upstream foo
>
> and plan to make it a hard error in the future.
>
> 5) Warn on
>
> git branch --set-upstream origin/foo foo
>
> which is almost certainly a typo for
>
> git branch --set-upstream=origin/foo foo
This is roughly what Junio suggested. His proposal was to also show how
to undo the --set-upstream if it was invoked the wrong way.
>
> 6) Perhaps, make -u a synonym for -t for consistency with "git push".
I don't really see -u and -t being consistent with push -u. The push
might create a branch, but that would be in another repository. I look
at it as modifying the upstream information for an existing branch in
the local repository, and -t does not do that, --set-upstream(-to) does
that. It can also create a new local branch, but that's another bug in
the interface.
cmn
--
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
The linux-input mailing list has been moved
The linux-input mailing list has been moved to vger.kernel.org. See http://vger.kernel.org/vger-lists.html for information on the new list server (or consult your local oracle). Yours virtually, Martin Mares -- 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
Problems pushing???
Hi, I have installed git locally to my machine. It is running mac os lion. This is intended to be the remote machine too. I have followed, what I think is the correct way to do this, using http://www.petermac.com/setup-git-local-and-remote-repositories/ this . All seemed to be ok until I tried to push. When I try the following command. git push --all --repo= I get the following output Counting objects: 12, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (12/12), 5.23 KiB, done. Total 12 (delta 1), reused 0 (delta 0) remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. Hope someone can help with this because I have spent a bit of time trying to solve this and still stuck!!! Thanks for your time, Paul -- View this message in context: http://git.661346.n2.nabble.com/Problems-pushing-tp7562695.html Sent from the git mailing list archive at Nabble.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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Jens Lehmann writes: >> One possible sane behaviour of "git rm $path" might be: >> >> - If --force is given, remove it from the index and from the >>working tree (i.e. "rm -rf $path"), but use the "gitfile" >>facility to save $path/.git away to $GIT_DIR/modules/$name; error >>out if the submodule directory $path cannot be removed like this. >>We would probably want to remove "submodule..*" entries in >>.gitmodules for for which "submodule..path" matches >>the $path. >> >> - If --cached is given, remove it from the index if the version in >>the index match either HEAD or the $path/.git/HEAD, without >>touching the working tree. This is consistent with what happens >>to a regular file. >> >> - If neither --force nor --cached is given, run an equivalent of >>(cd $path && git status), and also check if $path/.git/HEAD >>matches the index version. Error out if the submodule directory >>is dirty (again I am not sure about this part). If the submodule >>directory is clean, do the same as the case with --force. > > What you describe here is exactly how I think "git submodule rm" and > "git rm --recurse-submodules" should behave. If you have a directory A with a file B in it (i.e. A/B), "git rm A" is refused and you have to say "git rm -r A". So I can see why the above description of the mine is wrong with respect to "-r" option (all cases should fail if you did not give "-r" option). But I do not think "git rm" needs "--recurse-submodules". Wasn't "--recurse-submodules" the option to control, when you tell Git to do something to submodule "A", what should happen to submodules contained in the submodule "A" (e.g. "A/B" that appears at path "B" that itself is a separate project bound as a submodule to "A")? I can see what fetching or updating "A" (e.g. "git submodule update") while leaving "A/B" intact means, so there is a reason to have two ways (with or without --recurse-submodules) to such a command, but I do not see any sensible definition of what it means to "remove" (whether it is "git submodule rm" or just plain "git rm") "A" without affecting "A/B", especially with respect to the working tree files. If you remove "A" and its working tree files, is there a sensible way to keep "A/B" and its working tree files? I am OK if you choose to implement the behaviour described above only in "git submodule rm A" and not plain "git rm -r A", but if you are going that route, I do not see how it is an improvement for it to remove the index entry for A from the index if your "git rm -r A" does not remove working tree files for submodule A. The user asked to remove A with a command that would remove both index entry and working tree file for a regular file (or a directory), the command may decide it is not prudent to do so for whatever reason. Perhaps the entity being asked to remove has local changes the user may regret losing. Perhaps we decided that such an opration to cause a large structural change should not be done with a plain "rm" but should be done with "git submodule rm". The reasons do not matter much, but for the end result to be consistent, shouldn't the command keep the index entry intact if it does not remove the working tree? Unless the user used "git rm --cached" to explicitly ask for the index entry to be removed without touching the working tree files, 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
