git pull

git pull

[matteo brutti]

Hi,
i'm learning about git and soon have a question.
My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
local i thought that when i committ, i'll found the files on repo
changed, it was not so! I learn i have to use git pull, but i didn't
understand why.
I made some tries, put my repo in /home/user/myrepo cloned in
/home/user/myclones changed files and committed and the changes was in
the repo without any need of pulling, and i have permission to write
to /dev/sda6, so why have i to pull changes?

Thanks.


Matteo

Re: git pull

[Nicolas Sebrecht]

The 17/05/10, matteo brutti wrote:

> Hi,

Hi,

> i'm learning about git and soon have a question.
> My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
> local i thought that when i committ, i'll found the files on repo
> changed, it was not so! I learn i have to use git pull, but i didn't
> understand why.

"/dev/sda" is the physical device and "/dev/sda6" a physical partition
of the hard drive "sda".

Inside a partition, we may find (usually after the installation process
of the system) a filesytem. The filesytem contains the files we can
access to when mounted to the virtual filesytem (begining at "/").

While using user application which works on usual files (like git does),
we don't care about the underlying local hard drive device ("/dev/sda"
here).

You can safely forget all the "/dev/<something>" things here.

> I made some tries, put my repo in /home/user/myrepo cloned in
> /home/user/myclones changed files and committed and the changes was in
> the repo without any need of pulling, and i have permission to write
> to /dev/sda6, so why have i to pull changes?

With the above in mind, could you please try to rephrase your problem
(and maybe provide a basic use case with the commands to reproduce it) ?

-- 
Nicolas Sebrecht

Re: git pull

[hasen j]

On 17 May 2010 15:51, matteo brutti <webmbackslash@gmail.com> wrote:
> Hi,
> i'm learning about git and soon have a question.
> My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
> local i thought that when i committ, i'll found the files on repo
> changed, it was not so! I learn i have to use git pull, but i didn't
> understand why.
> I made some tries, put my repo in /home/user/myrepo cloned in
> /home/user/myclones changed files and committed and the changes was in
> the repo without any need of pulling, and i have permission to write
> to /dev/sda6, so why have i to pull changes?
>
> Thanks.
>
>
> Matteo

If you clone repoA into repoB, then you commit some new changes to
repoA, you won't see the same changes in repoB unless you pull them
from repoA.

I don't think it matters whether or not they are in the same partition or not.

As far as I understand, if you clone within the same partition, the
object database might be hard-linked. This won't affect what files you
have checked out though. It would just mean that you won't need to
"fetch", because the objects are already there.

GIT pull

[cvalusek]

My apologies if this isn't the appropriate place to post this. We are using
the windows port msysgit so I understand if I need to post over there first.

I have also posted this on stackoverflow. Here is a link to the question
there:

http://stackoverflow.com/questions/10110401/why-doesnt-git-clean-up-when-aborting-a-merge-triggered-from-pulling-in-changes

My team has had a lot of trouble with GIT lately because of aborted pull
commands.

If a user has local modifications not on the index and does a pull, I have
seen git attempt to start applying the merge to master and abort. The whole
checkout is then left in a terrible state that is nearly unrecoverable. In
the past, I thought GIT would run some sort of check to identify these
problems before it attempts the merge.

Even with a clean state (nothing to commit), I have seen the same thing
randomly happen at least once. I understand that without rebasing, you may
be forced to resolve merge conflicts when you pull, but this is not what is
happening though.

We are using gitolite. I am mainly using command line and have yet to run
into these issues. The rest of the team is using the git-gui or in 1 case
TortoiseGit.

git-gui version 0.13.GITGUI
git version 1.7.8.msysgit.0
Tcl/Tk version 8.5.1
TortoiseGit 1.7.6.0

We are not working with branches as much as we could, but feel like this
should be working.
Why does GIT allow you to try to pull when it is going to train-wreck?
Why does GIT not abort cleanly?

--
View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7459655.html
Sent from the git mailing list archive at Nabble.com.

Re: GIT pull

[Matthieu Moy]

cvalusek <clintv2@gmail.com> writes:

