* State of the repository conversion
@ 2014-03-19 17:51 Eric S. Raymond
2014-03-19 18:14 ` Paul Eggert
` (2 more replies)
0 siblings, 3 replies; 65+ messages in thread
From: Eric S. Raymond @ 2014-03-19 17:51 UTC (permalink / raw
To: emacs-devel
I have a complete lift script. It satisfies all the requests that I
have received for attic-file fixups, name canonicalization,
preservation of fixes-bugs information, and the like.
I meant to push a test copy to Gitorious this weekend, but life - and
the fact that the cleanup runs take about eight hours each -
intervened. I have a cleanup running now which may produce a
result I am ready to push around 6PM EST.
I have made almost all requested updates to the Emacs wiki. There
are two exceptions.
From Eli Zaretskii:
. I would suggest describing the setup of git-merge-changelog,
because as long as we keep ChangeLog files in the repository,
people might bump into conflicts in the logs, and it would be nice
to avoid that.
If this is really important to have on the Emacs wiki, someone else will have
to do it. Search engines don't turn up documentation on the tool and I
don't have direct experience with it.
. I think we should discuss some more how to work with the
development trunk and the release branch in parallel, and reflect
the results of the discussion in the Wiki.
The issue here is that the release branch and the trunk diverge
very quickly after the branch point, and the result is that after
you checkout the other branch, you generally need a very long
build, many times a full bootstrap. While on a modern system, a
full bootstrap should take a few minutes, it is still annoyingly
long, and makes higher the risk of losing the race against other
committers. In addition, you only have a single executable at any
given time, so comparison of behavior between the two branches is
difficult.
So perhaps we should find a way of having two separate branches,
such that switching between them does not require a build if
nothing changed.
This is not a documentation request, it's a research agenda. I can't
write up a technique that doesn't exist yet.
The only other major pre-conversion to-do left on my list is "Better
cross-VCS integration of smerge in vc.el", and we have Rüdiger
Sonderfeld's patch for that. It can be merged as soon as trunk is
open.
The lift script and conversion machinery continue to be available
fotr review at
git@gitorious.org:emacs-transition/emacs-transition.git
Getting to this point required two full months of work, including
several major feature additions to reposurgeon. I will be rather
surprised if I ever see another conversion as complex as this one.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is
a well-armed lamb contesting the vote!
-- Benjamin Franklin
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 17:51 State of the repository conversion Eric S. Raymond
@ 2014-03-19 18:14 ` Paul Eggert
2014-03-19 18:31 ` Eli Zaretskii
2014-03-19 21:25 ` Andreas Schwab
2 siblings, 0 replies; 65+ messages in thread
From: Paul Eggert @ 2014-03-19 18:14 UTC (permalink / raw
To: Eric S. Raymond, emacs-devel
On 03/19/2014 10:51 AM, Eric S. Raymond wrote:
> I will be rather surprised if I ever see another conversion as complex as this one.
Me too, though I've been surprised in the past. Thanks for all your work!
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 17:51 State of the repository conversion Eric S. Raymond
2014-03-19 18:14 ` Paul Eggert
@ 2014-03-19 18:31 ` Eli Zaretskii
2014-03-19 18:54 ` Eric S. Raymond
2014-03-19 21:25 ` Andreas Schwab
2 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-19 18:31 UTC (permalink / raw
To: Eric S. Raymond; +Cc: emacs-devel
> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Wed, 19 Mar 2014 13:51:24 -0400 (EDT)
>
> >From Eli Zaretskii:
>
> . I would suggest describing the setup of git-merge-changelog,
> because as long as we keep ChangeLog files in the repository,
> people might bump into conflicts in the logs, and it would be nice
> to avoid that.
>
> If this is really important to have on the Emacs wiki, someone else will have
> to do it. Search engines don't turn up documentation on the tool and I
> don't have direct experience with it.
The documentation for git-merge-changelog is available as a large
commentary at the beginning of the source. Also, someone created a
man page out of that commentary and posted it to the gnulib mailing
list a week or two ago.
> . I think we should discuss some more how to work with the
> development trunk and the release branch in parallel, and reflect
> the results of the discussion in the Wiki.
>
> The issue here is that the release branch and the trunk diverge
> very quickly after the branch point, and the result is that after
> you checkout the other branch, you generally need a very long
> build, many times a full bootstrap. While on a modern system, a
> full bootstrap should take a few minutes, it is still annoyingly
> long, and makes higher the risk of losing the race against other
> committers. In addition, you only have a single executable at any
> given time, so comparison of behavior between the two branches is
> difficult.
>
> So perhaps we should find a way of having two separate branches,
> such that switching between them does not require a build if
> nothing changed.
>
> This is not a documentation request, it's a research agenda.
It was a request to discuss and decide upon the recommended workflow.
Documenting the decision is the easy part. We did something very
similar when we switched from CVS to bzr, and the results are on the
wiki. The current Git wiki page simply repeats what the bzr workflow
said, which is probably sub-optimal, since Git is not bzr.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 18:31 ` Eli Zaretskii
@ 2014-03-19 18:54 ` Eric S. Raymond
2014-03-19 19:17 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Eric S. Raymond @ 2014-03-19 18:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org>:
> The documentation for git-merge-changelog is available as a large
> commentary at the beginning of the source. Also, someone created a
> man page out of that commentary and posted it to the gnulib mailing
> list a week or two ago.
OK. When it has a stable public location I'll add a link to it on the wiki.
> > This is not a documentation request, it's a research agenda.
>
> It was a request to discuss and decide upon the recommended workflow.
> Documenting the decision is the easy part. We did something very
> similar when we switched from CVS to bzr, and the results are on the
> wiki. The current Git wiki page simply repeats what the bzr workflow
> said, which is probably sub-optimal, since Git is not bzr.
On the other hand, it is the logical place for people to start - the
bzr workflow maps over fairly well even though the individual commands
have to change.
I suspect that if change is required here it will have to evolve from
practice rather than beung invented.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 18:54 ` Eric S. Raymond
@ 2014-03-19 19:17 ` Eli Zaretskii
2014-03-20 0:08 ` Stephen J. Turnbull
2014-03-22 7:18 ` Stefan-W. Hahn
0 siblings, 2 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-19 19:17 UTC (permalink / raw
To: esr; +Cc: emacs-devel
> Date: Wed, 19 Mar 2014 14:54:17 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
>
> I suspect that if change is required here it will have to evolve from
> practice rather than beung invented.
I suspect that the change (which I think will indeed be required) will
express itself in unpleasant arguments, as people start using their
own workflows taken from other projects, and we discover just how
incompatible some of them are with Emacs development.
It is better to draw upon the knowhow and experience of veteran git
users among us to identify in advance the preferred workflows, discuss
them, and make decisions blessed by the Powers That Be. We have ample
time for that, as v24.4 release is at least several months away.
I'm sorry that I cannot lead those discussions, due to lack of
knowledge. I hope someone else will.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 17:51 State of the repository conversion Eric S. Raymond
2014-03-19 18:14 ` Paul Eggert
2014-03-19 18:31 ` Eli Zaretskii
@ 2014-03-19 21:25 ` Andreas Schwab
2014-03-20 3:49 ` Eli Zaretskii
2 siblings, 1 reply; 65+ messages in thread
From: Andreas Schwab @ 2014-03-19 21:25 UTC (permalink / raw
To: Eric S. Raymond; +Cc: emacs-devel
esr@thyrsus.com (Eric S. Raymond) writes:
> So perhaps we should find a way of having two separate branches,
> such that switching between them does not require a build if
> nothing changed.
I'm using git-new-workdir to create separate work directories that share
the git object directory. (There is work underway to integrate it into
git core, though that seemed to have stalled a bit.)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 19:17 ` Eli Zaretskii
@ 2014-03-20 0:08 ` Stephen J. Turnbull
2014-03-20 0:32 ` Eric S. Raymond
` (2 more replies)
2014-03-22 7:18 ` Stefan-W. Hahn
1 sibling, 3 replies; 65+ messages in thread
From: Stephen J. Turnbull @ 2014-03-20 0:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, emacs-devel
About the workflow, Eli Zaretskii writes:
> It is better to draw upon the knowhow and experience of veteran git
> users among us to identify in advance the preferred workflows,
And the resulting recommendations will be ignored in favor of the
convenience of the powers that be, as the recommendations for Bazaar
were. (And mostly, so were such recommendations ignored when Python
converted from Subversion to Mercurial.) I don't know about Eric's
experience (he's participated in a lot more of these than I have), but
I suspect at least subconsciously he's thinking the same thing.
Please remember what that convenience boiled down to: "don't change
anything that doesn't need to change, because the current workflow
works fine for us". I admit I was wrong to suggest "the workflows
that work in other projects." Experience showed that people adopted
those workflows as needed for their own work, but many people
continued to use Bazaar as if it were CVS. It's only a tiny bit
harder to use git that way (no bound branches or lightweight
checkouts, so you do have to learn to push, and merge from upstream if
your push wouldn't be a fast-forward). But people are used to the
up-to-date check failing, I suspect, and it's not that hard to learn
-- everybody did learn in the bad old days of CVS. So it amounts to
learning that you need to "git push" after "git commit", if you were
using a checkout with Bazaar.
People who do want to use git as a free-branching distributed VCS
already know how to do that, and they may or may not follow
"recommended" workflows themselves.
So I think this is really a non-problem. Just translate bzr commands
to the git equivalents, configure public repos to prevent "destructive"
commands (require fast-forward pushes, mostly), and let the git fans
teach those who want to improve their git skills as issues come up.
Emacs doesn't have much structure in its abstract workflow (it
basically comes down to "hack, save, push") that requires careful
consideration of VCS operations.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 0:08 ` Stephen J. Turnbull
@ 2014-03-20 0:32 ` Eric S. Raymond
2014-03-20 1:01 ` Óscar Fuentes
2014-03-20 4:04 ` Eli Zaretskii
2 siblings, 0 replies; 65+ messages in thread
From: Eric S. Raymond @ 2014-03-20 0:32 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Eli Zaretskii, emacs-devel
Stephen J. Turnbull <stephen@xemacs.org>:
> So I think this is really a non-problem. Just translate bzr commands
> to the git equivalents, configure public repos to prevent "destructive"
> commands (require fast-forward pushes, mostly), and let the git fans
> teach those who want to improve their git skills as issues come up.
> Emacs doesn't have much structure in its abstract workflow (it
> basically comes down to "hack, save, push") that requires careful
> consideration of VCS operations.
I agree with this analysis. It's why I wrote GitForEmacsDevs as
nearly a literal translation into git commands from bzr commands.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 0:08 ` Stephen J. Turnbull
2014-03-20 0:32 ` Eric S. Raymond
@ 2014-03-20 1:01 ` Óscar Fuentes
2014-03-20 3:55 ` Eli Zaretskii
2014-03-20 4:04 ` Eli Zaretskii
2 siblings, 1 reply; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 1:01 UTC (permalink / raw
To: emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
[snip]
> So I think this is really a non-problem. Just translate bzr commands
> to the git equivalents, configure public repos to prevent "destructive"
> commands (require fast-forward pushes, mostly), and let the git fans
> teach those who want to improve their git skills as issues come up.
> Emacs doesn't have much structure in its abstract workflow (it
> basically comes down to "hack, save, push") that requires careful
> consideration of VCS operations.
I would encourage git newcomers to just use Magit. It provides a nice UI
for git, requiring very basic knowledge of git's specific features.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 21:25 ` Andreas Schwab
@ 2014-03-20 3:49 ` Eli Zaretskii
2014-03-20 7:46 ` Steinar Bang
2014-03-20 18:19 ` Andreas Schwab
0 siblings, 2 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 3:49 UTC (permalink / raw
To: Andreas Schwab; +Cc: esr, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Wed, 19 Mar 2014 22:25:56 +0100
> Cc: emacs-devel@gnu.org
>
> I'm using git-new-workdir to create separate work directories that share
> the git object directory. (There is work underway to integrate it into
> git core, though that seemed to have stalled a bit.)
At the time this came up, you said this feature is not ready yet for
prime time. Is this still the case? If so, perhaps we should ask the
git maintainers to try to gear up with it.
If this feature is already mature enough, perhaps we should recommend
it on the wiki as the solution for this issue.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 1:01 ` Óscar Fuentes
@ 2014-03-20 3:55 ` Eli Zaretskii
2014-03-20 4:09 ` Óscar Fuentes
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 3:55 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Mar 2014 02:01:38 +0100
>
> I would encourage git newcomers to just use Magit. It provides a nice UI
> for git, requiring very basic knowledge of git's specific features.
That's unrelated to the issue at hand, which is how we use git at the
project level.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 0:08 ` Stephen J. Turnbull
2014-03-20 0:32 ` Eric S. Raymond
2014-03-20 1:01 ` Óscar Fuentes
@ 2014-03-20 4:04 ` Eli Zaretskii
2014-03-20 4:25 ` Óscar Fuentes
2014-03-21 3:02 ` Stephen J. Turnbull
2 siblings, 2 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 4:04 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: esr, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
> emacs-devel@gnu.org
> Date: Thu, 20 Mar 2014 09:08:32 +0900
>
> About the workflow, Eli Zaretskii writes:
>
> > It is better to draw upon the knowhow and experience of veteran git
> > users among us to identify in advance the preferred workflows,
>
> And the resulting recommendations will be ignored in favor of the
> convenience of the powers that be, as the recommendations for Bazaar
> were.
I think almost all of the Emacs developers use the workflow described
on the wiki. I know I do. So I'm not sure what your assessment is
based on.
> Please remember what that convenience boiled down to: "don't change
> anything that doesn't need to change, because the current workflow
> works fine for us".
The current workflow includes kludges and workarounds for bzr
deficiencies. E.g., the way we merge from the release branch is due
to the fact that bzr doesn't track cherry-picks. Git does. I see no
reason to stick to the old workflow in these cases.
And that is just one example. I could go on. But since no one seems
to be interested, I'll probably shut up, before I once again am called
a bullshitter.
> I admit I was wrong to suggest "the workflows that work in other
> projects." Experience showed that people adopted those workflows as
> needed for their own work, but many people continued to use Bazaar
> as if it were CVS. It's only a tiny bit harder to use git that way
> (no bound branches or lightweight checkouts, so you do have to learn
> to push, and merge from upstream if your push wouldn't be a
> fast-forward). But people are used to the up-to-date check failing,
> I suspect, and it's not that hard to learn -- everybody did learn in
> the bad old days of CVS. So it amounts to learning that you need to
> "git push" after "git commit", if you were using a checkout with
> Bazaar.
I think you completely miss the point here. These issues are
important (and I see nothing wrong with having them described on the
wiki), but they are not the important part.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 3:55 ` Eli Zaretskii
@ 2014-03-20 4:09 ` Óscar Fuentes
2014-03-20 7:06 ` David Engster
2014-03-20 16:13 ` Eli Zaretskii
0 siblings, 2 replies; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 4:09 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> I would encourage git newcomers to just use Magit. It provides a nice UI
>> for git, requiring very basic knowledge of git's specific features.
>
> That's unrelated to the issue at hand, which is how we use git at the
> project level.
Magit can determine how you use git at the project level. Since it makes
ordinary tasks quite more simple and less error-prone, git's barroque UI
is no longer a significant factor.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:04 ` Eli Zaretskii
@ 2014-03-20 4:25 ` Óscar Fuentes
2014-03-20 4:59 ` Stefan
2014-03-20 16:17 ` Eli Zaretskii
2014-03-21 3:02 ` Stephen J. Turnbull
1 sibling, 2 replies; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 4:25 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> E.g., the way we merge from the release branch is due
> to the fact that bzr doesn't track cherry-picks. Git does.
No, it doesn't.
Which reminds me of a comment I made long time ago: applying fixes on
the maintenance branch and then cherry-picking them into the development
branch lowers the quality of the history of the development branch,
which is the everlasting one, while the maintenance branch will
eventually freeze and become almost irrelevant.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:25 ` Óscar Fuentes
@ 2014-03-20 4:59 ` Stefan
2014-03-20 7:36 ` Steinar Bang
2014-03-20 16:19 ` Eli Zaretskii
2014-03-20 16:17 ` Eli Zaretskii
1 sibling, 2 replies; 65+ messages in thread
From: Stefan @ 2014-03-20 4:59 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> Which reminds me of a comment I made long time ago: applying fixes on
> the maintenance branch and then cherry-picking them into the development
Not sure why this matters: we don't cherry pick from the
maintenance branch. Instead we merge the development branch. And we
sometimes cherry pick fixes from the development branch into the
maintenance branch (which makes the subsequent merge a bit more
delicate, since we want to avoid applying that change twice).
Stefan
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:09 ` Óscar Fuentes
@ 2014-03-20 7:06 ` David Engster
2014-03-20 7:49 ` Steinar Bang
2014-03-20 12:42 ` Óscar Fuentes
2014-03-20 16:13 ` Eli Zaretskii
1 sibling, 2 replies; 65+ messages in thread
From: David Engster @ 2014-03-20 7:06 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I would encourage git newcomers to just use Magit. It provides a nice UI
>>> for git, requiring very basic knowledge of git's specific features.
>>
>> That's unrelated to the issue at hand, which is how we use git at the
>> project level.
>
> Magit can determine how you use git at the project level. Since it makes
> ordinary tasks quite more simple and less error-prone, git's barroque UI
> is no longer a significant factor.
Since Eli is working on Windows, I don't think Magit is a good solution
for him. It is pretty slow there since it is often doing an excessive
number of calls of the Git binary under the hood.
-David
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:59 ` Stefan
@ 2014-03-20 7:36 ` Steinar Bang
2014-03-20 7:48 ` Florian Weimer
2014-03-20 16:19 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 7:36 UTC (permalink / raw
To: emacs-devel
>>>>> Stefan <monnier@iro.umontreal.ca>:
> Not sure why this matters: we don't cherry pick from the maintenance
> branch. Instead we merge the development branch. And we sometimes
> cherry pick fixes from the development branch into the maintenance
> branch (which makes the subsequent merge a bit more delicate, since we
> want to avoid applying that change twice).
What I do, after cherry picking a fix from the master HEAD back into a
release branch (named "release-branch" in the below commands) is
immediately do a:
git checkout master
git merge --no-ff --no-commit release-branch
(The latter command will apply the changes from the merge, and then stop
before committing)
Then I look at the changes in magit, and ideally there should be no
diffs, because I have done the same thing earlier in the lifetime of the
release branch, and have told git to drop irrelevant changes from the
release branch.
The way to tell git to drop the merge results and instead pick the
version from master, is to insert the master branch's version of the
file before committing, eg.:
git checkout origin/master version.txt
(this picks the master branch's version of the, er..., version file.
"origin/master" means the version of the master branch that has been
pushed to the remote git repository named "origin")
name of the first branch
After I am satisfied that the merge results contains no unexpected
changes with master, I do a:
git commit
to complete the merge (or just do a `c' in magit).
Whenever I am doing a bugfix, I _try_ to start a local branch in the
earliest branch where the fix is relevant, and do the fix there. Then,
instead of cherry picking, I can just merge the fix into the newer
branches that should have the same fix.
And most of the time the merge will be conflict free and correct.
But I always do
git commit --no-ff --no-commit
in these cases, and look at the diffs resulting from the merge in magit.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 3:49 ` Eli Zaretskii
@ 2014-03-20 7:46 ` Steinar Bang
2014-03-20 16:09 ` Glenn Morris
2014-03-20 16:33 ` Eli Zaretskii
2014-03-20 18:19 ` Andreas Schwab
1 sibling, 2 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 7:46 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> If this feature is already mature enough, perhaps we should recommend
> it on the wiki as the solution for this issue.
I'd recommend against using new and little tested features in the
recommended workflow. I saw some painful results from someone
_insisting_ to use git submodule, because it fit his perceived workflow.
Firstly, just switching branches inside the the working directory is
fast and easy, so coding on separate branches can easily be done inside
one working directory.
Secondly, if what you want is to have two working directories side by
side, because you eg. wish to do a long running build or test session in
one working directory, and you don't wish to pollute the upstream
repository with your short lived local branches, you can just create an
extra remote and push and pull from that.
You can create that extra remote locally on the disk of your computer,
or you can create a repository on github and use that.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:36 ` Steinar Bang
@ 2014-03-20 7:48 ` Florian Weimer
2014-03-20 8:07 ` Steinar Bang
0 siblings, 1 reply; 65+ messages in thread
From: Florian Weimer @ 2014-03-20 7:48 UTC (permalink / raw
To: emacs-devel
* Steinar Bang:
> What I do, after cherry picking a fix from the master HEAD back into a
> release branch (named "release-branch" in the below commands) is
> immediately do a:
> git checkout master
> git merge --no-ff --no-commit release-branch
> After I am satisfied that the merge results contains no unexpected
> changes with master, I do a:
> git commit
> to complete the merge (or just do a `c' in magit).
This complicates the history of the master branch. It is not clear if
it adds any useful information, especially if there is no expectation
of ever doing development on release branches and merge this
development back to the master branch later.
> Whenever I am doing a bugfix, I _try_ to start a local branch in the
> earliest branch where the fix is relevant, and do the fix there. Then,
> instead of cherry picking, I can just merge the fix into the newer
> branches that should have the same fix.
Tool support is generally better if you make the change in the oldest
supported release branch and merge that forward, but in practice, this
doesn't work that well. Often, you don't know for sure what the
oldest release branch that needs the change is. And from a general
engineering point of view, it is better to develop the best fix
possible on the master branch, test it, and then start backporting it,
taking shortcuts as necessary. If you do it in the other order, you
tend to end up with a suboptimal change in the master branch. And the
development history becomes really, really complicated, too.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:06 ` David Engster
@ 2014-03-20 7:49 ` Steinar Bang
2014-03-20 16:35 ` Eli Zaretskii
2014-03-20 12:42 ` Óscar Fuentes
1 sibling, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 7:49 UTC (permalink / raw
To: emacs-devel
>>>>> David Engster <deng@randomsample.de>:
> Since Eli is working on Windows, I don't think Magit is a good
> solution for him. It is pretty slow there since it is often doing an
> excessive number of calls of the Git binary under the hood.
Making magit use the git.exe, rather than the git.cmd, made it fast
enough for me on windows, even on a fairly large project.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:48 ` Florian Weimer
@ 2014-03-20 8:07 ` Steinar Bang
0 siblings, 0 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 8:07 UTC (permalink / raw
To: emacs-devel
>>>>> Florian Weimer <fw@deneb.enyo.de>:
> This complicates the history of the master branch. It is not clear if
> it adds any useful information,
It makes later merges more likely to only contain the relevant changes.
And the merge happens at a time where I can remember what was done and
what the changes should be.
That is useful information the way I see it.
> especially if there is no expectation of ever doing development on
> release branches and merge this development back to the master branch
> later.
Like I said, the pattern that works well for me, and gives a nice
history on the file level, and the "git blame" level, is to do the fix
on the earliest release branch were it is relevant, and then merge it
forward.
But that requires that the master is kept in sync with cherry picks
applied to the release branches. If it isn't, the merge results can be
strange, and it can be challenging to see what has happened (not
impossible, and as long as nothing is committed or pushed, recovery is
easy).
> Tool support is generally better if you make the change in the oldest
> supported release branch and merge that forward, but in practice, this
> doesn't work that well. Often, you don't know for sure what the
> oldest release branch that needs the change is.
True. So one always end up with some cherry picks.
> And from a general engineering point of view, it is better to develop
> the best fix possible on the master branch, test it, and then start
> backporting it, taking shortcuts as necessary.
Er... no. It's not possible to generalize like that. For one particular
fix this may have been the right approach. For another it may not.
Basically, the way important release fixes have come to me, they have
been reported as bugs against the released version, and then I naturally
start with the release branch for that version, and figure out the
problem, and do the fix.
Once that fix is complete and pushed (released as a patch, or as a new
version or whatever, and sent to the customer), I look at if the fix is
relevant in master and later releases. If the code has changed little
enough that a merge seems to be possible, I merge the older release
branches forward.
In many fixes, this is the case.
If the code has changed so much that a merge isn't possible I try to
figure out if the bug is still present in the master branch, and if it
is, how to best fix it (it may be a completely different fix to what was
done in the release branch).
> If you do it in the other order, you tend to end up with a suboptimal
> change in the master branch.
Only if you merge blindly and assume that the fix will be correct for
all versions.
> And the development history becomes really, really complicated, too.
In what way? Could you be specific?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:06 ` David Engster
2014-03-20 7:49 ` Steinar Bang
@ 2014-03-20 12:42 ` Óscar Fuentes
2014-03-20 14:03 ` Stefan
1 sibling, 1 reply; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 12:42 UTC (permalink / raw
To: emacs-devel
David Engster <deng@randomsample.de> writes:
> Óscar Fuentes writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> I would encourage git newcomers to just use Magit. It provides a nice UI
>>>> for git, requiring very basic knowledge of git's specific features.
>>>
>>> That's unrelated to the issue at hand, which is how we use git at the
>>> project level.
>>
>> Magit can determine how you use git at the project level. Since it makes
>> ordinary tasks quite more simple and less error-prone, git's barroque UI
>> is no longer a significant factor.
>
> Since Eli is working on Windows, I don't think Magit is a good solution
> for him. It is pretty slow there since it is often doing an excessive
> number of calls of the Git binary under the hood.
>
> -David
Magit is slow on Windows only if you compare it to how it performs on
GNU/Linux. I regularly use Magit on a Windows netbook and it is faster
than bzr ever was on that machine. Also, there is room for improvement:
the slowest part is where Magit refreshes the buffers (after switching
to another branch, for example) and that is Emacs's VC being slow, not
Magit. I experimented with advising the VC functions that update the VC
status and the speedup is dramatic (one or two git invocations per Magit
operation instead of one per visited file.)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 12:42 ` Óscar Fuentes
@ 2014-03-20 14:03 ` Stefan
2014-03-20 15:09 ` Óscar Fuentes
0 siblings, 1 reply; 65+ messages in thread
From: Stefan @ 2014-03-20 14:03 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> Magit. I experimented with advising the VC functions that update the VC
> status and the speedup is dramatic (one or two git invocations per Magit
> operation instead of one per visited file.)
Do post your hack (as a bug-report requesting a new VC feature), tho
better would be a proper patch.
Stefan
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 14:03 ` Stefan
@ 2014-03-20 15:09 ` Óscar Fuentes
0 siblings, 0 replies; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 15:09 UTC (permalink / raw
To: emacs-devel
Stefan <monnier@iro.umontreal.ca> writes:
>> Magit. I experimented with advising the VC functions that update the VC
>> status and the speedup is dramatic (one or two git invocations per Magit
>> operation instead of one per visited file.)
>
> Do post your hack
Below is the patch against an old version of magit.el.
> (as a bug-report requesting a new VC feature), tho better would be a
> proper patch.
This could be generalized to a generic VC feature, but I'm not sure it
is worth the trouble outside of Magit on Windows. Do you know any other
context (VC backend/package/platform) where it would make a difference?
Author: Oscar Fuentes <ofv@wanadoo.es>
Date: Mon Aug 15 00:15:30 2011 +0200
Speed-up magit-revert-buffers
Advice some vc-git-* functions and use a cache. 100x faster on Windows
when there are more than 10 files visited under the working copy.
1 file changed, 65 insertions(+), 14 deletions(-)
magit.el | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------
Modified magit.el
diff --git a/magit.el b/magit.el
index 0e6f2b6..8a938c9 100644
--- a/magit.el
+++ b/magit.el
@@ -2210,23 +2210,74 @@ Please see the manual for a complete description of Magit.
(defun magit-string-has-prefix-p (string prefix)
(eq (compare-strings string nil (length prefix) prefix nil nil) t))
+(defvar magit-refresh-needing-buffers nil)
+(defvar magit-refresh-pending nil)
+(defvar magit-cached-vc-state nil)
+(defvar magit-vc-state-cache-buffer-name " *magit-vc-state-cache*")
+
(defun magit-revert-buffers (dir &optional ignore-modtime)
- (dolist (buffer (buffer-list))
- (when (and buffer
- (buffer-file-name buffer)
- (magit-string-has-prefix-p (buffer-file-name buffer) dir))
- (with-current-buffer buffer
- (or (ignore-errors
- (and (or ignore-modtime (not (verify-visited-file-modtime buffer)))
- (not (buffer-modified-p buffer))
- (revert-buffer t t nil)))
- ;; Update the VC modeline info when revert-buffer failed to execute:
- (ignore-errors
- (vc-find-file-hook))))))
+ (let ((magit-cached-vc-state
+ (list (magit-get-current-branch) dir)))
+ (magit-create-vc-state-cache dir)
+ (dolist (buffer (buffer-list))
+ (when (and buffer
+ (buffer-file-name buffer)
+ (magit-string-has-prefix-p (buffer-file-name buffer) dir))
+ (with-current-buffer buffer
+ (or (ignore-errors
+ (and (or ignore-modtime (not (verify-visited-file-modtime buffer)))
+ (not (buffer-modified-p buffer))
+ (revert-buffer t t nil)))
+ ;; Update the VC modeline info when revert-buffer failed to execute:
+ (ignore-errors
+ (vc-find-file-hook)))))))
+ (kill-buffer magit-vc-state-cache-buffer-name)
(setq magit-revert-buffers-pending nil))
-(defvar magit-refresh-needing-buffers nil)
-(defvar magit-refresh-pending nil)
+(defun magit-create-vc-state-cache (dir)
+ (let ((sbuffer (get-buffer-create magit-vc-state-cache-buffer-name)))
+ (with-current-buffer sbuffer
+ (setq default-directory dir)
+ (buffer-disable-undo)
+ (erase-buffer)
+ (call-process vc-git-executable nil sbuffer nil "ls-files" "-tdcm"))))
+
+(defun magit-lookup-vc-state (file)
+ (when (magit-string-has-prefix-p file (nth 1 magit-cached-vc-state))
+ (setq file (substring file (length (nth 1 magit-cached-vc-state)))))
+ (with-current-buffer magit-vc-state-cache-buffer-name
+ (goto-char (point-max))
+ (if (re-search-backward (concat "^. " file "$") nil t)
+ (let ((line (match-string 0)))
+ (if (string-match "^\\(.\\) .+$" line)
+ (magit-vc-git--state-code (match-string 1 line))))
+ 'unregistered)))
+
+(defun magit-vc-git--state-code (code)
+ "Convert from a string to a added/deleted/modified state."
+ (case (string-to-char code)
+ (?C 'edited)
+ (?H 'up-to-date)
+ (?R 'removed)
+ (?M 'conflict)
+ (?T 'edited)))
+
+(defadvice vc-git-state (around ad-magit-vc-git-state activate)
+ (if magit-cached-vc-state
+ (setq ad-return-value (magit-lookup-vc-state file))
+ ad-do-it))
+
+(defadvice vc-git-working-revision (around ad-magit-vc-git-working-revision
+ activate)
+ (if magit-cached-vc-state
+ (setq ad-return-value (nth 0 magit-cached-vc-state))
+ ad-do-it))
+
+(defadvice vc-git-registered (around ad-magit-vc-git-registered activate)
+ (if magit-cached-vc-state
+ (setq ad-return-value
+ (not (eq 'unregistered (magit-lookup-vc-state file))))
+ ad-do-it))
(defun magit-refresh-wrapper (func)
(if magit-refresh-pending
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:46 ` Steinar Bang
@ 2014-03-20 16:09 ` Glenn Morris
2014-03-20 20:17 ` Steinar Bang
2014-03-20 16:33 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Glenn Morris @ 2014-03-20 16:09 UTC (permalink / raw
To: emacs-devel
Boy, I sure am glad that replacing bzrmerge.el with equivalent
functionality is a precondition for changing VCS.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:09 ` Óscar Fuentes
2014-03-20 7:06 ` David Engster
@ 2014-03-20 16:13 ` Eli Zaretskii
2014-03-20 20:23 ` Steinar Bang
1 sibling, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 16:13 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Mar 2014 05:09:58 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> I would encourage git newcomers to just use Magit. It provides a nice UI
> >> for git, requiring very basic knowledge of git's specific features.
> >
> > That's unrelated to the issue at hand, which is how we use git at the
> > project level.
>
> Magit can determine how you use git at the project level.
I very much hope that it will be the other way around: first we decide
how we want to work, and only afterwards tweak the tools (if needed)
to match that.
> Since it makes ordinary tasks quite more simple and less
> error-prone, git's barroque UI is no longer a significant factor.
We've been there: I don't think you can entirely ignore the
command-line UI to git. Too much of the useful functionality isn't
accessible through front ends.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:25 ` Óscar Fuentes
2014-03-20 4:59 ` Stefan
@ 2014-03-20 16:17 ` Eli Zaretskii
2014-03-20 19:28 ` Óscar Fuentes
1 sibling, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 16:17 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Mar 2014 05:25:22 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > E.g., the way we merge from the release branch is due
> > to the fact that bzr doesn't track cherry-picks. Git does.
>
> No, it doesn't.
Maybe with magit ;-)
From the command line, there's the -x switch to cherry-pick, which
does, sort of. The question is, do we want that service?
> Which reminds me of a comment I made long time ago: applying fixes on
> the maintenance branch and then cherry-picking them into the development
> branch lowers the quality of the history of the development branch,
> which is the everlasting one, while the maintenance branch will
> eventually freeze and become almost irrelevant.
That's another issue that I think is worth discussing. E.g., GDB
applies fixes to the trunk, and then cherry-picks some of them to the
release branch. But then GDB doesn't keep the release branch for very
long, and never makes more than 2 versions out of it, so I'm not sure
that example is good for Emacs.
(I hope now you agree that using or not using magit is not the
important issue here.)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:59 ` Stefan
2014-03-20 7:36 ` Steinar Bang
@ 2014-03-20 16:19 ` Eli Zaretskii
2014-03-20 18:02 ` Stefan
2014-03-20 20:30 ` Steinar Bang
1 sibling, 2 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 16:19 UTC (permalink / raw
To: Stefan; +Cc: ofv, emacs-devel
> From: Stefan <monnier@iro.umontreal.ca>
> Date: Thu, 20 Mar 2014 00:59:57 -0400
> Cc: emacs-devel@gnu.org
>
> > Which reminds me of a comment I made long time ago: applying fixes on
> > the maintenance branch and then cherry-picking them into the development
>
> Not sure why this matters: we don't cherry pick from the
> maintenance branch. Instead we merge the development branch. And we
> sometimes cherry pick fixes from the development branch into the
> maintenance branch (which makes the subsequent merge a bit more
> delicate, since we want to avoid applying that change twice).
See my other mail: why not install changes on the trunk, and then
cherry-pick some of them to the release branch?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:46 ` Steinar Bang
2014-03-20 16:09 ` Glenn Morris
@ 2014-03-20 16:33 ` Eli Zaretskii
2014-03-20 21:00 ` Steinar Bang
1 sibling, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 16:33 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 08:46:25 +0100
>
> Firstly, just switching branches inside the the working directory is
> fast and easy, so coding on separate branches can easily be done inside
> one working directory.
Switching is indeed fast, but building after the switch isn't. See my
original explanation why this is different in Emacs than in some other
projects. In a nutshell, you will many times need a full bootstrap,
sometimes with the configure step on top of that.
> Secondly, if what you want is to have two working directories side by
> side, because you eg. wish to do a long running build or test session in
> one working directory, and you don't wish to pollute the upstream
> repository with your short lived local branches, you can just create an
> extra remote and push and pull from that.
>
> You can create that extra remote locally on the disk of your computer,
> or you can create a repository on github and use that.
These are the kinds of workflows I suggested to discuss. I don't
doubt for a moment that there are no solutions, the question is which
one(s) are best suited to Emacs development and maintenance.
IOW, we need specific suggestions of workflows and procedures, rather
than general references to possible ways of going about this.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 7:49 ` Steinar Bang
@ 2014-03-20 16:35 ` Eli Zaretskii
0 siblings, 0 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 16:35 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 08:49:44 +0100
>
> >>>>> David Engster <deng@randomsample.de>:
>
> > Since Eli is working on Windows, I don't think Magit is a good
> > solution for him. It is pretty slow there since it is often doing an
> > excessive number of calls of the Git binary under the hood.
>
> Making magit use the git.exe, rather than the git.cmd, made it fast
> enough for me on windows, even on a fairly large project.
Please don't waste your breath on these issues. With or without
magit, I use git in several projects, and see no reason why Emacs
cannot be one more. And what I do on my machines is hardly the
important part of this discussion, anyway.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:19 ` Eli Zaretskii
@ 2014-03-20 18:02 ` Stefan
2014-03-20 18:09 ` David Kastrup
2014-03-20 18:15 ` Eli Zaretskii
2014-03-20 20:30 ` Steinar Bang
1 sibling, 2 replies; 65+ messages in thread
From: Stefan @ 2014-03-20 18:02 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
> See my other mail: why not install changes on the trunk, and then
> cherry-pick some of them to the release branch?
Because I want to be sure that changes applied to the release branch are
included in the trunk. A "merge" from the release to the trunk is
a good way to be sure.
Stefan
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:02 ` Stefan
@ 2014-03-20 18:09 ` David Kastrup
2014-03-20 20:35 ` Steinar Bang
2014-03-20 18:15 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: David Kastrup @ 2014-03-20 18:09 UTC (permalink / raw
To: emacs-devel
Stefan <monnier@iro.umontreal.ca> writes:
>> See my other mail: why not install changes on the trunk, and then
>> cherry-pick some of them to the release branch?
>
> Because I want to be sure that changes applied to the release branch are
> included in the trunk. A "merge" from the release to the trunk is
> a good way to be sure.
You can always do that merge privately and check that it has a zero diff
to the trunk.
--
David Kastrup
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:02 ` Stefan
2014-03-20 18:09 ` David Kastrup
@ 2014-03-20 18:15 ` Eli Zaretskii
2014-03-20 18:44 ` Stefan
1 sibling, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 18:15 UTC (permalink / raw
To: Stefan; +Cc: ofv, emacs-devel
> From: Stefan <monnier@iro.umontreal.ca>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Thu, 20 Mar 2014 14:02:01 -0400
>
> > See my other mail: why not install changes on the trunk, and then
> > cherry-pick some of them to the release branch?
>
> Because I want to be sure that changes applied to the release branch are
> included in the trunk.
If you apply the changes to the trunk to begin with, this condition is
satisfied by definition, no?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 3:49 ` Eli Zaretskii
2014-03-20 7:46 ` Steinar Bang
@ 2014-03-20 18:19 ` Andreas Schwab
2014-03-20 18:27 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Andreas Schwab @ 2014-03-20 18:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> At the time this came up, you said this feature is not ready yet for
> prime time.
Did I? I don't think so.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:19 ` Andreas Schwab
@ 2014-03-20 18:27 ` Eli Zaretskii
0 siblings, 0 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 18:27 UTC (permalink / raw
To: Andreas Schwab; +Cc: esr, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: esr@thyrsus.com, emacs-devel@gnu.org
> Date: Thu, 20 Mar 2014 19:19:07 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > At the time this came up, you said this feature is not ready yet for
> > prime time.
>
> Did I? I don't think so.
I meant this part from
http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00864.html:
> There is work in progress to fully integrate git new-workdir into the
> git core, to remove its shortcomings.
Apologies if I misinterpreted what you meant.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:15 ` Eli Zaretskii
@ 2014-03-20 18:44 ` Stefan
2014-03-20 20:17 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Stefan @ 2014-03-20 18:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
> If you apply the changes to the trunk to begin with, this condition is
> satisfied by definition, no?
Yup: "If"
Stefan
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:17 ` Eli Zaretskii
@ 2014-03-20 19:28 ` Óscar Fuentes
2014-03-20 20:19 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 19:28 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> > E.g., the way we merge from the release branch is due
>> > to the fact that bzr doesn't track cherry-picks. Git does.
>>
>> No, it doesn't.
>
> Maybe with magit ;-)
>
> From the command line, there's the -x switch to cherry-pick, which
> does, sort of.
-x just adds a line to the commit message with the revision id of the
source commit. It's a convenience for the user, not something that git
will exploit later.
[snip]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:44 ` Stefan
@ 2014-03-20 20:17 ` Eli Zaretskii
0 siblings, 0 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 20:17 UTC (permalink / raw
To: Stefan; +Cc: ofv, emacs-devel
> From: Stefan <monnier@iro.umontreal.ca>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Thu, 20 Mar 2014 14:44:47 -0400
>
> > If you apply the changes to the trunk to begin with, this condition is
> > satisfied by definition, no?
>
> Yup: "If"
The method I was asking about had that "If" condition fulfilled.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:09 ` Glenn Morris
@ 2014-03-20 20:17 ` Steinar Bang
2014-03-20 20:21 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 20:17 UTC (permalink / raw
To: emacs-devel
>>>>> Glenn Morris <rgm@gnu.org>:
> Boy, I sure am glad that replacing bzrmerge.el with equivalent
> functionality is a precondition for changing VCS.
What's bzrmerge.el?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 19:28 ` Óscar Fuentes
@ 2014-03-20 20:19 ` Eli Zaretskii
2014-03-20 20:31 ` Óscar Fuentes
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 20:19 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Mar 2014 20:28:50 +0100
>
> -x just adds a line to the commit message with the revision id of the
> source commit. It's a convenience for the user, not something that git
> will exploit later.
Yes, I know. And we are that user.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:17 ` Steinar Bang
@ 2014-03-20 20:21 ` Eli Zaretskii
0 siblings, 0 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 20:21 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 21:17:40 +0100
>
> >>>>> Glenn Morris <rgm@gnu.org>:
>
> > Boy, I sure am glad that replacing bzrmerge.el with equivalent
> > functionality is a precondition for changing VCS.
>
> What's bzrmerge.el?
admin/bzrmerge.el is its full name.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:13 ` Eli Zaretskii
@ 2014-03-20 20:23 ` Steinar Bang
0 siblings, 0 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 20:23 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> We've been there: I don't think you can entirely ignore the
> command-line UI to git. Too much of the useful functionality isn't
> accessible through front ends.
In particular the merge-and-stop-before-commit, and then manually
picking parts of the tree from one of the branches (a former colleague
referred to this as a "gonzo merge").
The use case is where a subtree comes completely from one branch, while
the rest comes from a different branch (and I've had that particular use
case (driven by other necessitiesm, btw. Not driven by git. git
actually made that easy)).
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:19 ` Eli Zaretskii
2014-03-20 18:02 ` Stefan
@ 2014-03-20 20:30 ` Steinar Bang
2014-03-20 20:39 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 20:30 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> See my other mail: why not install changes on the trunk, and then
> cherry-pick some of them to the release branch?
Here's why I does it the other way around (ie. fix on branch and then
merge to master): when a bug is reported on a released version, it feels
more natural to do the fix against what was released, and then get some
kind of patch or hotfix on that out the door, and then looking in to
moving that fix to master.
Taking an unreported fix from master and applying it to a relase branch
with a cherry pick also happens, but for that to happen, it has to be a
fix to an OMG!! condition (potential catastrophic data loss, or a high
enough crash rate to be annoying), and those bugs are thankfully few...
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:19 ` Eli Zaretskii
@ 2014-03-20 20:31 ` Óscar Fuentes
2014-03-20 20:40 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 20:31 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> -x just adds a line to the commit message with the revision id of the
>> source commit. It's a convenience for the user, not something that git
>> will exploit later.
>
> Yes, I know. And we are that user.
Then, why are you not using it with bzr?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 18:09 ` David Kastrup
@ 2014-03-20 20:35 ` Steinar Bang
0 siblings, 0 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 20:35 UTC (permalink / raw
To: emacs-devel
>>>>> David Kastrup <dak@gnu.org>:
> Stefan <monnier@iro.umontreal.ca> writes:
>>> See my other mail: why not install changes on the trunk, and then
>>> cherry-pick some of them to the release branch?
>> Because I want to be sure that changes applied to the release branch are
>> included in the trunk. A "merge" from the release to the trunk is
>> a good way to be sure.
> You can always do that merge privately and check that it has a zero diff
> to the trunk.
If you merge with stop-before-commit and get some unexpected diffs, you
can fix them (usually by doing "git checkout" on the files with diff
from their master versions) and commit, and the diffs won't confuse
future merge results.
(I actually don't know if there is any point to making a commit of a zero
diff merge result...?)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:30 ` Steinar Bang
@ 2014-03-20 20:39 ` Eli Zaretskii
2014-03-20 21:10 ` Steinar Bang
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 20:39 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 21:30:47 +0100
>
> >>>>> Eli Zaretskii <eliz@gnu.org>:
>
> > See my other mail: why not install changes on the trunk, and then
> > cherry-pick some of them to the release branch?
>
> Here's why I does it the other way around (ie. fix on branch and then
> merge to master): when a bug is reported on a released version, it feels
> more natural to do the fix against what was released
Why is it more natural? If the same bug exists on the trunk, you
could fix it in either of the two places first.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:31 ` Óscar Fuentes
@ 2014-03-20 20:40 ` Eli Zaretskii
2014-03-20 20:46 ` Óscar Fuentes
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-20 20:40 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Mar 2014 21:31:41 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> -x just adds a line to the commit message with the revision id of the
> >> source commit. It's a convenience for the user, not something that git
> >> will exploit later.
> >
> > Yes, I know. And we are that user.
>
> Then, why are you not using it with bzr?
Because "bzr merge" doesn't have such an option.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:40 ` Eli Zaretskii
@ 2014-03-20 20:46 ` Óscar Fuentes
0 siblings, 0 replies; 65+ messages in thread
From: Óscar Fuentes @ 2014-03-20 20:46 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> >> -x just adds a line to the commit message with the revision id of the
>> >> source commit. It's a convenience for the user, not something that git
>> >> will exploit later.
>> >
>> > Yes, I know. And we are that user.
>>
>> Then, why are you not using it with bzr?
>
> Because "bzr merge" doesn't have such an option.
Was it requested to bzr developers? It doesn't seem hard to implement.
Actually, it is something you could achieve with a simple wrapper
script.
Git does not track cherry-picks and -x solves nothing unless you develop
some kind of poor-man's tracking yourself.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 16:33 ` Eli Zaretskii
@ 2014-03-20 21:00 ` Steinar Bang
2014-03-21 9:08 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 21:00 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> IOW, we need specific suggestions of workflows and procedures, rather
> than general references to possible ways of going about this.
Ok, here's how to make a local, er... remote
1. Make an empty local repo
cd ~/git
git init --bare emacs-local
2. Add it as a remote
cd ~/git/emacs/
git remote add local ../emacs-local
3. Make a copy of the working directory:
cd ~/git
cp -a emacs emacs-copy
At this point the remote named "local" doesn't contain any branches, and
push and pull from either working directory will go against the same
remote (named "origin" if there is only one, and it has been given the
default name).
Now we'll make a branch in one of the working directories and push it to
the other, using the "local" remote (interesting terminology...).
4. Make the branch and push it to local:
cd ~/git/emacs
git checkout -b sb-fix-annoying-bug
git push -u local HEAD
5. Fetch the branch into the other working directory
cd ~/git/emacs-copy
git fetch local
git checkout sb-fix-annoying-bug
After 4 and 5, then sb-fix-annoying-bug will be a tracking branch in
both emacs and emacs-copy, but the upstream will be in "local" rather
than in "origin" (ie. push and pull when standing on that branch will go
to "local" rather than "origin").
Merge from sb-fix-annoying-bug to master will work fine, and can be done
from either working directory.
Downsides to a git repository backing multiple working directories, are:
- 3 copies of the git repository on disk, rather than just one
- An extra push needed after the commit in the workflow
Upside:
- Only uses core git functionality, rather than a new and experimental
feature
(Personally I have learned to stay away from experimental git
features. Even if they work as advertised they may not be installed on
all git instances I use, and GUI tool support may be lacking)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 20:39 ` Eli Zaretskii
@ 2014-03-20 21:10 ` Steinar Bang
2014-03-21 7:46 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-20 21:10 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> Why is it more natural? If the same bug exists on the trunk, you
> could fix it in either of the two places first.
I live in the land of refactoring, and one thing that happens
immediately after a branch for release, is that people tend to go wild
with refactoring that has been delayed pending the release.
So it makes most sense to look for the bug where it has been reported.
As for merging the fix into master: the master may have changed so much
that the fix doesn't make sense anymore.
That said, a merge has a better change at finding the correct place to
apply, in the refactoried code, than a cherry-pick does. But the merge
result needs to be inspected after the merge.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 4:04 ` Eli Zaretskii
2014-03-20 4:25 ` Óscar Fuentes
@ 2014-03-21 3:02 ` Stephen J. Turnbull
2014-03-21 8:01 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Stephen J. Turnbull @ 2014-03-21 3:02 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, emacs-devel
Eli Zaretskii writes:
> > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> > Cc: esr@thyrsus.com,
> > emacs-devel@gnu.org
> > Date: Thu, 20 Mar 2014 09:08:32 +0900
> >
> > About the workflow, Eli Zaretskii writes:
> >
> > > It is better to draw upon the knowhow and experience of veteran git
> > > users among us to identify in advance the preferred workflows,
> >
> > And the resulting recommendations will be ignored in favor of the
> > convenience of the powers that be, as the recommendations for Bazaar
> > were.
>
> I think almost all of the Emacs developers use the workflow described
> on the wiki. I know I do. So I'm not sure what your assessment is
> based on.
The reaction of you (!!), Ken'ichi, and Richard to the version of
BzrForEmacsDevs that Karl wrote and I revised (with, IIRC, the
enthusiastic approval of Karl).
I just don't see any point in spending a lot of time trying to design
a great workflow in advance. If you do, go right ahead and do it
yourself, and I wish you the good fortune that you're better at
channeling the "user to git: just stay out of my way" users than Karl
and I were.
But I see no point in asking Eric Raymond or git fans to get involved
in it. The only point in that is for them to suggest things that work
well for them that make no sense to most users until they've had a fair
amount of experience. And most users will go: "not now, please!" I
suggest that you respect that reaction, and let the appropriate
workflow evolve over time.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 21:10 ` Steinar Bang
@ 2014-03-21 7:46 ` Eli Zaretskii
2014-03-21 12:40 ` Stefan
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 7:46 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 22:10:01 +0100
>
> >>>>> Eli Zaretskii <eliz@gnu.org>:
>
> > Why is it more natural? If the same bug exists on the trunk, you
> > could fix it in either of the two places first.
>
> I live in the land of refactoring, and one thing that happens
> immediately after a branch for release, is that people tend to go wild
> with refactoring that has been delayed pending the release.
>
> So it makes most sense to look for the bug where it has been reported.
>
> As for merging the fix into master: the master may have changed so much
> that the fix doesn't make sense anymore.
In both of these cases, the fix should not be applied to the trunk
anyway. So this is not the situation I was describing, where a fix is
applicable to both the trunk and the branch.
When a fix is only applicable to the branch, just apply it there, and
don't worry to merge or cherry-pick anywhere else.
> That said, a merge has a better change at finding the correct place to
> apply, in the refactoried code, than a cherry-pick does. But the merge
> result needs to be inspected after the merge.
What bzrmerge.el does, when we merge a fix from the branch, is
effectively a cherry-pick, but it also records the branch commit as
being present on the trunk. If the fix is not applicable to the
trunk, we end up with a commit that didn't bring any changes in terms
of diff (because the changes will be edited out before committing
after the merge). I'm not sure this will work with git, btw.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 3:02 ` Stephen J. Turnbull
@ 2014-03-21 8:01 ` Eli Zaretskii
0 siblings, 0 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 8:01 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: esr, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
> emacs-devel@gnu.org
> Date: Fri, 21 Mar 2014 12:02:31 +0900
>
> > > > It is better to draw upon the knowhow and experience of veteran git
> > > > users among us to identify in advance the preferred workflows,
> > >
> > > And the resulting recommendations will be ignored in favor of the
> > > convenience of the powers that be, as the recommendations for Bazaar
> > > were.
> >
> > I think almost all of the Emacs developers use the workflow described
> > on the wiki. I know I do. So I'm not sure what your assessment is
> > based on.
>
> The reaction of you (!!), Ken'ichi, and Richard to the version of
> BzrForEmacsDevs that Karl wrote and I revised (with, IIRC, the
> enthusiastic approval of Karl).
What reaction? Again, I'm using the workflow described there since
the very beginning. I think so does Handa-san (judging by his
commits).
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-20 21:00 ` Steinar Bang
@ 2014-03-21 9:08 ` Eli Zaretskii
2014-03-21 9:38 ` Andreas Schwab
2014-03-21 9:53 ` Steinar Bang
0 siblings, 2 replies; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 9:08 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Thu, 20 Mar 2014 22:00:03 +0100
>
> >>>>> Eli Zaretskii <eliz@gnu.org>:
>
> > IOW, we need specific suggestions of workflows and procedures, rather
> > than general references to possible ways of going about this.
>
> Ok, here's how to make a local, er... remote
Thanks. However, I cannot easily map this arrangement to what I had
in mind, namely, having a separate trunk and release branches, each
one having its working tree in a different directory. What am I
missing?
As for feature branches, I think relatively short-lived ones will be
better off in the same directory as the trunk, because they aren't
expected to diverge too much, so having them co-located actually makes
a lot of sense and saves time. (Since each build produces also a
numbered emacs-XX.YY.nn executable, it is at least in theory possible
to have several executables available at once.) By contrast, feature
branches that make deep changes and this diverge a lot from the trunk
are better kept in separate directories, like the release branch.
> Downsides to a git repository backing multiple working directories, are:
> - 3 copies of the git repository on disk, rather than just one
Doesn't --separate-git-dir solve that problem?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 9:08 ` Eli Zaretskii
@ 2014-03-21 9:38 ` Andreas Schwab
2014-03-21 9:53 ` Steinar Bang
1 sibling, 0 replies; 65+ messages in thread
From: Andreas Schwab @ 2014-03-21 9:38 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Steinar Bang, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Downsides to a git repository backing multiple working directories, are:
>> - 3 copies of the git repository on disk, rather than just one
>
> Doesn't --separate-git-dir solve that problem?
No, the index cannot be shared between different working directories.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 9:08 ` Eli Zaretskii
2014-03-21 9:38 ` Andreas Schwab
@ 2014-03-21 9:53 ` Steinar Bang
2014-03-21 10:17 ` Eli Zaretskii
1 sibling, 1 reply; 65+ messages in thread
From: Steinar Bang @ 2014-03-21 9:53 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
> Thanks. However, I cannot easily map this arrangement to what I had
> in mind, namely, having a separate trunk and release branches, each
> one having its working tree in a different directory. What am I
> missing?
Ok, so you want separate working directories of the official master and
release branches?
I have satisfied this requirement for myself, by simply having separate
clones, something like this:
cd ~/git
git clone http://somewhere/emacs.git
git clone --branch release-23.4 http://somewhere/emacs.git emacs-release-23.4
git clone --branch release-24.0 http://somewhere/emacs.git emacs-release-24.0
Exchange of information between these branches can take place with push
and pull from the upstream repository.
> As for feature branches, I think relatively short-lived ones will be
> better off in the same directory as the trunk, because they aren't
> expected to diverge too much, so having them co-located actually makes
> a lot of sense and saves time.
By "co-located", do you mean one .git directory serving multiple working
directories? If so, that was the problem I was trying to solve by using
a local "remote": exchanging branches across separate clones.
> (Since each build produces also a numbered emacs-XX.YY.nn executable,
> it is at least in theory possible to have several executables
> available at once.) By contrast, feature branches that make deep
> changes and this diverge a lot from the trunk are better kept in
> separate directories, like the release branch.
Ok, separate clones would work here as well.
>> Downsides to a git repository backing multiple working directories, are:
>> - 3 copies of the git repository on disk, rather than just one
> Doesn't --separate-git-dir solve that problem?
I don't know. I have never used this.
Is this the experimental multiple working directories for one git
directory feature people were talking about earlier in the thread?
Or is this something else? It is in the main git documentation, so
presumably this is a mainline feature...?
Will using this option confuse other git tools?
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 9:53 ` Steinar Bang
@ 2014-03-21 10:17 ` Eli Zaretskii
2014-03-21 12:30 ` Steinar Bang
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 10:17 UTC (permalink / raw
To: Steinar Bang; +Cc: emacs-devel
> From: Steinar Bang <sb@dod.no>
> Date: Fri, 21 Mar 2014 10:53:18 +0100
>
> >>>>> Eli Zaretskii <eliz@gnu.org>:
>
> > Thanks. However, I cannot easily map this arrangement to what I had
> > in mind, namely, having a separate trunk and release branches, each
> > one having its working tree in a different directory. What am I
> > missing?
>
> Ok, so you want separate working directories of the official master and
> release branches?
Right.
> I have satisfied this requirement for myself, by simply having separate
> clones, something like this:
> cd ~/git
> git clone http://somewhere/emacs.git
> git clone --branch release-23.4 http://somewhere/emacs.git emacs-release-23.4
> git clone --branch release-24.0 http://somewhere/emacs.git emacs-release-24.0
Yes, that's the obvious possibility. I thought there were others.
Thanks.
> > As for feature branches, I think relatively short-lived ones will be
> > better off in the same directory as the trunk, because they aren't
> > expected to diverge too much, so having them co-located actually makes
> > a lot of sense and saves time.
>
> By "co-located", do you mean one .git directory serving multiple working
> directories?
No, I meant in the same working directory, using "git checkout" to
switch between branches.
> >> Downsides to a git repository backing multiple working directories, are:
> >> - 3 copies of the git repository on disk, rather than just one
>
> > Doesn't --separate-git-dir solve that problem?
>
> I don't know. I have never used this.
Andreas said this is not a solution.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 10:17 ` Eli Zaretskii
@ 2014-03-21 12:30 ` Steinar Bang
0 siblings, 0 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-21 12:30 UTC (permalink / raw
To: emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org>:
>> I have satisfied this requirement for myself, by simply having separate
>> clones, something like this:
>> cd ~/git
>> git clone http://somewhere/emacs.git
>> git clone --branch release-23.4 http://somewhere/emacs.git emacs-release-23.4
>> git clone --branch release-24.0 http://somewhere/emacs.git emacs-release-24.0
> Yes, that's the obvious possibility. I thought there were others.
All I've seen is the experimental feature mentioned earlier in the
thread (which I recommend against, based on my own experience with
earlier experimental features in git).
If space usage on your local disk is an issue, you can limit the clones
to just a single branch, but I don't think there's much to gain, since
the biggest part of the history will be shared anyway.
(And if you need to share branches between these clones that you don't
wish to push to the official emacs repo, that's what my local "remote"
setup earlier was for)
[snip!]
>> > Doesn't --separate-git-dir solve that problem?
>> I don't know. I have never used this.
> Andreas said this is not a solution.
I was kinda relieved to see that. I felt my entire understanding of git
slipping away from me...:-)
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 7:46 ` Eli Zaretskii
@ 2014-03-21 12:40 ` Stefan
2014-03-21 12:57 ` Steinar Bang
2014-03-21 16:08 ` Eli Zaretskii
0 siblings, 2 replies; 65+ messages in thread
From: Stefan @ 2014-03-21 12:40 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Steinar Bang, emacs-devel
> What bzrmerge.el does, when we merge a fix from the branch, is
> effectively a cherry-pick,
No, bzrmerge does not cherry pick in any sense of the word. It does
a merge. The only difference with "bzr merge" is that it does it with
more care, using hints from the commit messages to try and auto-resolve
some conflicts.
> I'm not sure this will work with git, btw.
There's nothing special in bzrmerge that should prevent it from working
in another VCS, so long as that VCS has a notion of "branch merge", basically.
E.g. I'm pretty sure we could have written a corresponding cvsmerge.el,
and AFAIK some other project has written something similar for svn.
Stefan
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 12:40 ` Stefan
@ 2014-03-21 12:57 ` Steinar Bang
2014-03-21 16:08 ` Eli Zaretskii
1 sibling, 0 replies; 65+ messages in thread
From: Steinar Bang @ 2014-03-21 12:57 UTC (permalink / raw
To: emacs-devel
>>>>> Stefan <monnier@iro.umontreal.ca>:
> There's nothing special in bzrmerge that should prevent it from
> working in another VCS, so long as that VCS has a notion of "branch
> merge", basically.
I would go so far as to say that the branch merge is THE main feature of
git.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 12:40 ` Stefan
2014-03-21 12:57 ` Steinar Bang
@ 2014-03-21 16:08 ` Eli Zaretskii
2014-03-21 17:02 ` David Kastrup
1 sibling, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 16:08 UTC (permalink / raw
To: Stefan; +Cc: sb, emacs-devel
> From: Stefan <monnier@iro.umontreal.ca>
> Cc: Steinar Bang <sb@dod.no>, emacs-devel@gnu.org
> Date: Fri, 21 Mar 2014 08:40:45 -0400
>
> > What bzrmerge.el does, when we merge a fix from the branch, is
> > effectively a cherry-pick,
>
> No, bzrmerge does not cherry pick in any sense of the word. It does
> a merge.
For crying out loud, Stefan, give me the benefit of the doubt that I
just _might_ know this!
I said "_effectively_ a cherry-pick".
> > I'm not sure this will work with git, btw.
>
> There's nothing special in bzrmerge that should prevent it from working
> in another VCS, so long as that VCS has a notion of "branch merge", basically.
In some ancient discussion Linus said that a commit that doesn't bring
in any diffs is "madness" and shouldn't exist. Or maybe I
misunderstood.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 16:08 ` Eli Zaretskii
@ 2014-03-21 17:02 ` David Kastrup
2014-03-21 18:35 ` Eli Zaretskii
0 siblings, 1 reply; 65+ messages in thread
From: David Kastrup @ 2014-03-21 17:02 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan <monnier@iro.umontreal.ca>
>> Cc: Steinar Bang <sb@dod.no>, emacs-devel@gnu.org
>> Date: Fri, 21 Mar 2014 08:40:45 -0400
>>
>> > What bzrmerge.el does, when we merge a fix from the branch, is
>> > effectively a cherry-pick,
>>
>> No, bzrmerge does not cherry pick in any sense of the word. It does
>> a merge.
>
> For crying out loud, Stefan, give me the benefit of the doubt that I
> just _might_ know this!
>
> I said "_effectively_ a cherry-pick".
>
>> > I'm not sure this will work with git, btw.
>>
>> There's nothing special in bzrmerge that should prevent it from working
>> in another VCS, so long as that VCS has a notion of "branch merge", basically.
>
> In some ancient discussion Linus said that a commit that doesn't bring
> in any diffs is "madness" and shouldn't exist. Or maybe I
> misunderstood.
You probably misunderstood. A merge commit introduces a change in
topology. There are even explicit merge strategies "theirs" and "ours"
that lead to a merge commit having a work tree matching one of its
parents.
--
David Kastrup
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 17:02 ` David Kastrup
@ 2014-03-21 18:35 ` Eli Zaretskii
2014-03-21 19:01 ` David Caldwell
0 siblings, 1 reply; 65+ messages in thread
From: Eli Zaretskii @ 2014-03-21 18:35 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
> From: David Kastrup <dak@gnu.org>
> Date: Fri, 21 Mar 2014 18:02:53 +0100
>
> > In some ancient discussion Linus said that a commit that doesn't bring
> > in any diffs is "madness" and shouldn't exist. Or maybe I
> > misunderstood.
>
> You probably misunderstood.
Quite likely. But maybe you will be kind enough to explain what Linus
meant in these two messages, when he said that an extra merge-commit
is wrong and has "zero semantic information in it"?
https://lists.ubuntu.com/archives/bazaar/2006q4/018265.html
https://lists.ubuntu.com/archives/bazaar/2006q4/018273.html
There's a definite difference between bzr and git that is alluded to
here, but what is it? (You may wish reading the surrounding messages
for context.)
Thanks.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-21 18:35 ` Eli Zaretskii
@ 2014-03-21 19:01 ` David Caldwell
0 siblings, 0 replies; 65+ messages in thread
From: David Caldwell @ 2014-03-21 19:01 UTC (permalink / raw
To: Eli Zaretskii, David Kastrup; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]
On 3/21/14, 11:35 AM, Eli Zaretskii wrote:
>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 21 Mar 2014 18:02:53 +0100
>>
>>> In some ancient discussion Linus said that a commit that doesn't bring
>>> in any diffs is "madness" and shouldn't exist. Or maybe I
>>> misunderstood.
>>
>> You probably misunderstood.
>
> Quite likely. But maybe you will be kind enough to explain what Linus
> meant in these two messages, when he said that an extra merge-commit
> is wrong and has "zero semantic information in it"?
>
> https://lists.ubuntu.com/archives/bazaar/2006q4/018265.html
> https://lists.ubuntu.com/archives/bazaar/2006q4/018273.html
He's saying that in the context of tracking a remote branch. He's saying
that if I'm pulling from your repo and I haven't made any changes, then
it's pretty rude of me to add random empty merges which only signify
when I happened to run the "pull" command. What I really want it to just
collect your changes and add them to my repo, using fast-forward merges
to move my branch to the latest commits.
In particular, I don't believe he is saying anything about merging
across release/master/feature branches. In fact, I've seen many people
advocate "git merge --no-ff" when merging important branches together.
-David
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: State of the repository conversion
2014-03-19 19:17 ` Eli Zaretskii
2014-03-20 0:08 ` Stephen J. Turnbull
@ 2014-03-22 7:18 ` Stefan-W. Hahn
1 sibling, 0 replies; 65+ messages in thread
From: Stefan-W. Hahn @ 2014-03-22 7:18 UTC (permalink / raw
To: Eli Zaretskii; +Cc: esr, emacs-devel
Mail von Eli Zaretskii, Wed, 19 Mar 2014 at 21:17:52 +0200:
Good morning,
> It is better to draw upon the knowhow and experience of veteran git
> users among us to identify in advance the preferred workflows, discuss
> them, and make decisions blessed by the Powers That Be. We have ample
I haven't seen any hint to "note from the maintainer" [1] and the "what's
cooking" [2] from the git maintainer J. Hamano. Perhaps this can help in the
discussions.
(He is maintaining his scripts in the todo branch in the git repository.)
[1] http://marc.info/?l=git&m=136320640722607&w=2
[2] http://marc.info/?l=git&m=139534976411660&w=2
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2014-03-22 7:18 UTC | newest]
Thread overview: 65+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-19 17:51 State of the repository conversion Eric S. Raymond
2014-03-19 18:14 ` Paul Eggert
2014-03-19 18:31 ` Eli Zaretskii
2014-03-19 18:54 ` Eric S. Raymond
2014-03-19 19:17 ` Eli Zaretskii
2014-03-20 0:08 ` Stephen J. Turnbull
2014-03-20 0:32 ` Eric S. Raymond
2014-03-20 1:01 ` Óscar Fuentes
2014-03-20 3:55 ` Eli Zaretskii
2014-03-20 4:09 ` Óscar Fuentes
2014-03-20 7:06 ` David Engster
2014-03-20 7:49 ` Steinar Bang
2014-03-20 16:35 ` Eli Zaretskii
2014-03-20 12:42 ` Óscar Fuentes
2014-03-20 14:03 ` Stefan
2014-03-20 15:09 ` Óscar Fuentes
2014-03-20 16:13 ` Eli Zaretskii
2014-03-20 20:23 ` Steinar Bang
2014-03-20 4:04 ` Eli Zaretskii
2014-03-20 4:25 ` Óscar Fuentes
2014-03-20 4:59 ` Stefan
2014-03-20 7:36 ` Steinar Bang
2014-03-20 7:48 ` Florian Weimer
2014-03-20 8:07 ` Steinar Bang
2014-03-20 16:19 ` Eli Zaretskii
2014-03-20 18:02 ` Stefan
2014-03-20 18:09 ` David Kastrup
2014-03-20 20:35 ` Steinar Bang
2014-03-20 18:15 ` Eli Zaretskii
2014-03-20 18:44 ` Stefan
2014-03-20 20:17 ` Eli Zaretskii
2014-03-20 20:30 ` Steinar Bang
2014-03-20 20:39 ` Eli Zaretskii
2014-03-20 21:10 ` Steinar Bang
2014-03-21 7:46 ` Eli Zaretskii
2014-03-21 12:40 ` Stefan
2014-03-21 12:57 ` Steinar Bang
2014-03-21 16:08 ` Eli Zaretskii
2014-03-21 17:02 ` David Kastrup
2014-03-21 18:35 ` Eli Zaretskii
2014-03-21 19:01 ` David Caldwell
2014-03-20 16:17 ` Eli Zaretskii
2014-03-20 19:28 ` Óscar Fuentes
2014-03-20 20:19 ` Eli Zaretskii
2014-03-20 20:31 ` Óscar Fuentes
2014-03-20 20:40 ` Eli Zaretskii
2014-03-20 20:46 ` Óscar Fuentes
2014-03-21 3:02 ` Stephen J. Turnbull
2014-03-21 8:01 ` Eli Zaretskii
2014-03-22 7:18 ` Stefan-W. Hahn
2014-03-19 21:25 ` Andreas Schwab
2014-03-20 3:49 ` Eli Zaretskii
2014-03-20 7:46 ` Steinar Bang
2014-03-20 16:09 ` Glenn Morris
2014-03-20 20:17 ` Steinar Bang
2014-03-20 20:21 ` Eli Zaretskii
2014-03-20 16:33 ` Eli Zaretskii
2014-03-20 21:00 ` Steinar Bang
2014-03-21 9:08 ` Eli Zaretskii
2014-03-21 9:38 ` Andreas Schwab
2014-03-21 9:53 ` Steinar Bang
2014-03-21 10:17 ` Eli Zaretskii
2014-03-21 12:30 ` Steinar Bang
2014-03-20 18:19 ` Andreas Schwab
2014-03-20 18:27 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.