Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil SCM

fossil-scm.org

Post reply on HN
Print view View original

91–100 of 147 posts

Re: Fossil SCM

#91

Post by sytse »

eslaught wrote: post #87
sytse wrote: post #83

Earlier quoted context omitted.

Thanks, we're indeed working on making the UI faster in https://about.gitlab.com/2017/02/06/vue-big-plan/ I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation: 1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something. 2. Fossil timeline seems similar to GitLab Activity http…

The issue is not that Gitlab is missing any of the pieces. The issue, I believe, is the organization of such pieces so that you can find them intuitively. This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon f…

Thanks for the response, and I'm glad that it is better than it used to be.

In GitLab people can have a project without a repository, for example with just a wiki or an issue tracker. For that reason we use different words for it.

Single people also use GitLab as a single tenant we prefer to use the word group over organization. That will also fit better when we introduce nested groups in GitLab 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772

Good point about showing files by default, we're discussing that in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834

Thanks for using GitLab!

Re: Fossil SCM

#92

Post by gkya »

tacostakohashi wrote: post #81
gkya wrote: post #76

Earlier quoted context omitted.

I firmly believe that GitHub has at least 40% role in git's success. Another 40% is Linus, and the remaining 20% is git's technical merits.

Sounds about right to me... but it's hard to decouple things so neatly. It wouldn't really be possible to create an SVNHub that worked as well as github.

wrt SVNHub, well, probably you're right. But on the technical level any Hub would be at least nearly as good as GitHub. And git didn't invent DVCS.

Re: Fossil SCM

#93

Post by sytse »

e12e wrote: post #80

I tried using Fossil as a DVCS/Project management tool for a class I'm currently teaching - but in the end I couldn't quite figure out self-registration combined with allowing authenticated push in a way that worked for ~25 students without needing much instruction/hand-holding. If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up usi…

Glad to hear you're considering using GitLab. We have an importer for Gitea but not for Gogs https://docs.gitlab.com/ee/workflow/importing/README.html so I think you might consider a batch import https://docs.gitlab.com/ce/raketasks/import.html

Re: Fossil SCM

#94

Post by __david__ »

tacostakohashi wrote: post #82
qznc wrote: post #79

Earlier quoted context omitted.

On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.

I disagree completely - I think these things have the same properties as source code. Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.

You might like https://github.com/brandonson/evict. I used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in a bad way. I've been meaning to switch to evict but haven't ever been able to get it to compile :-).

Re: Fossil SCM

#95

Post by sqrt17 »

tacostakohashi wrote: post #81
gkya wrote: post #76

Earlier quoted context omitted.

I firmly believe that GitHub has at least 40% role in git's success. Another 40% is Linus, and the remaining 20% is git's technical merits.

Sounds about right to me... but it's hard to decouple things so neatly. It wouldn't really be possible to create an SVNHub that worked as well as github.

Before everyone got onto GitHub, there was SourceForge and GoogleCode. Both worked well for a lot of people for quite some while. Also, if you really want to, you can use the SVN interface of GitHub and never go through git. You could, in its time, also use Google code with git repositories but without the pileup if nice little things that make GitHub more than just a git hosting service

Re: Fossil SCM

#96

Post by jdmichal »

BeetleB wrote: post #34
iso-8859-1 wrote: post #22

Earlier quoted context omitted.

If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underl…

So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily…

Git actually maintains the following:

Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact.

Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.

Re: Fossil SCM

#97

Post by OJFord »

lvh wrote: post #66
OJFord wrote: post #62

Earlier quoted context omitted.

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs) No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.

Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) mean that git gets useful new features?

> Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes)

Branch management:

    # creation
    git branch foobar

    # listing
    git branch

    # renaming
    git branch -m barfoo

    # relocation
    git branch -f barfoo

    # deletion
    git branch -d barfoo
Working directory management:

    # change WD to branch
    git checkout foo

    # change WD to state of HEAD
    git checkout -- .

    # change WD to new branch forking HEAD
    git checkout -b bar

    # ...
As an aside, `--` is UNIX for 'end of options'; nothing git-specific. I mention this because that's another thing that seems to come up with people saying it's some mad git option that makes no sense and you just have to remember it.

> mean that git gets useful new features?

I don't really understand what you mean by this. Is something only 'powerful' if it 'gets useful new features'?

--

I'm not saying it's easy for newcomers, I'm just saying the difficulty is biased to the early stages of the learning curve (I certainly experienced it, I used to fear git - now I fear lack of it) and disputing the claim that it isn't powerful.

Re: Fossil SCM

#98

Post by vonuebelgarten »

BeetleB wrote: post #11
jjirsa wrote: post #3

No/manual rebase sounds awful

Genuinely curious: Why do you need rebasing? I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?

>Genuinely curious: Why do you need rebasing?

Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team).

Also, rewriting history (in the good sense of the term).

Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand.

For git, history is a tool for documenting the project -- and I love it.

Re: Fossil SCM

#99

Post by BeetleB »

amluto wrote: post #39
BeetleB wrote: post #11

Earlier quoted context omitted.

Genuinely curious: Why do you need rebasing? I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?

I use git rebase -i as a way to develop. If I make a series of changes and the middle one doesn't compile or I want to restructure things, I'll use git rebase -i. The outcome is a set of patches that a suitable to send out for review. hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.

Interesting: For the short time I used mq, I was quite impressed with the functionality - but did not use a GUI and eventually stopped using it because of the overhead in typing.

Re: Fossil SCM

#100

Post by Rusky »

BeetleB wrote: post #34
iso-8859-1 wrote: post #22

Earlier quoted context omitted.

If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underl…

So let's say I branched off of master 3 months ago, and slowly developed the feature. Now if I rebase, will the commit history show all my local commits at the time they occurred (i.e. spread across 3 months)? Or will it show up as a single commit at the end? As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily…

It will show them at the time they occurred, with an additional notation for when the rebase command recreated them.

On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.

Post reply on HN