Theodore Ts'o writes:
> Spekaing of which, what I'd really appreciate is timestamps associated
> with the reflog. That's because the most common time when I've
> screwed something up is after doing a "git rebase -i" and so the
> reflog has a *huge* number of entries on it, and figuring out which
Theodore Ts'o wrote:
> Spekaing of which, what I'd really appreciate is timestamps associated
> with the reflog. That's because the most common time when I've
> screwed something up is after doing a "git rebase -i" and so the
> reflog has a *huge* number of entries on it, and figuring out which
>
Theodore Ts'o writes:
> On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
>> But in a triangular workflow, the way to make the result reach the
>> "upstream" is *not* by pushing there yourself. For developers at
>> the leaf level, it is to push to their own repository (often on
>>
On Thu, May 23, 2013 at 03:22:50PM +0530, Ramkumar Ramachandra wrote:
> Theodore Ts'o wrote:
> > Right now I do this just by being careful, but if there was an
> > automatic safety mechanism, it would save me a bit of work, since
> > otherwise I might not catch my mistake until I do the "git push
>
Theodore Ts'o wrote:
> Right now I do this just by being careful, but if there was an
> automatic safety mechanism, it would save me a bit of work, since
> otherwise I might not catch my mistake until I do the "git push
> publish", at which point I curse and then start consulting the reflog
> to ba
On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
> But in a triangular workflow, the way to make the result reach the
> "upstream" is *not* by pushing there yourself. For developers at
> the leaf level, it is to push to their own repository (often on
> GitHub), which is different fr
Theodore Ts'o writes:
> On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
>> Theodore Ts'o writes:
>>
>> > I was actually thinking that it might be interesting to have a
>> > branch..rewindable, which would change the guilt defaults, and
>> > could also key changes in key git beha
On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
> Theodore Ts'o writes:
>
> > I was actually thinking that it might be interesting to have a
> > branch..rewindable, which would change the guilt defaults, and
> > could also key changes in key git behavior which makes it less likely
Theodore Ts'o writes:
> I was actually thinking that it might be interesting to have a
> branch..rewindable, which would change the guilt defaults, and
> could also key changes in key git behavior which makes it less likely
> that a user shoots him or herself in the foot --- i.e., give warnings
>
On Wed, May 22, 2013 at 10:45:31AM -0400, Theodore Ts'o wrote:
> I just had another idea (although I haven't had a chance to code up
> anything yet). Perhaps instead of, or in addition to, a global
> setting (i.e., guilt.reusebranch), perhaps we should have a per-branch
> setting, such as branch..
I just had another idea (although I haven't had a chance to code up
anything yet). Perhaps instead of, or in addition to, a global
setting (i.e., guilt.reusebranch), perhaps we should have a per-branch
setting, such as branch..guiltReuseBranch?
I was actually thinking that it might be interesting
On Wed, May 22, 2013 at 03:01:36PM +0200, Per Cederqvist wrote:
> When the option is true (the default), Guilt does not create a new Git
> branch when patches are applied. This way, you can switch between
> Guilt 0.35 and the current version of Guilt with no issues.
>
> At a future time, maybe a
When the option is true (the default), Guilt does not create a new Git
branch when patches are applied. This way, you can switch between
Guilt 0.35 and the current version of Guilt with no issues.
At a future time, maybe a year after Guilt with guilt.reusebranch
support is released, the default s
13 matches
Mail list logo
