Re: [RFC PATCH v1 06/17] merge-index: libify merge_one_path() and merge_all()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Phillip,

Phillip Wood (phillip.wood123@xxxxxxxxx) a écrit :

> Hi Alban
> 
> On 12/07/2020 12:36, Alban Gruin wrote:
> > Hi Phillip,
> > 
> > Phillip Wood (phillip.wood123@xxxxxxxxx) a écrit :
> > 
> >> Hi Alban
> >>
> >> On 25/06/2020 13:19, Alban Gruin wrote:
> >> -%<-
> >>> diff --git a/merge-strategies.c b/merge-strategies.c
> >>> index 3a9fce9f22..f4c0b4acd6 100644
> >>> --- a/merge-strategies.c
> >>> +++ b/merge-strategies.c
> >>> @@ -1,6 +1,7 @@
> >>>  #include "cache.h"
> >>>  #include "dir.h"
> >>>  #include "merge-strategies.h"
> >>> +#include "run-command.h"
> >>>  #include "xdiff-interface.h"
> >>>  
> >>>  static int add_to_index_cacheinfo(struct index_state *istate,
> >>> @@ -189,3 +190,101 @@ int merge_strategies_one_file(struct repository *r,
> >>>  
> >>>  	return 0;
> >>>  }
> >>> +
> >>> +int merge_program_cb(const struct object_id *orig_blob,
> >>> +		     const struct object_id *our_blob,
> >>> +		     const struct object_id *their_blob, const char *path,
> >>> +		     unsigned int orig_mode, unsigned int our_mode, unsigned int their_mode,
> >>> +		     void *data)
> >>
> >> Using void* is slightly unfortunate but it's needed later.
> >>
> >> It would be nice to check if the program to run is git-merge-one-file
> >> and call the appropriate function instead in that case so all users of
> >> merge-index get the benefit of it being builtin. That probably wants to
> >> be done in cmd_merge_index() rather than here though.
> >>
> > 
> > Dunno, I am not completely comfortable with changing a parameter that 
> > specifically describe a program, to a parameter that may be a program, 
> > except in one case where `merge-index' should lock the index, setup the 
> > worktree, and call a function instead.
> 
> There is some previous discussion about this at
> https://lore.kernel.org/git/xmqqblv5kr9u.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/
> 

Thanks.  If no-one seems really against doing that, I'll include the patch 
below in the v2, with an additional note in the man page.

> I'll try and have a proper look at your comments towards the end of the
> week (or maybe the week after the way things are at the moment...)
> 
> Best Wishes
> 
> Phillip
> 

Cheers,
Alban




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux