Would a config var for --force-with-lease be useful?
Hello Everyone: I'm considering writing a patch that adds a configuration variable that will allow the user to default the command: git push --force to: git push --force-with-lease As discussed here: https://stackoverflow.com/questions/30542491/push-force-with-lease-by-default Now, I understand that there are downsides to having this enabled, namely that a user who has this enabled might forget that they have it enabled, and, as such, on a machine that _doesn't_ have it enabled (of which they are unfamiliar) might then run the more consequential command "git push --force", but my thinking is that adding this as a feature to the git codebase as an _optional_ (i.e. not enabled by default) configuration variable would then save some of us who use a "rebase-then-force-push for pull request" workflow some time and headaches. Of course, I don't want to submit a patch if this is a feature that isn't likely to be accepted, so I wanted to get some thoughts from the mailing list regarding this idea. Thank you, ~Scott Johnson
unsub
unsubscribe git
push.recurseSubmodules=check doesn't consider tags
I occasionally rebase my submodules. I realize the danger (historical submodule pointers could point to commits that get garbage-collected away) so I always create and push a tag before the rebase, to make sure the old commits will never get purged. I believe this is safe, based on some experiments I’ve run. The issue: I set the config var push.recurseSubmodules=check, and it seems to insist on having a branch and not merely a tag. When I push the parent repo’s commits, I get failures: "The following submodule paths contain changes that can not be found on any remote”. This is overly pessimistic: the commits are there on the remote, and the tag demonstrates that. Expected behavior: when the submodule remote has a branch or a tag with the submodule pointer as ancestor, the push.recurseSubmodules=check should succeed. Actual behavior: the push.recurseSubmodules=check fails when only a tag, and not any branch, contains the specific commit hash. I’m using Git 2.18.0, but I’ve checked newer Release Notes and didn’t see anything. Below is a Makefile that demonstrates the unexpected failure. The “pre-rebase” tag should be sufficient to allow the check to succeed. Run this in an empty directory. .PHONY: all clean # Make sure no config settings, either /etc/gitconfig or ~/.gitconfig, # affect this experiment. We will create our own ./.gitconfig. GIT := GIT_CONFIG_NOSYSTEM=1 HOME=$(PWD) XDG_CONFIG_HOME= git all: # Configure globally (into ./.gitconfig) $(GIT) config --global user.email "y...@example.com" $(GIT) config --global user.name "Your Name" $(GIT) config --global push.recurseSubmodules check # Create upstream repos mkdir sub.git && cd sub.git && $(GIT) init --bare mkdir repo.git && cd repo.git && $(GIT) init --bare # Create local repos $(GIT) clone repo.git repo $(GIT) clone sub.git sub # Populate submodule cd sub && echo "foo" > foo && $(GIT) add foo && $(GIT) commit -m 'rev 1 of foo' && $(GIT) push # Add submodule to parent repo cd repo && $(GIT) submodule add ../sub.git && $(GIT) commit -m 'Add submodule' && $(GIT) push # Track a new branch in the submodule cd repo/sub && $(GIT) checkout -b aril && $(GIT) push -u origin aril # Add commits to sub repo cd repo/sub && echo "bar" > bar && $(GIT) add bar && $(GIT) commit -m 'Add bar' && $(GIT) push cd repo/sub && echo "foo2" >> foo && $(GIT) commit -am 'Add more to foo' && $(GIT) push # Update parent with new submodule commits. Note: no push cd repo && $(GIT) add sub && $(GIT) commit -m 'Update sub' # Sub's master branch diverges cd sub && echo "three" > three && $(GIT) add three && $(GIT) commit -m 'Add three' && $(GIT) push # Rebase submodule: this tag is enough to keep the old commits from being garbage collected cd repo/sub && $(GIT) tag pre-rebase && $(GIT) push --tags origin cd repo/sub && $(GIT) checkout master && $(GIT) pull --ff-only cd repo/sub && $(GIT) checkout aril cd repo/sub && $(GIT) rebase master && $(GIT) push --force-with-lease # Update parent repo with newly rebased sub: this will FAIL due to push.recurseSubmodules=check unable to find HEAD^'s submodule pointer in any pushed branch in repo/sub cd repo && $(GIT) add sub && $(GIT) commit -m 'Add rebased submodule' && $(GIT) push clean: rm -rf repo repo2 repo.git sub sub.git .gitconfig
Feature Proposal: Track all branches from a given remote
Hello git experts: Recently, I've encountered the problem where I would like to set my local repository copy to track all branches on a given remote. There does not appear to be a switch for this in the git-branch command currently, however, I will admit that my somewhat limited understanding of the git-branch manpage might be causing me simply not to see it. It seems as though this is a use case that some users of git encounter now and then, as illustrated by this post: http://stackoverflow.com/a/6300386/281460 I was thinking that it might be useful to add a new option to git branch, perhaps something like: git-branch --track-remote Where specifies a given remote, and the command will track all branches remotes//* to refs/heads/*. So, for example, if I were to run: git-branch --track-remote origin and I had two branches on origin, master and maint, respectively, after the command finishes, my local repo would now have two branches, master (set up to track origin/master), and maint (setup to track origin/maint). I'm not entirely sure how to handle naming conflicts, for example if 'maint' already existed on another remote, and was set up to track from that remote previous to this invocation of the command. If I were to start work on a patch, would there be any interest in this feature, or are there reasons why it isn't currently implemented? Thank you, ~Scott Johnson -- 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: Feature Proposal: Track all branches from a given remote
Hi Brian: > [remote "origin"] > fetch = refs/heads/*:refs/heads/* Yes, you're right, this works just fine as long as I move out from a branch that's not in the remote in question, for example by doing: git checkout -b nothing git fetch - OR - git pull Do you think there would be any interest in a patch that added this as a simple command line option, though? I guess the idea of this patch then would simply change this line in the .git/config file for the length of the operation (and specified remote), execute the git pull command, and then reset the configuration after the command finished. (There really wouldn't be a need to affect the configuration on the filesystem - simply the effective configuration used while git is running for this operation). Thanks, ~Scott -- 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
