Was looking through some notes I took while reading Pro git book and had
the following written down...not sure if it’s of help but figured I’d pass
on just in case...
———
The difference between merges and rebase involved the history and how the
changes are applied.
In this case a patch[delta]
On Tue, Nov 19, 2019 at 12:53 AM Laszlo Kishalmi
wrote:
> I would like to defend the squashed commits.
> It is much easier to handle cherry-picks and other merges for PR-s
Since the above is a commonly expressed justification for destructive
history operations:
git cherry-pick -x -m1
I cannot agree more. I mostly work on legacy java projects. A good
commit history helps understanding how a project evolved and why some
things are handled how they're handled.
But tbh these disturbing clutter commits are only one part of the story.
What developers sometimes don't see that
On 11/18/19 11:39 AM, Emilian Bold wrote:
$ git fetch
$ git reset --hard / # Destructive!
I get it now. Thank you, Emilian. It's an interesting problem only if I
were also making changes to the code while testing, which I'm not. More
details here:
How do I recover/resynchronise after
Hi,
Am Mittwoch, den 20.11.2019, 15:31 -0500 schrieb Tim Boudreau:
> On Wed, Nov 20, 2019 at 2:36 PM Benjamin Asbach wrote:
>
> > So why
> > having these information in project history when it does not deliver any
> > additional value?
> >
>
> Because the point of developing software is to
On Wed, Nov 20, 2019 at 2:36 PM Benjamin Asbach wrote:
> So why
> having these information in project history when it does not deliver any
> additional value?
>
Because the point of developing software is to develop software, not please
hypothetical future historians.
-Tim
I don't want to argue for squashed commits but for changing the commit
history of pull request branches.
From my point of view a commit should provide additional information
about what changed. Having commits based on a code review like "fixed
typo", "added review comment" there's no additional
On 11/18/19 9:52 PM, Laszlo Kishalmi wrote:
As a former release manager I would like to defend the squashed commits.
Just for reference, OpenJDK projects go one step further and end up with
half the commits in their history as NetBeans, with a much simpler
history graph. I explain below.
On 11/18/19 12:20 PM, Emilian Bold wrote:
You are angry. But you did ask if you are doing something wrong and
re-downloading the entire repository for 1 force modified commit is
not the way to go.
You're right. I'm sorry, Emilian. I was wrong to disregard your honest
answer and use it just to
Hi, I'm the author of the PR in question. My intention of using `git
rebase` was to make review easier by splitting the changes into two
individually meaningful commits. It's less work to just push the
individual commits, so I'm fine doing that as well of course.
Regarding the rebase / merge
I really don't see the point of squashing commits. I know, everybody would
like to look like they write perfect, concise, error-free code the first
time. But nobody does - and that seems to be the primary purpose. If you
want to see the set of changes that implement a feature, it's not that
On Mon, 18 Nov 2019, 20:07 John Neffenger, wrote:
> Or we could just stop doing forced pushes on pull requests under review.
> I even think that's what our contributor guidelines suggest. Then I can
> run "git pull" after each change, and I'm done.
>
They also say fix-up changes should be
You are angry. But you did ask if you are doing something wrong and
re-downloading the entire repository for 1 force modified commit is
not the way to go. Just have to figure out the magical git incantation
that works.
Not sure what the guidelines say, but force push does happen and it
would be
On 11/18/19 11:39 AM, Emilian Bold wrote:
Or you could checkout HEAD~3 or some ancestor (which would be
netbeans:master) and then fetch the PR branch and re-checkout?
Or we could just stop doing forced pushes on pull requests under review.
I even think that's what our contributor guidelines
I think the problem is your local git repository is missing
apache/netbeans:master? The only branch you have is the PR branch.
Even so, I think something like
$ git fetch
$ git reset --hard / # Destructive!
should allow you to work.
Or you could checkout HEAD~3 or some ancestor (which would
I'm continuing on the mailing list a discussion that started here:
Next time, though, could you add incremental commits ...
https://github.com/apache/netbeans/pull/1548#issuecomment-554833121
The Contributor Guidelines [1] state, "After submission (and certainly
after someone starts reviewing
16 matches
Mail list logo
