git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).