[git-users] Git sub modules

[chunnu]

Hi,

I m new to git repository, with a star team back ground. In my project I 
have something called sub modules. I understand that these are a single 
repository in the git used by 5 different projects. 
But I m very confused about "updating the submodule references". What does 
this exactly mean? Please note my role is not a developer but need to 
understand this from a developer perspective as well. 

Can any one please explain?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Submodules, subtrees or something else?

[Bojan Stankovic]

Hello!

I have a situation with a larger project that has lots of modules/libraries 
with their respective repos. Most of these modules are dependencies of 
other modules which are than dependencies of a project. And now it has come 
to the point where the main project has several sub-projects and many of 
modules are being shared. Some dependencies are more than 3-4 levels deep.

I have read that it is possible to update/pull submodules inside of a 
project, but that works only for 1st level of submodules. Let's say that 
those submodules have their own submodules (2nd level) and that some 1st 
level submodules share the same 2nd level submodules. Also, 2nd lvl 
submodules have their submodules (lvl3), etc. Now what I should do is to 
firstly push changes made in 3rd level, than update submodules in 2nd level 
modules and push those, now I can go to 1st level, update and push, and 
finally update my project submodules and push those.

This is now not only more work, but it still doesn't solve my problem why I 
need something like this and that is to be able to easily push and pull 
multiple repositories when changes were being made to those that dependent 
on each other. It can easily happen that someone in a team pushes changes 
in 4 of 5 repos, and when other members pull all except this one production 
line stops until error has been found.

What can I do about this? Maybe some advices about workflow, has anyone 
else encountered this problem or is there some feature in Git that solves 
this.


Best regards,
Bojan

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: git pull-push ?

[Konstantin Khomoutov]

On Thu, 26 Jun 2014 04:42:38 -0700 (PDT)
Pierre-François CLEMENT  wrote:

[...]
> What I do not understand however, is what made you think *treaki*
> needed these explanations in the first place? Don't get me wrong,
> it's no big deal; but I could have asked the same question, and I
> would have appreciated not being told stuff I already know about
> git-pull / git-fetch / git-merge.

