On 2016-05-22, at 9:31 AM, Sharan Basappa <sharan.basa...@gmail.com> wrote:
> Dear Philip, Others,
> Thanks a lot. I have some follow-up questions.
> I am using a simple scenario to get additional clarity.
> 1) I have 4 files in my branch (a,b,c,d)
> 2) I modify a
> 3) I add a
> 4) I modify b,c
> 5) I add b,c
> 6) I commit
> 7) I modify d
> 8) I commit d
> 9) I push to remote
> Does step 6) above result in single commit object (single SHA reference) or
One commit object. That commit object contains (eventually) a full directory
tree reference to every file in the project as of that commit.
Three files have been changed, so three SHA references are different. Because
of that, each node that describes a directory will differ, so everything above
that will have a new blob/node describing the files and subdirectories below
> From a developer engineer's perspective, what does commit signify? Does it
> mean something key development is complete?
> I ask this question to understand when a developer would do some development
> but would make multiple commits.
Depends on your workflow.
Some people say "commit early, commit often".
Some people say "commit when it compiles"
I personally do "branch, then commit early, commit often, merge back when it
(Any given commit on the subbranch will probably compile, but almost certainly
has half-implemented features that just won't work.)
Some people take this a step further, and say "Do your work on a branch, then
commit a single squashed commit of the whole branch".
As far as I can tell, not only is there no "one true workflow", trying to
figure out what workflow is right for the situation you are in is exceedingly
non-trivial, and I have not seen it well-addressed in any of the guides for
learning GIT that I have seen yet.
> Similarly, if during push step, if it is found that remote is ahead of local
> (and most likely requires merging) then does it mean anything wrt to the
> already computed SHA?
> I assume that already computed SHA has no meaning.
I am not the person to ask here. My pushes only go to a repository I work on.
I would *love* to see a good writeup on how to manage, and contribute to, a
repository that will accept updates from many people doing pull requests,
letting you update as the master does, without losing your own "features in
progress". Yes, this is supposed to be git's area, but trying to understand
from the docs how to manage it, especially if it later turns out that the
"upstream master" is going off in an incompatible direction, and you want to
take over managing a fork that is doing something else, and accepting pull
requests from others.
It doesn't help that as far as I can tell, "Pull Requests" are actually things
that Github and Bitbucket do that are not in the core base git.
Entertaining minecraft videos
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
For more options, visit https://groups.google.com/d/optout.