Re: Bring together merge and rebase

On Sat, Jan 06, 2018 at 10:29:21AM -0700, Carl Baldwin wrote: > > When n==m==1, "amended" pointer from X1 to A1 may allow you to > > answer "Is this the first attempt? If this is refined, what did the > > earlier one look like?" when given X1, but you would also want to > > answer a related

Re: Bring together merge and rebase

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 > simple relationship.

Re: Bring together merge and rebase

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

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 and > sometimes discussed ways to track the relation of "amended" >

Re: Bring together merge and rebase

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

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 > wrote: > > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin > wrote: > >

Re: Bring together merge and rebase

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 to build from. > > I agree

Re: Bring together merge and rebase

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 following scenarios. All of these

Re: Bring together merge and rebase

> On Jan 4, 2018 11:19 AM, "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 > > > > wrote: > > > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin > > >

Re: Bring together merge and rebase

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 to build from. I agree (assuming we come up with a well defined feature) > With gerrit specifically,

Re: Bring together merge and rebase

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 following scenarios. All of these came up regularly > in my time with Gerrit. > > 1. Make a quick

Re: Bring together merge and rebase

On Sunday, December 24, 2017 12:01:38 AM 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 > > failed to mention that in my original post. > > And

Re: Bring together merge and rebase

On Tuesday, December 26, 2017 12:40:26 AM Jacob Keller wrote: > On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin wrote: > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote: > >> A bit of a tangent here, but a thought I didn't wanna > >> lose: In the

Re: Bring together merge and rebase

Hi, On Sun, 24 Dec 2017, Alexei Lozovsky wrote: > On Dec 24, 2017, at 01:01, 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

Re: Bring together merge and rebase

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

On Dec 27, 2017, at 06:35, Carl Baldwin wrote: > > On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: >> >> My experience, from seeing these much more complex use cases --- >> starting with something as simple as the Linux Kernel Stable Kernel >> Series, and

Re: Bring together merge and rebase

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

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

Very interesting topic, just this one part I wanted to comment on: On 26/12/2017 02:28, Jacob Keller wrote: > > What about some way to take the reflog and turn it into a commit-based > linkage and export that? Rather than tying it into the individual > commit history, keep track of it outside

Re: Bring together merge and rebase

Bisect is a interesting one. 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 cont

Re: Bring together merge and rebase

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

On Tue, 2017-12-26 at 12:44 -0700, Carl Baldwin wrote: > > Sure, it could be opt in, be a new format etc. But you haven't > > explained why you think a feature like this would need to rely on > > an entirely new parent structure and side-DAG, as opposed to just > > the more minor changes I'm

Re: Bring together merge and rebase

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 > > "change-id" Gerrit uses in

Re: Bring together merge and rebase

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

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 > "change-id" Gerrit uses in the commit messages cannot stand on its own. > It depends on data

Re: Bring together merge and rebase

On Tue, Dec 26 2017, Carl Baldwin jotted: > On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >> But I don't see why you think this needs a new "replaces" parent >> >> pointer orthagonal to parent pointers, i.e. something that would >> >> need to be a new field in the

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin wrote: > On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote: >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote: >> > Anyway, now I am compelled to use github which is also a fine tool and I >> >

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote: > On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin 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 80% of the time, > > I

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin 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 80% of the time, > I rebase and force push to my branch to update a pull request. I've come

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 4:16 PM, Carl Baldwin wrote: > On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ęvar Arnfjörš Bjarmason wrote: >> >> But I don't see why you think this needs a new "replaces" parent >> >> pointer orthagonal to parent pointers, i.e. something that would >> >>

Re: Bring together merge and rebase

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

On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> But I don't see why you think this needs a new "replaces" parent > >> pointer orthagonal to parent pointers, i.e. something that would > >> need to be a new field in the commit object (I may have misread the > >>

RE: Bring together merge and rebase

On December 25, 2017 6:44 PM Carl Baldwin wrote: > On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote: > > 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 failed to

Re: Bring together merge and rebase

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 failed to mention that in my > > original post. > >

Re: Bring together merge and rebase

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

On Fri, Dec 22, 2017 at 11:10:19PM -0700, Carl Baldwin wrote: > I've been calling this proposal `git replay` or `git replace` but I'd > like to hear other suggestions for what to name it. It works like > rebase except with one very important difference. Instead of orphaning > the original commit,

Re: Bring together merge and rebase

On Dec 24, 2017, at 01:01, 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 failed to mention that in my >> original post. > > And

Re: Bring together merge and rebase

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 failed to mention that in my > original post. And cherry-pick, too, of course. Both of these examples hint at a rather huge urge of

Re: Bring together merge and rebase

etch, push, gc, and others that > > move history around and clean out orphaned history should treat > > anything reachable through `replaces` pointers as precious. Log and > > related history commands may need new switches to traverse the history > > differently in different s

RE: Bring together merge and rebase

On December 23, 2017 4:02 PM, Carl Baldwin wrote: > On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote: > > I think this is a worthwhile thing to implement, there are certainly > > use-cases where you'd like to have your cake & eat it too as it were, > > i.e. have a nice

Re: Bring together merge and rebase

On Sat, Dec 23 2017, Carl Baldwin jotted: > On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote: >> I think this is a worthwhile thing to implement, there are certainly >> use-cases where you'd like to have your cake & eat it too as it were, >> i.e. have a nice rebased

Re: Bring together merge and rebase

On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote: > I think this is a worthwhile thing to implement, there are certainly > use-cases where you'd like to have your cake & eat it too as it were, > i.e. have a nice rebased history in "git log", but also have the "raw" > history

Re: Bring together merge and rebase

one. 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 >

Bring together merge and rebase

. 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