git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Merge into locally modified files?

From
Johan Herland <johan@herland.net>
Date
Jun 8, 2009, 22:36 UTC
Message-ID
<200906090036.43492.johan@herland.net>
In-Reply-To
<2729632a0906081214q43e45ce7p812bd02f34934691@mail.gmail.com>
On Monday 08 June 2009, skillzero@gmail.com wrote:
Show 9 quoted lines
> 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.)

Show 5 quoted lines
> 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'.

Show 8 quoted lines
> 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
Previous: skillzero@gmail.comNext: Sitaram Chamarty
Message 4 of 7 in “Merge into locally modified files?”
  1. skillzero@gmail.comJun 8, 2009
  2. Johan HerlandJun 8, 2009
  3. skillzero@gmail.comJun 8, 2009
  4. Johan HerlandJun 8, 2009
  5. Sitaram ChamartyJun 9, 2009
  6. Andreas EricssonJun 8, 2009
  7. Jon SmirlJun 8, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.