From: "Ed S. Peschko" <esp5@pge.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: simple cvs-like git wrapper
Date: Wed, 30 Jan 2008 21:41:24 -0800 [thread overview]
Message-ID: <20080131054124.GG9612@venus> (raw)
In-Reply-To: <20080131040839.GW24004@spearce.org>
> Merging all branches on the remote named "origin" is simply not an
> intelligent thing to do. Nobody blindly merges everything available
> from a remote, and nobody has ever asked for such a function before
> in Git. I still think its nuts, but I don't know all details of
> your situation so I'll just shut up now and hope you know what you
> are really asking for.
Ok, I'm not going to belabor the point, but for the most part, the
requests in our particular domain are separate. A developer for the
most part works only on files that other developers are not working on.
There are exceptions to this, but for the most part this is true..
Hence, most of the time there will be no conflicts.
Anyways, I'll try to improve on your script, but it looks like what I
want to do.
> This is going to be slow as you are running git-merge for each
> and every branch available to you. You can do a lot better by
> loading the branch DAG into memory in Perl/C/Python and doing a
> graph coloring algorithm to see if a merge is necessary or not,
> as if you are merging everything all of the time almost everything
> is going to be always merged to everything else. Which as I said
> earlier is nuts.
hmm. Is there a simple method to get this graph? I'm assuming that you
would have to get all the local commits and compare them to the remote
commits, and only merge the branches that have commits not yet
merged..
Ed
> --
> Shawn.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-01-31 5:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 20:40 simple cvs-like git wrapper Ed S. Peschko
2008-01-29 22:28 ` Jakub Narebski
2008-01-30 2:10 ` Ed S. Peschko
2008-01-30 4:00 ` Shawn O. Pearce
2008-01-30 22:52 ` Ed S. Peschko
2008-01-31 4:08 ` Shawn O. Pearce
2008-01-31 5:41 ` Ed S. Peschko [this message]
2008-01-31 6:01 ` Shawn O. Pearce
2008-01-31 6:17 ` Junio C Hamano
2008-01-30 19:49 ` Daniel Barkalow
2008-02-01 13:05 ` Kate Rhodes
2008-02-01 13:25 ` Johannes Schindelin
2008-02-01 15:35 ` Jakub Narebski
2008-02-01 7:29 ` Uwe Kleine-König
2008-02-01 9:58 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080131054124.GG9612@venus \
--to=esp5@pge.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).