Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Junio C Hamano wrote: > > * rj/mingw-compat-st-mode-bits (2013-05-28) 1 commit > - path: Fix a sparse warning > > Will merge to 'next'. Hmm, this breaks the build on cygwin. :( Now, I always test my patches on Linux, cygwin and MinGW before sending, ... except that I obviously didn't test on cygwin this time - it doesn't even compile. *ahem* The extern declaration for get_st_mode_bits() must come *before* including compat/cygwin.h; otherwise it will get mangled by the macro in that header file. Sorry for breaking the build. A v3 patch is on it's way. (I'm liking the v1 patch more now ;-) ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Junio C Hamano wrote: > Felipe Contreras writes: > > > Junio C Hamano wrote: > >> * fc/makefile (2013-05-26) 5 commits > >> - build: do not install git-remote-testpy > >> - build: add NO_INSTALL variable > >> - build: cleanup using $< > >> - build: cleanup using $^ > >> - build: trivial simplification > >> (this branch is used by fc/remote-helpers-use-specified-python.) > > > > No, these are independent. > > By the way, I dropped the order-only one and I explained my > reasoning for doing so, but I haven't heard back from you. > > As I haven't used the order-only dependencies nor '|' myself so far > (primarily because I have not seen a case where it was needed), it > would have been nice if you responded with either "yes, this is not > order-only and the patch should be dropped", or "no, order-only is > correct because...". I'm not sure, so I think it's OK to drop it. I've used order-only to dependencies that should not be listed when doing $^ which doesn't affect us anyway, so I thought it was more descriptive with the patch, but I can see why it would break the build if that file is updated and the targets that depend on it don't. I don't have time to investigate further, so I think it's OK. > In any case, I think the above remaining five were sensible changes, > and am thinking about having it graduating early in the cycle. If you do that, please add git-remote-testgit.sh to the NO_INSTALL list. I didn't do that at the time because I was working on the master branch, but this changed in 'next'. > I somehow had an impression that the other series depended on this > for SCRIPT_PYTHON_* stuff, but this is about the installation step > and the other one is primarily about the build step, so in that > sense it may be independent. They are completely independent. The improvments to the main Makefile is what I came up while trying to understand the code. > >> * fc/remote-bzr (2013-05-28) 8 commits > >> - remote-bzr: add fallback check for a partial clone > >> - remote-bzr: reorganize the way 'wanted' works > >> - remote-bzr: trivial cleanups > >> - remote-bzr: change global repo > >> - remote-bzr: delay cloning/pulling > >> - remote-bzr: simplify get_remote_branch() > >> - remote-bzr: fix for files with spaces > >> - remote-bzr: recover from failed clones > >> > >> The ones near the tip conflicted with the hotfix for 1.8.3 so I > >> discarded them for now. > >> > >> Will merge to 'next'? > > > > Didn't I resend these with the conflict fixed? > > As the date above (05-28) shows, it seems that I did not forget to > drop the old one to replace with the new one, but I did forget to > remove the stale comment from the previous issue. Thanks for > noticing. Oh, I see. Cool. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Junio C Hamano wrote:
>> Is there something you're not happy with?
>
> By the way, you probably should stop thinking in terms of "me" being
> (un)happy. I am just trying to help by preventing (collectively) us
> making silly mistakes.
As a general principle, okay.
IIRC, nobody else had comments on this one.
>> * publish-rev: the @{push} thing is still in the early poc stages.
>
> I presume this is the one that may someday lay foundations for Tytso's
> "do not rebase beyond this point, as I have published it already"?
Yep. More importantly, I'll get something I've been wanting badly:
the tracking info in the prompt.
>> * for-each-ref-pretty: not ready; working with Duy.
>
> I haven't been paying too much attention to it, but my impression
> was a "superset" syntax is coming? That would be going in the right
> direction.
Yes, a superset with coming with one caveat: %ae will be interpreted
as hex. I hope to send a large'ish series that also strips out the
-v, -vv code. Duy basically did most of the work by coming up with a
brilliant way to inject into the pretty-formats machinery.
>> * pickaxe-doc: you had some more comments in latest iteration, but the
>> returns from a re-roll are diminishing. Frankly, the work is too
>> boring: the first few iterations were interesting, because I was
>> learning;...
>
> Yeah, some parts of the project is boring and that is not a news.
> Think of documentation updates as helping others to learn.
See, the problem is that I might drop the ball on patches like this
(I've done it before, when I thought the change wasn't important
enough for me to bore myself). This is definitely important, and I
will see it to completion. But I'm echoing a more general problem:
If people don't feel like working on it, how will the documentation
improve? And if the pickaxe-doc was in such bad shape, how could
anyone have been using it? Do an internet search and see for
yourself. This feature is _extremely_ useful, and it's a real shame
that it has been so poorly documented for this long.
I'm not advocating a lax review that checks in technically incorrect
documentation; that will confuse users and turn it into a huge
maintenance burden. But we can maybe go down a notch on style?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Ramkumar Ramachandra writes:
>> * rr/die-on-missing-upstream (2013-05-22) 2 commits
>> - sha1_name: fix error message for @{}, @{}
>> - sha1_name: fix error message for @{u}
>>
>> When a reflog notation is used for implicit "current branch", we
>> did not say which branch and worse said "branch ''".
>>
>> Waiting for series of rerolls to settle.
>
> I'm happy with the version in pu, and I don't intend to send any
> re-rolls.
OK, then I'll take a final look at it (I may or may not have
comments after doing so) before merging it down.
> Is there something you're not happy with?
By the way, you probably should stop thinking in terms of "me" being
(un)happy. I am just trying to help by preventing (collectively) us
making silly mistakes.
> * publish-rev: the @{push} thing is still in the early poc stages.
I presume this is the one that may someday lay foundations for Tytso's
"do not rebase beyond this point, as I have published it already"?
> * for-each-ref-pretty: not ready; working with Duy.
I haven't been paying too much attention to it, but my impression
was a "superset" syntax is coming? That would be going in the right
direction.
> * push-current-head: ready but for the commit message: in your
> opinion, it doesn't "fix" anything other than the output. I'll
> rewrite and submit soon.
I do not recall what this one is about, but we'll see when you send
it out.
> * pickaxe-doc: you had some more comments in latest iteration, but the
> returns from a re-roll are diminishing. Frankly, the work is too
> boring: the first few iterations were interesting, because I was
> learning;...
Yeah, some parts of the project is boring and that is not a news.
Think of documentation updates as helping others to learn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Felipe Contreras writes: > Junio C Hamano wrote: >> * fc/makefile (2013-05-26) 5 commits >> - build: do not install git-remote-testpy >> - build: add NO_INSTALL variable >> - build: cleanup using $< >> - build: cleanup using $^ >> - build: trivial simplification >> (this branch is used by fc/remote-helpers-use-specified-python.) > > No, these are independent. By the way, I dropped the order-only one and I explained my reasoning for doing so, but I haven't heard back from you. As I haven't used the order-only dependencies nor '|' myself so far (primarily because I have not seen a case where it was needed), it would have been nice if you responded with either "yes, this is not order-only and the patch should be dropped", or "no, order-only is correct because...". In any case, I think the above remaining five were sensible changes, and am thinking about having it graduating early in the cycle. I somehow had an impression that the other series depended on this for SCRIPT_PYTHON_* stuff, but this is about the installation step and the other one is primarily about the build step, so in that sense it may be independent. >> * fc/remote-bzr (2013-05-28) 8 commits >> - remote-bzr: add fallback check for a partial clone >> - remote-bzr: reorganize the way 'wanted' works >> - remote-bzr: trivial cleanups >> - remote-bzr: change global repo >> - remote-bzr: delay cloning/pulling >> - remote-bzr: simplify get_remote_branch() >> - remote-bzr: fix for files with spaces >> - remote-bzr: recover from failed clones >> >> The ones near the tip conflicted with the hotfix for 1.8.3 so I >> discarded them for now. >> >> Will merge to 'next'? > > Didn't I resend these with the conflict fixed? As the date above (05-28) shows, it seems that I did not forget to drop the old one to replace with the new one, but I did forget to remove the stale comment from the previous issue. Thanks for noticing. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #08; Tue, 28)
Junio C Hamano wrote:
> * rr/rebase-autostash (2013-05-12) 7 commits
> - rebase: implement --[no-]autostash and rebase.autostash
> - rebase --merge: return control to caller, for housekeeping
> - rebase -i: return control to caller, for housekeeping
> - am: return control to caller, for housekeeping
> - rebase: prepare to do generic housekeeping
> - rebase -i: don't error out if $state_dir already exists
> - am: tighten a conditional that checks for $dotest
>
> This is from v3, but after a "Fixed" message in $gmane/224111 we
> haven't seen a reroll yet. Also there was an attempt for a
> follow-up, but it was never completed.
I've sent a tiny fixup for the last part. Let me know if you're
expecting something else.
> * rr/die-on-missing-upstream (2013-05-22) 2 commits
> - sha1_name: fix error message for @{}, @{}
> - sha1_name: fix error message for @{u}
>
> When a reflog notation is used for implicit "current branch", we
> did not say which branch and worse said "branch ''".
>
> Waiting for series of rerolls to settle.
I'm happy with the version in pu, and I don't intend to send any
re-rolls. Is there something you're not happy with?
Quick update from my side:
* publish-rev: the @{push} thing is still in the early poc stages.
* for-each-ref-pretty: not ready; working with Duy.
* push-current-head: ready but for the commit message: in your
opinion, it doesn't "fix" anything other than the output. I'll
rewrite and submit soon.
* pickaxe-doc: you had some more comments in latest iteration, but the
returns from a re-roll are diminishing. Frankly, the work is too
boring: the first few iterations were interesting, because I was
learning; now, it's mostly differences in taste. Nevertheless, I'll
re-roll when I want to sleep next.
That's about it, I think. I've abandoned everything else.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (May 2013, #08; Tue, 28)
Junio C Hamano wrote: > * fc/makefile (2013-05-26) 5 commits > - build: do not install git-remote-testpy > - build: add NO_INSTALL variable > - build: cleanup using $< > - build: cleanup using $^ > - build: trivial simplification > (this branch is used by fc/remote-helpers-use-specified-python.) No, these are independent. > * fc/remote-helpers-use-specified-python (2013-05-28) 4 commits > - remote-helpers: add exec-path links > - remote-helpers: allow direct test execution > - remote-helpers: rename tests > - remote-helpers: generate scripts > (this branch uses fc/makefile.) > > I do not particularly think the second from the bottom is a good > change, but it takes the remainder of the series hostage. > Will hopefully be rerolled without it. > * fc/remote-bzr (2013-05-28) 8 commits > - remote-bzr: add fallback check for a partial clone > - remote-bzr: reorganize the way 'wanted' works > - remote-bzr: trivial cleanups > - remote-bzr: change global repo > - remote-bzr: delay cloning/pulling > - remote-bzr: simplify get_remote_branch() > - remote-bzr: fix for files with spaces > - remote-bzr: recover from failed clones > > The ones near the tip conflicted with the hotfix for 1.8.3 so I > discarded them for now. > > Will merge to 'next'? Didn't I resend these with the conflict fixed? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
