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 
> two?

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 
passes tests".

(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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to