"Remote branches" extension

Patrick Mézard pmezard at gmail.com
Sat May 22 11:25:56 CDT 2010


Le 17/05/10 12:08, Rafael Fernández López a écrit :
> Hello all,
> 
> I have never written to this list, so I introduce myself: I am Rafael
> Fernández López, a KDE contributor, and a DVCS enthusiast. I love
> Mercurial, but I always end up using Git. I recently had an idea on
> how to improve certain work models using Mercurial, and how to catch
> up Git.
> 
> = Work model =
> 
> I believe my work model is really easy and common, but just in case, I
> explain it carefully. First of all, I always _need_ to have my work
> "backed up". This means, it doesn't matter I am fixing the most
> important bug in the world, or I am doing something really really
> crazy that I will discard with 99.9% of probability, I want my work
> backed up. This means I want to push my work to the server frequently.
> 
> So, when I start something crazy that will very probably be discarded,
> I'd like that thing to dissappear as it never existed, just because it
> was really crazy (note this is not always true, if I do something that
> I consider is really nice and fails for whatever reason, is important
> for the project too to know that it didn't succeed, and the reasons,
> so fails are important too).
> 
> Possible options:
> 
> - Use "implicit branching" and keep going.
> - Use specific "named branches" for that crazy work and perform
> "--close-branch" when you are finished.
> - Use patch queues.
> - Use repository cloning.
> 
> = Implicit branching =
> 
> While this feature is really cool, I have a problem here. Some, I'd
> say. I'd like my "branch" to have some kind of information about
> what's going on on that branch (Ok, you can tell, add "EXPERIMENTAL:
> testing whatever" to the first commit), but that isn't what I really
> want.
> 
> Also, when I am working very intensively on a feature, my tip will
> point to the most experimental change, what I really don't want,
> because people that clone my repo will think my repo is unstable.
> 
> Also, when asking someone else to pull from your repo so they can
> merge upstream (if you didn't merge), is pretty uncomfortable to say:
> "hey Nick plz pull from my repo revision 58e3a283".

[...]

> So, ideas ? comments ? ways to improve the work model ? Whatever is
> welcome... ;)

I may be wrong but it looks like shareable bookmarks would mostly solve this. "tip" might still be wrong but it would be flagged as "experimental" or something like that.

--
Patrick Mézard


More information about the Mercurial-devel mailing list