> If a user has local modifications not on the index and does a pull, I have
> seen git attempt to start applying the merge to master and abort. The whole
> checkout is then left in a terrible state that is nearly
> unrecoverable.

What do you mean by "terrible state"? What does "git status" say?

> In the past, I thought GIT would run some sort of check to identify
> these problems before it attempts the merge.

Git does check uncommited changes before merging. It allows the merge if
the changes touch different files (i.e. if the merge is guaranteed not
to touch the same files as the one for which you have uncommited
changes).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GIT pull

[Michael Witten]

On Thu, Apr 12, 2012 at 15:03, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> cvalusek <clintv2@gmail.com> writes:
>
>> If a user has local modifications not on the index and does a pull, I have
>> seen git attempt to start applying the merge to master and abort. The whole
>> checkout is then left in a terrible state that is nearly
>> unrecoverable.
>
> What do you mean by "terrible state"? What does "git status" say?
>
>> In the past, I thought GIT would run some sort of check to identify
>> these problems before it attempts the merge.
>
> Git does check uncommited changes before merging. It allows the merge if
> the changes touch different files (i.e. if the merge is guaranteed not
> to touch the same files as the one for which you have uncommited
> changes).

Also, if there *are* conflicts, then you should get an error that
looks like the following:

  error: Your local changes to the following files would be
  overwritten by merge:
  	some-file.txt
  Please, commit your changes or stash them before you can merge.
  Aborting

Sincerely,
Michael Witten

Re: GIT pull

[Johannes Sixt]

Am 12.04.2012 16:47, schrieb cvalusek:
> My team has had a lot of trouble with GIT lately because of aborted pull
> commands.
> 
> If a user has local modifications not on the index and does a pull, I have
> seen git attempt to start applying the merge to master and abort. The whole
> checkout is then left in a terrible state that is nearly unrecoverable. In
> the past, I thought GIT would run some sort of check to identify these
> problems before it attempts the merge.
> 
> Even with a clean state (nothing to commit), I have seen the same thing
> randomly happen at least once.

As others pointed out, this should not happen. That leaves one
possibility: You are on Windows, and you very likely have one or more of

- a virus scanner
- an IDE

running. It can happen that one of these programs happen to look at a
file at the same moment when git is trying to remove or rename the file.
This fails because on Windows a file that is open cannot be removed or
renamed. In this situation, the merge/checkout is aborted in the middle
and leaves a mess behind.

There's not a lot that can be done about it. I thought we have some
counter measures in our compatibility layer (e.g., retry the removal if
the first attempt fails due to permissions), but I have seen this happen
nevertheless. I haven't tried tracking it down because it happens so
rarely for me, and it didn't hurt *too* much so far.

-- Hannes

Re: GIT pull

[cvalusek]

Looks like it's the virus scan. I had this e-mail that I accidentally sent to
Michael directly instead of the list:

I will see if I can build a script that reproduces the issue we are seeing. 

We are starting to speculate about what is going on now. Maybe our virus
scan is causing some git operation to fail in the middle of the merge.

The "terrible state" is a half-way applied merge.

--
View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7460163.html
Sent from the git mailing list archive at Nabble.com.

Re: git pull

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> A few notes for other people who end up doing this:

