search

jedbrown / git-fat

Simple way to handle fat files without committing them to git, supports synchronization using rsync
BSD 2-Clause "Simplified" License
621 stars 137 forks source link

Big refactor, API incompatible changes #19

Closed abraithwaite closed 1 year ago

abraithwaite commented 10 years ago

Hey @jedbrown, we've been using git-fat at our company and we love it!

We've made a load of changes to suit our needs and some of those changes make it incompatible with yours.

I've also packaged it as a pypi package to make it easy to install (although it has no real usefulness as a module alone).

I don't expect you to merge it because of the API changes, but we wanted to let you know that we love what you've done and to give back what changes we made.

jedbrown commented 10 years ago

This looks great in general. There are some WIP commits in this series, are you still planning to amend those? Can you summarize the "incompatibilities"? I'm okay with UI changes, so long as they are not "dangerous", but would like to keep the format compatible (in the sense that new versions of git-fat should be able to use old repositories; it's okay if users have to upgrade git-fat).

abraithwaite commented 10 years ago

Good point about the WIP commits. I usually don't amend them because I'll sometimes go back to see my train of thought when working on something. I should probably refactor them and update the message before pushing as a good rule of thumb though. To answer your question, I finished the WIP commits in the commit directly following each.

Here are all the incompatibilities I can think of:

Perhaps the best solution is to start versioning and have major versions be completely incompatible with each-other. I believe that's how a lot of projects work, as it's hard to have every beneficial change be backwards compatible.

jedbrown commented 10 years ago

Adding the name of the file is definitely good. I would like to keep those extra commands around because they are handy for importing repositories that have had somewhat sloppy checkins. This is very common in science, and I'd imagine for other users as well. I agree that "shallow" is a better default, and will be happy to change.

The next couple weeks are busy for me, but then I think I will cherry-pick a lot of your excellent work into my branch. I will start versioning, but I do not plan to ever break backward-compatibility for repository format. If there is a load cry from users that have been writing scripts, I'll be more careful to offer compatibility in command-line options.

abraithwaite commented 10 years ago

I'll see if I can implement some backwards compatibility and the import command. I don't think that solves the filename (%f) problem though. That's a change that requires reconfiguration of all repos. There should be something I could do about it though.

Also, I think I read somewhere that using Argparse breaks some versions of Python. Don't worry about trying to cherry-pick too soon though because I am thoroughly enjoying this project. ;-)

With regards to supporting backward-compatibility; to what extent do you consider something backwards compatible? e.g. I could implement something that works with the old placeholder format, but might require different configuration parameters to enable it. Would that be acceptable?

jedbrown commented 10 years ago

If .gitattributes does not include %f, you wouldn't get a filename argument on the command line. Can't you still read from stdin?

Argparse is not available prior to 2.7, but it can be installed with older versions via pip install argparse. 2.7 is more common now than when I started, so I think moving to argparse is good.

Perhaps if it was purely local configuration. I think that .gitfat in the repository should only provide defaults for a remote, and the user should be able to override them locally (e.g., via a [fat] section in .git/config).

abraithwaite commented 10 years ago

@jedbrown, I implemented support for old repos; now I need to implement retroactive import.

ahmadia commented 10 years ago

@abraithwaite @jedbrown - Can you update me on the status of this? We've got an active pull request for packaging git-fat in HashDist, and as far as I can tell, Jed is actively maintaining git-fat, and there is a friendly fork hosted by cyaninc (that has claimed the PyPI git-fat namespace, which is perhaps, not-so-friendly).

Since as far as I can tell, the canonical version is still Jed's git-fat, I would suggest one of two things:

In either situation, the PyPI package for git-fat should be turned over to Jed.

I'm glad to see so much attention to git-fat, which solves a very important problem in the best manner I'm aware of, but this fork needs to be resolved.

Full Disclosure: I know Jed in real life and he's a friend, but I'm trying to act as a neutral packager here. Jed didn't ask me to say any of this, in fact, as far as I can tell, he's been trying to avoid any confrontation in dealing with this. But now it's my problem :)

abraithwaite commented 10 years ago

@ahmadia I'm completely open to handing over the git-fat pypi to Jed. It was just the easiest way for us to handle distributing the package.

I did fix the problems he raised, although I've probably broken a few of them again since I fixed the backwards compatibilities. If there are any other things that would need doing, I'm open to that as well but it looks like there were a handful of changes merged in the mean time that would need to be addressed too (none of them really incapable of being merged back into the changes I made though).

I also should have been more active in this thread regarding getting this back into Jed's repo and it was a bit rude so for that I apologize. Thanks for bumping the thread.

ahmadia commented 10 years ago

Thanks for the quick response @abraithwaite. It sounds like both you and @jedbrown are open to getting this fork resolved. Let me know if there's anything I can do to help.

abraithwaite commented 10 years ago

Just checking in.

I guess I should add that I'd be willing to manage the repository even if it was under @jedbrown's username so long as we can keep the changes we made.

Also, if we can't do that, then we can do a complete fork. We have just come to appreciate the creative name :smile:

Says a coworker:

'git-fat' or 'What I've been doing since I got out of college'

ahmadia commented 10 years ago

@abraithwaite - Thanks! Are you able to resolve the current merge conflicts, or do you need Jed's help?

abraithwaite commented 10 years ago

I think the most reasonable way to get this back in is to figure out what Jed want's to keep from the last six months and cherry-pick those commits back into our fork, then create a new master in Jed's from the result of applying those changes.

abraithwaite commented 9 years ago

I added a note referencing this pull request in the pypi package in the hopes that people are less confused.

mattions commented 9 years ago

I see there was a release on PyPi all the way to 0.5.0 (https://github.com/cyaninc/git-fat/commit/a25555b1204db2a443542f1f825f4e3fc349ea01) and the network activity on this package is quite active.

There is a plan to consolidate and bring all the cool stuff into the fold with the blessing of @jedbrown or you guys have different plans?

Best and thanks for this neat module

abraithwaite commented 9 years ago

Hi @mattions I've actually been lacking the time to properly maintain the cyaninc fork unfortunately. I'm not sure what would have been needed to get it back into the mainline here, but I think it'll probably just sit the way it is.

ahmadia commented 9 years ago

At this point, the projects have diverged enough that it doesn't really make sense for them to keep using the same name. @jedbrown - What do you think?

jedbrown commented 9 years ago

@ahmadia It appears that neither @abraithwaite nor myself have time to integrate the two forks in the near future. In that case, I think it's important to communicate to users that the two forks are not compatible. Names are the most common way to do that, but at this point would require a name change that may be even more confusing to users, thus I don't have a strong preference.