Re: Bring together merge and rebase

2018-01-06 Thread Carl Baldwin
On Sat, Jan 06, 2018 at 10:29:19AM -0700, Carl Baldwin wrote: > To me, this is roughly equivalent to saying that parent pointers > embedded in a commit object is a good idea because we want a richer > relationship than mere "parent". Look how much we've done with this &g

Re: Bring together merge and rebase

2018-01-06 Thread Carl Baldwin
On Fri, Jan 05, 2018 at 12:14:28PM -0800, Junio C Hamano wrote: > Martin Fick writes: > > > These scenarios seem to come up most for me at Gerrit hack- > > a-thons where we collaborate a lot in short time spans on > > changes. We (the Gerrit maintainers) too have wanted

Re: Bring together merge and rebase

2018-01-04 Thread Carl Baldwin
On Thu, Jan 04, 2018 at 10:09:19PM -0700, Carl Baldwin wrote: > This would be very cool. I've wanted to tackle this for a long time. I > think I even filed an issue with gerrit about this years ago. Yep, it turned out that it was a duplicate but I described what I did to work around it.

Re: Bring together merge and rebase

2018-01-04 Thread Carl Baldwin
On Thu, Jan 04, 2018 at 12:19:34PM -0700, Martin Fick wrote: > On Tuesday, December 26, 2017 12:40:26 AM Jacob Keller > wrote: > > On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin > <c...@ecbaldwin.net> wrote: > > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Bald

Re: Bring together merge and rebase

2018-01-04 Thread Carl Baldwin
On Thu, Jan 04, 2018 at 01:06:27PM -0700, Martin Fick wrote: > On Tuesday, December 26, 2017 01:31:55 PM Carl Baldwin > wrote: > ... > > What I propose is that gerrit and github could end up more > > robust, featureful, and interoperable if they had this > > feature

Re: Bring together merge and rebase

2018-01-04 Thread Carl Baldwin
On Thu, Jan 04, 2018 at 12:54:00PM -0700, Martin Fick wrote: > On Monday, December 25, 2017 06:16:40 PM Carl Baldwin wrote: > > On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o > wrote: > > Look at what happens in a rebase type workflow in any of > > the

Re: Bring together merge and rebase

2017-12-27 Thread Carl Baldwin
On Wed, Dec 27, 2017 at 03:35:58PM +0200, Alexei Lozovsky wrote: > I think the reasoning behind Theo's words is that it would be better > to first implement the commit relationship tracking as an add-in which > uses commit messages for data storage, then evaluate its usefulness > when it's

Re: Bring together merge and rebase

2017-12-26 Thread Carl Baldwin
On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: > Here's another potential use case. The stable kernels (e.g., 3.18.y, > 4.4.y, 4.9.y, etc.) have cherry picks from the the upstream kernel, > and this is handled by putting in the commit body something like this: > > [ Upstream

Re: Bring together merge and rebase

2017-12-26 Thread Carl Baldwin
On Tue, Dec 26, 2017 at 01:08:45PM +0900, Mike Hommey wrote: > FWIW, your proposal has a lot in common (but is not quite equivalent) > to mercurial's obsolescence markers and changeset evolution features. I've had experience with mercurial but not since about 2009. After reading up a little bit

Re: Bring together merge and rebase

2017-12-26 Thread Carl Baldwin
On Tue, Dec 26, 2017 at 03:19:02PM -0500, Paul Smith wrote: > As someone working in an environment where we do a lot of rebasing and > very little merging, I read these proposals with interest. I'm not > convinced that we would switch to using a "replaces"-type feature, but > I'm pretty sure that

Re: Bring together merge and rebase

2017-12-26 Thread Carl Baldwin
On Tue, Dec 26, 2017 at 01:04:36PM -0500, Theodore Ts'o wrote: > On Mon, Dec 25, 2017 at 06:16:40PM -0700, Carl Baldwin wrote: > > At this point, you might wonder why I'm not proposing to simply add a > > "change-id" to the commit object. The short answer is that the &g

Re: Bring together merge and rebase

2017-12-26 Thread Carl Baldwin
On Tue, Dec 26, 2017 at 06:49:56PM +0100, Ævar Arnfjörð Bjarmason wrote: > New headers should be added after existing headers, but other than > that it won't choke on it. See 4b2bced559 when the encoding header was > added, this also passes most tests: > > diff --git a/commit.c b/commit.c >

Re: Bring together merge and rebase

2017-12-25 Thread Carl Baldwin
On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote: > On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > > Anyway, now I am compelled to use github which is also a fine tool and I > > appreciate all of the work that has gone into it. About 8

Re: Bring together merge and rebase

