On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
I think what I missed is that the same logic to ignore side branches
whose history gets cauterised with such an ours merge may apply to
an ours merge that people already make, but the latter may want to
take both
On Fri, May 10, 2013 at 3:34 AM, William Swanson swanson...@gmail.com wrote:
I started working on something like this a few weeks ago, but
eventually came to the conclusion that this information does not
belong in the commit graph itself.
A better approach, I think, would be to enhance the
On Wed, May 22, 2013 at 6:32 AM, Matt McClure matthewlmccl...@gmail.com wrote:
Is there a way to push/pull reflogs among different repositories?
Not that I am aware of, at least not in core git.
In my original scenario:
1. the commits are created on a developer machine
2. pushed to a
Matt McClure matthewlmccl...@gmail.com writes:
On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
I think what I missed is that the same logic to ignore side branches
whose history gets cauterised with such an ours merge may apply to
an ours merge that people already
Am 5/8/2013 18:16, schrieb Matt McClure:
That begs a follow-up question. It sounds as though Git will typically
delete unreachable objects. My team often shares links like
https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90
Johannes Sixt j.s...@viscovery.net writes:
Am 5/8/2013 18:16, schrieb Matt McClure:
That begs a follow-up question. It sounds as though Git will typically
delete unreachable objects. My team often shares links like
Am 5/10/2013 8:37, schrieb Junio C Hamano:
What if we teach git rebase to record, perhaps by default, an
ours merge on top of Y that takes the tree state of Y but has X as
its second parent, ...
Please let's not go that route...
-- Hannes
--
To unsubscribe from this list: send the line
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net writes:
Imagine that a user runs git rebase on a history leading to commit
X to create an alternate, improved history that leads to commit Y.
What if we teach git rebase to record,
Duy Nguyen pclo...@gmail.com writes:
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net writes:
Imagine that a user runs git rebase on a history leading to commit
X to create an alternate, improved history that leads to commit Y.
What
On Thu, May 9, 2013 at 11:37 PM, Junio C Hamano gits...@pobox.com wrote:
What's a good strategy for avoiding breaking those links?
Do not rebase published history.
All true, but I think we could do a bit better, although I am
still on the fence if what I am going to suggest in this message
On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net writes:
Imagine that a user runs git rebase on a history leading to commit
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net writes:
Imagine that a user runs git rebase on a history leading to commit
X to create an alternate,
On Wed, May 8, 2013 at 12:05 PM, Matt McClure matthewlmccl...@gmail.com wrote:
On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt j.s...@viscovery.net wrote:
git gc moves unreachable objects that were packed before to the loose
object store, from where they can be pruned.
Thanks. That was the
On Wed, May 8, 2013 at 12:05 PM, Matt McClure matthewlmccl...@gmail.com wrote:
On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt j.s...@viscovery.net wrote:
git gc moves unreachable objects that were packed before to the loose
object store, from where they can be pruned.
Thanks. That was the
14 matches
Mail list logo
