Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39432

Re: Slightly OTT - Git

Show all headers | View raw

On Sun, 12 Apr 2020 16:57:19 +0200, Daniele Futtorovic wrote:

> The distributed nature means that your local and remote copies are
> different and somewhat independent things. Because they are different
> and yet woven together, it also means that working across repositories
> (forking) becomes a natural part of the experience.
>
Yes, I understand that, thanks.

My current stumbling block is that the book I have says remarkably little 
about encryption key management in spite of the fact that both Git and 
GitLab (unsurprising) insistence on using them for all network transfers, 
but maybe that just shows the age of the book, (c) 2013.

My main issue at present is that I want to maintain two remotes: one on 
my house server for use as a central repository if I should need to pull 
projects (where 'project' generally means a small set of related programs 
and documentation) and two or three projects need a second remote on 
GitLab (this is code I wrote for the gliding club I'm a member of) where 
we have a group repository of code written by various members and 
covering separate parts of the club operation.

I'm not having problems managing my own remote, but currently the stuff 
on GitLab is a bit more of a problem because they seem to have a local 
rule in play that prevents the remote being initialised without adding a 
README file as part of the process - and this gets in the way when I push 
my stuff into that remote.
 
> Secondly, Git is not a product; it's a tool made by a hacker (to wit,
> Torvalds). This is important to keep in mind because when hackers
> present something, they don't approach it through the lens of use-cases,
> but rather, they lay out its capabilities as a tool. And given that it's
> a very sophisticated tool, that presentation ends up being very complex
> as well.
>
I have no problem with that: or with the variety of tools and commands it 
provides - only that thre O'Reilly pocket guide to Git fails because it 
is extremely light on giving the big picture while its recipes are quite 
narrow in scope and not on a good sequence (it explains comittal before 
mentioning 'git config excludeFile' or .gitignore files.

> In fact, I would say the biggest ongoing effort -- ongoing for years and
> just recently stabilising -- with respects to Git is finding proper
> encapsulations of its huge complexity and power into standardised, and
> thus easily usable, abstracted flows. GitFlow is one of these I would
> recommend having a look at. I would venture guess that your own journey
> with it will follow the same pattern: finding a subset of its functions
> that you integrate into your workflow so you don't have to think of them
> any more -- because not having to think about things is always the
> ultimate goal of thinking.
> 
Thats exactly what I'd like - and where I am at with CVS, though in that 
case all the tools aren't so important because its easy to sort out with 
only 'sudo' and standard Linux tools.

> Aside from local, personal projects, for anything you work on that
> involves other people I would recommend one of the established platforms
> like GitHub and Bitbucket (I've used both and don't have a preference).
> I would also strongly recommend IDE-integrations of Git. IntelliJ does a
> very good job with this, and I expect others do, too. I've found the
> IDE-integration to be preferable to the combination of IDE and a desktop
> GUI -- but perhaps that's a matter of taste.
>
I'm retired, so that's unlikely, but all the same I take your point - 
always use the shop's usual toolset.
 
> In closing, let me reiterate what personally was my main takeaway from
> Git. Whereas often, software tools present us with simple entry points
> which turn out not to be sufficient for real-world requirements, and
> thus force us to dig beyond the surface to suit our needs -- Git is the
> exact opposite. It's a beautiful thing.
>
It seems good - I'm just  a little wary of it using its own binary blobs 
for storage after all these years CVS using plain old directories and 
files.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Slightly OTT - Git Martin Gregorie <martin@mydomain.invalid> - 2020-04-10 12:44 +0000
  Re: Slightly OTT - Git Andreas Leitgeb <avl@logic.at> - 2020-04-12 14:37 +0000
  Re: Slightly OTT - Git Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2020-04-12 16:57 +0200
    Re: Slightly OTT - Git Martin Gregorie <martin@mydomain.invalid> - 2020-04-12 16:53 +0000

csiph-web