[this meaning use of insteadOf to redirect public URLs to
ssh://git@gitolite URL]

>  (a) ssh is slower, and the gitolite machine is not as reachable.
>
>  (b) it affects your merge commit message.
>
> As to (a), yes it's noticeable, but the extra couple of seconds isn't
> really that big of a deal. Depending on exactly where you are, though,
> you might end up wanting to use https:// to the public servers
> instead.
>
> But (b) actually ends up being annoying, because I don't like my merge
> commits to contain references to repositories that aren't actually
> available unless you have a kernel.org account.
> ...
> Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
>
>   #!/bin/sh
>   sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
>
> and make it executable, and git will do that commit message editing for you.

This should work with any recent versions of Git (1.7.4.2 and
upwards), but it still is a workaround.  Should we mark it as a
feature request in the Git land to record the URL you typed as-is in
the builtin/fetch.c::store_updated_refs() function, instead of the
one that was rewritten by the insteadOf mechanism?

It would probably need an update to "struct remote" to have new
fields, to teach remote.c::alias_all_urls() not to overwrite the
url[] (and pushurl[] merely for symmetry) fields, to add a field to
"struct transport" and teach transport.c::transport_get() to record
the original URL in it so that builtin/fetch.c::fetch_refs() can
give it to store_updated_refs() instead of the rewritten one.

Many tiny changes in a rather deep codepath, but feels fairly a safe
change that is isolated and straightforward.

Re: git pull

[Linus Torvalds]

On Sun, Nov 19, 2017 at 7:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
>>
>>   #!/bin/sh
>>   sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
>>
>> and make it executable, and git will do that commit message editing for you.
>
> This should work with any recent versions of Git (1.7.4.2 and
> upwards), but it still is a workaround.  Should we mark it as a
> feature request in the Git land to record the URL you typed as-is in
> the builtin/fetch.c::store_updated_refs() function, instead of the
> one that was rewritten by the insteadOf mechanism?

The main problem with the prepare-commit-msg thing is actually that is
such a nasty hack, and it can change other things than just the remote
name. Maybe "gitolite" might be mentioned in the shortlog of the
merge, and then the sed script comes and edits that part too.

It is really not a huge issue simply because those things don't really
happen in real life, but it's the main thing about that
prepare-commit-msg hook that makes me go "eww, what an ugly hack".

But it's an ugly hack that just happens to work pretty well in practice.

And yes, I looked at alternatives. In fact, I  looked at a couple of
other approaches:

 - the one you mention, namely to remember the original url, and use
that instead

 - the one I'd actually prefer, which is to generalize the whole
"insteadOf" to work in more situations.

Why would I prefer that second one? It turns out that the "original"
isn't actually necessarily what I'd want either. Several people send
me pointers to "https://git.kernel.org/" and I prefer rewriting them
to git:// just to be consistent. And now that people have started
doing the "insteadOf", their pull requests end up containing that
"git@gitolite" version of the URL, so again, I'd actually like to
rewrite the url _anyway_ in the commit message.

For example, for the kernel, the git.kernel.org address is very
common, but it also has a very common path prefix, so almost all pull
messages for the kernel have that

   "git://git.kernel.org/pub/scm/linux/kernel/git/"

part in common, and I have occasioally felt that it's not adding a lot
of value particularly as it shows up in shortlogs and gitk. I could
change my own rules for the first line (instead of the "Merge tag xyz
from git://..." maybe I should just have my human-legible version),
but I have also considered just rewriting the url to something that
shortens that very common thing.

So maybe

   Merge tag 'sound-4.10-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

could be instead

   Merge tag 'sound-4.10-rc4' of git://kernel.org/../tiwai/sound

which would keep the _important_ part, and shorten the boilerplate
part away. But that kind of "insteadOf" would only be for the message,
since the end result isn't actually a "real" URL at all, it's
literally a rewritten shorthand.

Again, I can do all of this with the sed script. But again, it's kind
of wrong to do it on the whole message, when it's really only the url
that it should affect.

So it would potentially be nice to just have a generic "rewrite the
url" model, where you can do it for remote fetches, but you could also
do it for just the commit message, or you could do it for doing pushes
(we do have that "pushinsteadof" already - exactly because you might
want to pull and push from different versions, with the push having to
use ssh).

But, as you say:

> It would probably need an update to "struct remote" to have new
> fields, to teach remote.c::alias_all_urls() not to overwrite the
> url[] (and pushurl[] merely for symmetry) fields, to add a field to
> "struct transport" and teach transport.c::transport_get() to record
> the original URL in it so that builtin/fetch.c::fetch_refs() can
> give it to store_updated_refs() instead of the rewritten one.

Yes, the existing "insteadOf" is actually hidden surprisingly deep in
the remote code, and it's very non-obvious. That works ok for the pull
and push case, but really not for just the message rewriting case
(which doesn't happen as part of the pull, but as part of the "git
merge" that then takes the FETCH_HEAD or MERGE_HEAD that contains the
url, and parses that).

Anyway, it's not a big deal. The sed script works. It's a bit hacky,
but it does the job.

I might have wished for a different model, but it's almost certainly
not worth the effort unless somebody really gets fired up about this
and decides they really want to do it.

            Linus