From: Johan Herland <johan@herland.net>
To: skillzero@gmail.com
Cc: git@vger.kernel.org
Subject: Re: Merge into locally modified files?
Date: Tue, 09 Jun 2009 00:36:43 +0200 [thread overview]
Message-ID: <200906090036.43492.johan@herland.net> (raw)
In-Reply-To: <2729632a0906081214q43e45ce7p812bd02f34934691@mail.gmail.com>
On Monday 08 June 2009, skillzero@gmail.com wrote:
> On Mon, Jun 8, 2009 at 11:22 AM, Johan Herland <johan@herland.net> wrote:
> > Git, instead encourages you to commit your changes _first_
> > (aka. "commit-before-merge"), so that your changes are not necessarily
> > affected by the updated changes from the server.
>
> The problem I have with this is that it's a lot of extra work to
> commit, pull (which will create a merge commit), then back out the
> merge commit git pull did, back out my local commit, then re-apply my
> local changes.
I never suggested you do something convoluted like that. What I suggested
was:
1. "git commit" your local changes
2. "git pull --rebase"
After this, your local changes will be on top of the pulled changes. (Then
you can put them on a separate branch, if you're paranoid about accidentally
pushing them to the server.)
> I typically always have some modified files in my tree
> for little things I may never want to commit. I'll tweak some build
> Makefile build setting (e.g. enable extra logging, some debug printfs,
> etc.). These changes are very transient. We tend to pull in changes
> several times a day as people change stuff.
Yes, and that's why I suggest you keep your debug stuff on a separate
branch, so that it's easily separated from the mainline development.
> It looks like I can use git stash to help here. If I do 'git stash &&
> git pull && git stash pop', it seemed to work in a simple example.
Yes, that's another way of doing it; possibly better than my suggestion.
> If I had no changes, I'd need to be careful to not try to do a git stash
> pop since it would haven't stashed anything.
If this is the only thing you use 'git stash' for, you could start off with
a 'git stash clear'. That way, there would be nothing to 'pop' if there was
nothing to 'stash'.
> Is this something that would be pretty easy to add to git pull (or I
> guess really to git merge since pull is just fetch+merge)? Maybe
> something like a 'git pull --rebase-local'? If I wanted to add
> something like this, should I just start by looking at git stash and
> see how it does it and try to integrate support for that into git
> merge (and make sure git pull will pass that option through to git
> merge)? Conceptually, it seems easy, but I don't know how hard it
> would be to get it into the code.
Feel free to whip up a patch. I can't say whether it'll be accepted or not.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2009-06-08 22:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 17:30 Merge into locally modified files? skillzero
2009-06-08 18:22 ` Johan Herland
2009-06-08 19:14 ` skillzero
2009-06-08 22:36 ` Johan Herland [this message]
2009-06-09 0:46 ` Sitaram Chamarty
2009-06-08 23:10 ` Andreas Ericsson
2009-06-08 23:19 ` Jon Smirl
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=200906090036.43492.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=skillzero@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.