[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VC mode and git
From: |
Alan Mackenzie |
Subject: |
Re: VC mode and git |
Date: |
Tue, 31 Mar 2015 21:43:47 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hello, Stephen.
On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
> "Commit early, commit often", and you won't have to worry about
> remembering the details of your workflow.
And have my repository clogged up with meaningless arbitrary commits with
commit messages like "Just before resync with savannah, 2015-03-31
22-58"? Then I'd have the hassle of somehow ensuring these silly commits
wouldn't find their way back to savannah. I know vaguely this is a
solved problem, but it's one more thankless bit of drudgery I don't want
to get involved with.
> > > It does, the same way that bzr or Mercurial does.[1] I don't see
> > > why you would think otherwise.
> > Partly due to the following bug report which is near the start of the
> > git-merge man page: "Warning: Running git merge with non-trivial
> > uncommitted changes is discouraged: while possible, it may leave you in a
> > state that is hard to back out of in the case of a conflict.". I can't
> > imagine why the git maintainers don't fix this.
> Fix what? One can do it if one wants to. It's usually not dangerous
> because merge will abort if there are any local uncommitted changes in
> a file that would be changed by the merge. It's actually rather
> useful in certain limited use cases, for example when I have a
> different ignore file from upstream. In Mercurial, I have a patch in
> a queue that handles this but it's PITA to deal with. (Note that
> everybody's favorite blunted plastic scissors, aka Bazaar, has a
> "merge --force" option to allow the user to make the choice.)
> It is indeed a bad idea to do a lot of work without committing and
> then merging.
Why?
> But that's a trivial deduction from the general theorem: it is a bad
> idea to do a lot of work without committing.
Why?
These two "why?"s are not rhetorical questions.
[ .... ]
> > Mercurial will complete hg pull regardless of any changes in its working
> > directory; in the case of conflicts it may leave several heads which
> > require merging.
> Which is exactly what git does:
> b 22:00$ git pull
> remote: Counting objects: 3, done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 3 (delta 1), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /tmp/test/./a
> 684eca7..d47c24c master -> origin/master <<<< LOOK LOOK LOOK
> Updating 684eca7..d47c24c
> error: Your local changes to the following files would be overwritten
> by merge:
> quuz
> Please, commit your changes or stash them before you can merge.
> Aborting
> I think you're partly confused by the fact that what Mercurial calls
> pull is what git calls fetch, and what git calls pull has no
> equivalent in core Mercurial AFAIK (pull -u only updates on a fast
> forward).
No, I'm not confused on this point. There is hg fetch (deprecated) which
does hg pull followed (possibly) by hg merge, then hg update, more or
less. I've never used it.
> > Part of the problem is that the git-merge man page doesn't say that
> > it messes with the working tree
> What else would it do? Merge tools have changed the working tree from
> time immemorial.
That's poor, Stephen. It might well merge in the repository without
touching the working tree. The fact is, the documentation doesn't say
this - it doesn't even say where the two sources for its merge come from,
or where it puts the result.
> What's different from traditional 3-way merge tools (that aren't part
> of a VCS) is that git *also* creates a commit with more than one
> parent (which is what is meant by joining development histories).
Do development histories have 40-byte hashes? :-)
> I find it a PITA that Mercurial doesn't, but rather requires a separate
> merge operation and then an explicit commit.
> > By contrast, hg merge is documented concisely and adequately as
> > "merge another revision into working directory".
> Everybody hates git's documentation. I thought you were complaining
> about bugs in the program?
The documentation is part of the program. Whether bugs are in the doc or
the prog, it costs just as much wasted time and energy.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: VC mode and git, (continued)
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Dmitry Gutov, 2015/03/31
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Andreas Schwab, 2015/03/31
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Andreas Schwab, 2015/03/31
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Stephen J. Turnbull, 2015/03/31
- Re: VC mode and git, Steinar Bang, 2015/03/31
- Re: VC mode and git, Stephen J. Turnbull, 2015/03/31
- Re: VC mode and git,
Alan Mackenzie <=
- Re: VC mode and git, Stephen J. Turnbull, 2015/03/31
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Stephen J. Turnbull, 2015/03/31
- Re: VC mode and git, Richard Stallman, 2015/03/31
- Re: VC mode and git, Stephen J. Turnbull, 2015/03/31
- Re: VC mode and git, Mike Gerwitz, 2015/03/31
- Re: VC mode and git, Eli Zaretskii, 2015/03/31
- Re: VC mode and git, Dmitry Gutov, 2015/03/27
- Re: VC mode and git, Eli Zaretskii, 2015/03/27
- Re: VC mode and git, Dmitry Gutov, 2015/03/27