Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
Am 30.11.2012 04:27, schrieb W. Trevor King: On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote: On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. I haven't dealt with any gitlink merges, but I think that supporting easy gitlink merges is orthogonal to this --remote option. For simple cases like autocommitted submodule floats, one of the conflicting gitlinks will be an ancestor of the other, so it should be easy to automate that merge. Submodule merges where one submodule commit is the ancestor of the other are already resolved automatically in recent git. So Phil's example will just work as long as only fast-forward merges are needed. -- 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wk...@tremily.us wrote: [snip initial thoughts leading to the update --remote v5] I was thinking the same thing, but reading this whole thread a couple of weeks late. Thanks for noticing. Moreover, I think that 'git submodule update --pull' is also the wrong way to spell this action. Maybe you are misled from the outset by your current workflow: Did you see my v5 (add --remote) series? For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wk...@tremily.us wrote: [snip initial thoughts leading to the update --remote v5] I was thinking the same thing, but reading this whole thread a couple of weeks late. Thanks for noticing. Moreover, I think that 'git submodule update --pull' is also the wrong way to spell this action. Maybe you are misled from the outset by your current workflow: Did you see my v5 (add --remote) series? Eventually, I did. Sorry for the out-of-order replies. For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. This seems precisely backwards to me. Why not use $ git submodule update --remote --fetch to do your default behavior instead? I suppose I am arguing against the tide of the dominant workflow, but the fetch-by-default idea needlessly conflates two primitive operations: float and fetch. I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I've always felt that the origin defaults are broken and are simply being ignored because most users do not trip over them. But ISTR that submodule commands use the remote indicated by the superproject's current remote-tracking configuration, with a fallback to 'origin' if there is none. Sort of a best effort algorithm, I think. Am I remembering that wrong? I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. Phil -- 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 v5 0/2] submodule update: add --remote for submodule's upstream changes
On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote: On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wk...@tremily.us wrote: On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: For that reason, I don't like the --pull switch since it implies a fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. This seems precisely backwards to me. Why not use $ git submodule update --remote --fetch to do your default behavior instead? I suppose I am arguing against the tide of the dominant workflow, but the fetch-by-default idea needlessly conflates two primitive operations: float and fetch. Because --no-fetch is the existing option, and if it ain't broke… ;). I don't know which remote I should be tracking, though. I suppose it is 'origin' for now, but maybe it is just whatever $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use origin because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.name.remote configuration option. I've always felt that the origin defaults are broken and are simply being ignored because most users do not trip over them. But ISTR that submodule commands use the remote indicated by the superproject's current remote-tracking configuration, with a fallback to 'origin' if there is none. Sort of a best effort algorithm, I think. Am I remembering that wrong? The current code uses a bare git-fetch. I'm not sure what that defaults to if you're on a detached head. If it bothers you, I'm fine adding the submodule.name.remote option in v6. I am not sure I want the gitlinks in superproject to update automatically in the index, but I definitely do not want to automatically create a commit for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). But I really don't want to figure out how to handle submodule collisions during a merge (or rebase!) of my superproject with changes that someone else auto-committed in his local $superproject as he and I arbitrarily floated up the upstream independently. There is nothing but loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… They've always been trouble for me. But it may be that I am ignorant. I haven't dealt with any gitlink merges, but I think that supporting easy gitlink merges is orthogonal to this --remote option. For simple cases like autocommitted submodule floats, one of the conflicting gitlinks will be an ancestor of the other, so it should be easy to automate that merge. 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
[PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King wk...@tremily.us On Wed, Nov 28, 2012 at 11:53:34AM -0500, W. Trevor King wrote: I thought of a better idea on the train. How about adding `--remote` to `submodule update` that overrides the gitlinked SHA-1 with the SHA-1 for origin/$branch? All of the other checkout/merge/rebase functionality is untouched. The only thing that changes is where we look for the update. I'm working up the patch now, and will submit v5 shortly. Here it is. Changes since v4: * Remove `update --branch` in favor of the new `update --remote` logic as mentioned above. * Optional config overrides for submodule.name.branch (as suggested by Jens) * Save --branch as submodule.name.branch instead of requiring --local-branch. * Restructure doc edits. I'm a lot happier with this two-patch proposal. The first patch implements --remote and documents submodule.name.branch. The second patch just gives you a convenient way to set it. I haven't heard from anyone other than Heiko recently about the --branch/--remote-branch choice, so I returned to the simpler --branch side effect storage from v1. I'd be happy to submit v6 with explicit --remote-branch recording if desired. W. Trevor King (2): submodule update: add --remote for submodule's upstream changes submodule add: If --branch is given, record it in .gitmodules Documentation/config.txt| 9 + Documentation/git-submodule.txt | 26 +- Documentation/gitmodules.txt| 5 + git-submodule.sh| 30 +- t/t7400-submodule-basic.sh | 1 + t/t7406-submodule-update.sh | 31 +++ 6 files changed, 96 insertions(+), 6 deletions(-) -- 1.8.0.2.gad10246.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
