I dreamed a dream that I would never have to think about git-cvsimport
again. And yet. Somebody reported[1] that the link to cvsps in
gitcvs-migration is broken. While fixing it, I noticed a few other
out-of-date items. I haven't used any of these tools myself in years,
but hopefully these changes
parsecvs maintenance was taken over by ESR, and the name
changed to cvs-fast-export as it learned to support that
output format. Let's point to cvs-fast-export, as it should
have additional bug-fixes and be more convenient to use.
Signed-off-by: Jeff King
---
No opinion on how this compares to cv
The old page gives a 404 now. Searching for "cvsps" via
Google returns a GitHub project page as the top hit.
Reported-by: Dan Pritts
Signed-off-by: Jeff King
---
Documentation/gitcvs-migration.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitcvs-migration.
Back when this guide was written, cvsimport was the only
game in town. These days it is probably not the best option.
Rather than go into details, let's point people to the note
at the top of cvsimport which gives other options.
Signed-off-by: Jeff King
---
Documentation/gitcvs-migration.txt | 4
> On 21 Sep 2016, at 18:42, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote:
>>>
>>> In the Subject: s/the //
>>>
>>> Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com:
From: Lars Schneider
The Tr
Sorry for my late reply. Thanks for your support -- I really appreciate that.
@Jeff: Unfortunately, I do not know how to implement the patch you provided.
Can you explain how to do that?
Thanks and best regards,
Jonas
> Gesendet: Mittwoch, 21. September 2016 um 10:48 Uhr
> Von: "Jeff King"
>
On Thu, Sep 22, 2016 at 1:44 AM, Junio C Hamano wrote:
>> @@ -314,6 +315,8 @@ static void create_object_directory(void)
>> int set_git_dir_init(const char *git_dir, const char *real_git_dir,
>>int exist_ok)
>> {
>> + original_git_dir = xstrdup(real_path(git_dir));
>> +
>>
Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
> Junio C Hamano wrote:
> |Steffen Nurpmeso writes:
> ...
> |Sorry, but I did not notice that there was an attached patch when I
> |was reading your response for the first time. Risk of using an
> |attachment to e-mail ;-)
> |
> |I th
I am having problems cloning a 2.1GB repo from googlesource
C:\Users\Aaron Gray\GitHub>git clone
https://chromium.googlesource.com/chromium/chromium
Cloning into 'chromium'...
remote: Sending approximately 2.11 GiB ...
error: fatal: The remote end hung up unexpectedly MiB | 2.74 MiB/s
fatal: RPC f
Hello,
Michael J Gruber wrote:
|Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
|> Junio C Hamano wrote:
|>|Steffen Nurpmeso writes:
...
|>|I think this issue does not need a separate bullet point. The
|>|existing text says:
|> ..
|>|and what caused your surprise is already cov
Jeff King :
> Back when this guide was written, cvsimport was the only
> game in town. These days it is probably not the best option.
It is absolutely not. As I have tried to point out here before, it
is *severely* broken in its processing of branchy CVS repositories.
Nobody wanted to hear that,
I have the following .gitignore file in patch arm/arm64/boot/dts:
*.dtb
qcom
qcom.orig
When I do a git status, I see this:
modified: .gitignore
modified: qcom/Makefile
All of the other files in arm/arm64/boot/dts/qcom are being ignored,
as request. However, the file "Makefile" is n
On Wed, Sep 21, 2016 at 10:24 PM, Jeff King wrote:
> When cloning with "--recursive", we'd generally expect
> submodules to show progress reports if the main clone did,
> too.
>
> In older versions of git, this mostly worked out of the
> box. Since we show progress by default when stderr is a tty,
On Thu, Sep 22, 2016 at 09:19:22AM -0500, Timur Tabi wrote:
> I have the following .gitignore file in patch arm/arm64/boot/dts:
>
> *.dtb
> qcom
> qcom.orig
>
> When I do a git status, I see this:
>
> modified: .gitignore
> modified: qcom/Makefile
>
> All of the other files in arm/a
On Thu, Sep 22, 2016 at 2:23 AM, Jonas Thiel wrote:
> Sorry for my late reply. Thanks for your support -- I really appreciate that.
>
> @Jeff: Unfortunately, I do not know how to implement the patch you provided.
> Can you explain how to do that?
I think this should do:
git clone https://g
On Wed, Sep 21, 2016 at 9:18 PM, Jeff King wrote:
> On Wed, Sep 21, 2016 at 04:13:22PM -0700, Junio C Hamano wrote:
>
>> Brandon Williams writes:
>>
>> > yes you mentioned this and I meant to change that before sending it out.
>> > Looks like it slipped through have slipped through.
>>
>> I alrea
Add a static initializer for struct checkout and use it throughout the
code base. It's shorter, avoids a memset(3) call and makes sure the
base_dir member is initialized to a valid (empty) string.
Signed-off-by: Rene Scharfe
---
apply.c | 4 +---
builtin/checkout-index.c | 2 +-
Signed-off-by: Ramsay Jones
---
Hi Lars,
If you need to re-roll your 'ls/filter-process' branch, could you please
squash this into the relevant commit c42a4cbc ("run-command: move check_pipe()
from write_or_die to run_command", 20-09-2016).
[Note that commit 9658846c ("write_or_die: handle EPI
Jeff King writes:
> I don't think it is a bad move overall. I use "pager.log" to pipe
> through a specific command (that is different than I would use for other
> commands).
>
> So I like the idea of configurability; the problem is just that it is
> happening at the wrong level.
The level at whi
Duy Nguyen writes:
>> Perhaps a comment before init_db() to tell callers to always call
>> the other one is the least thing necessary?
>
> Good thinking. We could go a step further, baking it as assert() to
> catch new/incorrect call sequences automatically.
>
> Or we could combine the two functi
Jeff King writes:
> Should this option just be "--prefix", or maybe "--output-prefix"?
> Submodules are the obvious use case here, but I could see somebody
> adapting this for other uses (alternatively, if we _do_ want to keep it
> just as an implementation detail for submodules, we should probab
Jeff King writes:
> So I wanted to know whether there were any code paths that failed to do
> so, and just blindly rely on the lazy-open. Finding the races is
> inherently hard, because you only catch them when somebody else is doing
> a repack. But if we just _remove_ the lazy-load, then it beco
Kevin Daudt writes:
> Often people advise tricks like `git update-index --assume-unchanges
> `, but this does not work as expected. It's merely a promise to
> git that this file does not change (and hence, git will not check if
> this file has changed when doing git status), but command that try
This is regarding the packfile negotiation in fetch-pack. If there is a
concern that MAX_IN_VAIN would be hit too early (as a consequence of the
patch below), I'm currently investigating the possibility of improving
the negotiation ability of the client side further (for example, by
prioritizing re
The MAX_IN_VAIN mechanism was introduced in commit f061e5f ("fetch-pack:
give up after getting too many "ack continue"", 2006-05-24) to stop ref
negotiation if a number of consecutive "have"s have been sent with no
corresponding new acks. A use case (as described in that commit) is the
scenario in
Hi Junio,
On Wed, 21 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > ...
> > Happily, there is an extension to regexec() introduced by the NetBSD
> > project and present in all major regex implementation including
> > Linux', MacOSX' and the one Git includes in compat/regex/
Junio C Hamano wrote:
It actually is even worse. As the user promised Git that the
will not be modified and will be kept the same as the version in the
index, Git reserves the right to_overwrite_ it with the version in
the index anytime when it is convenient to do so, removing whatever
local c
> Hello, maybe right place this time...
>
>
> I want to report a bug:
>
> On MacOS Sierra git gui crashes randomly with this message:
>
> 2016-09-22 13:17:36.759 Wish[23615:1501726] *** Terminating app due to
> uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position
> contains
From: Santiago Torres
Hello everyone,
This is a followup on [1]. There we discussed what would be the best way
to provide automated scripts with mechanisms to inspect the contents of
a tag upon verification.
We struggled a little bit with how to make this fit the current git
codebase in the bes
From: Lukas P
Adding --format to git tag -v mutes the default output of the GPG
verification and instead prints the formatted tag object.
This allows callers to cross-check the tagname from refs/tags with
the tagname from the tag object header upon GPG verification.
Signed-off-by: Lukas Puehrin
From: Lukas P
Ref-filter functions are useful for printing git object information
without a format specifier. However, some functions may not want to use
a complete ref-array, and just a single item instead. Expose
create/show/free functions for ref_array_items through wrappers around
the origina
From: Lukas P
Calling functions for gpg_verify_tag() may desire to print relevant
information about the header for further verification. Add an optional
format argument to print any desired information after GPG verification.
Signed-off-by: Lukas Puehringer
---
builtin/tag.c| 2 +-
bu
From: Santiago Torres
The format specifier will be likely used in other functions throughout
git tag. One likely candidate to require format strings in the future is
the gpg_verify_tag function. However, changing the signature of
functions such as for_each_ref or verify_tag would be quite burdens
From: Lukas P
Functions that print git object information may require that the
gpg-interface functions be silent. Add a GPG_VERIFY_QUIET to prevent
functions such as `print_signature_buffer` from printing any output and
only return whether signature verification passed or not.
Signed-off-by: Luk
From: Santiago Torres
Callers of verify-tag may want to cross-check the tagname from refs/tags
with the tagname from the tag object header upon GPG verification. This
is to avoid tag refs that point to an incorrect object.
Add a --format parameter to git verify-tag to print the formatted tag
obj
On Thu, Sep 22, 2016 at 11:53 AM, wrote:
>
> P.S. Gmane seems to be broken for git after it was rebooted. Should we ping
> them about it?
I think most of the git developers have moved on and reference emails by
message id. An archive of all messages of the mailing list is found at
public-i
Hi All,
is there a good reason why
git fetch -vpnf
works like
git fetch -v -p -n -f
and
git commit -avem msg
works like
git commit -a -v -e -m msg
etc etc, but
git log -wWp
says
fatal: unrecognized argument: -wWp
?
--
Mit freun
Timur Tabi writes:
> So .gitignore only ignores new files, not modified ones?
It is determines if an untracked file should be considered by "git
add" to add it or ignore it.
Jonathan Tan writes:
> This is regarding the packfile negotiation in fetch-pack. If there is a
> concern that MAX_IN_VAIN would be hit too early (as a consequence of the
> patch below), I'm currently investigating the possibility of improving
> the negotiation ability of the client side further (
Hi Stefan,
this section was added to the manual in the commit
cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder"
6 years ago. Maybe he remembers better?
--
Mit freundlichen Grüßen,
Anatoly Borodin
On Thu, Sep 22, 2016 at 07:33:11PM +, Anatoly Borodin wrote:
> Hi Stefan,
>
> this section was added to the manual in the commit
> cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder"
> 6 years ago. Maybe he remembers better?
>
Just to make it clear, this section explicitly talks a
Jonathan Tan writes:
> The MAX_IN_VAIN mechanism was introduced in commit f061e5f ("fetch-pack:
> give up after getting too many "ack continue"", 2006-05-24) to stop ref
> negotiation if a number of consecutive "have"s have been sent with no
> corresponding new acks. A use case (as described in t
santi...@nyu.edu writes:
> From: Santiago Torres
>
> The format specifier will be likely used in other functions throughout
> git tag. One likely candidate to require format strings in the future is
> the gpg_verify_tag function. However, changing the signature of
> functions such as for_each_ref
santi...@nyu.edu writes:
> diff --git a/gpg-interface.c b/gpg-interface.c
> index 8672eda..b82bc50 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -88,6 +88,9 @@ int check_signature(const char *payload, size_t plen, const
> char *signature,
>
> void print_signature_buffer(const str
On Thu, Sep 22, 2016 at 12:54:57PM +0100, Aaron Gray wrote:
> I am having problems cloning a 2.1GB repo from googlesource
>
> C:\Users\Aaron Gray\GitHub>git clone
> https://chromium.googlesource.com/chromium/chromium
> Cloning into 'chromium'...
> remote: Sending approximately 2.11 GiB ...
> error
santi...@nyu.edu writes:
> From: Lukas P
Please match this with S-o-b: below.
>
> Functions that print git object information may require that the
> gpg-interface functions be silent. Add a GPG_VERIFY_QUIET to prevent
> functions such as `print_signature_buffer` from printing any output and
> o
santi...@nyu.edu writes:
> From: Lukas P
>
> Ref-filter functions are useful for printing git object information
> without a format specifier. However, some functions may not want to use
> a complete ref-array, and just a single item instead. Expose
> create/show/free functions for ref_array_item
On Thu, Sep 22, 2016 at 12:48 PM, Kevin Daudt wrote:
> On Thu, Sep 22, 2016 at 07:33:11PM +, Anatoly Borodin wrote:
>> Hi Stefan,
>>
>> this section was added to the manual in the commit
>> cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder"
>> 6 years ago. Maybe he remembers better
santi...@nyu.edu writes:
> Calling functions for gpg_verify_tag() may desire to print relevant
> information about the header for further verification. Add an optional
> format argument to print any desired information after GPG verification.
> diff --git a/builtin/tag.c b/builtin/tag.c
> index d
On 09/21, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > But I came to a different conclusion as I said in a message that
> > crossed yours. I hope Thomas can pick up the baton again.
Sorry for not getting back earlier, my git time is quite limited
unfortunately.
> Yeah, our mails crossed,
Hi Stefan,
I've also done some archaeology and found that the original version of
the merge preserving code was written by Johannes Schindelin
, see e.g.
f09c9b8c5ff9d8a15499b09ccd6c3e7b3c76af77
There were also some big discussion threads in 2007-2008 regarding a
better mechanism to "mark" or "ta
Hi Kevin,
Kevin Daudt wrote:
> Changing the order, or dropping commits might then give unexpected
> results.
The question that Stefan has is rather "what is *supposed* to work /
give *expected* results?". Some stuff can be found in the tests
(t/t*rebase*preserve*), but maybe there is more?
--
On Thu, Sep 22, 2016 at 2:01 PM, Anatoly Borodin
wrote:
> Hi Stefan,
>
> I've also done some archaeology and found that the original version of
> the merge preserving code was written by Johannes Schindelin
> , see e.g.
I think it would be helpful if you'd cc those folks involved, not just
the ma
santi...@nyu.edu writes:
> From: Santiago Torres
>
> Callers of verify-tag may want to cross-check the tagname from refs/tags
> with the tagname from the tag object header upon GPG verification. This
> is to avoid tag refs that point to an incorrect object.
>
> Add a --format parameter to git ver
santi...@nyu.edu writes:
> @@ -425,8 +431,11 @@ int cmd_tag(int argc, const char **argv, const char
> *prefix)
> die(_("--merged and --no-merged option are only allowed with
> -l"));
> if (cmdmode == 'd')
> return for_each_tag_name(argv, delete_tag);
> - if
Jeff King writes:
> On Wed, Sep 21, 2016 at 07:45:50PM +0200, Kevin Daudt wrote:
>
>> On Wed, Sep 21, 2016 at 10:36:57AM -0700, Junio C Hamano wrote:
>> > Kevin Daudt writes:
>> >
>> > > On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote:
>> > >>
>> > >> * kd/mailinfo-quoted-string
Jeff King writes:
> On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote:
>
>> + ...
>> +while ((c = *in++) != 0) {
>> +if (take_next_literally) {
>> +take_next_literally = 0;
>> +} else {
>> [...]
>> +}
>> +
>> +strbu
W dniu 22.09.2016 o 00:18, Ian Kelling napisał:
> The highlight binary can detect language by shebang when we can't tell
> the syntax type by the name of the file. In that case, pass the blob
> to "highlight --force" and the resulting html will have markup for
> highlighting if the language was de
Hi,
please, what should I do to fix this error? thanks
Luko ~ $ git init
error: malformed value for push.default: aguas
error: Must be one of nothing, matching, simple, upstream or current.
fatal: bad config variable 'push.default' in file '/Users/imac/.gitconfig' at
line 16
-bash: __git_ps1: c
Not sure if this is the appropriate mailing list or not. If not, I apologize.
Our company (METECS) decided this year to try and give back to the
open source communities that help us do our work. We had a vote for
our 2016 METECS Open Source Award and Git came in 2nd place! So we
will be making
On Thu, Sep 22, 2016 at 08:36:01AM -0700, Stefan Beller wrote:
> > Signed-off-by: Jeff King
>
> Acked and thanked by Stefan ;)
Thanks.
> > + /*
> > +* We want to show progress for recursive submodule clones iff
> > +* we did so for the main clone. But only the transport k
On Thu, Sep 22, 2016 at 11:13:13AM -0700, Junio C Hamano wrote:
> In any case, I would strongly recommend against exposing this (or
> anything for that matter) "--prefix" to the end-user, especially
> because this feature is likely to be applicable to many subcommands,
> and some subcommands would
On Thu, Sep 22, 2016 at 10:19:32AM -0700, Junio C Hamano wrote:
> The level at which configurability happens might be one issue
> (i.e. you may want different pager for two operating modes for the
> same command, hence your need to use "tag.list" not just "tag"), but
> I think another issue is tha
On Thu, Sep 22, 2016 at 09:15:26AM -0400, Eric S. Raymond wrote:
> Jeff King :
> > Back when this guide was written, cvsimport was the only
> > game in town. These days it is probably not the best option.
>
> It is absolutely not. As I have tried to point out here before, it
> is *severely* brok
On Thu, Sep 22, 2016 at 08:57:45AM -0700, Stefan Beller wrote:
> On Thu, Sep 22, 2016 at 2:23 AM, Jonas Thiel wrote:
> > Sorry for my late reply. Thanks for your support -- I really appreciate
> > that.
> >
> > @Jeff: Unfortunately, I do not know how to implement the patch you
> > provided. Can
On Thu, Sep 22, 2016 at 03:17:23PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote:
> >
> >> + ...
> >> + while ((c = *in++) != 0) {
> >> + if (take_next_literally) {
> >> + take_next_literally = 0;
> >
On Fri, Sep 23, 2016 at 12:07:30AM -0400, Jeff King wrote:
> I have access to an OS X system, but if I understand the bug correctly,
> reproducing it may involve re-setting the system hostname, which is not
> something I'll be able to do. But I'll give it a shot.
Actually, it turned out to be pre
On Thu, Sep 22, 2016 at 08:02:35PM -0300, Luciano Schillagi wrote:
> please, what should I do to fix this error? thanks
>
> Luko ~ $ git init
> error: malformed value for push.default: aguas
> error: Must be one of nothing, matching, simple, upstream or current.
> fatal: bad config variable 'push
On Thu, Sep 22, 2016 at 07:03:00PM +, Anatoly Borodin wrote:
> is there a good reason why
>
> git fetch -vpnf
>
> works like
>
> git fetch -v -p -n -f
>
> and
>
> git commit -avem msg
>
> works like
>
> git commit -a -v -e -m msg
>
> etc etc, but
>
>
On Thu, Sep 22, 2016 at 8:41 PM, Jeff King wrote:
>> * As Stefan alluded to (much) earlier, it might be a better idea
>>to have these 'prefix' as the global option to "git" potty, not
>>to each subcommand that happens to support them;
>
> That seems like it would be nice, but there's goi
On Thu, Sep 22, 2016 at 10:47:17PM -0700, Stefan Beller wrote:
> On Thu, Sep 22, 2016 at 8:41 PM, Jeff King wrote:
>
> >> * As Stefan alluded to (much) earlier, it might be a better idea
> >>to have these 'prefix' as the global option to "git" potty, not
> >>to each subcommand that happ
71 matches
Mail list logo