Re: [Query] Separate hooks for Git worktrees
- From
Stefan Beller <sbeller@google.com>
- Date
- Nov 10, 2017, 18:00 UTC
- Message-ID
- <CAGZ79kZ8PKBwe+aWTUOgPwV2tNQS7+dUrLTVsWhzemj-e35kaA@mail.gmail.com>
- In-Reply-To
- <xmqq60aihgod.fsf@gitster.mtv.corp.google.com>
On Thu, Nov 9, 2017 at 9:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Stefan Beller <sbeller@google.com> writes: > >> We have no worktree specific config yet, though patches for >> this were floated on the mailing list. >> >> Though recent versions of git learned to conditionally include >> config files. (look for includeIf in man git-config), which I think >> could be used to set the option gerrit.createChangeId depending >> on the worktree you are in. >> >>> Any idea how I can get around this problem without having separate >>> repositories for kernel and android ? >> >> The proposed approach above might be hacky but sounds as if >> it should work? > > If you meant "conditional include" by "proposed approach above", I > do not see which part you found possibly hacky.
Compared to a per-worktree configuration that you can setup via
git config --for-worktree=X key value
the setup using conditional includes seems hacky to me. (I just realize that these conditional includes can be set using regular git-config, so maybe it is not as hacky as I thought.)
> It is to allow > different set of configurations to apply depending on where you are > working at, which I think was invented exactly for something like > this.
From a UX perspective, I can imagine a way easier workflow, but the data model seems to make sense.
> It certainly is not any hackier than using the same repository to > house separately manged projects even if they may be related > projects.
Well it is the same project with different upstream workflows. For example I would imagine that Viresh wants to cherry-pick from one branch to another, or even send the same patch (just with different commit messages, with or without the ChangeId) to the different upstreams?
> Where does the aversion of "having separate repositories" primarily > come from? Is it bad due to disk consumption? Is it bad because > you cannot do "git diff android-branch kernel-branch"? Something > else?
Yeah, that is an interesting question! (I suspect workflow related things, diff/cherry-pick)
Show 5 quoted lines
> If it is purely disk consumption that is an issue, perhaps the real > solution is to make it easier to maintain separate repositories > while sharing as much disk space as possible. GC may have to be > made a lot more robust in the presense of alternate object stores, > for example.