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

On Fri, Dec 22, 2017 at 11:10:19PM -0700, Carl Baldwin wrote: > The big contention among git users is whether to rebase or to merge > changes [2][3] while iterating. I used to firmly believe that merging > was the way to go and rebase was harmful. More recently, I have worked > in some

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

Hi Ævar, On Sat, 23 Dec 2017, Ævar Arnfjörð Bjarmason wrote: > On Sat, Dec 23 2017, Carl Baldwin jotted: > > > The big contention among git users is whether to rebase or to merge > > changes [2][3] while iterating. I used to firmly believe that merging > > was the way to go and rebase was

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

On Sat, Dec 23 2017, Carl Baldwin jotted: > The big contention among git users is whether to rebase or to merge > changes [2][3] while iterating. I used to firmly believe that merging > was the way to go and rebase was harmful. More recently, I have worked > in some environments where I saw