@@ -68,7 +68,7 @@ HOW MERGE WORKS --------------- A merge is always between the current `HEAD` and one or more-remote branch heads, and the index file must exactly match the+branch heads (remote or local), and the index file must exactly match the tree of `HEAD` commit (i.e. the contents of the last commit) when it happens. In other words, `git-diff --cached HEAD` must report no changes.
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:44:19
On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy [off-list ref] wrote:
"Paolo Ciarrocchi" [off-list ref] writes:
quoted
"A merge is always between the current HEAD and one or more remote
branch heads"
I think this is just wrong. Would this be correct?
Sounds better than the original document,
however I'm still having some problems in visualizing what happens
when I type "git fetch" followed by "git merge".
@@ -68,7 +68,7 @@ HOW MERGE WORKS --------------- A merge is always between the current `HEAD` and one or more-remote branch heads, and the index file must exactly match the+branch heads (remote or local), and the index file must exactly match the
When I run the command git fetch the objects are downloaded from the remote
branch and locally stored in the objects database.
Both the working tree and index are not touched by this operation.
Is this correct?
How can I look to what I just downloaded?
Should I simply do a git diff?
Backing to the documentation, your proposal is:
A merge is always between the current `HEAD` and one or more
branch heads (remote or local), and the index file must exactly match the
In case of a git fetch + git merge the merge is between the current
`HEAD` and the
downloaded objects. Is correct to define it `branch heads`?
Maybe (read it: for sure) I'm a bit confused by the git terminology
but I really feel that
other newbies are not easily understanding this process.
Thanks.
ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:44:19
On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:
On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy [off-list ref] wrote:
quoted
"Paolo Ciarrocchi" [off-list ref] writes:
quoted
"A merge is always between the current HEAD and one or more remote
branch heads"
I think this is just wrong. Would this be correct?
Sounds better than the original document,
however I'm still having some problems in visualizing what happens
when I type "git fetch" followed by "git merge".
@@ -68,7 +68,7 @@ HOW MERGE WORKS --------------- A merge is always between the current `HEAD` and one or more-remote branch heads, and the index file must exactly match the+branch heads (remote or local), and the index file must exactly match the
Yes, this is much better. A merge may occur with any other branches,
local or remote, or even with a tag, or any other random commit
reference for that matter.
When I run the command git fetch the objects are downloaded from the remote
branch and locally stored in the objects database.
Both the working tree and index are not touched by this operation.
Is this correct?
Yes. The fetch operation will figure out, with the remote machine, what
is the set of objects that you already have and the set that you don't
have so the remote machine will create and send you a pack of only the
objects you're missing. And the remote machine will also reduce it to
deltas against objects that you already have when possible so the
transferred pack is even smaller. Once that pack has successfully been
received, then the branch head for which this pack was requested will be
updated to point at the latest commit for that branch.
How can I look to what I just downloaded?
Should I simply do a git diff?
If you have reflog enabled (it should be by default) then a good thing
to remember is the @{1} notation. For example, if the fetch updated the
origin/master branch, then origin/master@{1} is what your origin/master
was before being updated. To see the difference between the previous
and the current state of origin/master, you can do:
git diff origin/master@{1}..origin/master
Or to see the list of new commits:
git log origin/master@{1}..origin/master
git log -p origin/master@{1}..origin/master
Etc.
This notation is a bit obnoxious and the re were suggestions about
addind the equivalent origin/master@{1..} but that didn't materialize
yet.
Backing to the documentation, your proposal is:
A merge is always between the current `HEAD` and one or more
branch heads (remote or local), and the index file must exactly match the
In case of a git fetch + git merge the merge is between the current
`HEAD` and the
downloaded objects. Is correct to define it `branch heads`?
A merge doesn't happen between a branch and some objects. Please don't
see it that way. Objects are at a lower level of abstraction. What a
fetch does is to make sure your version of a branch (say origin/master)
matches the remote version of the branch "master" on server "origin".
If you happen to already have all the needed objects already, then no
objects will be transferred and only the branch reference will be
updated.
The merge operation really works at the commit graph level in order to
jointwo or more branches together. Objects associated to the involved
branches are only checked so to make sure the merging of the specified
branches does not create a conflict (and to fix it otherwise). If a
merge conflict is fixed (either manually or automatically) then new
objects corresponding to the modified files are locally created but the
previously existing objects remain unchanged. But object handling
during a merge is really a low level thing.
Maybe (read it: for sure) I'm a bit confused by the git terminology
but I really feel that
other newbies are not easily understanding this process.
I suggest you have a look at the following article:
http://eagain.net/articles/git-for-computer-scientists/
It is really well written, with the right level of vulgarization to make
the Git concept really obvious very quickly.
Nicolas
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:44:19
On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre [off-list ref] wrote:
On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:
quoted
On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy [off-list ref] wrote:
quoted
"Paolo Ciarrocchi" [off-list ref] writes:
quoted
"A merge is always between the current HEAD and one or more remote
branch heads"
I think this is just wrong. Would this be correct?
Sounds better than the original document,
however I'm still having some problems in visualizing what happens
when I type "git fetch" followed by "git merge".
@@ -68,7 +68,7 @@ HOW MERGE WORKS --------------- A merge is always between the current `HEAD` and one or more-remote branch heads, and the index file must exactly match the+branch heads (remote or local), and the index file must exactly match the
Yes, this is much better. A merge may occur with any other branches,
local or remote, or even with a tag, or any other random commit
reference for that matter.
It's probably a good idea to mention the tag as well.
Something like:
A merge is always between the current `HEAD` and one or more
branch heads (remote or local) or tags, and the index file must
exactly match the
quoted
When I run the command git fetch the objects are downloaded from the remote
branch and locally stored in the objects database.
Both the working tree and index are not touched by this operation.
Is this correct?
Yes. The fetch operation will figure out, with the remote machine, what
is the set of objects that you already have and the set that you don't
have so the remote machine will create and send you a pack of only the
objects you're missing. And the remote machine will also reduce it to
deltas against objects that you already have when possible so the
transferred pack is even smaller. Once that pack has successfully been
received, then the branch head for which this pack was requested will be
updated to point at the latest commit for that branch.
OK, that's now completely clear and understood.
quoted
How can I look to what I just downloaded?
Should I simply do a git diff?
If you have reflog enabled (it should be by default) then a good thing
to remember is the @{1} notation. For example, if the fetch updated the
origin/master branch, then origin/master@{1} is what your origin/master
was before being updated. To see the difference between the previous
and the current state of origin/master, you can do:
git diff origin/master@{1}..origin/master
Or to see the list of new commits:
git log origin/master@{1}..origin/master
git log -p origin/master@{1}..origin/master
Etc.
Very nice, I didn't find in the documentation.
I'll read again the documents and if needed, I'll propose some new text.
This notation is a bit obnoxious and the re were suggestions about
addind the equivalent origin/master@{1..} but that didn't materialize
yet.
Mybe it's just me but wouldn't be very nice to have a simple command
to look at what data have been used for updating the currente branch?
i.e.
git fetch
git diff -- fetch (which is an alias of git diff
origin/master@{1}..origin/master)
And how about a repository which have reflogs disabled?
quoted
Backing to the documentation, your proposal is:
A merge is always between the current `HEAD` and one or more
branch heads (remote or local), and the index file must exactly match the
In case of a git fetch + git merge the merge is between the current
`HEAD` and the
downloaded objects. Is correct to define it `branch heads`?
A merge doesn't happen between a branch and some objects. Please don't
see it that way. Objects are at a lower level of abstraction. What a
fetch does is to make sure your version of a branch (say origin/master)
matches the remote version of the branch "master" on server "origin".
If you happen to already have all the needed objects already, then no
objects will be transferred and only the branch reference will be
updated.
OK.
The merge operation really works at the commit graph level in order to
jointwo or more branches together. Objects associated to the involved
branches are only checked so to make sure the merging of the specified
branches does not create a conflict (and to fix it otherwise). If a
merge conflict is fixed (either manually or automatically) then new
objects corresponding to the modified files are locally created but the
previously existing objects remain unchanged. But object handling
during a merge is really a low level thing.
quoted
Maybe (read it: for sure) I'm a bit confused by the git terminology
but I really feel that
other newbies are not easily understanding this process.
I suggest you have a look at the following article:
http://eagain.net/articles/git-for-computer-scientists/
It is really well written, with the right level of vulgarization to make
the Git concept really obvious very quickly.
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:44:19
On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:
On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre [off-list ref] wrote:
quoted
If you have reflog enabled (it should be by default) then a good thing
to remember is the @{1} notation. For example, if the fetch updated the
origin/master branch, then origin/master@{1} is what your origin/master
was before being updated. To see the difference between the previous
and the current state of origin/master, you can do:
git diff origin/master@{1}..origin/master
Or to see the list of new commits:
git log origin/master@{1}..origin/master
git log -p origin/master@{1}..origin/master
Etc.
Very nice, I didn't find in the documentation.
I'll read again the documents and if needed, I'll propose some new text.
I found the reflog notation burried in git-rev-parse.txt. Maybe some
example usage could be added to more frequently used commands.
quoted
This notation is a bit obnoxious and the re were suggestions about
addind the equivalent origin/master@{1..} but that didn't materialize
yet.
Mybe it's just me but wouldn't be very nice to have a simple command
to look at what data have been used for updating the currente branch?
i.e.
git fetch
git diff -- fetch (which is an alias of git diff
origin/master@{1}..origin/master)
You still think in terms of "data used to update a branch". There is no
such direct relation between the fetched data (objects) and the updated
branch heads. What you do when listing the commits found between
origin/master@{1} and origin/master@{0} (or simply origin/master wich
is equivalent to origin/master@{0}) does not necessarily correspond to
the data you received during the fetch. For example, it is possible
that half of those commits were already part of another branch in your
repository, hence the fetch operation won't download them again. Still,
the origin/master branch now has acquired them all which wasn't the case
before. To really _see_ the actually received data during a fetch
requires internal Git knowledge and digging in the pack directory --
there is no (need for any) UI for that.
And how about a repository which have reflogs disabled?
Well, just re-enable them. ;-)
Since they're on by default, if you turned them off then you surely know
what you're doing and why.
Nicolas
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:44:19
On Mon, Mar 3, 2008 at 7:07 PM, Nicolas Pitre [off-list ref] wrote:
[...]
You still think in terms of "data used to update a branch". There is no
such direct relation between the fetched data (objects) and the updated
branch heads. What you do when listing the commits found between
origin/master@{1} and origin/master@{0} (or simply origin/master wich
is equivalent to origin/master@{0}) does not necessarily correspond to
the data you received during the fetch. For example, it is possible
that half of those commits were already part of another branch in your
repository, hence the fetch operation won't download them again. Still,
the origin/master branch now has acquired them all which wasn't the case
before. To really _see_ the actually received data during a fetch
requires internal Git knowledge and digging in the pack directory --
there is no (need for any) UI for that.
Yes, this time it was me using a completely wrong terminology.
What I was looking for is what Sergei suggested.
> And how about a repository which have reflogs disabled?
Well, just re-enable them. ;-)
Since they're on by default, if you turned them off then you surely know
what you're doing and why.
Oh well, very true!
Maybe it's again just me which is still not used to git fetch (or my
mental translation of °fetch° in Italian)
but I found easier to "visualize" the commang "git remote update"
which in my setup alway means
"Fetch updates all the remotes in the repository"
Again, thank you for your comments and for your time.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/