[git-users] Re: another git rebase thread

[Philip Oakley]

Hi

On Thursday, March 19, 2020 at 5:14:40 PM UTC, Alexander Mills wrote:
>
> I am praying for a good answer to this question on SO:
>
> https://stackoverflow.com/q/60761947/12211419
>
> many upvotes promised.
>

It is better to include the original question. Most readers won't follow 
the link...

"I have used git rebase a few times and I am still confused about how it 
actually works. 

With git-merge it seems simple - resolve the diff between the tip of your 
branch and the tip of the other branch. 


However with git-rebase often times we are resolving multiple diffs when 
doing the rebase. I believe the number of resolved diffs is "how many 
commits my branch has that the other branch doesnt have" is that correct? 
but still why do need to resolve all the diffs, why not just the diff for 
the most recent commit on my branch?


alternatively, doing git-rebase could mean resolving all the diffs for "all 
the commits from the other branch that my branch doesn't have"! i haven't 
figured out which is which. Can anyone explain how this works?"

Answer:  

A rebase is a request to move a series of *patches* from one place in your 
commit hierarchy to another place in your hierarchy. It is just like a 
series of 'cherry-pick's (yes, it really is ;-)


So first you need to identify the correct list of commits, treated as 
patches, that you want to move. Beware of misunderstandings about some of 
the revision range options (some do not work. They don't even say what you 
thought).


Beware of your "Upstream" - it may not be what you think, so Git may think 
the patch has already been applied to the "upstream".

Having got your series of patches (range of commits), those patches need to 
be applied, one by one, to the new destination. You are doing this because 
it is a better place and usually already has some fixes already applied.


The first patch (diff) is applied, there was some minor conflict, say the 
new ('upstream') place had renamed a variable, while you edited the 
formula. It will be a conflict (two changes to the same place, or adjacent 
lines). So you fix the first patch conflicts.


Now the second patch hits the same awkward spot. Its a dumb diff. It knows 
not enough of the rename and line fixes and so can't find the right exact 
starting point, so you have to resolve it again. Cue third patch, and the 
same style of problem recurs.


This is especially bad if your commits are not atomic (i.e. each really 
small!). and without the semantic (renames etc) changes.

So, rebase quite often if you have a fast moving upstream (i.e. keep up), 
or do it very occasionally (i.e. do one big fix-it session).


Also, use the "ReReRe" facility. This is the 'Reuse Recorded Resolution' 
capability of Git. You need to enable it. It will remember each of your 
'fixes', and then if it needs doing again, it can reuse it. So you can 
practice the fixes, forget the bad ones, and re-run the rebase (use the 
--onto option for the temporary attempts).


The rerere documentation isn't great but there are a few web articles.


 
Philip Oakley  

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/18496d98-2d9b-4d26-98fe-a056beeae605%40googlegroups.com.

[git-users] Error while doing git rebase

[Alexander Mills]

use this email address:

g...@vger.kernel.org

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/4c8e2db0-b216-4c1c-980d-be44916960fd%40googlegroups.com.

[git-users] Error while doing git rebase

[Alexander Mills]

report it to the git team, google "git support email address" and send them a 
plain text email

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/a1d6a137-db33-449a-a31e-70ff64f91713%40googlegroups.com.

[git-users] another git rebase thread

[Alexander Mills]

I am praying for a good answer to this question on SO:

https://stackoverflow.com/q/60761947/12211419

many upvotes promised.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/a9af4e08-a460-46e3-b2b7-29b03eeece5f%40googlegroups.com.

Re: [git-users] Re: Multiple clones of the same remote repo

[David]

I just wanted to let you know that your post here is still helping folks!

I gained a lot of good info from it, and it allowed me to understand pulls 
and fetches much more completely!

Thanks!


