On 27 July 2013 23:31, Fred Cooke wrote:
> Yes, I've been guilty of it from time to time, as most have been,
> especially years ago ;-)
>
> Did you find any of the above useful? I hope so :-)
I don't know (yet), but I do know that it would be a lot easier to
reference as a web (e.g. Wiki) page ;-
Yes, I've been guilty of it from time to time, as most have been,
especially years ago ;-)
Did you find any of the above useful? I hope so :-)
Coincidental-Fred.
On Sun, Jul 28, 2013 at 12:26 AM, Barrie Treloar wrote:
> On 28 July 2013 07:45, Fred Cooke wrote:
> > [1] http://pragprog.com/the-
On 28 July 2013 07:45, Fred Cooke wrote:
> [1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence
Ahh I see they are using you as an example :)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additi
This ought to keep you out of trouble if you're a downstream user:
NEVER git pull
NEVER git merge
ALWAYS git fetch
ALWAYS git merge --ff-only /
ALWAYS git rebase /
[image: http://stuff.fredcooke.com/IDontAlwaysMergeButWhenIDoI.jpg]
rebase -i is your friend if used appropriately.
As mentioned,
I don't think we have many things on Maven project side and really few
things on apache side
About the workflow to use with git you have the well known successful
branching model
http://nvie.com/posts/a-successful-git-branching-model/
At work I adapted / completed it for our internal usage (maybe w
On 28 July 2013 00:24, Kristian Rosenvold wrote:
> It's ok if not pushed, but I think it should be made a lot clearer in the
> guide.
Do we have a "how to" guide for using Git?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.ap
Not perfect but what you could do is to add a git note on this commit.
-
Arnaud
Le 27 juil. 2013 à 13:29, "Hervé BOUTEMY" a écrit :
> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
>
> I'm not a git blackbelt: can the comment be updated to add the classical
> [MNG-5499
SVN's 1 level commit vs. GIT's 2+1 level commit: I'd say it's a tie.
Let me be a bit pessimistic, but I don't think that'll work here with the
Apache Maven project due to the number of active committers. It would slow
things down even more.
Robert
Op Sat, 27 Jul 2013 17:04:18 +0200 schreef
Is there a problem you're trying to fix or have you just been taking too
many vitamin pills ?
Kristian
2013/7/27 Fred Cooke :
> :-) Tui, yeah right. [1][2]
>
> Or work on branches, pushed publicly with meaningful names like
> attempt-fix-of-site-behaviour or whatever and seek peer review before
:-) Tui, yeah right. [1][2]
Or work on branches, pushed publicly with meaningful names like
attempt-fix-of-site-behaviour or whatever and seek peer review before
rebasing and applying to master. IMO this should apply to Maven "gods" as
much to any other committer. No one is incapable of making mis
It's ok if not pushed, but I think it should be made a lot clearer in the guide.
We could install commit hooks into the repo that enforce specific
patterns on commits,
like [\d].* *or* starts with an "o ". But then again the "o " seems to
be under attack too :)
Kristian
2013/7/27 Hervé BOUTEMY
so http://maven.apache.org/developers/conventions/git.html#Edit_Commit_Message
is wrong? or ok only if not pushed?
Le samedi 27 juillet 2013 15:36:03 Arnaud Héritier a écrit :
> At Apache it is forbidden to rewrite the history of the master branch.
> Which isn't so bad.
>
> -
> Arnaud
>
so, this time:
svn +1
git -1
:)
more seriously: if we cannot fix comments later, we'll need to be more careful
when committing
Regards,
Hervé
Le samedi 27 juillet 2013 16:27:50 Fred Cooke a écrit :
> How did I know you'd say that? You think I didn't know you could do that?
> LOL :-p
>
> Can'
How did I know you'd say that? You think I didn't know you could do that?
LOL :-p
Can't do it without bad config and/or administrator privileges. There,
fixed.
Fred.
On Sat, Jul 27, 2013 at 4:22 PM, Robert Scholte wrote:
> "With SVN changing a bad comment wasn't even possible"
>
> Yes it is, I'
"With SVN changing a bad comment wasn't even possible"
Yes it is, I've done it very often:
http://subversion.apache.org/faq.html#change-log-msg
(although I use the GUI for it)
Robert
Op Sat, 27 Jul 2013 16:07:09 +0200 schreef Fred Cooke
:
Good practice is to work on a branch anyway, then y
Good practice is to work on a branch anyway, then you're free to do
whatever you wish. I have ~30 branches in my private copy of my project
right now. When one matures I rebase it onto the latest public, then
publish it. Then I rebase the others periodically up onto the latest public
too. Wash rins
I'm actually kind of surprised. I'm learning my co-workers that comments
are very important. With a buildserver it has become very easy to have an
overview of the latest commits and understand what broke the build.
Writing good comments should help everybody to understand why a commit is
done
On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke wrote:
> On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:
>
>> At Apache it is forbidden to rewrite the history of the master branch.
>> Which isn't so bad.
>>
>
> Ahh, this is a very sound policy! Someone is switched on! :-)
Yes, very good!
>>
My most humble apologies to Herve for leading you astray! I was unaware of
the policy on this. I hope that I didn't inadvertently cause any harm.
On Sat, Jul 27, 2013 at 3:38 PM, Fred Cooke wrote:
> On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:
>
>> At Apache it is forbidden to rewrite
On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:
> At Apache it is forbidden to rewrite the history of the master branch.
> Which isn't so bad.
>
Ahh, this is a very sound policy! Someone is switched on! :-)
>
> -
> Arnaud
>
> Le 27 juil. 2013 à 15:19, Jeff Jensen
> a écrit :
>
When you rewrite history of something that has been already pushed, you
need to push and add --force to rewrite history on the remote repo.
Of course, as Fred mentioned, this isn't recommended for branches that have
been pulled by other people, because it will mess their next pull.
Vincent
2013
At Apache it is forbidden to rewrite the history of the master branch.
Which isn't so bad.
-
Arnaud
Le 27 juil. 2013 à 15:19, Jeff Jensen
a écrit :
> That message indicates you need to git pull first. Even though you
> may already have done so and no one else has pushed since, this usu
No, you do NOT want to do a git pull, almost ever. You want to do a git
fetch, ensure you're not going to destroy other's good work, then if you're
just replacing same with same, force push. This is a risky operation for an
upstream to do as I mentioned above in my amendment. I would recommend
igno
That message indicates you need to git pull first. Even though you
may already have done so and no one else has pushed since, this usually
happens when modifying a commit that has been pushed/shared.
On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY wrote:
> the last 2 commits are to be amended: ls
the last 2 commits are to be amended: lst one for MNG-5499, previous one for
MNG-5495
I tried git commit --amend -m "[MNG-5499]..." for the last one, but when I git
push, I get
To https://git-wip-us.apache.org/repos/asf/maven.git
! [rejected]master -> master (non-fast-forward)
error: f
Of course, if anyone is working down stream of this, they will hate you,
and it should be left as is.
On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke wrote:
> Yes, easily, if it's the HEAD just do a --amend on it and update it
> yourself, Jason's name will be retained. If it's not HEAD then do rebas
Yes, easily, if it's the HEAD just do a --amend on it and update it
yourself, Jason's name will be retained. If it's not HEAD then do rebase -i
then mark the one of interest for
comment edit and proceed.
On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY wrote:
> IIUC, this is a fix to https://jira.
IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
I'm not a git blackbelt: can the comment be updated to add the classical
[MNG-5499]?
(and next time not be forgotten from initial comment :) )
I'm adding a reference to the commit in the Jira issue
Regards,
Hervé
Le samedi 27 ju
28 matches
Mail list logo
