Matt McClure writes:
> On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano 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
>
On Wed, May 22, 2013 at 6:32 AM, Matt McClure 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 central origin repository r
On Fri, May 10, 2013 at 3:34 AM, William Swanson 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 reflogs to the
> p
On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano 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 histories into ac
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:
>>> Johannes Sixt 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
On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:
>>> Johannes Sixt writes:
>>> Imagine that a user runs "git rebase" on a history leading to commit
>>> X to create an alternate, improved history that leads to
On Thu, May 9, 2013 at 11:37 PM, Junio C Hamano 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 is
> tr
Duy Nguyen writes:
> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:
>> Johannes Sixt 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, perhaps
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:
> Johannes Sixt 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, perhaps by default, an
> "ours" mer
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
Johannes Sixt 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
>> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959c
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=0055e0959cd13780494fe33832bae9bcf91e4a9
On Wed, May 8, 2013 at 12:05 PM, Matt McClure wrote:
> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt 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 piece I was missing. I assumed `git gc` di
On Wed, May 8, 2013 at 12:05 PM, Matt McClure wrote:
> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt 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 piece I was missing. I assumed `git gc` di
14 matches
Mail list logo
