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

Groups > comp.lang.java.programmer > #39428 > unrolled thread

Slightly OTT - Git

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#39428 — Slightly OTT - Git

For a variety of reasons I won't bore you with, I'm having to find out 
about Git in a hurry, which is a bit of a shock to the system, since I've 
been using CVS since the late '80s.

I have a copy of the "Git pocket Guide", but its almost useless - OK if 
you need to do straight forward stuff for which it has a recipe, but 
almost useless for getting an understanding on how Git works, how its 
designed to work and how to use it in rather more complex circumstances, 
such as with multiple remote repositories and the likes of GitLab.

"Professional Git" by Brent Laster (pub Wrox) looks like a possibility, 
so I'd appreciate comments about it and/or pointers to other books.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [next] | [standalone]

#39430

Martin Gregorie <martin@mydomain.invalid> wrote:
> For a variety of reasons I won't bore you with, I'm having to find out 
> about Git in a hurry, which is a bit of a shock to the system, since I've 
> been using CVS since the late '80s.
>
> I have a copy of the "Git pocket Guide", but its almost useless - OK if 
> you need to do straight forward stuff for which it has a recipe, but 
> almost useless for getting an understanding on how Git works, how its 
> designed to work and how to use it in rather more complex circumstances, 
> such as with multiple remote repositories and the likes of GitLab.
>
> "Professional Git" by Brent Laster (pub Wrox) looks like a possibility, 
> so I'd appreciate comments about it and/or pointers to other books.

https://xkcd.com/1597/ and https://explainxkcd.com/wiki/index.php/1597:_Git

and then there is also:
https://www.youtube.com/watch?v=1ffBJ4sVUb4

hth and he

[toc] | [prev] | [next] | [standalone]

#39431

On 2020-04-10 14:44, Martin Gregorie wrote:
> For a variety of reasons I won't bore you with, I'm having to find out 
> about Git in a hurry, which is a bit of a shock to the system, since I've 
> been using CVS since the late '80s.
> 
> I have a copy of the "Git pocket Guide", but its almost useless - OK if 
> you need to do straight forward stuff for which it has a recipe, but 
> almost useless for getting an understanding on how Git works, how its 
> designed to work and how to use it in rather more complex circumstances, 
> such as with multiple remote repositories and the likes of GitLab.
> 
> "Professional Git" by Brent Laster (pub Wrox) looks like a possibility, 
> so I'd appreciate comments about it and/or pointers to other books.
> 
While I can't point you to specific resources for Git (I've found the
various online tutorials sufficient, if cumbersome to seep through),
here's a few observations derived from my working with it for a long
time and which may or may not prove useful.

First and perhaps most importantly, get your head wrapped around the DAG
(directed acyclic graph) concept, if you haven't already. That and the
distributed nature of Git is the most important thing to have in mind
when working with it.

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.

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.

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.

Besides local and remote copies, and the pull requests this entails, you
need to understand merging, and the difference between merging and
rebasing -- which is one I, after a number of years, must admit I still
haven't figured out completely; but that is mostly because I haven't
really had to so far.

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.

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.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#39432

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web