Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle

[Johannes Schindelin <Johannes.Schindelin@xxxxxx>]

Hi,

On Thu, 3 Jul 2008, Adam Brewster wrote:

> > Yes, certainly it is more flexible to have them split. I find Adam's 
> > argument the most compelling, though. Think about moving commits as a 
> > multi-step protocol:
> >
> >  1. Local -> Remote: Here are some new commits, basis..current
> >  2. Remote -> Local: OK, I am now at current.
> >  3. Local: update basis to current
> >
> > git-push has the luxury of asking for "basis" each time, so we know it 
> > is correct. But with bundles, we can't do that. And failing to update 
> > "basis" means we will send some extra commits next time. But updating 
> > "basis" when we shouldn't means that the next bundle will be broken.
> >
> > So I think even if people _do_ want to update "basis" when they create 
> > the bundle (because it is more convenient, and they are willing to 
> > accept the possibility of losing sync), it is trivial to create that 
> > workflow on top of the separate components. But I can see why somebody 
> > might prefer the separate components, and it is hard to create them if 
> > the feature is lumped into "git-bundle" (meaning in such a way that 
> > you cannot perform the steps separately; obviously git-bundle --basis 
> > would be equivalent).
> >
> > But I am not a bundle user, so that is just my outsider perspective.
> 
> How does everybody feel about the following:
> 
> - Leave git-basis as a small perl script.

I'd rather not.

> - Add a -b/--basis option in git-bundle that calls git-basis.  Any 
>   objects mentioned in the output would be excluded from the bundle.  
>   Multiple --basis options will call git-basis once with several 
>   arguments to generate the intersection of specified bases.

So the only function of -b would be to fork() && exec() a _shell_ script?  
I don't like that at all.

> - (maybe) Add an option "--update-bases" to automatically call git-basis 
>   --update after the bundle is created successfully.

Rather, have it as a feature to auto-detect if there is a ".basis" file of 
the same basename (or, rather ".state", a I find "basis" less than 
descriptive), and rewrite it if it was there.

It could be forced by a to-be-introduced "--state" option to git-bundle.

> There's still plenty of potential for improvements, like a --gc mode
> to clean up basis files,

umm, why?  "rm" is not simple enough?

> a --rewind option to undo an incorrect --update,

Rather hard, would you not think?  The information is either not there, or 
you store loads of cruft in the .state file.

> or improvements in the way it calculates intersections,

Umm.  How so?

> but I think that with these changes the system is as simple as possible 
> while maximizing flexibility, utility, and usability.

I am not convinced.  This sort of feature belongs into git-bundle.  It 
certainly does not deserve being blessed by yet-another git-* command, 
when we are constantly being bashed for having _way_ too many _already_.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html