git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: More Beginning Git Questions

From
Jakub Narebski <jnareb@gmail.com>
Date
Sep 23, 2011, 17:42 UTC
Message-ID
<m3ipojqhpm.fsf@localhost.localdomain>
In-Reply-To
<4E7C9AAD.7060209@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> I'm reading the git tutorial at
> http://schacon.github.com/git/gittutorial.html
I recommend reading "Pro Git" book (http://progit.org)
Show 15 quoted lines
> I'm a very literal reader so if something isn't clear
> to me, I try to make the effort to understand it.
> 
> In reading about what happens when Alice pulls from Bob,
> it says:
> 
> "Note that in general, Alice would want her local changes committed
> before initiating this "pull"."
> 
> This is an interesting statement. I'll come back to it shortly.
> 
> "If Bob’s work conflicts with what Alice did since their histories forked,"
> 
> Does this include both changes that Alice has checked in to
> her repository and uncommitted changes in her working tree?

Generally Alice shouldn't have uncommitted changes when doing "git pull".

Show 8 quoted lines
> "Alice will use her working tree and the index to resolve conflicts,"
> 
> How does Alice use her working tree and index? Does this mean
> she makes changes to her working tree so that the conflicts
> no longer exist? How does the index play a part in this?
> I thought that the index gets populated only when a
> "git add" is done. Does Alice need to do "git add" as part
> of the conflict resolution process?
This is actually a very important information.

When there is a merge conflicts, the index gets populated by more than one version: "ours" (i.e. Alice version) in stage 2, "theirs" (i.e. Bob version) in stage 3, and "base" (common ancestor version) in stage 1. The stage 0, where "git add" / "git stage" puts contents of file, is empty.

You can see it using "git ls-files --abbrev --stage".
 
The working area gets populated with version that contains both "ours"
and "theirs" hunks using conflict markers (the 3-way textual merge,
like 'rcsmerge' or 'diff3 -E' does).  Sidenote: you can use "git
checkout --conflict=merge <file>" to re-create this version if you
messed up conflict resolution, or even --conflict=diff3 if you want
"base" (ancestor) version to be shown in conflict markers as
well... but this would discard your changes.

After resolving conflict you do "git add" on resolved file to mark it as done. This leaves you with only newly add-ed stage 0 in the index!

The pre-commit hook might check if you didn't accidentally marked as resolved (added) file with [something that looks like] conflict markers in it.

HTH
-- 
Jakub Narębski
Previous: Matthieu MoyNext: Jon Forrest
Message 3 of 24 in “More Beginning Git Questions”
  1. Jon ForrestSep 23, 2011
  2. Matthieu MoySep 23, 2011
  3. Jakub NarebskiSep 23, 2011
  4. Jon ForrestSep 23, 2011
  5. Mihamina RakotomandimbySep 23, 2011
  6. Jakub NarebskiSep 23, 2011
  7. tacticalSep 24, 2011
  8. Frans KlaverSep 24, 2011
  9. tacticalSep 24, 2011
  10. Seth RobertsonSep 24, 2011
  11. tacticalSep 25, 2011
  12. Jakub NarebskiSep 25, 2011
  13. tacticalSep 25, 2011
  14. Jakub NarebskiSep 25, 2011
  15. tacticalSep 25, 2011
  16. Konstantin KhomoutovSep 26, 2011
  17. tacticalSep 26, 2011
  18. Andrew ArdillSep 26, 2011
  19. tacticalSep 26, 2011
  20. Jakub NarebskiSep 26, 2011
  21. Jakub NarebskiSep 24, 2011
  22. tacticalSep 24, 2011
  23. Jakub NarebskiSep 25, 2011
  24. Junio C HamanoSep 23, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.