Am 04.09.2014 um 00:16 schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> It bugged me enough that we didn't identify which short option
>>> letter we were complaining about
>>
>> The old code did report the short option. E.g. for t1502 it said:
>>
>> error: BUG: switch 'b' short name alr
On Wed, Sep 03, 2014 at 07:19:45PM -0700, Shawn Pearce wrote:
> I would be interested if its 23rd or before. I hop a plane to Germany
> on the 24th. :)
On the 23rd (Thursday), there's a GSoC welcome reception. We could do
something in the afternoon, or something in the evening on Wednesday the
22
On Wed, Sep 3, 2014 at 2:47 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I know you are talking about something potentially much larger than
>> this, but I wanted to note that Michael Haggerty, Ramkumar Ramachandra,
>> and I will all be in the Bay Area for the GSoC Reunion, October 23-26.
>
On Wed, Sep 03, 2014 at 04:14:34PM -0700, Junio C Hamano wrote:
> > The main advantage of the "tag" field is that it is machine-readable,
> > and that your verification process can check that "git verify-tag
> > v2.1.0" actually returns a tag that says "tag v2.1.0". But I do not
> > think we do th
On Thu, Sep 4, 2014 at 11:19 AM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Patches created using gitk's "write commit to file" functionality (which
>> uses 'git diff-tree -p --pretty' under the hood) need some massaging in
>> order to apply cleanly.
>
> Shouldn't that output routine be t
Probably the most notable are ta/config-set-{1,2} series that use
the caching config-set API to update git_config() calls and also
many single-variable peekers. I do not expect too many issues from
the topics merged to 'next' today, but if you found breakages please
holler.
Thanks.
--
To unsubscr
Chris Packham writes:
> Patches created using gitk's "write commit to file" functionality (which
> uses 'git diff-tree -p --pretty' under the hood) need some massaging in
> order to apply cleanly.
Shouldn't that output routine be the one to be corrected, then? We
really do not need yet another
Jeff King writes:
> This is a bit of an aside, but why do we have the "tag" line in the tag
> object in the first place?
http://thread.gmane.org/gmane.linux.kernel/297998/focus=1410
> It is part of the object contents, and therefore is part of the
> signature (which the refname is not). That's
When gitfile is used, git sets GIT_DIR environment variable for
subsequent commands, and that commands start working in mode "GIT_DIR
set, workdir current", which is incorrect for the case when git runs
from subdirectory of repository. This can be observed at least for
running aliases - git fails w
On Sun, Aug 31, 2014 at 03:46:42PM -0700, Junio C Hamano wrote:
> If "git fsck" were a tool to validate that the objects and refs are
> in line with how "git-core" plumbing and Porcelain toolset uses the
> underlying Git data model, it makes sense to insist a tag has a name
> that is suitable for
In check_patch_format we feed $1 to a block that attempts to determine
the patch format. Since we've already redirected $1 to stdin there is no
need to redirect it again when we invoke tr. This prevents the following
errors when invoking git am
$ git am patch.patch
tr: write error: Broken pipe
Patches created using gitk's "write commit to file" functionality (which
uses 'git diff-tree -p --pretty' under the hood) need some massaging in
order to apply cleanly. This consists of dropping the 'commit' line
automatically determining the subject and removing leading whitespace.
Signed-off-by:
I've done some digging into the tr error message. I think the extra
re-direction of stdin is unnecessary. I've removed it and the tests
still pass. The error message I was seeing is no longer seen but I've
found it hard to actually reproduce (even with different sized patches).
I've also updated '
René Scharfe writes:
>> It bugged me enough that we didn't identify which short option
>> letter we were complaining about
>
> The old code did report the short option. E.g. for t1502 it said:
>
> error: BUG: switch 'b' short name already used
>
> You can leave that to optbug(), no need fo
On Wed, Sep 03, 2014 at 02:46:25PM -0700, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > --- a/parse-options.c
> > +++ b/parse-options.c
> > @@ -345,12 +345,27 @@ static void check_typos(const char *arg, const struct
> > option *options)
> > static void parse_options_check(const struct opt
Jeff King writes:
> I know you are talking about something potentially much larger than
> this, but I wanted to note that Michael Haggerty, Ramkumar Ramachandra,
> and I will all be in the Bay Area for the GSoC Reunion, October 23-26.
>
> I do not think we want to have a "real" conference, but I
Am 03.09.2014 um 23:05 schrieb Junio C Hamano:
René Scharfe writes:
Compact and useful, I like it.
You might want to squash in something like this, though. Without it
t1502 fails because -b is defined twice there.
Thanks. I like it to see that the check automatically propagates
even to sc
Junio C Hamano wrote:
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -345,12 +345,27 @@ static void check_typos(const char *arg, const struct
> option *options)
> static void parse_options_check(const struct option *opts)
> {
> int err = 0;
> + char short_opts[128];
> +
> +
On Tue, Sep 02, 2014 at 11:41:11AM -0700, Junio C Hamano wrote:
> > Personally, I think the cover letter is a good place for such things.
>
> Yeah, and I saw it explained in the cover. It looked somewhat out
> of place to see it duplicated only for this patch in the 6 patch
> series and I was wo
Christian Couder writes:
> '=' is always accepted as separator when parsing
> "--trailer ''" command line arguments, for
> compatibility with other git commands
Hmph. Which of other commands take "--option foo=bar"?
Puzzled...
--
To unsubscribe from this list: send the line "unsubscribe
On 09/03/2014 11:09 PM, Jeff King wrote:
> Reply-To:
> In-Reply-To:
>
>
> On Tue, Sep 02, 2014 at 08:21:37AM +0200, Christian Couder wrote:
>
>> It looks like there will be no Git conference or Git developer meeting
>> this year.
>
> I know you are talking about something potentially much lar
On 03.09.2014 23:09, Jeff King wrote:
> Reply-To:
> In-Reply-To:
>
>
> On Tue, Sep 02, 2014 at 08:21:37AM +0200, Christian Couder wrote:
>
>> It looks like there will be no Git conference or Git developer meeting
>> this year.
>
> I know you are talking about something potentially much larger
Reply-To:
In-Reply-To:
On Tue, Sep 02, 2014 at 08:21:37AM +0200, Christian Couder wrote:
> It looks like there will be no Git conference or Git developer meeting
> this year.
I know you are talking about something potentially much larger than
this, but I wanted to note that Michael Haggerty,
René Scharfe writes:
> Compact and useful, I like it.
>
> You might want to squash in something like this, though. Without it
> t1502 fails because -b is defined twice there.
Thanks. I like it to see that the check automatically propagates
even to scripts ;-)
It bugged me enough that we didn'
On Wed, Sep 03, 2014 at 10:15:15AM -0700, Shawn Pearce wrote:
> I hadn't realized Git is turning 10 next year. Just been too busy
> using Git to pay attention to its upcoming anniversary. Let me talk to
> some folks at Google and see if we can organize something here in
> Mountain View, or help th
Junio C Hamano writes:
>> +ifndef NO_CLOCK_GETTIME
>> ifdef HAVE_CLOCK_GETTIME
>> BASIC_CFLAGS += -DHAVE_CLOCK_GETTIME
>> EXTLIBS += -lrt
>> endif
>> +endif
>
> I am not sure why you even need this change. Wouldn't you get
> exactly the same result if you did not define HAVE_CLOCK_GE
Am 03.09.2014 um 21:42 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>>> diff --git a/builtin/revert.c b/builtin/revert.c
>>> index f9ed5bd..831c2cd 100644
>>> --- a/builtin/revert.c
>>> +++ b/builtin/revert.c
>>> @@ -91,6 +91,7 @@ static void parse_args(int argc, const char **argv,
>>> str
Reuben Hawkins writes:
> Some really old platforms, rhel3, which don't define CLOCK_MONOTONIC, still
> need a way to build git. Some high resolution timer code was added Jul 12,
> 2014 to aid debugging performance issues. That code uses clock_gettime and
> CLOCK_MONOTONIC. That change breaks b
Junio C Hamano writes:
>> diff --git a/builtin/revert.c b/builtin/revert.c
>> index f9ed5bd..831c2cd 100644
>> --- a/builtin/revert.c
>> +++ b/builtin/revert.c
>> @@ -91,6 +91,7 @@ static void parse_args(int argc, const char **argv, struct
>> replay_opts *opts)
>> N_("option
Johan Herland writes:
> Allow users to temporarily disable the pre-commit and commit-msg hooks
> when running "git revert" or "git cherry-pick", just like they currently
> can for "git commit".
>
> The --no-verify option is added to the sequencer machinery and handled
> like the other commit-rela
On Wed, 2014-09-03 at 12:18 -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > But IMHO, this topic goes in a wrong direction. "Avoid deprecated
> > interfaces" is way overrated. It would be preferable (IMHO) to implement
> > setitimer() in compat/ for systems that don't have it.
>
> I t
Johan Herland writes:
> The revert/cherry-pick machinery currently exercises the pre-commit
> and commit-msg hooks. However, where commit accepts a --no-verify
> option to temporarily disable these hooks, the revert and cherry-pick
> commands have no such option.
>
> This patch adds some testcase
Johan Herland writes:
> A colleague of mine noticed that cherry-pick does not accept the
> --no-verify option to skip running the pre-commit/commit-msg hooks.
>
> Here's a first attempt at adding --no-verify to the revert/cherry-pick.
Back when cherry-pick was a single commit operation, lack of
Johannes Sixt writes:
> But IMHO, this topic goes in a wrong direction. "Avoid deprecated
> interfaces" is way overrated. It would be preferable (IMHO) to implement
> setitimer() in compat/ for systems that don't have it.
I think I agree.
Adding compat/setitimer.c that implements git_setitimer(
Some really old platforms, rhel3, which don't define CLOCK_MONOTONIC, still
need a way to build git. Some high resolution timer code was added Jul 12,
2014 to aid debugging performance issues. That code uses clock_gettime and
CLOCK_MONOTONIC. That change breaks building git on ancient platforms
On 2014-09-03 08.27, Johannes Sixt wrote:
> Am 03.09.2014 00:06, schrieb Junio C Hamano:
>> * jt/timer-settime (2014-08-29) 9 commits
>> - use timer_settime() for new platforms
>> - autoconf: check for timer_settime()
>> - autoconf: check for struct itimerspec
>> - autoconf: check for struct si
We are currently investigating whether to move from RTC (source control) to GIT
and wanted to find out if there is more information available than what we have
found in
http://stackoverflow.com/questions/23928927/how-to-migrate-from-rtc-jazz-to-git
We really need to preserve the version history
On 2014-09-02 22.49, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> Should this be marked with "From: Brice Lambson "?
>>>
>>> Thanks.
>> Yes. If possible please squeeze.
>
> OK, thanks. Please double check the result on 'pu' in several
> hours.
Excellent
t0027 and t0026 passed und
On Wed, Sep 3, 2014 at 1:53 AM, Christian Couder
wrote:
> On Tue, Sep 2, 2014 at 3:51 PM, Theodore Ts'o wrote:
>> On Tue, Sep 02, 2014 at 07:21:17AM -0400, Theodore Ts'o wrote:
>>> On Tue, Sep 02, 2014 at 08:20:42AM +0100, Luca Milanesio wrote:
>>> > Hi Chris,
>>> > Seattle is a very inconvenient
On Tue, Sep 02, 2014 at 09:59:17AM -0700, Junio C Hamano wrote:
>
> I would rather see "rev-parse --all" not to include HEAD,
> especially if it has been documented that way.
Ok, then probably I'll want to change it in gitk.
But, with the "multiple working trees" feature, I would also
want to ge
HEAD is not explicitly used as a starting commit for
calculating reachability, so if it's detached and reflogs
are disabled it may be pruned.
Add tests which demonstrate it. Test 'prune: prune former HEAD after checking
out branch' also reverts changes to repository.
Signed-off-by: Max Kirillov
Signed-off-by: Thomas Braun
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 06bf262..5ea5b82 100644
--- a/contrib/completion/git-completion.bas
A colleague of mine noticed that cherry-pick does not accept the
--no-verify option to skip running the pre-commit/commit-msg hooks.
Here's a first attempt at adding --no-verify to the revert/cherry-pick.
Have fun! :)
...Johan
Johan Herland (3):
t7503/4: Add failing testcases for revert/cherr
The revert/cherry-pick machinery currently exercises the pre-commit
and commit-msg hooks. However, where commit accepts a --no-verify
option to temporarily disable these hooks, the revert and cherry-pick
commands have no such option.
This patch adds some testcases demonstrating how the --no-verify
Allow users to temporarily disable the pre-commit and commit-msg hooks
when running "git revert" or "git cherry-pick", just like they currently
can for "git commit".
The --no-verify option is added to the sequencer machinery and handled
like the other commit-related options.
This fixes the failin
Add --no-verify to the revert and cherry-pick man pages. Also mention
revert and cherry-pick in the corresponding documentation for the
pre-commit and commit-msg hooks.
Signed-off-by: Johan Herland
---
Documentation/git-cherry-pick.txt | 4
Documentation/git-revert.txt | 4
Docu
Hello,
I just finished building and installing git on my Android device.
After testing, I'd like to build it in such a way that I can tarball
and upload/send it. Are there any make targets that would allow me to
do that or do I need to rebuild with the NO_CROSS_DIRECTORY_HARDLINKS
option and insta
On Tue, Sep 2, 2014 at 6:39 PM, Junio C Hamano wrote:
> We punt from repairing the cache-tree during a branch switching if
> it involves having to create a new tree object that does not yet
> exist in the object store. "mkdir dir && >dir/file && git add dir"
> followed by "git checkout" is one ex
On Wed, Sep 3, 2014 at 9:35 PM, Chris Packham wrote:
> Hi List,
>
> When I first tried to apply a patch someone gave me I got the following
> errors.
>
> $ git am patch.patch
> tr: write error: Broken pipe
> tr: write error
> Patch format detection failed.
I can't do this with every patch
Reviewing my own code.
On Wed, Sep 3, 2014 at 9:35 PM, Chris Packham wrote:
> Patches created using gitk's "write commit to file" functionality (which
> uses 'git diff-tree -p --pretty' under the hood) need some massaging in
> order to apply cleanly. This consists of dropping the 'commit' line
>
Patches created using gitk's "write commit to file" functionality (which
uses 'git diff-tree -p --pretty' under the hood) need some massaging in
order to apply cleanly. This consists of dropping the 'commit' line
automatically determining the subject and removing leading whitespace.
Signed-off-by:
Hi List,
When I first tried to apply a patch someone gave me I got the following
errors.
$ git am patch.patch
tr: write error: Broken pipe
tr: write error
Patch format detection failed.
The patch itself was generated from gitk and while I'd seen the format
detection problem before but th
On Tue, Sep 2, 2014 at 3:51 PM, Theodore Ts'o wrote:
> On Tue, Sep 02, 2014 at 07:21:17AM -0400, Theodore Ts'o wrote:
>> On Tue, Sep 02, 2014 at 08:20:42AM +0100, Luca Milanesio wrote:
>> > Hi Chris,
>> > Seattle is a very inconvenient location for most of the people
>> > coming from Europe: somew
Hi Michael:
> On 08/04/2014 03:13 AM, Duy Nguyen wrote:
>
>> On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen <[hidden email]>
>> wrote:
>> [...]
>>> My first impression reading this patch was to rename
>>> clear_filename() into free_and_clear_filename() or better
>>> free_filename(),
>>>
54 matches
Mail list logo