Can I squash the merge created by "git subtree add"?
When I do a "git subtree add", I get two commits. df7e8f5 Merge commit '6de34775ea846c90e3f28e9e7fdfe690385c068b' as 'go/src/gopkg.in/ns1/ns1-go.v1' 6de3477 Squashed 'go/src/gopkg.in/ns1/ns1-go.v1/' content from commit 1d343da Unfortunately, in the environment I'm currently working in, merge commits aren't allowed. Is it safe to squash these two commits into a single commit? Will future "subtree" commands still work correctly?
"git push" says "src refspec XYZ matches more than one" even without explicit XYZ argument.
1. My repo has a branch named 'v1' that is tracking 'origin/v1'. 2. My repo has a tag named 'v1'. 3. I have "push.default" set to "upstream". I made a commit on branch 'v1' and tried doing a push: # git push error: src refspec v1 matches more than one. error: failed to push some refs to 'g...@github.com:whatever/ns1-go.git' If I rename the branch to 'v1-dev', then the push goes through. I understand why the command "git push origin/v1 v1" is ambiguous. But if I do a plain "git push", I thought Git would know to push my current branch. [Git version 2.10.1 from Homebrew on Mac OS 10.11.6.]
Re: Make "git checkout" automatically update submodules?
Stefan Beller google.com> writes: > [1] https://github.com/jlehmann/git-submod-enhancements/wiki Oh wow, Christmas came early! I'll give this code a try. -- 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: Make
Thanks for the explanation. I didn't realize some projects don't want to initialize all their submodules, but the explicit opt-in idea you described sounds nice. I've seen cases where people will financially "sponsor" feature development in open source projects. Is there any precedent for this in the Git project? Is it ok to use this mailing list to ask about such things? -- 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: Make "git checkout" automatically update submodules?
Junio C Hamano pobox.com> writes:
> We are unfortunately not set up to handle money well. For a
> background explanation, please go read [*1*], which I wrote my take
> on "money" some time ago. Note that it is an explanation and not a
> justification. It explains why we are not set up to handle money
> well and what the issues around money that are troublesome for the
> project are. It does not mean to say that it is a good thing that
> it is hard to buy feature with money from our project [*2*].
I think the way I described it ("sponsoring a feature") doesn't really
reflect how I was imagining it. In my head, it looked like this:
1. Figure out whether the Git community and maintainers seem ok with the
overall feature idea. If not, give up.
2. Come up with a plan for the UI/UX; see if the Git community and
maintainers seem ok with it. If not, iterate or give up.
3. Implement it, then go through the regular process of getting it merged
upstream. If it doesn't go well, might have to iterate or give up.
I could try doing that myself, but someone familiar with the Git
codebase/community/history would be better at it (and probably be easier for
you guys to work with :-)
I guess I'm just wondering if there are people who meet those qualifications
and are interested in going through those steps for pay. Or maybe there's a
company that does this, like the old Cygnus Solutions?
In particular, I don't expect anything to change about the project's
development process.
(This part is not relevant to the Git project, but I understand that it's
hard for anyone to guarantee a feature will make it into an open source
project. I imagine these kinds of contracts are set up so that you're
primarily paying for the effort, not the outcome. If it ends up not working
out, you don't get your money back.)
--
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
Make "git checkout" automatically update submodules?
Git submodules seem to be a great fit for one of our repos. The biggest pain point is that it's too easy to forget to update submodules. 1. I often forget since most repos don't need it. 2. Infrequent users of our repo almost never know to update submodules and end up coming to us with strange build errors. 3. Existing scripts that work with Git repos are usually not built to handle submodules. In the common case of the submodule content having no local edits, it would be nice if "git checkout" automatically updated submodules [1]. If there are local edits, it could error out (maybe override with "--ignore-modified-submodules" or something). I'm not a Git expert, though. Is there a reason something like this isn't already implemented? Maybe there's an existing write-up or mailing list thread I can read to get some background information? Thanks! [1] Our post-checkout procedure is: git submodule sync git submodule update --init git submodule foreach --recursive \ 'git submodule sync ; git submodule update --init' (Not sure if this is correct. Different articles/blogs suggest a slightly different set of commands.) -- 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
