On 28 September 2015 at 19:47, Junio C Hamano wrote:
> I won't enable it on github.com:gitster/git anyway, so I do not
> think that is a concern. I thought what people are talking about
> was to add it on github.com:git/git, but have I been misreading the
> thread? I do not even own the latter r
On 22 May 2015 at 16:59, Junio C Hamano wrote:
> Roberto, isn't your threading of multi-patch series busted?
>
> Why is 1/2 a follow-up to 2/2? Do you have a time-machine ;-)?
Oh, embarrassing, I better destroy the time-machine:
https://github.com/rtyley/submitgit/pull/5
This was due to me not
On 28 January 2016 at 21:41, Stefan Beller wrote:
> On Thu, Jan 28, 2016 at 1:25 PM, Matthias Aßhauer wrote:
https://github.com/git/git/pull/191
>>>
>>> Oh I see you're using the pull-request to email translator, cool!
Yay!
>> Yes, I did. It definitly makes things easier if you are not use
On 9 February 2016 at 18:42, Junio C Hamano wrote:
> Lars Schneider writes:
>> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
>> where I found checkpatch.pl [3]. Would it make sense to check all commits
>> that are not in next/master/maint with this script on Travis-CI
On 22 February 2016 at 04:49, Eric Sunshine wrote:
> On Sun, Feb 21, 2016 at 11:14 PM, Peter Dave Hello
> wrote:
>> From: Peter Dave Hello
>
> This "From:" line looks suspiciously incorrect. If anything, you'd
> probably want to drop the line altogether or use:
>
> From: Peter Dave Hello
P
On 11 March 2016 at 05:44, Eric Sunshine wrote:
> On Fri, Mar 11, 2016 at 05:45:27AM +0530, Pranit Bauva wrote:
>> Actually I am sending the patches with submitGit herokuapp because my
>> institute proxy does not allow IMAP/POP3 connections.
Really glad to hear this is helping you Pranit - I hadn
Most of the guidance on how to use submitGit will stay with the tool
itself, so the edits here are mostly to make the choice clear to users.
Because generation of patches is quite different for MUA-users and
submitGit users, I've merged section 3 and 4 together:
section 3 - 'Generate your patch u
No editorial changes in this commit, the text that is transferred into the
second file is unchanged apart from minor chunk re-ordering.
The split is based on:
* Information needed for all users, whether using `git send-email` or
submitGit (ie good commit practice, mailing list etiquette)
* Info
On Thu, 31 Jan 2019 at 22:37, Elijah Newren wrote:
> On Thu, Jan 31, 2019 at 8:09 PM Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> > > git-filter-repo[1], a filter-branch-like tool for rewriting repository
> > > history, is ready for more widespread testing and feedback. The rough
> > >
On Tue, 12 Mar 2019 at 21:34, Jeff King wrote:
...
> We could continue to mention _both_ tools, but it's probably better to
> pick one in order to avoid overwhelming the user with choice. After all,
> one of the purposes here is to reduce friction for first-time or
> infrequent contributors. And t
On 26 September 2017 at 16:40, Christian Couder
wrote:
> On Sun, Sep 24, 2017 at 9:59 AM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> (It looks like smtp.gmail.com isn't working anymore for me, so I am
>>> trying to send this using Gmail for the cover letter and Submitgit for
>>> th
Turns out that putting 'link:' before the 'http' is actually superfluous
in AsciiDoc, as there's already a predefined macro to handle it.
"http, https, [etc] URLs are rendered using predefined inline macros."
http://www.methods.co.nz/asciidoc/userguide.html#_urls
"Hypertext links to files on the
inks to cvs2git & parsecvs)
http://git-scm.com/docs/git-filter-branch (link to The BFG)
It's worth noting that after this change, the html generated by 'make html'
in the git project is identical, and all links still work.
Signed-off-by: Roberto Tyley
---
Documentation/git-cvsim
The Git documentation pages hosted at kernel.org are a bit over a year
out of date ("Last updated 2013-02-15 19:24:31 UTC") - so from around
Git v1.8:
https://www.kernel.org/pub/software/scm/git/docs/
Are they fiddly to update? Should they be updated in celebration of
Git 2.0, or maybe instead re
on use (The Guardian, RedHat, Google, UK Government
Digital Service), been tested against large repos (~300K commits, ~5GB
packfiles) and received significant positive feedback from users:
http://rtyley.github.io/bfg-repo-cleaner/#feedback
Signed-off-by: Roberto Tyley
---
Documentation/git-fi
On 17 December 2013 18:13, Junio C Hamano wrote:
>
> Having said that, "You may want to use ..." without giving the
> reason why we recommend the other tool leaves the reader wondering
> what the pros and cons are, and why git-filter-branch exists if BFG
> is the first thing its document recommend
on use (The Guardian, RedHat, Google, UK Government
Digital Service), been tested against large repos (~300K commits, ~5GB
packfiles) and received significant positive feedback from users:
http://rtyley.github.io/bfg-repo-cleaner/#feedback
Signed-off-by: Roberto Tyley
---
Documentation/git-fi
emphasising
the significance the constraint plays in making the BFG work quickly
while satisfying the common use-case.
Roberto Tyley (1):
docs: add filter-branch notes on The BFG
Documentation/git-filter-branch.txt | 33 -
1 file changed, 32 insertions(+), 1 deleti
Hi Martin, I'm the developer of the BFG - I'd guess that there
probably isn't a bug for Git developers here, so you might want to
open one or more issues at
https://github.com/rtyley/bfg-repo-cleaner/issues, where I'd be happy
to take a look.
best regards,
Roberto
> On 8 Dec 2014 16:35, "Martin S
On 9 December 2014 at 14:14, Jeff King wrote:
> On Mon, Dec 08, 2014 at 05:22:23PM +0100, Martin Scherer wrote:
>
>> # invoke bfg --delete-folders something multiple times with different
>> pattern.
>>
>> # try to cleanup
>>
>> git gc --aggressive --prune=now # big blobs still in history
>> git fs
On Tuesday, 9 December 2014, Jeff King wrote:
> I actually think filter-branch's "refs/original" is a bit outdated at
> this point. The information is there in the reflogs already, and
> dealing with refs/original often causes confusion in my experience. It
> could probably use a "git filter-branc
On 9 December 2014 at 18:59, Jeff King wrote:
> On Tue, Dec 09, 2014 at 07:52:33PM +0100, Henning Moll wrote:
>> I assume that there is a lot of process forking going on. Could that be the
>> cause?
>
> Yes. filter-branch is a shell scripts, and it is probably running
> multiple git commands per c
On 10 December 2014 at 14:37, Jeff King wrote:
> On Wed, Dec 10, 2014 at 02:18:24PM +0000, Roberto Tyley wrote:
>> object SetCommitterToAuthor extends CommitNodeCleaner {
>> override def fixer(kit: CommitNodeCleaner.Kit) = c =>
>> c.copy(committer = c.author) // Pers
On 10 December 2014 at 16:07, Junio C Hamano wrote:
> Jeff King writes:
>>> git reflog expire --expire=now --all && git gc --prune=now --aggressive
>>>
>>> Maybe:
>>>
>>> git gc --purge
>>
>> Yeah, that is common enough that it might be worthwhile (you probably
>> want --expire-unreachable in the
On 10 December 2014 at 16:05, Junio C Hamano wrote:
> Roberto Tyley writes:
>
>> The BFG is generally faster than filter-branch for 3 reasons:
>>
>> 1. No forking - everything stays in the JVM process
>> 2. Embarrassingly parallel algorithm makes good use of multi-c
On 21/09/2013 23:16, Keshav Kini wrote:
[SNIP]
This situation came about because the BFG Repo-Cleaner doesn't write new
reflog entries after creating its new objects and moving refs around.
True enough - I don't think the BFG does write new entires to the
reflog when it does the final ref-updat
On Tuesday, 19 May 2015, Stefan Beller wrote:
> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
> wrote:
> > How do you send your patches inline?
[snip]
> This workflow discussion was a topic at the GitMerge2015 conference,
> and there are essentially 2 groups, those who know how to send email
>
On Tuesday, 19 May 2015, Stefan Beller wrote:
> On Tue, May 19, 2015 at 12:29 PM, Robert Dailey
> wrote:
> > How do you send your patches inline?
>
> This workflow discussion was a topic at the GitMerge2015 conference,
> and there are essentially 2 groups, those who know how to send email
> and t
ealistic
understanding of their exposure, and would like to update the
documentation of git-filter-branch to give them a better idea of their
options for removing private data - that would include noting the BFG
as alternative.
- Roberto Tyley
https://github.com/rtyley/bfg-repo-cleaner/blo
ired cleaned
id.
In the case of git-filter-branch, the user has a lot more freedom to
change the tree-structure of commits on a commit-by-commit basis, so
memoising tree-cleaning is out of the question, but I guess it might
be possible to do memoisation of just the commit ids to short-cut the
m
reciate you giving the BFG a try and letting
me know how you found it.
thanks,
Roberto Tyley
software dev @ The Guardian
http://rtyley.github.com/bfg-repo-cleaner/
--
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
31 matches
Mail list logo
