From: Junio C Hamano <gitster@pobox.com>
To: "John Dlugosz" <JDlugosz@TradeStation.com>
Cc: <git@vger.kernel.org>
Subject: Re: Files different for me
Date: Wed, 25 Feb 2009 09:55:19 -0800 [thread overview]
Message-ID: <7vd4d62ygo.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709E047DE@EXCHANGE.trad.tradestation.com> (John Dlugosz's message of "Wed, 25 Feb 2009 11:11:39 -0500")
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I'm working with a group, and using git for source code. I need to
> change a couple files temporarily and just for me. I thought, "that's
> easy", just don't stage them when I check in changes. But, what do I do
> when I pull changes from others? I think it will complain that I have
> unsaved changes. What's the best way to do this?
[jc: Overlong lines wrapped]
This typically happens when a configuration file of some sort that *must*
be different in each work tree is tracked.
"git pull" and "git merge" do not care when you have local changes to
paths *and* the merge does not involve them, and errors out without
touching any files in your tree when the merge needs to touch them. You
can safely deal with your local changes after seeing such an error. This,
and because such a file tend to be modified much less often than the real
contents, means that:
(1) you do not usually have to worry about this issue, and can keep your
small local changes you do not mind losing around, and
(2) when you have to recover, you can easily stash your changes away,
redo the pull and unstash them.
If you want an "I do not have to think" solution, an easiest recipe to
follow would be:
$ git stash
$ git pull
... potentially resolve conflicts and make a merge commit ...
$ git stash pop
But as described above, stash/stash pop are superfluous for most of the
time.
next prev parent reply other threads:[~2009-02-25 17:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 16:11 Files different for me John Dlugosz
[not found] ` <16946e800902250840o677f8708x7c0bf8980e004b91@mail.gmail.com>
2009-02-25 16:42 ` Feanil Patel
2009-02-25 17:05 ` Brian Gernhardt
2009-02-25 18:02 ` John Dlugosz
2009-02-25 18:38 ` Brian Gernhardt
2009-02-25 19:01 ` John Dlugosz
2009-02-25 18:44 ` Matthieu Moy
2009-02-25 17:55 ` Junio C Hamano [this message]
2009-02-25 18:04 ` Linus Torvalds
2009-02-25 18:51 ` Junio C Hamano
2009-02-25 19:12 ` Linus Torvalds
2009-02-25 20:06 ` Junio C Hamano
2009-02-25 20:14 ` Linus Torvalds
2009-02-25 19:16 ` Jay Soffian
2009-02-25 19:38 ` John Dlugosz
2009-02-25 19:23 ` John Dlugosz
2009-02-25 20:04 ` Junio C Hamano
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=7vd4d62ygo.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=JDlugosz@TradeStation.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).