2017-12-25 Thread Carl Baldwin
On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: > As a suggestion, before diving into the technical details of your > proposal, it might be useful consider the usage scenario you are > targetting. Things like "git rebase" and "git merge" and your > proposed "git replace/replay" are

Re: Bring together merge and rebase

2017-12-25 Thread Carl Baldwin
Thank you again for your reply. Following is the kind of commit that I would like to create. tree fcce2f309177c7da9c795448a3e392a137434cf1 parent b3758d9223b63ebbfbc16c9b23205e42272cd4b9 replaces e8aa79baf6aef573da930a385e4db915187d5187 author Carl Baldwin <c...@ecbaldwin.net> 15140572

Re: Bring together merge and rebase

2017-12-25 Thread Carl Baldwin
On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote: > Hi Carl, > > On Sat, 23 Dec 2017, Carl Baldwin wrote: > > > I imagine that a "git commit --amend" would also insert a "replaces" > > reference to the original commit but I fa

Re: Bring together merge and rebase

2017-12-25 Thread Carl Baldwin
On Sat, Dec 23, 2017 at 05:19:35PM -0500, Randall S. Becker wrote: > No matter how this plays out, let's please make very sure to provide > sufficient user documentation so that those of us who have to explain > the differences to users have a decent reference. Even now, explaining > rebase vs.

Re: Bring together merge and rebase

2017-12-23 Thread Carl Baldwin
C2 which > would be one or more of "replaces ", commit objects > support adding arbitrary new fields without anything breaking. > > But most importantly, while I think this gives you the same things from > a UX level, it doesn't need any changes to fetch, push, gc or

Bring together merge and rebase

2017-12-22 Thread Carl Baldwin
. I tend to think that bisect should prefer the regular commit history but have the ability to drill into the change history if necessary. In my opinion, this proposal would bring together rebase and merge in a powerful way and could end the contention. Thanks for your consideration. Carl Baldwin

Re: [PATCH] unset CDPATH in git-clone

2005-09-06 Thread Carl Baldwin
On Mon, Sep 05, 2005 at 12:37:58PM -0700, Junio C Hamano wrote: Carl Baldwin [EMAIL PROTECTED] writes: The function get_repo_base seems to break with this CDPATH. Sorry, your message somehow slipped my filtering. Thanks for the analysis. Of course, CDPATH would break it. Is there any

[PATCH] unset CDPATH in git-clone

2005-09-01 Thread Carl Baldwin
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO

Re: [RFC] undo and redo

2005-08-25 Thread Carl Baldwin
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote: On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote: snip... Another example is if I'm working on a commit and suddenly get a brilliant idea for some easy modification that I want to make and commit by itself before

Re: [RFC] undo and redo

2005-08-25 Thread Carl Baldwin
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL

Re: [RFC] undo and redo

2005-08-24 Thread Carl Baldwin
at 11:23:39AM -0600, Carl Baldwin wrote: Hello, So, one thing that I liked about GNU Arch when I tried it out was the ability to undo and redo changes in the local working copy. I decided to try to do this with git. What I have is preliminary. I'm sure it could use some work. So, I

Re: [RFC] undo and redo

2005-08-24 Thread Carl Baldwin
On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote: On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing

Re: [RFC] undo and redo

2005-08-24 Thread Carl Baldwin
On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote: Carl Baldwin [EMAIL PROTECTED] writes: Attached are the two scripts. Comments and criticism are welcome. An obligatory non-technical comment. I would have liked to see this not in a MIME multipart format, which made

Re: cg-update/cg-merge refuse to update if state is dirty?

2005-08-23 Thread Carl Baldwin
of things. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl Baldwin

[RFC] Removing deleted files after checkout

2005-08-23 Thread Carl Baldwin
script that I actually use to do this. Again, comments are welcome. Thanks, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523

Re: [RFC] Removing deleted files after checkout

2005-08-23 Thread Carl Baldwin
old_commit (the first time push happens to a new ref you would not have that one). -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523

Re: Making note, in the repository, of push/pull relationships

2005-08-16 Thread Carl Baldwin
. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED

Re: Making note, in the repository, of push/pull relationships

2005-08-16 Thread Carl Baldwin
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL

Re: Add an empty directory?

2005-08-13 Thread Carl Baldwin
but it is a convenience. Not supporting it may seem like an artificial limit that really didn't need to be there. I'll read up on the index file when I get the chance. Cheers, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

2005-08-12 Thread Carl Baldwin
avoid mistakes like pushing to the wrong head. Anyway, those are my two cents. I couldn't tell wether a resolution had been achieved so I thought I would pipe up. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI