2017-02-27 10:02 GMT+01:00 Christian Borntraeger <borntrae...@de.ibm.com>:
> For a pull like approach I would suggest to either
> a: do not this step (Linux style git handling)
> b: use git pull --rebase (flat history style)
>
>
>> build + test
>> git commit
>> [git push - if you have write access]
>
> If we give write accesses, then I suggest to use the --rebase variant.
> Not sure what git server is running, but git-o-lite for example allows
> to reject non-fast-forward merges, so that we do not fill the
> history with single patch merge commits.
> Merge commits can be very useful though, if the merge commit contains
> a description of a multititude of patches.
Are you referring here to the git merge model?
We had a discussion with Mark Wielaard previously which git model to use:
----------------------
> > And given the git model we should also
> > decide whether we want a merge model or that we ask people to only push
> > rebased branches at the top of the tree. The merge model is more
> > flexible and more accurately shows the development history if features
> > get developed/integrated in parallel. But having just one straight
> > linear commit history often helps with bisecting and precisely
> > pin-pointing when bugs were introduced. I know sourceware can setup
> > commit/push hooks to make sure one or the other model is followed.
>
> I think the second one reflects what we have been using in SVN.
> Any reason to change that other than that it's more GIT'ish?
I think that is a fine reason and probably works out nicely when
multiple people push to the same repository. The "more GIT'sh" way is
(IMHO) slightly nicer when there is a single person that pushes to a
repo. Merges often represent work others did and show where they started
off and where they integrated their work. But this can (IMHO) get
slightly messy if multiple people push to the same repo.
---------------------
So we decided to stick with existing (SVN) workflow which translates to
"rebased branches at the top of the tree".
Our valgrind.git config will have (after the final migration happens):
[receive]
denyNonFastforwards = true
So based on this information, could you suggest different git commands
(with some reasoning) than initially outlined by me?
I.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
