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

Re: [PATCH v2] Give git-pull a --reset option

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Apr 21, 2019, 21:18 UTC
Message-ID
<20190421211833.GC6316@genre.crustytoothpaste.net>
In-Reply-To
<xmqqftqbdijl.fsf@gitster-ct.c.googlers.com>
On Sun, Apr 21, 2019 at 02:38:38PM +0900, Junio C Hamano wrote:
Show 15 quoted lines
> Alex Henrie <alexhenrie24@gmail.com> writes:
> 
> > A common workflow is to make a commit on a local branch, push the branch
> > to the remote, check out the remote branch on a second computer, amend
> > the commit on the second computer, force-push back to the remote branch,
> > and finally submit a pull request. However, if the user switches back to
> > the first computer, they must then run the cumbersome command
> > `git fetch && git reset --hard origin`. 
> 
> Doesn't anybody sense there is a larger problem if such a workflow
> is "common" in the first place?  In that sequence, when you come
> back to the first repository there is no guarantee that what you are
> losing is exactly what you are willing to lose and nothing else
> (i.e. your earlier WIP you sent to the second repository, which was
> further polished, making the earlier WIP you had here irrelevant).

It may be helpful to point out that this is essentially the workflow I had before I had only one computer. I would make some changes on my desktop, which was my primary computer, then need to travel somewhere and use my laptop. I would want to go back to my desktop when I returned home, because it was far more powerful, and I would know that I was the only user of this branch.

Now, as a contributor and a moderately advanced user, I would likely end up using "git commit --fixup" (or "--squash") for this purpose and squash only before submitting, but there are situations where fixup commits cause conflicts and it's necessary to do a rebase and force push if you don't want extensive pain.

So while I think that "git pull --rebase" or "git pull --ff-only" are probably better options in most situations, I can see the use in this command, with appropriate foresight and knowledge. I can also see how it's easy to blow away data with the proposed option, especially for novice users, who are likely not aware of how to restore it from the reflog.

I'm not sure if this email is an argument for or against this option, but maybe it provides some helpful perspective.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Previous: Philip OakleyNext: Junio C Hamano
Message 5 of 7 in “Give git-pull a --reset option”
  1. Give git-pull a --reset optionAlex Henrie, Apr 21, 2019
  2. Junio C HamanoApr 21, 2019
  3. Alex HenrieApr 21, 2019
  4. Philip OakleyApr 21, 2019
  5. brian m. carlsonApr 21, 2019
  6. Junio C HamanoApr 21, 2019
  7. Phillip WoodApr 22, 2019

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.