situations. 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 contention. Than
out how to use it in a way
that gives me what I'm after.
> You could even add a new field to the commit object of A2+B2 & C2 which
> would be one or more of "replaces ", commit objects
> support adding arbitrary new fields without anything breaking.
>
> But
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. mer
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
se that's not the case.
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 151405722
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
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,
> &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 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
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: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
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 c
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 actually
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 foll
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: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:
> &g
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
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 and
> > sometimes discu
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 th
local head is actually quite strong and should 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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
where it is
absolutely necessary 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
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Sat, Aug 13, 2005 at 12:41:45PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 13 Aug 2005, Carl Baldwin wrote:
> >
> > The bottom line is that I don't really see many situations where it is
> > absolutely necessary but it is a convenience. Not supporting it
on should
be stored to maintain compatibility between porcelains while (hopefully)
allowing for some degree of flexibility. I don't yet know where this
line should be drawn.
Carl
On Sat, Aug 13, 2005 at 12:48:32AM -0700, Junio C Hamano wrote:
> Carl Baldwin <[EMAIL PROTECTED]> wr
think it is important, though, to specify how this information should
be stored to maintain compatibility between porcelains while (hopefully)
allowing for some degree of flexibility. I don't yet know where this
line should be drawn.
Carl
--
- - - - - - - - - - - - - - - - - -
On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Carl Baldwin wrote:
>
> > Somewhere in the thread something was mentioned about maintaining
> > : pairs in the git repository when pushes
> > and pulls are perfor
t; the local "pu" branch. This is a one-shot override, so next
> time around, "git push ko" will do the usual three heads that is
> recorded in the .git/remotes/ko file.
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystem
ing 'bad' has been done outside of
that porcelain.
I hope I'm being clear. Please let me know if something is not clear.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Compa
t; More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAI
ed I attached the full post-update hook script that I
actually use to do this. Again, comments are welcome.
Thanks,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88
On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > Hello,
> >
> > I recently started using git to revision control the source for my
> > web-page. I wrote a post-update hook to checkout the file
On Tue, Aug 23, 2005 at 05:27:12PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> > >
> > > > Hello,
>
d new commit name, so you
> should be able to do (untested):
>
> git-read-tree -m -u $old_commit $new_commit
>
> there, of course after making sure that you had old_commit (the
> first time push happens to a new ref you would not have that one).
>
--
- - - -
ld still work assuming no
conflicts emerge.
Attached are the two scripts. Comments and criticism are welcome.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88
2005 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
>
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 thin
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 M
aniel Barkalow wrote:
> On Wed, 24 Aug 2005, Carl Baldwin wrote:
>
> > This brings up a good point (indirectly). "git prune" would destroy the
> > undo objects. I had thought of this but decided to ignore it for the
> > time being.
>
> If you made undo store t
;
> - When running "redo", you would want a handy way to name
>what to redo. You can say "undo-redo~N" to mean "Nth
>from the top of undo-redo branch.
>
>Your implementation of "redo" can eit
g
>the new feature should go to Documentation/howto/ directory.
>
> - Documentation. Files Documentation/git-*.txt to describe
>new commands or updates to existing pages, new entry in
>Documentation/Makefile as necessary, and a new link from
>Documentation/git.txt to
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:
>
> > 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 a
the needed information to
> pull this off.
>
> I would think this would be generally useful outside of the
> context of "undo/redo" also.
>
> Kirby
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin
With only a handful of
> > > commands.
> >
> > I can simulate git manually too with just a few more commands. Where's
> > the cutoff?
This analogy *was* a bit extreme.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Ba
.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl BaldwinSystems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
F
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 co
44 matches
Mail list logo