Simply because I'm staying in the industry for long enough time to
learn that terse and moot questions (like the OP's one) most of the
time fall into the "XY problem" class [1].  I mean, if Git folks
(most of which, trust me, are top-notch programmers and, obviously Git
gurus) did not feel any need to implement git-pull-push, there's a
reason to this, and hence I tried to explain why there's no such tool.
I mean, I tried to make the OP reconsider his problem rather than
merely providing a solution (which I did as well).  I think that blind
pull+push is a suboptimal thing; you think it's not, and that's fine,
but we both are entitled to our own opinions and are free to express
them, which I did.

1. http://meta.stackexchange.com/a/66378

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: git pull-push ?

[Pierre-François CLEMENT]

Le jeudi 26 juin 2014 13:04:18 UTC+2, Konstantin Khomoutov a écrit :
>
> On Thu, 26 Jun 2014 01:44:34 -0700 (PDT) 
> Pierre-François CLEMENT > wrote: 
>
> > > The imaginary `git pull-push` has no sense as `git pull` might 
> > > legitimately result in a merge conflict.  Note that `git pull` is a 
> > > sort of macro for `git fetch` + `git merge` which just makes 
> > > certain (rather strong) assumptions about your workflow.  Think 
> > > about this a bit more and you'll see that in fact you want `git 
> > > fetch-merge-push` which looks rather awkward and only suitable for 
> > > some automated changeset processing (and, honestly, I can't even 
> > > fancy one).m 
> > 
> > Git-pull (followed or not by git-push) is a perfectly sensible set of 
> > commands imo. Git-pull *is* a shortcut for git-fetch + git-merge 
> > upstream, so if you're not planning on investigating what commits 
> > you're pulling why bother doing in two steps (fetch then merge) 
> > rather than one? 
>
> Well, that's why I wrote 
>

Not exactly, cuz' it feels like you're not supporting the use of *git-pull*. 
All I'm sayin' is that people can have perfectly legitimate reasons to use 
it.

Le jeudi 26 juin 2014 13:04:18 UTC+2, Konstantin Khomoutov a écrit : 

>
> > ... which looks rather awkward and only suitable for some automated 
> > changeset processing (and, honestly, I can't even fancy one). 
>
> The chief problem with merging, as I perceive it, it that quite some 
> number of people understands it either as a sort of burden or a purely 
> mechanical process.  In reality, when a VCS is used for 
> development (or some code base or something like this) merging is an 
> engeneering duty: reconciling your changes with someone other's changes 
> is no really different from writing new code, and it's of the same 
> importance.  Those who don't understand this (and not properly trained 
> to do so) are entitled to repeat things like described in [1]. 
>
> That is, even if merging went okay and no conflict was indicated, this 
> does not mean the resulting state of the repository is OK. 
> You have to verify it's okay -- by inspecting the results, by 
> building and running the test suite etc. 
>
> Only truly trivial cases are okay for the pull+push paradigm.  But 
> anyway to deem them trivial you really have to know what you're pulling 
> which narrows the set of suitable workflows to an almost empty set 
> IMO.  For instance, I do routinely use Git for one-man micro projects 
> where I have a repo on each of machines I work at and a central bare 
> repo to gateway the changes between all the involved repos.  In this 
> workflow I just always push to the same branch in the central repo, and 
> when at the next work place, I do fetching and --ff-only merging locally 
> which is often reduced to something like 
>
>   git fetch origin +branch:master 
>
> 1. http://randyfay.com/content/avoiding-git-disasters-gory-story 
>

I agree with *almost* all of this, although I'll add to it that not all 
users need to go this far in their workflow. It's probably better if they 
do, but it's not required -- especially if you have a project maintainer 
for instance. They might also feel more comfortable investigating the files 
or the test suite's results rather than the repo's tree. I personally 
prefer investigating the commits too, but I do understand people who don't.

What I do not understand however, is what made you think *treaki* needed 
these explanations in the first place? Don't get me wrong, it's no big 
deal; but I could have asked the same question, and I would have 
appreciated not being told stuff I already know about git-pull / git-fetch 
/ git-merge.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Re: git pull-push ?

[Konstantin Khomoutov]

On Thu, 26 Jun 2014 01:44:34 -0700 (PDT)
Pierre-François CLEMENT  wrote:

> > The imaginary `git pull-push` has no sense as `git pull` might 
> > legitimately result in a merge conflict.  Note that `git pull` is a 
> > sort of macro for `git fetch` + `git merge` which just makes
> > certain (rather strong) assumptions about your workflow.  Think
> > about this a bit more and you'll see that in fact you want `git
> > fetch-merge-push` which looks rather awkward and only suitable for
> > some automated changeset processing (and, honestly, I can't even
> > fancy one).m
> 
> Git-pull (followed or not by git-push) is a perfectly sensible set of 
> commands imo. Git-pull *is* a shortcut for git-fetch + git-merge
> upstream, so if you're not planning on investigating what commits
> you're pulling why bother doing in two steps (fetch then merge)
> rather than one?

Well, that's why I wrote

> ... which looks rather awkward and only suitable for some automated
> changeset processing (and, honestly, I can't even fancy one).

The chief problem with merging, as I perceive it, it that quite some
number of people understands it either as a sort of burden or a purely
mechanical process.  In reality, when a VCS is used for
development (or some code base or something like this) merging is an
engeneering duty: reconciling your changes with someone other's changes
is no really different from writing new code, and it's of the same
importance.  Those who don't understand this (and not properly trained
to do so) are entitled to repeat things like described in [1].

That is, even if merging went okay and no conflict was indicated, this
does not mean the resulting state of the repository is OK.
You have to verify it's okay -- by inspecting the results, by
building and running the test suite etc.

Only truly trivial cases are okay for the pull+push paradigm.  But
anyway to deem them trivial you really have to know what you're pulling
which narrows the set of suitable workflows to an almost empty set
IMO.  For instance, I do routinely use Git for one-man micro projects
where I have a repo on each of machines I work at and a central bare
repo to gateway the changes between all the involved repos.  In this
workflow I just always push to the same branch in the central repo, and
when at the next work place, I do fetching and --ff-only merging locally
which is often reduced to something like

  git fetch origin +branch:master

1. http://randyfay.com/content/avoiding-git-disasters-gory-story

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: git log --graph

[Thomas Ferris Nicolaisen]

On Thursday, June 26, 2014 10:53:41 AM UTC+2, dexter ietf wrote:
>
> how to interpret the output of git log --graph, is there any explanation 
> or good documentation available for this.
>   
>

The graph is a good way to get your bearings on how different commits and 
branches relate to each other. However, it becomes much more usable, or 
readable, if you add a few more parameters:

git log --graph --oneline --decorate --all

(See git log --help for an explanation of each parameter.)

For quick access, many people create an alias like git logtree :

git config --global alias.logtree "log --graph --oneline --decorate --all"

If you still don't like the ASCII-art graphics, try some graphical tool, 
like gitk --all

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] git log --graph

[dexter ietf]

how to interpret the output of git log --graph, is there any explanation or 
good documentation available for this.

-dexter

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: git pull-push ?

[Pierre-François CLEMENT]

Le mercredi 25 juin 2014 13:15:23 UTC+2, Konstantin Khomoutov a écrit :

> The imaginary `git pull-push` has no sense as `git pull` might 
> legitimately result in a merge conflict.  Note that `git pull` is a 
> sort of macro for `git fetch` + `git merge` which just makes certain 
> (rather strong) assumptions about your workflow.  Think about this a 
> bit more and you'll see that in fact you want `git fetch-merge-push` 
> which looks rather awkward and only suitable for some automated 
> changeset processing (and, honestly, I can't even fancy one).m
>

Git-pull (followed or not by git-push) is a perfectly sensible set of 
commands imo. Git-pull *is* a shortcut for git-fetch + git-merge upstream, 
so if you're not planning on investigating what commits you're pulling why 
bother doing in two steps (fetch then merge) rather than one?

Le mercredi 25 juin 2014 09:26:50 UTC+2, treaki a écrit :
>
> Hi,
>
> i am using git with an ssh remote running at my router@home. the most 
> times i use it the following way:
>
> git pull
> git push
>
> the problem i see it that he ueses 2 ssh sessions for this job, so i would 
> like to ask if there is a way to do everything together using one session.
>
> thanks for your help
>

 You're right, running those two commands in a row does open two SSH 
connections, one for the git-pull and another one for the git-push. It's 
not a problem in itself, but if you're looking for optimising this process 
as I think you are, I'd definitely back Konstantin's suggestion of setting 
up SSH multiplexing: it will allow any of your processes using SSH to 
re-use existing SSH connections instead of opening new ones each time. Have 
a look at the ssh_config man page 
,
 
in particular the *ControlMaster*, *ControlPath* and *ControlPersist* 
options.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.