Re: pull into dirty working tree

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: pull into dirty working tree

From: Randal L. Schwartz <hidden>
Date: 2016-06-15 22:43:16

quoted
quoted
quoted
quoted
"Alex" == Alex Riesen [off-list ref] writes:
Alex> No, it wont. What files are you going to add?

Whatever you are working on.  Whatever you want tracked.  It's a commit.
I'm not sure why you're having trouble following me.  What did I leave out?
quoted
git-rebase *will* do the merge.  It must. :)
Alex> It won't merge anything which isn't known to git.

And that's irrelevant, because my first step *did* a commit so they are
*known* to git.

Alex>  Now, I come to think
Alex> about it, no existing merge method will help you here (and very likely
Alex> it shouldn't).

Yes, it should.  You're merging your changes onto the upstream.  This
happens dozens of times a day with git repos all over the world. :)

Alex> It is actually much simplier doing things right: all this stashing
Alex> people keep talking about.

Yes, and that's what I said too.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: pull into dirty working tree

From: Alex Riesen <hidden>
Date: 2016-06-15 22:43:16

Randal L. Schwartz, Wed, Jun 13, 2007 22:52:35 +0200:
Alex> No, it wont. What files are you going to add?

Whatever you are working on.  Whatever you want tracked.  It's a commit.
I'm not sure why you're having trouble following me.  What did I leave out?
You left the process of figuring out what files should be temporarily
added to the index. _Automatically_. Because that's what you need if
you want "git pull" to just work. Otherwise it just fails.
quoted
quoted
git-rebase *will* do the merge.  It must. :)
Alex> It won't merge anything which isn't known to git.

And that's irrelevant, because my first step *did* a commit so they are
*known* to git.
It is not enough. It didn't add the "other" files to index, so the
files are _not_ known to git.

Imagine you added a file to Makefile (which was known to git), wrote
the file, put some code in it, played with it. Never called "git add"
on it yet (you were just playing, as original poster suggested).
Now someone from team calls and asks you to tests his changes (and
imagine he added a file with exactly the same name as yours). You do a
pull from his repo and it breaks. With your method it will break too,
"git commit -a" wont add your file to index.
Alex>  Now, I come to think
Alex> about it, no existing merge method will help you here (and very likely
Alex> it shouldn't).

Yes, it should.  You're merging your changes onto the upstream.  This
happens dozens of times a day with git repos all over the world. :)
Other way around. You merge upstream in your branch. And it conflicts
with work you haven't told git about just yet.
Alex> It is actually much simplier doing things right: all this stashing
Alex> people keep talking about.

Yes, and that's what I said too.
You (and others) just keep forgetting about this small detail with
"other" files. Junio noticed it too. This "small" detail can make the
whole stashing bussiness impossible except for maybe a common case.
Which is not very helpful for a newbie who meets the uncommon, but his
case. He'll learn his way though, of course. After saying out loud:
"git sucks!"; which what they already do.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help