Junio C Hamano wrote: > If we _were_ to sanction the use of the hook to tweak the result, I do not > want to see it implemented as an ad-hoc hack that tells the hook writers > that it is _entirely_ their responsiblity to update the remote tracking > branches from what it fetched, and also update $GIT_DIR/FETCH_HEAD to > maintain consistency between these two places. > > A very cursory look at the patch tells me that there are a few problems > with it. It does not seem to affect what will go to $GIT_DIR/FETCH_HEAD > at all, and hence it does not have any way to affect the result of the > fetch that does not store it to any of our remote tracking branches. True, it does not update FETCH_HEAD. I had not considered using the hook that way. I suppose that after running the hook, fetch could check each remote tracking branch for a new value, and only then write to FETCH_HEAD. > > The #1 point of confusion for git-annex users is the need to run > > "git annex merge" after fetching. That does a union merge of newly > > fetched remote git-annex branches into the local git-annex branch. > > That use case sounds like that "git fetch" is called as a first class UI, > which is covered by "git myfetch" (you can call it "git annex fetch") > wrapper approach, the canonical example of a hook that we explicitly do > not want to add. It also does not seem to call for mucking with the result > of the fetch at all. Most users are fetching by calling git pull as part of their normal workflow. I would like to avoid git-annex needing its own special pull command. For one thing, there can be many programs that use git branches in similar ways (another one is pristine-tar), and a user shouldn't have to run multiple wrapped versions of git fetch or pull when using multiple such programs. -- see shy jo
Attachment:
signature.asc
Description: Digital signature