On Tuesday, September 3, 2013 at 8:22:28 AM UTC-4, Konstantin Khomoutov 
wrote:
>
> On Mon, 2 Sep 2013 21:43:26 -0700 (PDT) 
> Juha Aaltonen > wrote: 
>
> > I guess I described the problem. 
>
> I guess I explained the reason for `git fetch` reporting everything is 
> up-to-date and `git pull` complaining about conflicts. 
>
> > I don't seem to be able to update my working tree from the remote 
> > repo using Giteye. 
> > The pull complains about masses of conflicts (even if I know that not 
> > that much has changed) and 
> > the fetch just says the SW is the same (nothing to merge). 
> > 
> > Maybe the problem is in Giteye, not in the repo clones. It's hard to 
> > understand why the different results. 
> > (everything changed / nothing changed) 
>
> In your case, it seems, the root problem is that people are taught Git 
> by making them memorize several simple commands which should "just do 
> this", without explaining what actually happens.  So someone told you 
> "use git-pull to bring the changes from remote repos"; that someone 
> failed to explain in detail what `git pull` actually does, and why it 
> may legitimately fail. 
>
> So let me try to explain the situation in more detail... 
>
> When you clone a repository, Git: 
>
> 1) Creates or initalizes a local repo. 
>
> 2) In its configuration, creates a single "remote" named "origin". 
>
> 3) Fetches all the branches from the remote repository, creating 
>a single "remote branch" for each branch that repository has. 
>You can enumerate these branches by running `git branch -r`. 
>
> 4) Creates a single normal branch which tracks one of the created 
>remote branches -- matching that which is currently "main" 
>in the repository being cloned, this is "master" most of the time. 
>
> Recently I explained to someone here these concepts in detail, so 
> please refer to [1] for more info. 
>
> Now the `git fetch origin` (or just `git fetch` in your case) contacts 
> the repository pointed to by the remote named "origin" in the 
> configuration of your local clone and fetches all the branches from it 
> -- updating the matching *remote branches* for that repository, and 
> creating new, if needed.  The crucial thing to understand is that none 
> of your personal local branches is ever updated by this command. 
> Of course, if you call `git fetch` twice in a row, it's likely that the 
> first call brings some changes in and the second one reports that 
> everything is up-to-date, because the state of the remote repository 
> stored locally in the form of remote branches for it is the same as the 
> state of branches in that remote repository. 
>
> The usual course of action when you want to reconcile the changes 
> someone did to the branch of interest located in some remote repository 
> and your changes you did to a branch in your local repository is to 
>
> 1) Fetch from the remote repository to update its remote branches in 
>your local repository. 
>
> 2) Check out the necessary local branch. 
>
> 3) Inspect what changes the relevant remote branch has compared to your 
>branch, and in reverse. 
>
> For instance, if you have a local branch named "master" which tracks 
> the same named branch in a remote repository named "origin", you'd do: 
>
> git fetch origin 
> git checkout master 
> # What the remote "master" has our local "master" hasn't? 
> git log master..origin/master 
> # What changes our local "master" has which the remote "master" hasn't? 
> git log origin/master..master 
>
> Now we can merge: 
>
> git merge origin/master 
>
> This operation might rightfully result in conflicts if both sides 
> changed the same portions of the same files. 
>
>
> Now let's move to `git pull`.  It has much magic built in, and that's 
> why it really sucks to ever tell Git newcomers this command exists (but 
> everyone does this, unfortunately). 
>
> When you have a branch named "master" checked out and do `git pull`, 
> it goes like this: 
>
> 1) Reads the branch.master.remote configuration variable to learn which 
>remote this local branch named "master" "tracks". 
>
>In a typical setup: 
>
>$ git config --get branch.master.remote 
>origin 
>
>If you call `git pull ` this step is skipped and the 
>name of the remote is taken from the command line. 
>
> 2) Reads the branch.master.merge configuration variable to learn which 
>branch this local branch named "master" "tracks" in the remote 
>repository learned on step (1). 
>
>In a typical setup: 
>
>$ git config --get branch.master.merge 
>refs/heads/master 
>
>If you call `git pull  ` this step is skipped 
>and the name of the branch is taken from the command line. 
>
> 3) Fetches a branch which name was obtained on step (2) from the 
>