Junio C Hamano writes: > Karthik Nayak writes: > >> From: Karthik Nayak >> >> In the previous commits, we converted `refs_create_symref()` to utilize >> transactions to perform symref updates. Earlier `refs_create_symref()` >> used `create_symref()` to do the same. >> >> We can now remove `create_symref()` and any code associated with it >> which is no longer used. We remove `create_symref()` code from all the >> reference backends and also remove it entirely from the `ref_storage_be` >> struct. >> >> Signed-off-by: Karthik Nayak >> --- > > This has serious semantic conflicts with in-flight topics. I think > I resolved them all correctly while merging it in 'seen', but please > double check the result after I push it out. > I had a look at the commit pushed to 'seen', looked good to me. Thanks. > This comment equally applies to the "force all callers to use > get_main_ref_store() on the_repository and remove functions that > implicitly used the main ref store of the_repository" topic by > Patrick, but we really should devise a bit more smoother way to cope > with out of tree and in-flight topics. For example, as the new > refs_update_symref() function works exactly like the existing > refs_create_symref() function, after renaming all the in-base (i.e., > in-tree at the point this topic forks from) users to call the new > function, instead of just removing the original one, it would have > been nice to guide authors of other in-flight topics by (1) causing > build failure and at the same time (2) telling them what they need > to do to adjust to the new world order. This patch does only (1) > but does a poor job for (2). We may want to establish a better > convention than just outright removing and breaking others' topics. > > Thanks. Just so I can do better next time, what is your suggestion for doing (2) better?