Consider recreating repo as a fork of iceman1001/proxmark3 about proxmark3 HOT 19 CLOSED

Sorry, I think I didn't explain my initial idea very well. I think having a separate repo for rdv4-centric work is a good idea. What I mean is:

1. Make sure you have an up-to-date clone of this repo.
2. Delete this repo.
3. Go to iceman1001/proxmark3 and click Fork.
4. On your local clone, git push -f.
5. Now this repo exists again (but the issues will be gone).

That way you'll end up with a github repo that knows it's a fork of iceman1001/proxmark3. The benefit here is that when someone contributes a PR to both projects that github will then know to show this fork in the project selector for creating the PR.

from proxmark3.

I think I might have done an exceedingly poor job of explaining the issue. This issue isn't about whether there should be a forked repo. I taking it as a foregone conclusion that there will be a fork repo. I just want the GitHub metadata to point to the iceman repo as the repo which this was forked from so I can one-click Pull Request into this repo. 😬

from proxmark3.

Hmm interesting thoughts guys. Many good opinions here. Just how to move forward? Maybe we need to do some kind of community poll to get some insights in to how the majority feel about this situation?

from proxmark3.

Yes, you'd lose the other 4 issues that are open on this repo. But I feel like now's the time. 😄

from proxmark3.

I hear what you are saying.
Already dropped it once and recreated this one. The different repos is good to separate it from iceman fork, since its not focused on rdv40. I am reluctant to this idea, but I appreciate your feedback.

from proxmark3.

Would probably make sharing easier too

from proxmark3.

I second this. Being an owner of both the RDV3 and RDV4 I would prefer to have one set of tools that can support both. While both may have different development branches at some point merging stable features/support back would be great.

from proxmark3.

From the readme

Why didn't you based it on offical PM3 Master?
The separation from offical pm3 repo gives us very much freedom to create a firmware/client that suits the RDV40 features. We don't want to mess up the offical pm3 repo with RDV40 specific code.

This is completely false. First your branch can have any number of updates that are ahead of an upstream master. At no point must pull requests happen all a proper fork does is help facilitate pull should they be accepted.

There are hundreds of ways to add in RDV40 code that wouldn't pollute upstream and other builds. Only lazy coding which doesn't properly use layering and separation would produce this problem. Enabling the RDV40 code could be done at build time (see configure) or it could happen at run time on device detection.

This explanation boils down to we are too lazy or don't know how to play nice with upstream. Neither of which support the decision not to be a proper fork. Pulls would just be delayed until this project got its crap together.

from proxmark3.

I think I might have done an exceedingly poor job of explaining the issue. This issue isn't about whether there should be a forked repo. I taking it as a foregone conclusion that there will be a fork repo. I just want the GitHub metadata to point to the iceman repo as the repo which this was forked from so I can one-click Pull Request into this repo. 😬

Not doing this as you pointed out will just set this repo to be underutilized. Someone will properly fork upstream then manually merge the changes from here. As that repo will properly track upstream and allow for pulls it will likely get more community support. If RFIDResearchGroup can't understand soon it would almost be better to make that happen now before this dead end repo diverges too much making the manual patching more difficult.

from proxmark3.

I agree please consider recreating repo as a fork of iceman1001/proxmark3

from proxmark3.

Maybe its too late.

from proxmark3.

closed.

from proxmark3.

It seems the RFIdResearchGroup isn't going to do the right thing. So Before we get too far down the path who wants to properly fork iceman then rebase the changes in this repo onto that proper fork ? @TomHarkness @gkelly @BreakSecurity @CumpsD any takers ??

from proxmark3.

I can not take care of it, sorry

from proxmark3.

Look, I am really unsure how exactly this should move forward as I am not mainly a software dev, I focus a lot on hardware and add to the software repo where I cam, as I learn more. Problem is that this repo now has SO many changes that are rdv4 specific and would take a huge amount of time and effort to merge into the master repo.

from proxmark3.

from proxmark3.

it depends...
if it needs to sync with official proxmark. it almost impossible. it like 2000 commits ahead/behind.
but if it needs to have fork of Iceman's fork. it possible, but it have like 60k-100k lines that needs merge.
it not impossible... but it very long work...

from proxmark3.

@merlokk I disagree. This is a common problem that is solved all the time. First find the proper branch point of icemans repo. Then apply all the changes from this repo, which should go into without a problem. Since we are mostly just fixing up the meta data the state of the files should be the same as what is currently here. Then this 'issue' is closed. Now if we want to todo a pull request back into icemans upstream that typically is done via a rebase. That's where we need to sort out the changes since this branch and the current tip of iceman, but that is a separate task for another day. The point is we still have it as an option. Similarly once we have the upstream fixed we can pull from upstream to get the improvements that are going into iceman. Setting up the upstream correctly with a proper fork does enables us not only to pull these changes into iceman but also allows us to pull icemans fixes here.

from proxmark3.

Any news on this @TomHarkness

from proxmark3.