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
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
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.
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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.
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
. 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
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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO
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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
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
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
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
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
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
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
.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
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
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
33 matches
Mail list logo