On Mon, Oct 27, 2014 at 1:33 AM, Matthieu Moy
wrote:
> Dennis Kaarsemaker writes:
>
>> On zo, 2014-10-26 at 22:27 -0700, Cong Wang wrote:
>>>
>>> My question is how to edit dozens of git commit changelogs
>>> automatically?
>>
>> You can use git filter-branch in --msg-filter mode.
>
> Note that i
On Sun, Oct 26, 2014 at 11:05 PM, Dennis Kaarsemaker
wrote:
> On zo, 2014-10-26 at 22:27 -0700, Cong Wang wrote:
>>
>> My question is how to edit dozens of git commit changelogs
>> automatically?
>
> You can use git filter-branch in --msg-filter mode.
This is exactly what I am looking for. Good t
Here is the data dumper info . I tried the dumper code on the R repo
as well, and saw that against the virtual box repo, there is one
curious difference - $self->{last_rev} is a string rather than a number.
I tried hacking around doing "$x += 0;" to coerce last_rev
to a number at various places bu
On Thu, 30/10/14, Eric Wong wrote:
> The missing merge on branch
"R-2-14-branch" is:
>
> commit
93af4d4cc3a5e0039944dd4e340d26995be8a252
> Merge: 121990f 6ff1b87
> Author: ripley
> Date: Wed Feb 22 13:45:34
2012 +
>
>
port r584
Hin-Tak Leung wrote:
> Argh, sorry. I thought I included the info but I didn't.
Thanks. I'll try a different version of svn later.
> What do you think were missing in my e-mails?
I was skimming and missed the part about Debian packages :)
--
To unsubscribe from this list: send the line "unsubsc
Hin-Tak Leung wrote:
> On Tue, 28/10/14, Eric Wong wrote:
>
> > So both merges
> are correct, but we lose one, and gain one?
> I'll try to check more closely tomorrow.
> Can you point out
> the exact revisions in the
> R repo? Thanks.
>
>
> The missing merge on branch "R-2-14-branch" is
Argh, sorry. I thought I included the info but I didn't.
git 2.1.0 + 10 patches aborts after trunk@28923 (i.e. failing to fetch 28924);
if I revert the patches in that order (#5,#4,#2, #1) and retry in the middle,
I have to revert all 4 to get 'git svn fetch' to continue on to 28924.
I tried --st
Bernhard Reiter writes:
> Resending this once more, as indicated by
>
> Hope my formatting and posting style is now conformant. Sorry for the noise.
Thanks.
The patch does not apply for me (please send a trial message to
yourself and then try to apply it out of your mailbox to avoid such
an i
Thomas Schwinge wrote:
> I couldn't find this answered in the documentation: if, instead of
> exiting right away, a »git gc --auto« actually commences its housekeeping
> tasks, is it safe to interrupt (C-c, SIGINT) the original git invocation
> at this point, or might this cause any inconsistencie
On Wed, Oct 29, 2014 at 11:58:57AM +, Francis Irving wrote:
> I could not find out how to report a bug. In the end, a colleague
> had to tell me.
Thanks for your suggestions; they all seem like improvements. I just
opened:
https://github.com/git/git-scm.com/pull/462
which implements most
The latest maintenance release Git v2.1.3 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.1.3'
tag and the 'maint' branch that the tag points at:
url = https://kernel
Peter,
You should be happy of getting the error message.
Since Git 2 invalid years will default to the current year (keeping
the given day and month) without warnings.
--
Roberto Decurnex
On Wed, Oct 29, 2014 at 4:31 PM, Junio C Hamano wrote:
> Peter Vojtek writes:
>
>> It seems the commit d
Memoizing these initialization functions saves some memory for
long fetches which require scanning many unwanted revisions
before any wanted revisions happen.
Signed-off-by: Eric Wong
---
perl/Git/SVN/Ra.pm | 63 +++---
1 file changed, 36 insertion
On Wed, Oct 29, 2014 at 11:51:34AM +, Francis Irving wrote:
> The help for "git log --all" says:
>
>--all
> Pretend as if all the refs in refs/ are listed on
> the command line as .
>
> This makes no sense, as is not a documented valid command lin
thanks for quick response, Fredrik.
> I'm curious, why did you choose git for this? Maybe this is a use case
we should consider?
this is a part of "thinking out of the box" mental execise.
With the advent of many tools to visualize and analyze git
repositories, it makes some sense to use the und
Eric Wong writes:
> This should help me track down errors in git-svn more easily:
>
> write .git/Git_XX: Bad file descriptor
>at /usr/lib/perl5/SVN/Ra.pm line 623
>
> Signed-off-by: Eric Wong
> ---
> Not sure you want to take this separately or in a git-svn pull.
> Still wo
This should help me track down errors in git-svn more easily:
write .git/Git_XX: Bad file descriptor
at /usr/lib/perl5/SVN/Ra.pm line 623
Signed-off-by: Eric Wong
---
Not sure you want to take this separately or in a git-svn pull.
Still working on the error this patch is
Peter Vojtek writes:
> It seems the commit date can be between 1970 and 2100 (on my 32bit
> linux),...
The underlying data representation records time as number of seconds
since epoch (1970-01-01). Theoretically the codepaths that read
data could consider negative timestamps to represent times
Hin-Tak Leung wrote:
> Hi, I patched my system git with the recent git-svn improvements, and just use
> it for general use; so theses are the patches, against 2.1.0.
>
> 0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch
> 0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patc
Jeff King writes:
> On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
>
>> --- a/bundle.c
>> +++ b/bundle.c
>> @@ -381,7 +381,7 @@ int create_bundle(struct bundle_header *header, const
>> char *path,
>> write_or_die(bundle_fd, "\n", 1);
>>
>> /* write pack */
>> -mems
On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:
> I am playing with git in slightly unusual manner - e.g., to use git to
> store history of europe:
Actually you're the second person I hear that is trying to use git as a
timeline of some sort. The previous person had the exact same pr
On Wed, Oct 29, 2014 at 11:50:12AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm a little iffy on this just because it is fixing one particular bug,
> > and I am sure there are probably a bunch of other ways to have a bogus
> > index. Fundamentally, I think we pretty much trust that
Jeff King writes:
> I'm a little iffy on this just because it is fixing one particular bug,
> and I am sure there are probably a bunch of other ways to have a bogus
> index. Fundamentally, I think we pretty much trust that the index was
> not maliciously generated (unlike packfiles, for instance,
Hello all,
I am playing with git in slightly unusual manner - e.g., to use git to
store history of europe:
$ touch Italy
$ git add Italy
$ git commit -m "add Italy" --date="01/01/1861T01:01:01" # Italy
gained sovereignity at year 1861
fatal: invalid date format: 01/01/1861T01:01:01
It seems the
Ronnie Sahlberg writes:
> On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano wrote:
>
>> More importantly, when you know that the end result you want to see
>> is that the old and new log files are bit-for-bit identical, and if
>> not there is some bug in either parsing or formatting, why parse the
Resending this once more, as indicated by
Hope my formatting and posting style is now conformant. Sorry for the noise.
Am 2014-08-27 um 19:20 schrieb Junio C Hamano:
> Bernhard Reiter writes:
>
>> [...] For now,
>> the old ones are wrapped in #ifdefs, and the new functions are enabled
>> by ma
On Tue, Oct 28, 2014 at 09:52:34PM +0100, René Scharfe wrote:
> --- a/bundle.c
> +++ b/bundle.c
> @@ -381,7 +381,7 @@ int create_bundle(struct bundle_header *header, const
> char *path,
> write_or_die(bundle_fd, "\n", 1);
>
> /* write pack */
> - memset(&rls, 0, sizeof(rls));
>
On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> I timed a git branch -m for a branch with ~2400 log entries and it
>> takes neglible time :
>> real 0m0.008s
>> user 0m0.000s
>> sys 0m0.007s
>
> I really hate this line of reasoning. Small things tend to
The loop in cache-tree's update_one iterates over all the
entries in the index. For each one, we find the cache-tree
subtree which represents our path (creating it if
necessary), and then recurse into update_one again. The
return value we get is the number of index entries that
belonged in that sub
Hi!
I couldn't find this answered in the documentation: if, instead of
exiting right away, a »git gc --auto« actually commences its housekeeping
tasks, is it safe to interrupt (C-c, SIGINT) the original git invocation
at this point, or might this cause any inconsistencies, data loss, or
failure to
Hi all,
git rebase can sometimes "forget" a commit, here is the workflow to reproduce
this problem:
$ git init .
$ echo "content 1" > file1
$ git add file1 && git commit -m "C1"
$ echo "content 2" > file2
$ git add file2 && git commit -m "C2"
$ echo "content 3" > file3
$ echo "content 2.3" >> file
I could not find out how to report a bug. In the end, a colleague
had to tell me.
Some suggested improvements:
1) Explicitly mention the word "bug" on the home page, or have
a page which Google will find called "Reporting bugs".
2) I did eventually get to the Community page:
http://git-scm.com
The help for "git log --all" says:
--all
Pretend as if all the refs in refs/ are listed on
the command line as .
This makes no sense, as is not a documented valid command line
parameter. These are the documented parameters:
SYNOPSIS
33 matches
Mail list logo
