Git code hosting beta (launchpadblog) [LWN.net]

Early support for hosting Git repositories directly on Launchpad has been announced. "This has been by far the single most commonly requested feature from Launchpad code hosting for a long time; we’ve been working hard on it for several months now, and we’re very happy to be able to release it for general use. This is distinct from the facility to import code from Git (and some other systems) into Bazaar that Launchpad has included for many years."

to post comments

Git + launchpad

Posted May 6, 2015 1:52 UTC (Wed) by smurf (subscriber, #17840) [Link] (36 responses)

Finally.

Bets as to when BZR will be deprecated, anybody? I'd guess at most two years.

Git + launchpad

Posted May 6, 2015 3:05 UTC (Wed) by roskegg (subscriber, #105) [Link] (35 responses)

If bzr is less like using sharp pointy objects than git is, maybe this move will encourage more people to give bzr a try.

Git + launchpad

Posted May 6, 2015 5:36 UTC (Wed) by edomaur (subscriber, #14520) [Link]

from my point of view, bzr is more like walking blindly into a room where there is some hard furniture at shin height... (don't like it much)

Git + launchpad

Posted May 6, 2015 6:24 UTC (Wed) by epa (subscriber, #39769) [Link] (4 responses)

It might be a bit better but the big improvement in usability and learnability comes not from some slightly improved and incompatible tool, but from having everyone use the same tool. Then there is only one set of weirdness to get used to.

Git + launchpad

Posted May 6, 2015 7:00 UTC (Wed) by bangert (subscriber, #28342) [Link] (3 responses)

i guess that would be windows then...

Git + launchpad

Posted May 6, 2015 10:46 UTC (Wed) by rvfh (guest, #31018) [Link]

Still haven't got used to it...

Re: i guess that would be windows then...

Posted May 8, 2015 6:04 UTC (Fri) by ldo (guest, #40946) [Link] (1 responses)

Unfortunately (or otherwise), Linux has already surpassed Windows to become the world’s most popular OS.

Re: i guess that would be windows then...

Posted May 18, 2015 9:55 UTC (Mon) by epa (subscriber, #39769) [Link]

Linux is everywhere but in 99.99% of cases it provides no user interface. Only a minority of users even know that the device is running Linux. Possibly Android might now have beaten Windows as the most common UI.

Git + launchpad

Posted May 6, 2015 6:52 UTC (Wed) by smurf (subscriber, #17840) [Link] (24 responses)

Frankly I have no idea which sharp pointy objects you're talking about, given that you can trivially undo any goof-up you commit with some judicious use of "git reset".

"bzr uncommit" seems to do roughly the same thing, except that you can't undo _that_.

Git + launchpad

Posted May 6, 2015 7:56 UTC (Wed) by NAR (subscriber, #1313) [Link] (13 responses)

You can undo commits, but can't undo interactive rebases or pushes. I have met the sharp pointy end of these commands. Of course it was my fault (in fact, I expected to err, so I saved the diff before the rebase), but nevertheless the tool has sharp pointy ends. The scalpel of a surgeon has also sharp pointy end, otherwise the surgeon couldn't do it's job...

Git + launchpad

Posted May 6, 2015 8:17 UTC (Wed) by cebewee (guest, #94775) [Link] (5 responses)

Of course you can undo interactive rebases in Git. The reflog (git log -g) is your friend.

Git + launchpad

Posted May 6, 2015 9:36 UTC (Wed) by tpo (subscriber, #25713) [Link] (4 responses)

git log -g? First time I've heard of that.

<rant>
And *of course* there's also git's own virtual machine and C like language that can be used to fix further stuff, because you can't really expect to use such advanced machinery as a "commit" without knowing the third order relations of quantum git algebra.
</rant>

Git + launchpad

Posted May 6, 2015 12:31 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

What? Commit doesn't require that knowledge. It *helps* to know what git is doing behind the scenes, but is by no means necessary.

Git's flexibility let's me write a tool that uses one clone to spawn X empty directories in which to do manipulations on the repository (such as running hooks, merging, etc.) without actually checking a workdir out (an bottleneck when you do it thousands of times a day on large repositories). Now, most people don't need to know about things like update-index, ls-files, or read-tree, but I really don't know how'd I'd even approach the problem with another VCS while staying in the requirements (though I admit ignorance, at least to the same depth I know of git, of other tools) since I don't think they give me the same tools. It also let's me atomically write references out to avoid race conditions when these parallel workdirs write back notes to keep the work they do around from being garbage collected.

Git + launchpad

Posted May 6, 2015 15:36 UTC (Wed) by pboddie (guest, #50784) [Link] (1 responses)

By "without actually checking a workdir out", do you mean like Mercurial clones which have been updated to the null revision? (You get the .hg directory and nothing else.)

I imagine bzr permits the same, although my experience with bzr has been mostly to dip into some repository someone has asked me to look at, and to run some fairly intuitively-named commands, which did what I expected. Quite a contrast to Git, in fact.

(It seems to be the case that criticism of Git's usability is frequently met by retorts that it's an object filesystem and sink-cleaner all in one, and that the frustrated user should feel the power. The manpages, despite probably having had a few iterations, reinforce this impression: git-checkout is my current "favourite".)

Git + launchpad

Posted May 6, 2015 21:11 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

You make a file path and an empty directory, set GIT_INDEX_FILE and GIT_WORK_TREE in the environment pointing to those and set GIT_DIR pointing to the bare repository with all the objects. We then prep the index with the right revision (git read-tree), tell the index that the working tree is OK without hitting disk (git update-index), and then checkout the .gitmodules file (if it exists) (git checkout-index followed by git update-index to update it that there's a real file on disk now) so that submodules work properly. This can be done concurrently with a single clone of a repository and each chain of commands thinking they are working on a real thing (you need the directory so that conflict files have a place to be dropped).

So basically, can I work with a single clone from multiple directories at once where all of them think they are in their own little sandbox and don't interfere with each other (even to the point of avoiding race conditions when asking for available names in refs/)?

I agree that the git docs are not as end-user-oriented as they could be. I'm also not *too* concerned with intuitiveness (cf. my use of Vim, XMonad, tmux, uzbl, etc.), but rather that things *make sense*. As an example, the "standard" cut/copy/paste shortcuts are convenient, but are not composable like Vim's versions of them. That's what I like about git; it gives me a toolbox with some pre-made tools composed of the bare bits rather than a completed sawsall or something which, while nice, can't quite be made into a hammer when I need one without some sanity checks.

Git + launchpad

Posted May 6, 2015 20:45 UTC (Wed) by nix (subscriber, #2304) [Link]

Git's own what? It doesn't have a virtual machine, nor a C like language. Its revision specifiers look more like the shell than anything.

You may be thinking of Mercurial here (which *also* doesn't have a virtual machine of any sort, but which has ways to specify revisions that look more like a conventional programming language).

Git + launchpad

Posted May 6, 2015 8:17 UTC (Wed) by alexl (guest, #19068) [Link] (1 responses)

You can undo an interactive rebase, or any changes to a (local) git repository that has been commited (but not if you accidentally lose outstanding changes). Every single commit is kept in the repo as long as you don't trigger a GC, so the head before the interactive rebase is still there, and can be found via "git reflog".

Git + launchpad

Posted May 6, 2015 12:35 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

FTR, commits stay around if they have a name (branch, tag, other arbitrary ref, reflog entry, etc.), or a path from a name, or are younger than 30 days (by default).

Git + launchpad

Posted May 6, 2015 11:50 UTC (Wed) by agateau (subscriber, #57569) [Link]

While in the middle of an interactive rebase, you can undo it with `git rebase --abort`.

Furthermore, when I know I embark into some heavy rebase, I start by creating a branch for the rebase with `git checkout -b rebased`. I then do the rebase in this branch. This is quite handy because when I am done I can easy compare the two branches with `git diff name-of-original-branch`.

Git + launchpad

Posted May 6, 2015 18:05 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

AIUI, if you make a note of what the current head is, you can ALWAYS get back to it unless BOTH you abandon that branch AND you do a garbage collect.

Otherwise, it's all part of your history, and knowing the commit means you can reset that to be you current working head. So if you reset the head back somewhere in the history (or abandon that head) a GC will detect the hanging end and garbage-collect backwards, but as long as there is an active commit after the one you want, it can't be GC'd, and it can be retrieved.

Oh - and aiui you can also back up your working directory - "git stash" if I've got it right. I don't use it, I don't understand it, but that's what it's for.

Cheers,
Wol

Git + launchpad

Posted May 6, 2015 20:47 UTC (Wed) by nix (subscriber, #2304) [Link]

AIUI, if you make a note of what the current head is, you can ALWAYS get back to it unless BOTH you abandon that branch AND you do a garbage collect.

The garbage collection also must have happened at least as long after the rebase as specified by the gc.pruneexpire config option (if unset, two weeks).

You need to really work to lose committed data in git.

Git + launchpad

Posted May 6, 2015 20:23 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

git reflog?

Git + launchpad

Posted May 7, 2015 15:37 UTC (Thu) by smurf (subscriber, #17840) [Link]

Sure you can undo a push. "git push -f destination OLD_COMMIT_HASH:branch". Or, if you want to delete a remote branch, leave OLD_COMMIT_HASH empty.

Sure you can undo a rebase. "git reset --hard OLD_COMMIT_HASH".

You get the old commit hash from the reflog, or from a gitk window you conveniently left open, or whatever.

I never had to "save a diff", by the way. What would that accomplish?

Git + launchpad

Posted May 6, 2015 8:55 UTC (Wed) by Flimm (guest, #98097) [Link] (5 responses)

You can't undo git checkout -- filename or git reset --hard commit, whereas you can do that in Bazaar (it creates a hidden backup file every time).

Git + launchpad

Posted May 6, 2015 9:37 UTC (Wed) by juliank (guest, #45896) [Link] (1 responses)

Right. git's job is managing your version history, not making backups of your working directory.

Git + launchpad

Posted May 6, 2015 11:09 UTC (Wed) by nye (guest, #51576) [Link]

>git's job is managing your version history, not making backups of your working directory

You say that as if those are clearly two different tasks, but reasonable people can disagree on that point.

Git + launchpad

Posted May 9, 2015 9:46 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> You can't undo git checkout -- filename or git reset --hard commit, whereas you can do that in Bazaar (it creates a hidden backup file every time).

As has been pointed out, git DOES NOT delete anything unless you try very hard to make it. So "git reset --hard commit" should be easy to undo - "git reset --hard oldhead".

As for "git checkout -- filename", well I guess the old filename was never in git, so how can git recover it?

Cheers,
Wol

Git + launchpad

Posted May 9, 2015 14:33 UTC (Sat) by madscientist (subscriber, #16861) [Link] (1 responses)

I think Flimm is talking about modified files; if you run git reset --hard then all modified files are reset and the modifications are not saved anywhere. Apparently bzr will make a hidden backup copy of modified files.

In Git, you need to first run "git stash" or similar to keep a backup of modified files.

Git + launchpad

Posted May 16, 2015 6:46 UTC (Sat) by zenaan (guest, #3778) [Link]

And "git stash" can be simply added to a checkout hook, for the paranoid, for those for whom that risk is too great, it is easy to configure that pain away...

Git + launchpad

Posted May 6, 2015 11:03 UTC (Wed) by cjwatson (subscriber, #7322) [Link] (3 responses)

$ bzr uncommit
143 Colin Watson 2015-05-06
Sort imports and remove pyflakes lint.

The above revision(s) will be removed.
Uncommit these revisions? ([y]es, [n]o): yes
You can restore the old tip by running:
bzr pull . -r revid:cjwatson@canonical.com-20150506110304-negzvl15v4ytaknv

Git + launchpad

Posted May 6, 2015 12:36 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

How would you discover that name if you put the output there into /dev/null?

Git + launchpad

Posted May 6, 2015 12:55 UTC (Wed) by cjwatson (subscriber, #7322) [Link] (1 responses)

"bzr heads --dead-only" will show it (as long as it hasn't been GCed yet, I think - I'm not a bzr expert).

FWIW: I've been working on git support in Launchpad for most of this year, and I'm really excited about getting it to the point where I can use it for everything, so this isn't intended to persuade people to use bzr. I just think that if we're criticising bzr it would be nice if the criticisms were in fact accurate.

Git + launchpad

Posted May 6, 2015 21:13 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

OK, good to know it isn't really lost then :) .

> I just think that if we're criticising bzr it would be nice if the criticisms were in fact accurate.

Understandable. I get the urge to pick nits with folks who claim rebase is a "never use it" tool, but there are only so many hours in the day :( .

Re: If bzr is less like using sharp pointy objects than git is

Posted May 8, 2015 6:15 UTC (Fri) by ldo (guest, #40946) [Link] (3 responses)

Seems unlikely at this stage. Git became popular entirely through its own merits, not because any big organization with any multi-billion-dollar budget was behind it (Microsoft Team Foundation Server, anybody?). Against all that deep-pocketed competition and insidious vendor lock-in, all those overwhelming odds stacked against it, Git has now reached the point that no other VCS, whether Free or proprietary, stands any hope of offering serious competition.

Re: If bzr is less like using sharp pointy objects than git is

Posted May 8, 2015 12:44 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

> not because any big organization with any multi-billion-dollar budget was behind it

You mean like GitHub?

OK, replace "billion" with "million", but it's their sole business and I believe they are one of the biggest factors in git becoming the dominant VCS.

Back when GitHub got started, git, Mercurial and Bazaar were all quite close in mindshare and features. At one point it even seemed possible that Mercurial was winning due to many large projects adopting it (Python, Mozilla, OpenJDK, OpenOffice; Google Code added Mercurial support long before git; even kernel.org provided an official Mercurial mirror of the git repo).

But GitHub was the first website to offer such quick code hosting and convenient distributed workflows. People could just throw up some code and not worry about whether it's a "project" or not -- unlike "old school" FOSS hosting sites. And even though copycats like Bitbucket followed (Mercurial-only at first), network effects made sure that GitHub stays in the dominant position.

Re: If bzr is less like using sharp pointy objects than git is

Posted May 8, 2015 13:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Bitbucket has other problems (and always has). They support cloning over hg or git for all repos, but you can't make pull requests to any repo other than the one you forked directly (no cross-fork collaboration). They *still* lack 2FA support (they said they'd do it on Twitter a few years ago, but then nothing happened; their issue for it has no comments from Atlassian on any recent timescale). The web interface is a lot clunkier than GitHub. All emails for an issue share a Message-Id so MUAs which actually use it display the threads suboptimally. There are other things, but I can't think of them right now. Even if Bitbucket had come first, GitHub has been so much better at execution that I think they'd still have "won".

Honestly, GitLab is better than Bitbucket (though I replace all "hg clone" commands with "git clone hg::" because I just cannot grok Mercurial, so that difference doesn't mean much to me) in every way I've had to deal with either and you can host your own (and I haven't used the enterprise edition).

Re: You mean like GitHub?

Posted May 8, 2015 22:11 UTC (Fri) by ldo (guest, #40946) [Link]

Given the number of GitHub users who are clueless about Git, I don’t think many of them use it at all.

No, it was Git that made GitHub, not the other way round.

Git code hosting beta (launchpadblog)

Posted May 6, 2015 16:38 UTC (Wed) by josh (subscriber, #17465) [Link] (21 responses)

Nice to see this change. I just wish they'd done this years ago, so that we might have a credible Open Source competitor to github.

Git code hosting beta (launchpadblog)

Posted May 6, 2015 17:26 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (20 responses)

What would be really great is if this feature gives Debian a reason to take a hard look at possibly spinning up a Debian launchpad instance using the launchpad code source. Not just the CodeHosting component, but for the Soyuk build component and other things. I think there is a lot of value in Launchpad code that Debian could benefit from, but they'd need to be able to run their own instance.

Git code hosting beta (launchpadblog)

Posted May 6, 2015 21:12 UTC (Wed) by ballombe (subscriber, #9523) [Link] (19 responses)

FWIW, alioth.debian.org has hosted git repositories for years.

Git code hosting beta (launchpadblog)

Posted May 6, 2015 21:32 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (18 responses)

I know that.
I'm saying that git support might be a big enough new feature for Debian to another look at hosting their own instance of launchpad..kick the tires a bit. As a set of modules collectively, launchpad with git support, might marginally useful enough to host an instance of. The ppa concept, the integrated code review stuff, the blueprints, all of that stuff together could be useful to Debian beyond what they have now.

Or not. I'm saying, its a big enough feature enhancement to take a look and assess and maybe even bring up a toy instance and poke it with a stick.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 4:40 UTC (Thu) by raof (subscriber, #57409) [Link] (17 responses)

Few things could make me happier as the maintainer of a couple of Debian packages than Debian spinning up a Launchpad instance (one of them, ddebs, seems to be imminent. YAY!).

Solely because I curse the Debian BTS everytime I need to interact with it.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 7:55 UTC (Thu) by pabs (subscriber, #43278) [Link] (16 responses)

What about the Debian BTS causes you to curse?

Personally I find it better that any other centralised BTS. Launchpad is almost as good but you still have to register an account to use it.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 11:22 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (6 responses)

Yestday a Debian developer forwarded a bug to me (a non-Debian developer). I simply replied to that email with some information regarding the issue at hand.

Then I received… three? emails from the Debian Bug Tracking System: a rather verbose help message how to use the email interface, a kind of welcome message and the »results of your commands« mail listing all of my reply lines and stating each time that the command wasn't understood.

No big surprise there, I didn't use commands, I just wrote a paragraph of text. I didn't _want_ to interact with a bug tracking system, just to give the sender some more information.

Now you might say »well then you shouldn't have CCed control@bugs.debian.org«. You may have a point there. But am I, as a non-DD, supposed to know such things? Anyway, no harm done; I just thought it fitting the »curse at the Debian BTS every time I use it« theme :)

Git code hosting beta (launchpadblog)

Posted May 7, 2015 20:07 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

Sane bug tracking systems will process your reply and make it a comment on the bug. This works well enough in small groups, though out on the Internet it needs careful implementation to avoid autoreply loops and spam. Github seem to have managed it.

Certainly the idea of sending 'commands' over an email interface is absurdly retro these days. Surely anyone with the technical chops to be doing automated bug tracker work is able to send authenticated POST requests over https instead.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 22:50 UTC (Thu) by andresfreund (subscriber, #69562) [Link]

The debian BTS does that. In fact, it's pretty much the only write access.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 5:03 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Github really needs an option to send my own comments as email. Issues end up having holes poked in them in mutt and there is no easy way to get a list of all issues I've opened but are neglected (other than the web interface; the only API endpoint for it is by searching or scraping).

Git code hosting beta (launchpadblog)

Posted May 8, 2015 20:33 UTC (Fri) by peter-b (guest, #66996) [Link] (1 responses)

You could use the GitHub web service API to pull out a list of all your issues as JSON...

Git code hosting beta (launchpadblog)

Posted May 8, 2015 21:10 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The only explicit endpoint that was available was equivalent to the "issues that are assigned to me". To get the github.com/issues list, you need to use the search API (which does not support disjunctions). I contacted them about it and they said it'd be nice, but for now, you're stuck with searching.

Git code hosting beta (launchpadblog)

Posted May 9, 2015 20:08 UTC (Sat) by robbe (guest, #16131) [Link]

It seems CC-ing (instead of BCC-ing) control@bugs.debian.org was an error of the Debian developer, not something that you should have know.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 23:28 UTC (Thu) by raof (subscriber, #57409) [Link] (8 responses)

What I dislike about the BTS is its entirely arcane mechanism for making changes. Each and every time I need to change the status of a bug in some way I need to refer to the online doc, and I don't think I've *ever* got it completely correct, even rigourously consulting the documentation.

On the other hand, the Launchpad email interface offers pretty much the same features, but doesn't have the control@, bug-nnn@, bug-whatever-the-other-addresses-are@ split and usually ends up doing what I wanted. And for complex tasks there's a nice web UI.

I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

We should *additionally* have an entirely hands-off crash reporting mechanism - errors.ubuntu.com is pretty close to this, and I'm pretty sure Fedora has similar infrastructure now.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 0:40 UTC (Fri) by josh (subscriber, #17465) [Link]

Personally, I use the "bts" command-line tool, which knows all the syntax.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 16:30 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

Which then annoys the people who actually make heavy use of a lot of systems. I have, what, eight e-mail folders for software I am seriously enough interested in to want to track the dev list. That's a LOT of reading. Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

Yes I know there's a spam problem etc etc, but it would be nice to be able to send an anonymous bug report, and know that there's a decent chance some developer will at least triage it and maybe promote it to "real bug", or point you at the relevant help or somesuch.

I don't expect much response from a drive-by bug report, but I really don't like software that puts hoop after hoop in front of you when you are trying to report a problem ...

Cheers,
Wol

Git code hosting beta (launchpadblog)

Posted May 8, 2015 18:53 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

We need to develop one universal login that can be used to access everyone's bug trackers. (See: https://xkcd.com/927/)

Git code hosting beta (launchpadblog)

Posted May 9, 2015 16:50 UTC (Sat) by flussence (guest, #85566) [Link]

> Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

For better or worse, sites like GitHub have alleviated that problem. I'm about 99% more likely to go report a found bug if the project it's in is on a site I don't have to do a register-email-login dance on.

(Honourable mention goes to the dnssec-validator project, which tried to allow anonymous bug reporting on their trac site. They had a captcha which didn't actually work. I couldn't be bothered reporting *that* bug.)

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:32 UTC (Fri) by pabs (subscriber, #43278) [Link]

New bug reports are never spam in the Debian bug tracker, spammers never figured out how to put "Package: foo" at the top of the mail.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 19:35 UTC (Fri) by bfields (subscriber, #19510) [Link]

I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

I'd rather get the reports. I can use filtering and such to keep my initial time investment low if necessary. Lots of problems are very difficult to reproduce so will only be spotted and fixed if we can get reports from the widest possible population.

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:28 UTC (Fri) by pabs (subscriber, #43278) [Link]

I need to look up how to change bugs whenever I modify bugs on Launchpad, that is just because I don't use it very often though.

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:31 UTC (Fri) by pabs (subscriber, #43278) [Link]

Hands-off crash reporting is the wrong way to do it as automatic crash reports automatically have private data in them that shouldn't be uploaded anywhere.