git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: cvalusek <clintv2@gmail.com>
To: git@vger.kernel.org
Subject: GIT pull
Date: Thu, 12 Apr 2012 07:47:57 -0700 (PDT)	[thread overview]
Message-ID: <1334242077960-7459655.post@n2.nabble.com> (raw)

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.

             reply	other threads:[~2012-04-12 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 14:47 cvalusek [this message]
2012-04-12 15:03 ` GIT pull Matthieu Moy
2012-04-12 15:07   ` Michael Witten
2012-04-12 16:58 ` Johannes Sixt
2012-04-12 17:29 ` cvalusek
     [not found] <20171113231155.GA26779@eros>
     [not found] ` <20171114110500.GA21175@kroah.com>
     [not found]   ` <20171114213320.GB905@eros>
     [not found]     ` <CA+55aFyMxkS=8JzZ+ROOAFkwR45EKBnQ0GUMQS4f+r_-fFWiEA@mail.gmail.com>
     [not found]       ` <CA+55aFzhK+GPO1_Zm2PoQiq5-cHAq6nz1ejrBhGhWX-KAjTU9A@mail.gmail.com>
2017-11-20  5:37         ` git pull Junio C Hamano
2017-11-20  6:04           ` Linus Torvalds
  -- strict thread matches above, loose matches on Subject: below --
2010-05-17 21:51 matteo brutti
2010-05-18 16:31 ` Nicolas Sebrecht
2010-05-19 11:03 ` hasen j

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1334242077960-7459655.post@n2.nabble.com \
    --to=clintv2@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).